When a web page loads slowly, you wait. When a video call stutters, you hear half a word and the conversation moves on.

That difference isn't an accident. It's a design choice made underneath your app, at the transport layer: a web page wants every byte, in order, even if that takes a bit longer. A video call wants the latest audio right now, even if some of it is missing. Those two wishes map to two protocols, TCP and UDP, and once you see why, a lot of networking behaviour starts to make sense.

Two ways to send a message

Here's the analogy I use.

TCP is a phone call with a careful note-taker. Before anything is said, both sides confirm they can hear each other. Every sentence is numbered. If the listener misses sentence 7, they ask for it again, and they won't write down sentence 8 until 7 has arrived. Slow sometimes, but the notes are complete and in order.

UDP is shouting across a busy room. No setup, no numbering, no "pardon?". You shout each message and hope it lands. Some messages get lost, some arrive in a different order, and nobody automatically fixes that. But there's no waiting either.

Both run on top of IP, which just moves packets from one address to another with no promises. TCP adds the promises. UDP mostly doesn't.

What does TCP actually guarantee?

TCP gives the application a reliable, ordered stream of bytes. To do that it adds:

• A handshake. SYN, SYN-ACK, ACK. One round trip before any data flows (and TLS adds its own handshake on top for HTTPS).
• Sequence numbers and acknowledgements. The receiver confirms what it got, so the sender knows what to resend.
• Retransmission. Lost packets are sent again until they arrive or the connection gives up.
• Ordering. Data is handed to your app in the order it was sent.
• Flow and congestion control. The sender slows down when the receiver or the network can't keep up.

For a web page, an API response, a database query or a file download, this is exactly what you want. A JSON response with a missing chunk in the middle isn't "slightly worse". It's broken.

So why would anyone choose UDP?

Because every one of those guarantees costs time, and sometimes time is the thing you can't spare.

Think about a video call. A packet carrying 20 milliseconds of audio gets lost. With TCP, everything behind it waits while that packet is resent. By the time it arrives, the moment has passed, and now the whole stream is behind. The user hears a freeze followed by a rush.

With UDP, the app simply moves on. Audio codecs can hide a small gap, and video can show a slightly blurry frame for a moment. A late packet is worse than a lost one, so real-time apps prefer to lose a little than to wait.

That's why UDP shows up in:

• Voice and video calls. WebRTC, which powers browser video calls, sends media over UDP when it can.
• Online games. The player's position from 100 ms ago is useless; send the new one.
• DNS lookups. One small question, one small answer. A handshake would double the time. If the answer doesn't come back, the client just asks again (and DNS falls back to TCP for large responses).
• Live streaming and telemetry, where fresh data beats complete data.

UDP doesn't mean "no reliability ever". It means the application decides which reliability it needs, instead of getting TCP's full package.

Head-of-line blocking: TCP's hidden cost

There's one TCP behaviour worth understanding properly, because it shaped the modern web.

TCP delivers one ordered stream. If packet 7 is lost, packets 8, 9 and 10 sit in a buffer, even if they arrived fine, until 7 is resent. This is called head-of-line blocking.

HTTP/2 sends many requests over one TCP connection, which is efficient, but it also means one lost packet can stall every request on that connection: your CSS, your images and your API call all wait for the same missing piece. On a clean office network you rarely notice. On a phone moving between cell towers, you do.

QUIC and HTTP/3: the best of both

The fix was clever: build a new transport on top of UDP and add back only the guarantees the web needs, in a smarter way. That's QUIC, and HTTP/3 is HTTP running over QUIC.

• Independent streams. Each request has its own stream, so a lost packet only delays the stream it belongs to. No more one-stalls-all.
• Encryption built in. QUIC includes TLS 1.3 in its own handshake, so a new connection typically needs fewer round trips than TCP plus TLS.
• Connection migration. Connections are identified by an ID rather than by IP and port, so switching from Wi-Fi to mobile data doesn't have to mean starting over.

Why build it on UDP instead of changing TCP? Because TCP lives in operating system kernels and in countless routers and firewalls along the way, and changing it everywhere would take forever. UDP passes through almost everything, and QUIC can be updated as ordinary software.

The nice part for most of us: you don't have to do anything in your code. Browsers and CDNs negotiate HTTP/3 automatically when both sides support it, and fall back to HTTP/2 over TCP when they don't.

Side by side

Why this matters to an app developer

You'll rarely open a raw socket, but this knowledge pays off in everyday ways. It explains why a firewall rule that only allows TCP can break video calls. Why DNS issues feel so random. Why the same API is fast on office Wi-Fi and painful on a train. And why turning on HTTP/3 at your CDN can help mobile users on flaky networks more than any amount of code tuning.

What's the strangest networking problem you've debugged that turned out to be about the transport layer, not your code?