[kabdib]

If you changed TCP sufficiently to make it a real-time protocol suitable for gaming, it wouldn't be TCP any more. Reliable streaming and real-time packet delivery are two completely different animals.

I would argue that bandwidth-sharing fairness with stuff going over UDP is easy: Just start dropping packets when pipes get full.

Most updates are going to be pretty small. It's not like game developers want the user experience of their titles to be bad, after all.

[xir78]

It’s not easy to share the bandwidth fairly, it’s taken decades of research and it continues to be improved in TCP.

You’re not consindering a server, the bandwidth is very high on the backend and does saturate links. You run many servers per physical or virtual machine due to cost, so you can have 1000s if players connected over a single network path.

[kabdib]

... which is why you provision servers and design your software and network architecture to take the demand (latency, bandwidth, etc.) into account. Data rates for online games are pretty predictable. A 10 Gbit fiber connection to a racked server doesn't cost that much.

At the datacenter level you're making sure that the bandwidth you bought from providers is sufficient (and ideally, redundant), and that you can shift load from one area to another if necessary. You can buy this capability from AWS or Azure, or build it yourself in many different ways.