Back in the day, TCP connections over dialup/ISDN/slow broadband resulted in choppy, laggy games because a single dropped packet resulted in a resync. That meant a lot of game developers had to implement their own reliability layer on top of UDP, or they used UDP for messages that could be dropped or received out of order, and used a parallel TCP connection for information that must be reliable.

Given the average user has faster network connections now, can a real time game such as an FPS give good performance over a TCP connection?


I would say no. Spacial information of game objects need to be as fast as possible, and for that it's better to use UDP, because reliability is not 100% crutial. Even on modern connections, UDP is still slow enough that you have to make some special considerations for interpolation and such. Even just in terms of the amount of data transferred, TCP would add significant overhead to this.

However, TCP is perfectly acceptable for non-realtime things, such as multiplayer negotiation, chat messages, score updates, etc.

  • 7
    \$\begingroup\$ Sean is pretty much on the money. If, by chance, you are developing a game in C#/.NET (you know you want to!), I have found the Lidgren Network Library (code.google.com/p/lidgren-library-network) to be a pretty good choice. It even provides ordered, reliable messaging over UDP, should you need it. \$\endgroup\$ – Mike Strobel Jul 16 '10 at 15:46
  • 2
    \$\begingroup\$ It's unwise to mix both TCP and UDP; as a result of the way TCP performs flow control, it can induce packet loss. (source:isoc.org/INET97/proceedings/F3/F3_1.HTM) \$\endgroup\$ – Jason Kozak Jul 16 '10 at 23:39
  • 4
    \$\begingroup\$ It's also important to keep in mind that in some cases your end users will be sitting behind ISPs that block UDP traffic, have router setups that prevent UDP traffic, or otherwise are in a situation where using UDP is less than ideal. In those cases, if your game can support it, being able to fall back to TCP communication is quite handy. \$\endgroup\$ – Charles Ellis Jul 19 '10 at 21:54
  • \$\begingroup\$ another + point for UD is that its naturally packet orientated, you have to emulate this in TCP if needed (boilderplatecode), sadly the more modern protocols are not supported by windows (this sucks) \$\endgroup\$ – Quonux Apr 9 '13 at 18:20

As Flash doesn't support UDP, by looking at multiplayer Flash games you can get a pretty good idea of what's possible with TCP/IP and what isn't. Basically you can create real time games, as long as they don't rely on lightning-fast response times. A couple of examples:



If you have the option of using UDP, you really should, but with Flash you sadly don't get that option.


It depends.

Games like World of Warcraft use TCP for their communication, because you circumvent many problems by using it. There may be a higher ping as a result, but for many games, this is acceptable. You need to do spatial interpolation even when you use UDP as your protocol.

  • 1
    \$\begingroup\$ It's not just ping. There's a reason why there is no player-player collisions in WoW. It would be too hard to do well. WoW can use TCP because where you are standing doesn't matter much. Targeting and attacking does not depend on the real position of the monster or enemy player. If you care about these things, then TCP will hurt the play experience. \$\endgroup\$ – Nuoji Aug 14 '13 at 15:40

If your client/server architecture is clean, the transport layer (almost) doesn't matter.

TCP has some drawbacks, but these are easily cirumvented.

So yes, TCP and a brain is all you need.

With common network setups (proxies, firewalls, etc) today UDP is pretty much useless for all but local (read: LAN) games.

  • 7
    \$\begingroup\$ If you downvote, please leave a comment why. We use TCP and never had a single issue with it. \$\endgroup\$ – Andreas Jul 22 '10 at 14:58
  • 3
    \$\begingroup\$ I fail to see the relevance of common network setups in this. Firewalls generally interfere with hosting servers only, but even then regardless of protocol, whereas proxies actually increase the risk of delayed or dropped packets, making UDP far more useful than it would be on a local network. UDP's drawbacks can largely be circumvented by doing integrity checks yourself, but you can't take features out of TCP to make it faster. \$\endgroup\$ – Marcks Thomas Jul 17 '12 at 9:36
  • 1
    \$\begingroup\$ You need to mention Nagles. I always forget that's the root cause why TCP is evil (Nagle's buffers packets at client/server, basically "withholding" them from your game and introducing additional delay). \$\endgroup\$ – bobobobo Apr 22 '13 at 19:59
  • \$\begingroup\$ There several reasons why you should use UDP instead of TCP if latency is a concern. If you don't care about latency and/or you're able to do enough client side prediction, then TCP can be enough. In the case of real time games. Forget TCP. \$\endgroup\$ – Nuoji Aug 14 '13 at 15:36

Its perfectly acceptable to use TCP instead of UDP - if you turn off the Nagle's algorithm.

Once you turn off Nagle, you have most of the speed of UDP and will be fully able to make a twitch reaction game. Indeed, I have made such a game using TCP in Flash:


Hope that helps!

  • \$\begingroup\$ Non-operational app at your link, sir. \$\endgroup\$ – Engineer Feb 26 '14 at 7:49
  • \$\begingroup\$ Link completely roted, sir. I get an Apache server test. \$\endgroup\$ – Gustavo Maciel Jun 5 '16 at 2:25

For FPS games we always use UDP. Especially if you are doing a twitch shooter where pings matter.


It depends on the kind of game.

Some games such as RTS, play much better over TCP and typically use TCP all the time.

The real problem with TCP is that if you get packet loss - even a small amount - then the connection "stalls" until retransmission happens. The OS can't deliver out-of-order data to the application (this breaks TCP's guarantees, but also, TCP does not show the application frame boundaries). The connection stall means that late data subsequently arrive. But in a (e.g.) FPS game, out-of-date data are useless.

With UDP, the application gets to choose what it does with late or out-of-order data. It can (and for a game such as FPS, usually does) ignore old data and just take the latest ones. An occasional lost packet doesn't delay subsequent packets at all. If a delayed packet eventually arrives, it can be ignored by the game.

  • \$\begingroup\$ Note that your implementation will need to handle the aspect of discarding delayed packets, as UDP will treat it as a datagram received. \$\endgroup\$ – Guvante Aug 15 '14 at 20:37

Don't just accept a straight "yes or no cuz I said so" type answer here as you may be opening up yourself to having to fight a bunch of problems with UDP that actually you don't need to face.

None of the other answers here state the obvious way to prove this.

Take some simple facts

  • An IP header is 20 bytes no matter what protocol you use.
  • UDP headers are 4 bytes
  • TCP headers are 20 bytes

So each time you send a message of 1 byte down the line you have actually sent either 25 or 41 bytes depending on protocol assuming an IP header is also needed.


My advice

Take your situation where you need client server interaction, estimate the number of clients then do the math based on the data you actually send between the 2.

An Example

Lets say I send 10 messages that are 1 byte each per update in my game and i'm updating around 60 fps so I need to send 60 * 10 = 600 bytes per second of actual message data + the relevant headers.

Now depending on the game I could send that all as a single message so my overhead from the TCP layer is just 40 bytes (effectively a cost over UDP of 20 bytes per second), not having that overhead is a potential cost of 600 bytes (because I may have to resend the whole message stream).

If however it's vitally important that every message be sent on its own the very instant its ready to be sent, I have 600 messages (also 600 bytes) + 40 * 600 = 24k worth of TCP overhead or ~14k of UDP overhead per second + 600 bytes of message data.

Again, we ask the questions, how vital are those messages, how frequent are they, and can they be batched up in some way to reduce the overheads?

That's just based on a bunch of single byte messages, typically you would do something very different but without knowing the raw data being sent its hard to prove either way if TCP is a better fit to your situation than UDP.

So, will it work?

Well, if you have a typical fps, and position is important (to avoid cheating or incorrect decisions), you need to know that your network stream is realiable, but 32 players each streaming that 24k + message bytes back and forth (so 768KB/s + messages) ... that's about a 10mb/s broadband line just for individual headers based on sending at least 1 message per frame from each client to all the other clients via a server.

You obviously won't code your server and client to work that way and the message sizes are very likely to be a lot bigger and probably a bit less frequent than 1 byte per frame in most situations so it's hard to say without seeing a real world "this is the data I need to send" example.

My case

I have made the call in my case that its a reasonable overhead but that's based on how I build my message streams so I don't have huge overheads compared to some designs.

TCP works fine and I have a scaleable MMO server and client framework but I don't need to stream lots of data ever frame or lots of small packets because I can batch my calls.

for others: TCP just won't do, and they can only use UDP but have to accept that it won't give them assurances about what they get (ordering / arrival guarantee).

Other considerations

Many poorly coded game engines handle everything on the main thread on the cpu so the cpu is often only given a very small amount of time to handle networking code, a decent implementation of both the serve and the client would be entirely async and possibly push and pull messages in batches.

There are some good networking libraries out there but as seen here, many seem to have an opinion that UDP is "just better", well factor in your own needs first and that may not be the case, and finding a library that doesn't factor in things the way you do may result in a poorly coded TCP setup in comparison to the UDP variant in the same lib (i'm just saying i've seen this, and load tests have proven it).

Build something first a technical base of the data you want to be sending and test it then do the math to scale it up, worst case load test it by deploying to a cloud and have 50 computers run a test client to see if it can handle your limit of 32 players per game (or whatever limits you may have).


I don't think so... Games where data transfer is very frequent (on mouse-move or key-down), should use UDP. It'll lag even on LAN if TCP is used.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.