When would one use UDP over TCP? [closed]

Question

It seems TCP is quite a reliable service with error checking, end-to-end delivery assurance etc/, while UDP is a connectionless unreliable service.

In what occasion would application engineers use UDP over TCP?

Answer 1

This is a frequently asked question. The answer below is one of the best answers from another site. https://stackoverflow.com/questions/1099672/when-is-it-appropriate-to-use-udp-instead-of-tcp

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.

Answer 2

The answer is as simple as it can get:

speed

TCP, due to its connection establishing and error checking mechanism is considered a slow protocol (although reliable).

While UDP does not have all those time consuming mechanisms and so it is much faster, not reliable but fast. He just streams out the data and does not really care about the receiver getting the whole message or not.

It is actually a trade off, speed over reliability, sometimes you need quick data transmission and you don't care about loosing some packets in the process, like live chat and video streaming.

But sometimes (of course) you need a reliable data transmission for your purpose, something that makes sure the receiver gets the whole message, however a little bit later. Like sending email or chatting in chat-rooms.

Answer 3

TCPs reliability comes at a price in several areas.

1. Compexity: a UDP only stack is simpler than a TCP one.
2. Startup time: A UDP protocol can send a request and get a response in one round trip. A TCP protocol needs to go through the TCP connection setup process first which means a second round trip.
3. Head of line blocking: If a TCP packet is lost all subsequent packets will be held in the network stack and unavailable to the application until the lost packet is resent.
4. Server resource use, all that buffering and connection state tracking takes memory and CPU.
5. Extra network chatter, UDP can deliver a small request and response in two packets. TCP is likely to send substantially more.

Taking some practical examples:

TFTP uses UDP because of point 1, it was designed to be implemented in very limited environments.

DNS uses UDP because of points 2,4 and 5. The small request and response doesn't justify the resource use of TCP.

Low latency realtime stuff like games, VOIP etc uses UDP because of point 3. Having the whole stream be delayed by a retransmission can be worse than having a packet not arrive at all (though this is somewhat mitigated by TCP fast retransmission).

Answer 4

one increasingly common reason is to use udp to wrap a new transport that can be distributed without operating system permission. QUIC is an example of this, as is SCTP over UDP ala webrtc. Tunnels/VPN also work this way, because you don't want to tunnel TCP in TCP as two layers of flow and congestion control interact poorly.

Native application use of UDP might make sense, in addition to the reasons cited above, when you desire out of order delivery (i.e. avoiding head of line blocking that TCP imposes because it delivers in order).

Answer 5

A property of UDP which is frequently overlooked is that fact that it can work with entirely one-way traffic.

Consider two systems T and R. T wants to transmit something, R receives it. Under normal behaviour (with a few preconditions eg no ARP, no ICMP unreachables) T will not receive a single packet from R. Appropriate filtering can then prevent all traffic from R to T, which means that faults/intrusions on R can never affect T in any way. This is an extremely important property in complex systems, which can be used to overcome unforeseen boot-order dependencies, for example. I've seen this used in various vision systems.

I've also seen UDP "syslog sinks", where log data is sent to multiple inward-only systems to create multiple cross-referable logs. In some sites you can't even ssh to them, you have to go to the machine room and use the console.

It is frequently stated that UDP is unreliable, which makes it sound as though it has inherent non-delivery. This is false: what it lacks is an inbuilt retry mechanism, leaving it to the upstairs protocols (compare DNS and streaming for approaches). Further, under many real-world conditions (decent switches, non-saturated network), you will find 100% UDP delivery.

Under some very nasty real-world conditions with very high packet loss, you also find that UDP gets through where TCP often doesn't. For example when packet loss is say 90%, it's basically certain to break a TCP connection, whereas at least some of the UDP packets would get through. Protocols such as NTP and DNS will still work, syslog and SNMP are likely to work well enough to find the cause.

Answer 6

In fact, both TCP and UDP are necessary to design of good network comms. They each do one job well. Because of the separation of comms into discrete tasks, testing and debugging is much easier