We've seen how TCP guarantees perfect, in-order delivery. It does this by buffering data, retransmitting lost packets, and aggressively throttling itself when the network is congested. But for some applications, this reliability is a fatal flaw.
Head-of-Line Blocking
If you are streaming a live video call or playing a fast-paced multiplayer game, what happens if packet #3 gets lost, but packets #4 and #5 arrive perfectly on time?
Because TCP promises an in-order byte stream, the receiver's operating system cannot hand packets 4 and 5 to the video player. It must lock them in the receive buffer, wait a few hundred milliseconds for the RTO timer to fire on the sender, and wait for packet 3 to be retransmitted and arrive.
By the time packet 3 finally arrives, the video frame it contains is a half-second old. The user experiences this as a massive video freeze or game lag spike.
Head-of-Line Blocking Race
Click "Stream Data" to send 5 frames. Notice how UDP immediately renders Frame 4 and 5 even though Frame 3 was lost, while TCP freezes completely until Frame 3 is retransmitted.
TCP Video Player
UDP Video Player
UDP (User Datagram Protocol) is the opposite of TCP. It has no handshakes, no sequence numbers, no ACKs, and no flow control. It simply wraps the data in an IP packet and fires it into the network. If it drops, it's gone forever. The application is responsible for dealing with missing data (like dropping a video frame and moving on).
HTTP/3 and QUIC: HTTP/2 runs over TCP. Because browsers open a single TCP connection to download the HTML, CSS, JS, and images concurrently, a single dropped packet stalls the entire webpage (Head-of-Line blocking). To fix this, HTTP/3 was built on top of QUIC: a protocol that runs over UDP. QUIC reinvents reliability in user-space, but does it per-stream. If an image packet drops, only that image pauses; the CSS and JS continue downloading instantly.
Check yourself
1. Why is TCP inappropriate for fast-paced multiplayer gaming?
TCP's guarantee of strictly ordered delivery means newer data cannot be processed until missing older data arrives, causing unbearable latency spikes in real-time applications.
2. If a UDP packet drops in transit, how does the UDP protocol handle the retransmission?
UDP provides absolutely no reliability or retransmission mechanisms. If an application needs reliability over UDP, it must build its own mechanisms (like QUIC does).