69
\$\begingroup\$

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?

\$\endgroup\$
  • 24
    \$\begingroup\$ With UDP there is no guarantee that your packets will be received or even ordered, that alone makes UDP faster than TCP. \$\endgroup\$ – nathan Apr 18 '16 at 8:39
  • 4
    \$\begingroup\$ @KaareZ what do you mean faster to implement? \$\endgroup\$ – nathan Apr 18 '16 at 8:51
  • 2
    \$\begingroup\$ @nathan That it's easier to develop your application with TCP than UDP. I want to know wether all the TCP optimizations have made TCP a better option in terms of performance. \$\endgroup\$ – KaareZ Apr 18 '16 at 8:53
  • 3
    \$\begingroup\$ @KaareZ i'm not an expert but let's think about it. How could TCP be better in term of performance and still be a reliable protocol? You can't have everything. TCP is made for reliability. The real question is why would you want to use TCP in your game? \$\endgroup\$ – nathan Apr 18 '16 at 9:04
  • 7
    \$\begingroup\$ UDP is better than TCP if and only if you are able to(=experienced low-level networking programmer) re-implement just the TCP features you need inside it effectively. Droping the unnecessary TCP features for performance. \$\endgroup\$ – wondra Apr 18 '16 at 10:33

10 Answers 10

116
\$\begingroup\$

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:

  1. The loss of the first update is detected.
  2. A retransmission of the first update is requested.
  3. the retransmission has arrived and been processed.

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.

\$\endgroup\$
  • \$\begingroup\$ Note: UDP can broadcast local network (possible advantage), and since Vista requires admin to run server/broadcast on UDP (disadvantage) (UAC/firewall tend to fail to inform user action is required). \$\endgroup\$ – PTwr Apr 18 '16 at 12:51
  • 7
    \$\begingroup\$ "If you send 2 updates on TCP, and a packet of the first update gets lost" True, but what are the chances for that occur? According to pingman: "Anything over 2% packet loss over a period of time is a strong indicator of problems." \$\endgroup\$ – mucaho Apr 18 '16 at 14:42
  • 29
    \$\begingroup\$ @Peter you're forgetting that in TCP every dropped packet stalls every subsequent packet. With 100ms ping it could easily be 300-500ms before that packet is retransmitted and received, so that's 6-10 packets that get stalled every 33 seconds. That will definitely be noticeable in a quake-like FPS. \$\endgroup\$ – BlueRaja - Danny Pflughoeft Apr 18 '16 at 18:25
  • 12
    \$\begingroup\$ On many TCP implementations, the first timeout after a missed ack will take a full second. That's a long time. If packets are small, UDP could easily smooth over a missed transmission or two by simply having each packet include data from the last two updates so the application would get the data it needs before the sender or receiver could know the first packet went missing. \$\endgroup\$ – supercat Apr 18 '16 at 19:04
  • 21
    \$\begingroup\$ With a game like Quake, losing the first packet is irrelevant. In FAR less than time it would take you to detect the loss and retransmit the first packet, you should have already transmitted a second packet which makes the first one obsolete anyway. This is the same reason than many real-time voice and video applications also use UDP. If a packet gets dropped, you'd much rather just lose 0.02 seconds of audio than delay the whole stream by a full second or more. The same is generally true with real-time games, as you want to know where an object is now, not 1.5 seconds ago. \$\endgroup\$ – reirab Apr 18 '16 at 21:42
18
\$\begingroup\$

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 in the form of datagrams, 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.

\$\endgroup\$
  • 8
    \$\begingroup\$ TCP uses streams of bytes rather than datagrams. UDP uses datagrams. Good TCP implementations will keep the packets that arrive out of order, but no packet's contents can be made available to the application unless or until all preceding packets have been received. Thus, if one packet gets lost the sender might not need to retransmit everything that followed the lost packet, but the receiving application wouldn't see anything past the lost packet until that packet gets retransmitted (whereupon the application would instantly see the contents of that packet and the ones after it). \$\endgroup\$ – supercat Apr 18 '16 at 21:37
  • \$\begingroup\$ @supercat Unfortunately, TCP doesn't have any way to tell the sender exactly which packets it did and didn't receive. It only has a mechanism for "I've received all of the bytes up through x sequence number." If the sender retransmits packets that the receiver already received, it will just ignore the copies. \$\endgroup\$ – reirab Apr 18 '16 at 21:46
  • \$\begingroup\$ @reirab: I thought there were some modern extensions which included that feature, though even without that I think that an implementation which had sent a data up to byte #1,050,000 but only received acks for data up to 1,000,000 would, after a second without hearing any ack for anything past 1,000,000, start by sending a block of data from 1,000,000 to 1,000,500 or so and then waiting for a response. If it gets an ack for data up to 1,000,500 it can then retransmit more data; if it gets an ack for data up to 1,050,000 it can skip the retransmissions. \$\endgroup\$ – supercat Apr 18 '16 at 21:51
  • 1
    \$\begingroup\$ @Giorgio IP specifies nothing whatsoever about analog signals. That's done at the physical layer. IP operates two layers above that at the network layer. IP couldn't care less whether the bits are going over fiber, a satellite link, or a 14.4 kbps dial-up modem. UDP and TCP are a layer up from IP, at the transport layer. Also, like supercat says, TCP presents a stream interface to the application, not a datagram interface like UDP. \$\endgroup\$ – reirab Apr 18 '16 at 21:52
  • \$\begingroup\$ @supercat Hmm... you might be right about modern extensions, though it's certainly not part of the original TCP standard. An ACK just has a sequence number. I'd assume a TCP implementation would normally start retransmitting the entire send window if a packet gets dropped rather than waiting around an entire RTT for each packet. That would add a huge amount of latency if several consecutive packets were lost for very little gain. \$\endgroup\$ – reirab Apr 18 '16 at 21:56
9
\$\begingroup\$

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:

  • Receiver detects a missing packet, tells the sender to slow down (halve the rate for a while).
  • Receiver detects wrong incoming packet order (maybe they took different network paths), tells the sender to slow down - and btw, the receiver won't accept further packets until the missing one comes in. Dealing with this takes time.
  • Sender detects network congestion (eg. slow roundtrip time), adds latency.
  • Receiver cannot keep up with the speed (input buffer is getting too full), asks sender to add latency (flow control).
  • There is a single slow receiver (high ping bastard, crybaby, what are they called) among receivers, latency (may be) added in the household.

Additionally

  • Nagle's algorithm may keep the senders data on hold, until there s more to send (in order to utilise data frames more efficiently). Time critical data gets delayed.
  • I believe ordinary home-routers with wlan may do smart things (slow down) to smooth the TCP throughput between multiple clients (the wlan interface being the bottleneck, even if the game doesn't use it). Relates to broadcasting/multicasting, ie. "other" data may decrease your TCP throughput.
  • TCP ACKnowledges everything, which is not necessary for a gaming environment. There is no point in ACKing every single physics update. Enough to ackknowledge for example once per second, or similarly. If a client (or a server) is silent for a longer time, then it's time to react.

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ Note: Nagle's algorithm can be disabled, e.g. for linux. \$\endgroup\$ – mucaho Apr 18 '16 at 16:42
  • \$\begingroup\$ Nagle may work against (and can be sidestepped by setting every packet to "push" by the application) meanwhile Delayed Ack works in TCPs favor, it allows the sender to put more bytes on the wire until the send window is full (ideally as big as the receive buffer is on the other side) regardless of if an ack has been seen. \$\endgroup\$ – Jeff Meden Apr 18 '16 at 16:59
  • 4
    \$\begingroup\$ It's transmission control protocol. \$\endgroup\$ – ysdx Apr 19 '16 at 7:05
  • 1
    \$\begingroup\$ Type these words a million times... thx - fixed. \$\endgroup\$ – Stormwind Apr 19 '16 at 9:53
3
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Although English summaries (as seen in some other answers) are nice, just having some accurate and precise descriptions can be simplest. \$\endgroup\$ – TOOGAM Apr 21 '16 at 0:40
  • \$\begingroup\$ You mean 16 bits, not bytes! \$\endgroup\$ – jcaron Apr 21 '16 at 22:47
  • \$\begingroup\$ Oh, silly me. 'tis an example of why technically precise answers are nice; they are easy to identify errors and see correct info. I fixed the answer. Thank you @jcaron \$\endgroup\$ – TOOGAM Apr 21 '16 at 23:31
2
\$\begingroup\$

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):

  1. Keep a TCP session open, and when the bomb is to go off send a TCP message to all players (if possible, see below)
  2. Keep a UDP port listening, and when the bomb is to go off send a UDP message to all players no matter their connection state

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.

\$\endgroup\$
  • \$\begingroup\$ The latency would be low enough, except that by default, TCP writes are only sent when the data-to-write cross a certain treshold or a timeout (usually 200-1000ms) occurs. If you need TCP on a low-latency system with little throughput, you must disable this feature and make sure you don't write individual bytes all the time (e.g. you're no longer treating the TCP stream as stream, and you pretend you're dealing with individual messages instead). You don't have to wait for the ACK unless your buffers are full, which is quite unlikely to happen in a typical real-time game. \$\endgroup\$ – Luaan Apr 19 '16 at 16:01
  • 1
    \$\begingroup\$ @Luaan Enter: the TCP PSH flag. When an application hands it down the stack the packet is sent immediately without waiting for more data. Lots of applications use this successfully (telnet and ssh for example). \$\endgroup\$ – Jeff Meden Apr 19 '16 at 16:54
2
\$\begingroup\$

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).

\$\endgroup\$
2
\$\begingroup\$

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.

\$\endgroup\$
  • 3
    \$\begingroup\$ Your point about "obsolete" data is a good one. TCP is good for "better late than never" data, but UDP is good for data which will be useful if it reaches the destination quickly, but useless if it doesn't. \$\endgroup\$ – supercat Apr 18 '16 at 21:40
1
\$\begingroup\$

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

\$\endgroup\$
  • \$\begingroup\$ It's a "voxel" game, so yes, it will need to send a lot of scene data. \$\endgroup\$ – KaareZ Apr 19 '16 at 6:25
  • \$\begingroup\$ @KaareZ Well, you probably want to send those as individual independent messages in that case anyway, with your own retransmission mechanisms. Minecraft started on TCP, and was pretty much unplayable over the internet; the switch to UDP was a happy occasion for most people. The main idea is that when you send 20 chunks of voxel data, and the first one is "lost", it shouldn't block the other 19 chunks from showing as soon as you get the data; when you find that the first one is missing, you retransmit. On TCP, all of those 19 are stalled at the very least, and retransmitted at worst case. \$\endgroup\$ – Luaan Apr 19 '16 at 16:05
  • 2
    \$\begingroup\$ @Luaan Minecraft hasn't switched to UDP for the actual gameplay. Even the latest versions still use TCP. No happy occasion... :( The only part of Minecraft that uses UDP is the server list, to ping individual servers and determine whether they are online. \$\endgroup\$ – camerondm9 Apr 20 '16 at 2:35
1
\$\begingroup\$

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.

A Comparison of Protocols

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.


Example: Skype Conference Call

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.


Implementation Choices

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.

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Are you trying to suggest that UDP and TCP headers are the same size? \$\endgroup\$ – Cameron Dec 10 '17 at 12:53

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.