When is it appropriate to use UDP instead of TCP? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.

Since TCP guarantees packet delivery and thus can be considered "reliable", whereas UDP doesn't guarantee anything and packets can be lost. What would be the advantage of transmitting data using UDP in an application rather than over a TCP stream? In what kind of situations would UDP be the better choice, and why? I'm assuming that UDP is faster since it doesn't have the overhead of creating and maintaining a stream, but wouldn't that be irrelevant if some data never reaches its destination?

As well as suffering from possible packet loss, UDP does not guarantee that you'll only receive the packet once. If you have convoluted or badly configured networks, you can receive the same packet multiple times. Just a heads up since people tend to forget this!

TCP does not guarantee delivery, it just guarantees that if it is able to deliver the packets they will be in the same order that they were sent.

BTW, I frequently see people equate reliability/in-order delivery to TCP retransmits. Those "experts" will tell you that to overcome transmission errors on UDP, you will reimplement TCP (badly) and therefore you might as well use TCP. This is not true. There are other error-recovery techniques besides retransmit, that do not suffer latency or exponentially degraded throughput as a result of small-but-non-zero error rates.

A very similar question was asked on the Network Engineering Stack Exchange, I am linking my answer to it here to provide additional insight: How to know whether a protocol uses UDP or TCP?

24 Answers 24

This is one of my favorite questions. UDP is so misunderstood.

In situations where you really want to get a simple answer to another server quickly, UDP works best. In general, you want the answer to be in one response packet, and you are prepared to implement your own protocol for reliability or to resend. DNS is the perfect description of this use case. The costs of connection setups are way too high (yet, DNS does support a TCP mode as well).

Another case is when you are delivering data that can be lost because newer data coming in will replace that previous data/state. Weather data, video streaming, a stock quotation service (not used for actual trading), or gaming data comes to mind.

Another case is when you are managing a tremendous amount of state and you want to avoid using TCP because the OS cannot handle that many sessions. This is a rare case today. In fact, there are now user-land TCP stacks that can be used so that the application writer may have finer grained control over the resources needed for that TCP state. Prior to 2003, UDP was really the only game in town.

One other case is for multicast traffic. UDP can be multicasted to multiple hosts whereas TCP cannot do this at all.

Thanks for the interesting answer. We have a server currently doing everything in UDP (high bandwidth requirement) which is Ok because there is a single hop really (routing disabled, . ), but have noticed that packet reordering could become an issue on some faulty network cards. What user-mode TCP (or some other user-mode flow controlled) stack do you suggest?

@dashesy - can you get rid of the ordering requirement? Is there a monotonically increasing number inside the payload that you can use? If so, you don't really need a full blown user land TCP stack.

@drudru- yes the sequence number is there, I may need to buffer and de-jitter myself. Thanks, eliminating one more option is always great.

If a TCP packet is lost, it will be resent. That is not handy for applications that rely on data being handled in a specific order in real time.

Examples include video streaming and especially VoIP (e.g. Skype). In those instances, however, a dropped packet is not such a big deal: our senses aren't perfect, so we may not even notice. That is why these types of applications use UDP instead of TCP.

I think you have it backwards. TCP re-orders packets so that data is delivered in the sent order. UDP does not re-order and delivers data in whatever order it received it in.

UDP does not guarantee the order, you can however number the packets and reorder them after retreiving them.

@Kugel: Just beware that you might be implementing a new TCP stack. You're unlikely to do a better job than the OS at this.

@erikkallen: If one were using UDP to implement a higher-level protocol with the same requirements TCP was designed to meet, one would be unlikely to do much better than the existing protocols. On the other hand, some applications benefit from the addition of a few features to the protocol which a UDP wrapper could handle better than TCP.

The "unreliability" of UDP is a formalism. Transmission isn't absolutely guaranteed. As a practical matter, they almost always get through. They just aren't acknowledged and retried after a timeout.

The overhead in negotiating for a TCP socket and handshaking the TCP packets is huge. Really huge. There is no appreciable UDP overhead.

Most importantly, you can easily supplement UDP with some reliable delivery hand-shaking that's less overhead than TCP. Read this: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP is useful for broadcasting information in a publish-subscribe kind of application. IIRC, TIBCO makes heavy use of UDP for notification of state change.

Any other kind of one-way "significant event" or "logging" activity can be handled nicely with UDP packets. You want to send notification without constructing an entire socket. You don't expect any response from the various listeners.

System "heartbeat" or "I'm alive" messages are a good choice, also. Missing one isn't a crisis. Missing half a dozen (in a row) is.

"As a practical matter, they almost always get through". Highly depends on lower network layers reliability.

besides, is there a difference between planning for "a few" packet loss and "too much" packet loss? loss is loss. you have to plan for it anyway.

I work on a product that supports both UDP (IP) and TCP/IP communication between client and server. It started out with IPX over 15 years ago with IP support added 13 years ago. We added TCP/IP support 3 or 4 years ago. Wild guess coming up: The UDP to TCP code ratio is probably about 80/20. The product is a database server, so reliability is critical. We have to handle all of the issues imposed by UDP (packet loss, packet doubling, packet order, etc.) already mentioned in other answers. There are rarely any problems, but they do sometimes occur and so must be handled. The benefit to supporting UDP is that we are able to customize it a bit to our own usage and tweak a bit more performance out of it.

Every network is going to be different, but the UDP communication protocol is generally a little bit faster for us. The skeptical reader will rightly question whether we implemented everything correctly. Plus, what can you expect from a guy with a 2 digit rep? Nonetheless, I just now ran a test out of curiosity. The test read 1 million records (select * from sometable). I set the number of records to return with each individual client request to be 1, 10, and then 100 (three test runs with each protocol). The server was only two hops away over a 100Mbit LAN. The numbers seemed to agree with what others have found in the past (UDP is about 5% faster in most situations). The total times in milliseconds were as follows for this particular test:

1. 1 record
   • IP: 390,760 ms
   • TCP: 416,903 ms
2. 10 records
   • IP: 91,707 ms
   • TCP: 95,662 ms
3. 100 records
   • IP: 29,664 ms
   • TCP: 30,968 ms

The total data amount transmitted was about the same for both IP and TCP. We have extra overhead with the UDP communications because we have some of the same stuff that you get for "free" with TCP/IP (checksums, sequence numbers, etc.). For example, Wireshark showed that a request for the next set of records was 80 bytes with UDP and 84 bytes with TCP.

Probably the 5% is because is sent in a local network (two hopes away)? My guess is that the farther it is, the higher the difference is.

There are already many good answers here, but I would like to add one very important factor as well as a summary. UDP can achieve a much higher throughput with the correct tuning because it does not employ congestion control. Congestion control in TCP is very very important. It controls the rate and throughput of the connection in order to minimize network congestion by trying to estimate the current capacity of the connection. Even when packets are sent over very reliable links, such as in the core network, routers have limited size buffers. These buffers fill up to their capacity and packets are then dropped, and TCP notices this drop through the lack of a received acknowledgement, thereby throttling the speed of the connection to the estimation of the capacity. TCP also employs something called slow start, but the throughput (actually the congestion window) is slowly increased until packets are dropped, and is then lowered and slowly increased again until packets are dropped etc. This causes the TCP throughput to fluctuate. You can see this clearly when you download a large file.

Because UDP is not using congestion control it can be both faster and experience less delay because it will not seek to maximize the buffers up to the dropping point, i.e. UDP packets are spending less time in buffers and get there faster with less delay. Because UDP does not employ congestion control, but TCP does, it can take away capacity from TCP that yields to UDP flows.

UDP is still vulnerable to congestion and packet drops though, so your application has to be prepared to handle these complications somehow, likely using retransmission or error correcting codes.

The result is that UDP can:

• Achieve higher throughput than TCP as long as the network drop rate is within limits that the application can handle.
• Deliver packets faster than TCP with less delay.
• Setup connections faster as there are no initial handshake to setup the connection
• Transmit multicast packets, whereas TCP have to use multiple connections.
• Transmit fixed size packets, whereas TCP transmit data in segments. If you transfer a UDP packet of 300 Bytes, you will receive 300 Bytes at the other end. With TCP, you may feed the sending socket 300 Bytes, but the receiver only reads 100 Bytes, and you have to figure out somehow that there are 200 more Bytes on the way. This is important if your application transmit fixed size messages, rather than a stream of bytes.

In summary, UDP can be used for every type of application that TCP can, as long as you also implement a proper retransmission mechanism. UDP can be very fast, has less delay, is not affected by congestion on a connection basis, transmits fixed sized datagrams, and can be used for multicasting.

When networks get sufficiently congested as to cause packet loss, TCP tries to minimize its impact on other users of the network, while many UDP-based implementations don't. This lets them grab a bigger share of a diminishing pie, but also reduces the total amount of useful bandwidth available period (e.g. as a consequence of unnecessary retransmission in cases where data would in fact be delivered but the sender wouldn't realize that)

First of all, thank you for the great answer, I really learned a lot from it! But I have a question: doesn't segmentation happens on the layer 3(IP) because of the Ethernet adapter limitations for all the packets received from layer 4(both TCP and UDP)? Do you mean any other kind of segmentation which happens in TCP but does not happen in UDP? I'd really appreciate if you could explain it to me.

@Freezy. You are right, fragmentation of packets that exceed the MTU of the link (layer 2) happens at layer 3-IP. However, TCP is a stream based protocol and it treats data as a stream of bytes. TCP do send its data in segments in order to fit inside IP packets, which are sized according to the MSS, so segmentation do happen in TCP as well. How much data TCP puts in a segment, or much data your socket reads varies by many factors though; it can be 1 byte or MSS bytes. With UDP, the receiver always gets the exact number of bytes the transmitter sent, if the packet is not lost en route.

UDP is a connection-less protocol and is used in protocols like SNMP and DNS in which data packets arriving out of order is acceptable and immediate transmission of the data packet matters.

It is used in SNMP since network management must often be done when the network is in stress i.e. when reliable, congestion-controlled data transfer is difficult to achieve.

It is used in DNS since it does not involve connection establishment, thereby avoiding connection establishment delays.

UDP does have less overhead and is good for doing things like streaming real time data like audio or video, or in any case where it is ok if data is lost.

One of the best answer I know of for this question comes from user zAy0LfpBZLC8mAC at Hacker News. This answer is so good I'm just going to quote it as-is.

TCP has head-of-queue blocking, as it guarantees complete and in-order delivery, so when a packet gets lost in transit, it has to wait for a retransmit of the missing packet, whereas UDP delivers packets to the application as they arrive, including duplicates and without any guarantee that a packet arrives at all or which order they arrive (it really is essentially IP with port numbers and an (optional) payload checksum added), but that is fine for telephony, for example, where it usually simply doesn't matter when a few milliseconds of audio are missing, but delay is very annoying, so you don't bother with retransmits, you just drop any duplicates, sort reordered packets into the right order for a few hundred milliseconds of jitter buffer, and if packets don't show up in time or at all, they are simply skipped, possible interpolated where supported by the codec.

Also, a major part of TCP is flow control, to make sure you get as much througput as possible, but without overloading the network (which is kinda redundant, as an overloaded network will drop your packets, which means you'd have to do retransmits, which hurts throughput), UDP doesn't have any of that - which makes sense for applications like telephony, as telephony with a given codec needs a certain amount of bandwidth, you can not "slow it down", and additional bandwidth also doesn't make the call go faster.

In addition to realtime/low latency applications, UDP makes sense for really small transactions, such as DNS lookups, simply because it doesn't have the TCP connection establishment and teardown overhead, both in terms of latency and in terms of bandwidth use. If your request is smaller than a typical MTU and the repsonse probably is, too, you can be done in one roundtrip, with no need to keep any state at the server, and flow control als ordering and all that probably isn't particularly useful for such uses either.

And then, you can use UDP to build your own TCP replacements, of course, but it's probably not a good idea without some deep understanding of network dynamics, modern TCP algorithms are pretty sophisticated.

Also, I guess it should be mentioned that there is more than UDP and TCP, such as SCTP and DCCP. The only problem currently is that the (IPv4) internet is full of NAT gateways which make it impossible to use protocols other than UDP and TCP in end-user applications.