TCP or UDP for a multiplayer game?

Question

This is a question I see a lot. Most people say UDP is always better for real-time games than TCP. My understanding is that TCP tries to re-send packets over and over til the other side gets them whereas UDP doesn't care.

Most of the things I've read is that UDP is a must for any realtime game and TCP is terrible. But the thing is, most people seem to implement some form of TCP on top of UDP anyways. And I've also heard that the difference between the two is negligible given that we're not in the 80s anymore and the internet is now pretty fast and reliable.

Is my general understanding here wrong? Can someone clear this up for me?

`internet is now pretty fast and reliable` No, it's not. The *bandwidth* has dramatically increased, yes, but *latency* is still quite high. With pure TCP you need the server tick time to be more than the max affordable latency, unless you do packet squishing - which is best done at the client via UDP. The problem is that some info in a game needs to be reliable, while some other needs to be fast. Custom protocols on top of UDP allow for that, as well as a bunch of proprietary ones that give you everything you need in a nice package. — Ordous, Feb 14 '17 at 18:34
They don't exactly implement TCP over UDP. There are some features that TCP offer which are desirable and that are implemented on top of UDP. A major point of using UDP is that if you send a packet containing the world state at time `t0` that is never received, then you send the new world state at time `t1`, you don't have to wait until the client actually receive the first package, which is already obsolete. — Vincent Savard, Feb 14 '17 at 18:51
Also be aware that UDP is prone to IP spoofing which could make your server open to DDoS attacks if that is a concern. You could avoid that by having a "control" TCP connection that sends the clients IP address and other details to the server which then accepts UDP packets from the "authenticated" address. Also you may have to implement your own encryption layer as there are no open standards for that over UDP. — ARau, Feb 14 '17 at 19:21
@ARau IPsec does IP packet encryption and is an open standard. — Armen Michaeli, Dec 02 '18 at 01:13
@amn IPSec is more than just packet encryption, it creates an encrypted tunnel a.k.a VPN tunnel over which UDP or TCP packets can be sent. It is possible to have a IPSec connection over UDP but this would require a VPN server and would cause additional latency which is not desirable for multiplayer gaming. — ARau, Dec 03 '18 at 02:56
@ARau IPsec can perfectly well be used for IP packet encryption, without VPNs or whatever else people usually associate with it. And that's what it does in transport mode. Since it is an open standard, your statement "there are no open standards for that over UDP" is simply incorrect. — Armen Michaeli, Dec 03 '18 at 09:14
@amn You are right and I stand corrected about my statement about there being no open standards for encryption over UDP. With QUIC (see my comment below on the next answer) which supports TLS over UDP which is set become the HTTP/3 standard, it could be a good alternative. As far as using IPSec for IP packet encryption without VPNs in transport mode, do you have any practical implementations/examples open source or otherwise that are currently doing this? Any libraries and code samples? — ARau, Dec 03 '18 at 18:10

score 13 · Accepted Answer · answered Feb 14 '17 at 18:41

Depends on if you're talking about peer-to-peer, client/server with the users running the server, or client/server with a data center running the server. Only in the latter-most case is the internet really fast and reliable. Your users' computers are not guaranteed to be fast, and certainly won't be reliable.

UDP allows you greater control over the sort of TCP-like implementation you're making. It gives you greater flexibility to execute packets out of order, discard packets that you consider unnecessary while retrying packets you consider important, that sort of thing. But this should only be done if needed and if you have the necessary expertise.

If you can do without that flexibility, TCP works well enough and saves you a whole lot of time. Even professional studios (like one I worked at) use TCP if they don't absolutely need UDP, and they have people dedicated to network programming.

I'd also suggest that "for what" matters - e.g. for an in-game chat system I wouldn't even consider UDP. The other thing I'd consider (at least for "client server") is how efficiently server can handle traffic - modern NICs have a lot of built-in "offloading" stuff for TCP (splitting and merging packets, sorting packets into streams, etc) that are designed to reduce CPU overhead, and most of that can't work for UDP. — Brendan, Feb 15 '17 at 14:42
Things may change now that QUIC (https://en.wikipedia.org/wiki/QUIC) which will be part of HTTP/3 which uses UDP and is encrypted using TLS by default. It will take some time for this to be widely available and is something to look forward to. More details on some issues that need to be handled here https://blog.cloudflare.com/the-road-to-quic/ — ARau, Dec 03 '18 at 03:15

score 4 · Answer 2 · edited Sep 25 '19 at 15:37

It would be an assumption to say "Internet is now pretty fast and reliable" as @Ordous pointed out, and a dangerous one too.

The reason why UDP+custom protocol for delivery-critical packets does magic on most games is that, there are times when it could be "okay" if you lose some packet (just for. e.g. secondary non-critical events to complete game play), there are also times where its "not at all okay" to lose some data for e.g cursor movement etc. (I don't do game development for a living so pardon my vague-ish examples)

UDP doesn't waste time in pushing them again and again, by default.

And, many games incidentally seem to have the "okay to lose sometimes" packets more than "always need to deliver without fail" packets. Hence making a natural fit for this task.

All that was needed on UDP was to use a custom protocol that just helps deliver the "always need to deliver without fail" packets properly, leaving the rest of game data to the mercy of the network connection.

Now deciding on what kind of traffic makes up most of YOUR data to be transmitted across will help you decide better.

The point against TCP would be that time spent on retries could rather be spent on sending packets that matter NOW.

There is also a chance that if there is any issue during transmission, TCP could cascade to a more broken down game-play scenario for the user, spoiling their experience compared to UDP+Custom Stack (This last part is just hunch. I will leave this to other experts here to comment on this. Would love to learn about possibilities of this scenario).

TCP or UDP for a multiplayer game?

2 Answers2