HTTP/2

HTTP/2 keeps every semantic from HTTP/1.1 — the same methods, status codes, and headers — and throws away the text wire format that carried them. In its place is a binary, multiplexed framing layer: the connection is divided into independent streams, each carrying one request/response, and frames from many streams interleave on a single TCP connection. The thing browsers used to do — open six parallel connections to get concurrency — becomes one connection carrying dozens of concurrent exchanges.

It also compresses headers with HPACK, because in HTTP/1.1 the same fat header block (cookies, user-agent, accept lists) was re-sent verbatim on every request. HTTP/2 kills HTTP/1.1's head-of-line blocking at the HTTP layer — but it rides on one TCP connection, and a single lost TCP segment still stalls every stream underneath it. That residual blocking, at the transport layer this time, is exactly the problem HTTP/3 was built to remove.

Streams, Frames, and Multiplexing

An HTTP/2 connection carries many streams, each identified by a numeric ID and representing one request/response pair. A stream is a sequence of frames — a HEADERS frame carries the request or response headers, DATA frames carry the body, and control frames like SETTINGS, WINDOW_UPDATE, and RST_STREAM manage the connection. Each frame is tagged with its stream ID, so the receiver can demultiplex interleaved frames back into the right streams.

This is what multiplexing means: stream 1's response and stream 3's response travel as interleaved frames on the same wire, neither waiting on the other. A slow response on one stream no longer blocks a fast one on another, which was impossible in HTTP/1.1 where responses came back strictly in order. Flow control is per-stream and per-connection via WINDOW_UPDATE, so one greedy download cannot starve the others. The whole point is concurrency without the cost of multiple connections.

# nghttp -v shows the frame trace — note interleaved stream IDs
nghttp -nv https://example.com/
 recv SETTINGS frame <stream_id=0>
 send HEADERS frame <stream_id=1>   GET /
 send HEADERS frame <stream_id=3>   GET /style.css
 recv HEADERS frame <stream_id=3>   200   <- stream 3 replies first
 recv DATA    frame <stream_id=3>
 recv HEADERS frame <stream_id=1>   200   <- out of request order, fine

HPACK Header Compression

Headers are repetitive and large. The same Cookie, User-Agent, and Accept lines go out on every request, easily hundreds of bytes each, and HTTP/1.1 sent them in full every time. HPACK fixes this with a shared dynamic table: once a header has been sent, both ends remember it, and later requests reference it by a small index instead of re-spelling the whole field. A static table covers common headers like :method: GET out of the box, so they cost one byte.

HPACK is deliberately not a general compressor like gzip, and that is a security decision. The CRIME and BREACH attacks showed that compressing attacker-influenced data alongside secrets leaks the secrets through compressed size; HPACK's index-based scheme with a bounded table avoids that class of attack while still collapsing repeated headers. The result is that the header overhead that made many small HTTP/1.1 requests expensive largely disappears — header-heavy API traffic benefits the most.

Server Push and Its Retirement

Server push let a server send resources the client had not yet requested — push the CSS and JS alongside the HTML, before the browser parsed the page and asked for them. On paper it saved a round trip. In practice it was a mess: the server pushed assets the browser already had cached, wasting bandwidth, and getting the priority and timing right was harder than the saving was worth.

Chrome removed support in 2022 and the feature is effectively dead. The problem push tried to solve — telling the browser to fetch a critical resource early — is now handled by the 103 Early Hints status and <link rel=preload> hints, which let the browser decide whether it actually needs the resource rather than the server guessing. Building anything new on server push today is building on a retired feature.

The Residual TCP Head-of-Line Blocking

Multiplexing solved head-of-line blocking at the HTTP layer, but HTTP/2 still runs over a single TCP connection — and TCP delivers bytes strictly in order. When one TCP segment is lost, TCP holds back every byte that arrived after it until the retransmission fills the gap, because it cannot hand the application data out of order. To TCP, the multiplexed streams are just one undifferentiated byte stream.

So a single dropped packet stalls all the HTTP/2 streams at once, even the ones whose data already arrived intact, because they are queued behind the missing segment in TCP's receive buffer. On a clean network this never shows; on a lossy mobile link it can make HTTP/2 perform worse than six independent HTTP/1.1 connections, where a loss on one connection only stalls that one. This is the wall HTTP/2 could not climb — and the reason HTTP/3 moved off TCP onto QUIC, where each stream has its own delivery.