Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
I know that UDP is usually recommended for real-time multiplayer games with high data usage.
Most articles are serval years old, and since ~80% of all data transmitted on the internet is TCP, a lot of optimization must have been done for TCP.
This make me wonder: is UDP still superior in terms of speed and latency? Could recent TCP optimizations have made TCP perform better than UDP?
No, UDP is still superior in terms of performance latency, and will always be faster, because of the philosophy of the 2 protocols - assuming your communication data was designed with UDP or any other lossy communication in mind.
TCP creates an abstraction in which all network packets arrive, and they arrive in the exact order in which they were sent. To implement such an abstraction on a lossy channel, it must implement retransmissions and timeouts, which consume time. If you send 2 updates on TCP, and a packet of the first update gets lost, you will not see the second update until:
It doesn't matter how fast this is done in TCP, because with UDP you simply discard the first update and use the second, newer one, right now. Unlike TCP, UDP does not guarantee that all packets arrive and it does not guarantee that they arrive in order.
This requires you to send the right kind of data, and design your communication in such a way that losing data is acceptable.
If you have data where every packet must arrive, and the packets must be processed by your game in the order they were sent, then UDP will not be faster. In fact using UDP in this case would likely be slower because you're reconstructing TCP and implementing it by means of UDP in which case you might as well use TCP.
EDIT - Adding some additional information to incorporate/address some of the comments:
Normally, the packet loss rate on Ethernet is very low, but it becomes much higher once WiFi is involved or if the user has an upload/download in progress. Let's assume we have a perfectly uniform packet loss of 0.01% (one way, not round-trip). On a first person shooter, clients should send updates whenever something happens, such as when the mouse cursor turns the player, which happens about 20 times per second. They could also send updates per frame or on a fixed interval, which would be 60-120 updates per second. Since these updates get sent at different times, they will/should be sent in one packet per update. On a 16 player game, all 16 players send these 20-120 packets per second to the server, resulting in a total of 320-1920 packets per second. With our packet loss rate of 0.01%, we expect to lose a packet every 5.2-31.25 seconds. In this example we ignore the packets sent from the server to the players for simplicity.
On every packet we receive after the lost packet, we'll send a DupAck, and after the 3rd DupAck the sender will retransmit the lost packet. So the time TCP requires to initiate the retransmit is 3 packets, plus the time it takes for the last DupAck to arrive at the sender. Then we need to wait for the retransmission to arrive, so in total we wait 3 packets + 1 roundtrip latency. The roundtrip latency is typically 0-1 ms on a local network and 50-200 ms on the internet. 3 packets will typically arrive in 25 ms if we send 120 packets per second, and in 150ms if we send 20 packets per second.
In contrast, with UDP we recover from a lost packet as soon as we get the next packet, so we lose 8.3 ms if we send 120 packets per second, and 50 ms if we send 20 packets per second.
With TCP things get messier if we also need to consider Nagle (if the developer forgets to turn off send coalescing, or can't disable delayed ACK), network congestion avoidance, or if packet loss is bad enough that we have to account for multiple packet losses (including lost Ack and DupAck). With UDP we can easily write faster code because we quite simply don't care about being a good network citizen like TCP does.
We agree upon both TCP and UDP being protocols built on top of IP, don't we? IP specifies how messages are delivered across the internet, but nothing is about the messages structure, format. Here come TCP and UDP protocols. They use IP properties, but let the programmer focus on the message exchange without worrying about the lower layers of net communication. And that's great, because dealing with analogic signals in wires directly would be kind of painful.
TCP provides a set of functions to send and receive messages. It divides our data into small packets for ourselves and send them across the network. All we are asked is a port to use for the net socket, and the actual message we want to send. Also, it's reliable, meaning if some packets are lost along the network they are detected, then sent again taking care of sending them in the same order they were supposed to arrive.
On the other hand, UDP is a protocol oriented toward user control. When using UDP to send our datagrams, we can't be sure if the datagram will ever arrive at destination or not (and we mean mathematical certainty here: when we send a packet it will probably arrive, but we can't be sure at 100%). Also, when a packet is lost it is neither going to be detected nor sent again.
At this point, TCP would look like the ideal solution to all our problems. It's reliable, it's fast, it solves connection latency for us by keeping track of what packets arrived and what packets we still need to send.
BUT, look beyond. The only advantage UDP gives us is its speed, and that's right the one thing we really want. A UDP packet is just crafted, sumchecked and sent without any particular controls, because that's how UDP protocol works. A TCP packet must be crafted, labeled, sumchecked, and when it arrives an ACK is sent back to tell the sender "packet x is here, keep going", and when this signal is not sent then that means such packet x must be sent again.
I know that UDP is usually recommended for real-time multiplayer games with high data usage.
Yes, but not only. UDP is largely preferred over TCP mainly because its high speed is idea to handle high data sending and management. This happens when, assuming such videogame runs on deterministic lockstep (what happens on the server is identically replicated on any client independently of network latency), an update packet is lost and never get to its destination. TCP would re-send such packet, and the following packets are dropped because arrive not in order, and are then re-sent after the lost one. UDP is much more tolerant in this scenario: it won't care about this packet, because newer updates are coming. The update lost is not rendered, instead game physics is interpolated upon integration method used and latest update received.
TCP causes jittering when latency is high enough, UDP does not:
<video style="min-width: 100% height: auto" autoplay="" preload="auto" loop="true"><source src="https://gafferongames.com/videos/deterministic_lockstep_tcp_250ms_5pc.mp4" type="video/mp4"><source src="http://173.255.195.190/cubes_deterministic_lockstep_tcp_250ms_5pc.webm" type="video/webm">Your browser does not support the video tag.</video>This make me wonder if UDP is still superior in terms of speed and latency.
Well, yes, it is and it will for a long time. You can read more about TCP vs UDP here.
TCP <- Transmission Control Protocol. It's made to control transmission.
TCP was created to be a good and diplomatic network citizen. It focuses on making the networking a good experience for everyone, and willingly decreases it's throughput to achieve that. It adjusts to the environment by adding latency. Reasons are for example:
Additionally
Despite these, TCP provides the highest figure for (overall transmitted data) / (overall consumed time). Just that it doesn't happen precisely when you want it to happen.
UDP does none of these. It fires upon your will, just that one cannot expect it to hit each time - insead the target must announce that "you haven't shot in a long time, why?". One can still create own custom ACK packets, put multiple records in a single packet, etc. And also important, control NAT traversal. UDP is most certainly suitable for games with low latency demand.
You may compare the first diagram of RFC 768 (UDP) to the first diagram of RFCP 793 (TCP) page 15.
Both show 16 bits for a “source port” followed by 16 bits for a “destination port”. Both show 16 bits for a “checksum”. According to RFC 768, UDP's “checksum procedure is the same as is used in TCP.”
Whereas UDP's Length wraps up the details of UDP's diagram, TCP's length is part of a “a 96 bit pseudo header” described on page 15 and 16.
Don't expect TCP to outperform UDP. That's simply not likely to happen, for multiple reasons. One is that TCP simply has more bits. So if equipment can effectively process a certain number of bits per second, that will permit more UDP packets than TCP packets.
The other reason is that TCP's “three way handshake” means that the sender must wait for a response. This requirement introduces additional overhead that UDP doesn't handle. There's a reason why most of your Internet communications start with some UDP communication. Basic DNS uses UDP because a request and a response can be completed in fewer steps than TCP's “three way handshake” process. TCP's feature of keeping track of lost packets is rather unexciting, because a computer could simply make a new request rather than trying to let a remote system know that there is an unfulfilled prior request.
Consider what's happening for a moment. To simplify the scenarios, you have two choices when trying to send a state change (like your player just changed direction, or shot a gun, or some other player just set off a bomb):
Assuming there wasn't an update needed right before it, the time when that singular update arrives in 1 vs 2 wont be very different. It's one trip from the server to the client. But, say instead of just a bomb going off, you are trying to continuously relay the activity of someone running through a maze; weaving, ducking, shooting, etc. In the case of UDP, every action will be sent in a datagram, as soon as it happens. In the case of TCP every action will be sent in a packet only if the server is allowed to send. What says it's allowed to send? Having room in the TCP window (assuming delayed ack is active) so that the message can be put on the wire. If not, it has to wait for an ack to arrive from the client before sending.
How long is too long? When multiplayer first person shooter development hit it's stride back in the late 90's and early 2000s low latency connections were not common. A dialup modem would have a typical one-way latency of 180ms. Waiting around for an ack before sending another update, effectively doubling that time to 360ms, was painful; even novice users could definitely feel the difference. When broadband connections caught on, they brought the latency down a lot but it still persisted when bandwidth was in short supply (quite often in some areas). So the preference for lowest possible latency persisted.
Modern home connections and interconnections have changed this, to the point where regional latency, even during congested times of day, are in the 15ms or below range. Choosing TCP instead of UDP would be invisible in most cases, since the latency is "low enough". However, there is still the tendency of UDP to be prioritized over TCP given its history as a low latency protocol. So, for now (and probably some time into the future) UDP will be preferred for real-time communication.
I know that UDP is usually recommended for real-time multiplayer games with high data usage
Is UDP still superior in terms of speed and latency? Could recent TCP optimizations have made TCP perform better than UDP?
Your assumptions are wrong. TCP and UDP differ primarily in what model they represent (unreliable datagrams versus in-order reliable virtual stream).
They do not differ in respect of volume ("high data usage") or throughput. TCP will push through just as much data as UDP, it will easily saturate the physical cable.
In presence of packet loss, the two do differ in latency, but only in that condition. Otherwise, TCP has just as low latency as UDP (give or take maybe a few dozen nanoseconds because the network stack has slightly more logic to do, but that's rather neglegible).
There is a slight difference in header size, so technically, more bytes must make it over the wire on serial lines, but that one is rather inconsequential, too. It only really matters for bulk transfers, and then it's about a 0.5% difference. Most people with home DSL internet access route all their traffic over ATM which adds upwards of 10% protocol overhead (5 control bytes for 48 bytes of payload, plus partial frames), and nobody even notices.
Some people build reliability on top of UDP. If some level of reliability is desired, but strict in-order deliverance is not needed, that may give a small advantage. However, it is still debatable whether the approach makes a lot of sense, and you pay a hefty price for that small advantage.
If you have clients connecting from hotel WiFis or other "weird" places, you will notice that often overall support for TCP is much, much better than for UDP.
Games generally use UDP not because it is superior in one of the forementioned ways -- it isn't -- or because you can reduce jitter by half a millisecond by implementing reliability without in-order, but because games (much like IP telephony) often contain a lot of very volatile data, such as for example position updates.
This volatile data is regularly and quickly obsoleted both by time passing, and by the next datagram coming in. Which means nothing more and nothing less than you actually don't care too much about being 100% reliable (or in-order).
Assuming a network packet is dropped in a service which runs at a steady pace with frequent updates coming in (shooter game, telephone, video chat) it does not make a lot of sense to have the acknowledge time out and resend the packet, and meanwhile freeze everything on the other end while waiting for the resent packet to arrive. That's way too disturbing, and no good.
Instead, you just consider the packet lost and move on, taking the data from the next packet that makes it through and meanwhile, to the best of your ability, hide the fact that a packet was lost from the user. Interpolation, dead reckoning, you name it.
Note by the way that packet loss is a normal condition. While IP is generally "quite reliable", packets occasionally being dropped can happen, and will happen. While packets being lost is normally rather on the rare side (<1% here), it is not something extraordinary or theoretical, or an indication that something is broken. It is perfectly normal.
Every TCP bulk transfer will necessarily include lost packets, for example (it's how the congestion control works).
In a high bandwidth MPG, you don't care if you missed a packet giving you the location and health of monster #425, because you'll be getting another update in some fraction of a second. This is and example where UDP makes TCP look stupid for making you wait for instantly obsolete data.
In that same game, you want the patches to show up exactly as they were designed. TCP already has the "tell me if it fails" features built in, facilitating automatic retries and verified failures. You can do it in UDP, but why recreate the technology?
Here's a simple description of what's going on.
UDP - Isolate chunk O'data.
Make a packet.
Encapsulate in IP.
Ship it.
TCP - Isolate a Stream O'data.
Make a packet from the front of the stream.
Encapsulate in IP.
Wait for space in the TCP window.
Ship it.
Keep reshipping until a receipt is received or timeout.
Stay in the TCP window until a receipt is received or timeout.
Shipping just means it made it through the local NIC, no more.
A TCP receipt reception both guarantees data reception and frees space in the window for the next packet.
Resending (slightly) increases the likelihood of eventual receipt.
TCP packets are reassembled on the other side as an ordered stream of data. UPD packets are received as distinct packet. The protocol does not preserve order.
TCP is good for pushing required data and large ordered amounts of data. TCP provides notification of a persistent failure. TCP self-throttles through choked pipes (ref: window). TCP has handshakes to slow down initialization. TCP requires a "connection" prior to transmission.
UDP just puts the data on the wire and lets you proceed without waiting for windows and retransmissions. UDP will blast data at full speed into a choked pipe, no matter how much data is lost.
I designed and wrote a commercially applied UDP Multicast File Transport Utility. I've worked on IP stacks. These are just basics, sans minutia. Explaining "sockets, MTUs and other fun toys" was a little beyond what would be useful for this question.
P.s. (I can't add comments to reply to comments) UDP is also good for data which is desirable but not required. Forward Error Correction is an example of this, lots of unnecessary but desirable packets.
Has all the TCP optimized routers made TCP perform better than UDP?
One more question is: does "data heavy" mean you will frequently load scenes?
If yes, you may need to send large pieces of data (>1k) intensively in which TCP may be much more efficient because especially on the server side the NICs will provide various offloads which same lot of cycles. A user space application may issue large writes with TCP while in UDP an attempt to send more than MTU-headers size bytes will cause IP fragmentation and other overheads which will kill performance
Neither UDP or TCP (or any other variant) is out-right superior, not even in terms of speed/latency. Your choice must be made depending on the requirements of your application. To do this, you should compare the features each protocol offers, realizing that more features implies more overhead. So, if the goal is to minimize latency or maximize speed, then you should choose a protocol with as few features as possible, but while keeping the essential features needed to meet your requirements.
Generally speaking, UDP (User Datagram Protocol) offers the least amount of features. It is simplistic in that you send data without any sort of receipt/acknowledgement.
On the other hand, TCP (Transmission Control Protocol) offers the most amount of features needed for a reliable, connected communication. A TCP communication sends duplicates or more of packets and tags them with ordering information. Upon receipt at the destination, an ACK (acknowledgement) must be sent back along with information on which packets were lost so that the original sender can resend those lost packets. If I recall correctly, even ACK packets may need acknowledgement for proper reliability.
For a Skype conference call, it is unimportant to ensure that all video and audio data is sent/received in a reliable fashion. Nowadays, UDP does a great job in minimizing packet loss anyways. The important thing to know is that there is absolutely no guarantee in UDP whether or not transmission was successful. For audio/video data in a conference call, UDP is a proper choice because we care more about getting real-time data (that is, the most recent). If a few packets are lost here and there, it will not interrupt the communication in a dramatic way.
However, in a conference call, people can send IM's (instant messages) or send files. In these cases, reliability is an necessary requirement to ensure that files and messages are not corrupted or lost. For IM's you may not need the connected state that TCP provides. An intermediary protocol, such as RUDP (Reliable UDP) may be sufficient. However, for files, it may be necessary to have the connected state that TCP provides.
If you have a complex application or need to optimize your communication, then it is beneficial to begin with a UDP communication. Afterwards, you can add all features you need on top. This will give you the most control on your network communication.
If you have a simple application where optimization isn't required, consider going with one either standard (UDP or TCP) to meet your needs. That would allow you to move on to more important matters.
I noticed many comments where people believe that TCP packets are bigger than UDP packets. Don't just trust me, read the documentation. The protocol is as follow: a few bytes for Ethernet header (2 bytes message type, 48 bit MAC, 6 bytes) (for Wifi, header may differ) 20 bytes for IP 20 bytes for TCP or UDP x bytes for the data x ranging from 0 to about 1500 (see MTU) Lastly, the checksum to make sure that no corruption occured in that Ethernet packet.
TCP allow to send bigger "stream" packet of about 64K. This "large" block is actually chopped in many smaller Ethernet packets.
I think Both TCP and UDP should be implemented in the game, UDP should be mostly used in the main game and TCP for basic things.
For Example, suppose you have a login system, so its better to implement login system over TCP using HTTP
and on the other hand if you have some tasks such as updating the location of the player in a multiplayer game you should make use of UDP rather then TCP.
In login system if login fails, (Running on HTTP) or in a chat system message something goes wrong (Running on Web Socket or HTTP) you should inform the player about it, on the other hand if due to some reasons the position of the player doesn't get updated at all or it gets updated multiple times, You don't have to worry about it here, just resume from wherever the user is.
So a mix-up of both TCP and UDP is better, when it comes to a multiplayer game, so in short you can say the main part of game is implemented on UDP most of the time, Its also possible to implement all the stuff in just UDP.
So its totally a design decision which defers from game to game
