TCP vs UDP: guaranteed delivery, or raw speed?

TCP is connection-oriented and reliable: it opens a connection with a handshake, numbers every byte, acknowledges what arrives, retransmits what doesn’t, and delivers the stream to the application in order — with flow and congestion control so it doesn’t overwhelm the receiver or the network. UDP is connectionless and best-effort: it wraps your data in a tiny header and fires it off with no handshake, no acknowledgements, no retransmission, and no ordering. If a UDP packet is lost or arrives out of order, the protocol neither knows nor cares — that’s the application’s problem, if it’s a problem at all.

The two aren’t a permanent fork. Modern transport increasingly builds the reliability it needs on top of UDP rather than using TCP. QUIC — the transport under HTTP/3 — runs over UDP and re-implements connection setup, reliability and congestion control in user space, so it gets TCP-grade guarantees while dodging TCP’s baked-in limitations (notably head-of-line blocking, below) and enabling faster connection setup. So "TCP vs UDP" at the app layer is often really "a reliable protocol vs a bare one," and UDP has quietly become the flexible foundation that new reliable protocols are built on.

TCP’s in-order guarantee has a sharp edge called head-of-line blocking. Because TCP must hand bytes to the application in order, a single lost packet stalls everything behind it: the receiver has the later packets buffered but can’t deliver them until the missing one is retransmitted and arrives. For a file, that’s fine — you wait a few milliseconds. For a live video call, it’s a disaster: the frame you’re stuck waiting to retransmit is already stale by the time it arrives, and meanwhile the picture freezes.

UDP has no such rule. If a packet is lost, the ones after it are delivered immediately, and the app simply skips the missing audio sample or video frame — a tiny glitch nobody notices, versus a frozen call everybody hates. That’s the core reason real-time media runs on UDP: for live data, late is worse than lost. (And it’s exactly the blocking QUIC was designed to eliminate by multiplexing independent streams over UDP, so a loss in one stream doesn’t stall the others.)

Loading this web page is a TCP job. The HTML, CSS and JavaScript must arrive complete and in order — a single dropped byte in a script breaks it, and there’s no such thing as "skip the missing part of the file." TCP’s handshake and retransmission cost a few milliseconds you won’t notice, and in exchange you get a perfect copy of every resource. This is why the web runs on TCP (and QUIC, its UDP-based successor).

A video call is a UDP job. Frames of audio and video pour in dozens of times a second, and if one packet drops, you do not want the protocol to freeze the call while it fetches a now-useless old frame — you want it to skip that frame and keep the conversation live. A momentary blip is invisible; a two-second freeze while TCP retransmits is maddening. So the app sends over UDP and accepts (or conceals) the occasional loss. Same internet, opposite protocol, because one payload must be perfect and the other must be prompt.