How the web outgrew the phone call

A real 8-dish order, timed from a laptop against the same kitchen three different ways.

Before you start. You need that TCP promises to deliver bytes in the exact order they were sent - the promise this whole lesson is about, set up in TCP vs UDP, and the 3-way handshake. You also need that opening a connection costs its own round trip before any data can move. The page in this lesson needs eight dishes (files), so the whole story is about paying that opening cost once instead of eight times. The costs themselves are the slow first lap of Reading a book aloud to America and the secure hello of The whisper code (how a call goes private). What a request and its response actually say, line by line, is What a request actually says (HTTP).

The idea in 30 seconds

A webpage is never one request. Loading one page fires off dozens of small ones, and speed depends on how they share a connection, not just their size.
HTTP/1.1 (1997) answers one request at a time on each connection, so one slow file blocks every file queued behind it.
HTTP/2 (2015) weaves every dish onto the same line at once - multiplexing - and that one change alone made the same eight requests seven times faster.
Multiplexing did not remove the queue; it moved it. TCP still delivers everything in strict order, so one lost packet now stalls every file sharing that connection. The queue (head-of-line blocking) just moved down into TCP.
That in-order promise is wired into every router and firewall alive, so it cannot be changed in place. A protocol stuck like that is ossified.
QUIC, which Jim Roskind started building at Google in 2012, ships today as HTTP/3. It skips TCP entirely and rebuilds order on top of UDP, the postcards nothing along the way bothers to inspect.

Read the story · Skip to the numbers