UDP — What You Gain by Promising Nothing

In a nutshell

UDP is a thin shell with only port numbers and a checksum added, and it gives you the freedom to design reliability yourself in the application when you want to.

Why this was needed

TCP's reliability is not free. Connection establishment needs round trips, and when loss occurs, it does not hand the data after it to the application until retransmission is finished. In a real-time voice call, a sound from 0.5 seconds ago is useless even if retransmitted, yet TCP waits, because of its promise to guarantee order.

This phenomenon is called head-of-line blocking. For some applications latency matters more than reliability, and then a transport layer that promises nothing is actually better.

How it works

The UDP header is 8 bytes. The source port, destination port, length, and checksum are all there is. There is no connection state, no sequence number, and no retransmission. A datagram you send may or may not arrive, and may arrive out of order.

This simplicity gives three things. First, there is no connection establishment round trip. Second, the server does not maintain connection state, so it can handle far more clients. Third, the application can decide the retransmission policy itself.

The first and second are the reasons DNS uses UDP. A query finishes with one query and one response, so there is no reason to spend three round trips opening and closing a connection. However, if the response exceeds 512 bytes, the server sets the truncated (TC) flag and the client sends the same query again over TCP. So if you block TCP port 53 to DNS servers, things are fine normally, but only certain domains whose records have grown fail to resolve. It is a kind of incident that is hard to diagnose.

QUIC is an example that pushes the third to the extreme. It newly implemented retransmission, ordering, encryption, and multiplexing entirely on top of UDP. Why did it rebuild on top of UDP instead of fixing TCP? TCP is embedded in operating system kernels and in middle devices around the world and takes a decade to change, whereas an implementation on top of UDP can be deployed with just an application update. The fact that HTTP/3 provides independent delivery per stream and eliminates TCP's head-of-line blocking is also thanks to this freedom.

What it looks like in the field

What you must take care of yourself when using UDP is size. MSS clamping applies only to TCP, so UDP-based protocols must handle path MTU problems on their own. This is why QUIC sets its default datagram size to a conservative 1200 bytes.

One more thing. UDP has no flow control, so if the sender is faster than the receiver, the receive buffer overflows and data is silently dropped. You can confirm this loss by looking at the drops column of /proc/net/udp or at the queue state with ss -u -a. It is a cause often found when a metrics collector or log shipper says "data is occasionally missing".

What to check in the quiz that follows

Check whether you can explain when choosing UDP is reasonable, and why TCP's order guarantee is actually harmful to some applications.