Card 05/ 10
HTTP/2: Many Requests on One Connection
HTTP/2 splits requests into frames and interleaves them, so one slow response no longer blocks the rest.
HTTP/2 carries many requests and responses on one TCP connection at the same time. It splits each message into binary frames and labels every frame with a stream number, one stream per request, so frames from different requests can be interleaved and reassembled at the other end. A slow response no longer holds up the ones behind it on the same connection.
Think of several conversations sharing one phone line, taking turns a sentence at a time, so no conversation waits for another to finish. The comparison breaks in one place: on a phone line a crackle loses one word, but on TCP a lost packet silences every conversation until it is resent.
| Request | HTTP/1.1, one connection | HTTP/2, one connection |
|---|---|---|
| Report data, slow to generate | Sent first; its response takes 900 ms | Stream 1; its frames arrive when ready |
| Stylesheet | Waits for the report to finish | Stream 3; arrives at once, between report frames |
| Logo image | Waits for the stylesheet | Stream 5; arrives at once |
HTTP/1.1 answers requests on one connection strictly in order: a response must finish before the next one starts. That is head-of-line blocking at the HTTP level. Browsers work round it by opening up to six connections per site, each paying its own handshakes, and sites worked round it by bundling files together.
HTTP/2 changes three things.
Binary framing. Messages are split into frames with a type, a length and a stream number, which are faster to parse than lines of text and leave no doubt about where a message ends.
Multiplexing. Many streams share one connection, their frames interleaved, so the slow report does not delay the stylesheet. One connection also means one handshake and one congestion window that warms up once.
Header compression. Headers repeat across requests, such as cookies and user agents. HPACK sends each one once and refers back to it, saving bytes on every request.
What HTTP/2 does not fix is the layer underneath. All the streams still travel in one TCP stream, and TCP delivers bytes in order. A single lost segment holds back every stream's frames until it is resent, so on a lossy network HTTP/2 can do worse than HTTP/1.1's six connections.
So HTTP/2 removes the waiting caused by slow responses, and leaves the waiting caused by lost packets, which is the problem HTTP/3 takes on.
← → move through sections and cards