TCP & UDP — Part 2: UDP Foundations

What is this?

In Part 1, TCP was the careful phone call: "can you hear me? — yes — great," then a steady stream of "got it... got it... got it" to make sure nothing was lost. UDP is the opposite instinct. UDP is shouting a fact across a crowded room: you say it once, loudly, and move on. No "can you hear me?" first. No waiting for "got it." If someone in the back didn't catch it — well, you're already onto the next thing.

That sounds reckless, and for a bank transfer it would be. But for a lot of real work it's exactly right. If you're announcing the score of a game every second, and someone misses one announcement, there's no point repeating the old score — the next one is already on its way and it's fresher. The whole point of UDP is to get out of the application's way: it does almost nothing, so the application can do exactly what it needs and not one thing more.

The one-line idea: UDP is a thin, connectionless wrapper over IP — it adds ports and a checksum, and nothing else. No handshake, no ordering, no retransmission, no flow or congestion control. If the application wants any of that, the application builds it.

Like TCP, UDP lives at Layer 4 of the OSI model — same layer, opposite philosophy. Where TCP is "reliable by default, and you can't turn it off," UDP is "unreliable by default, and you add back exactly the reliability you want." That single inversion is why UDP underpins DNS, real-time gaming, VoIP, and — most consequentially — QUIC and HTTP/3, which we'll meet at the end of this chapter and dissect in Part 3.