hop 24 of 32 · 4 min
When you do not want reliability
A video call drops a packet holding one thirtieth of a second of picture. Should the protocol resend it?
No. By the time the resend arrives, at least one round trip later, that moment has passed. Inserting it would play a stale frame. Waiting for it would freeze the call.
This is the case TCP is wrong for, and why UDP exists.
What UDP does not do
| TCP | UDP |
|---|---|
| Guarantees delivery | Does not |
| Guarantees order | Does not |
| Flow and congestion control | Neither |
| Connection setup, 1 RTT | None |
| 20 byte header | 8 byte header |
Head-of-line blocking
TCP's worst property for live media is not the retransmission. It is that everything after a lost segment waits, because TCP promises order. One lost packet stalls perfectly good data that already arrived.
For a file that is exactly right. For a call it is the freeze.
What uses which
| Uses TCP | Uses UDP |
|---|---|
| Web pages, email, file transfer | Video and voice calls |
| Anything where every byte matters | DNS, one small question and answer |
| SSH | Online games, where a stale position is useless |
DNS is the interesting one: it uses UDP because a query and its answer fit in one packet, and asking again is cheaper than a handshake.