HTTP/2 multiplexing and head-of-line blocking

The top chart counts finished objects over time for each protocol; the waterfall below shows the selected protocol, one row per object, from request to last byte. Click a protocol's name to see its waterfall and its event log.

• With no loss, compare HTTP/1.1's waterfall, a staircase of six connections taking one object at a time, with HTTP/2's, where everything is requested together and arrives interleaved.
• Set loss to 1%. HTTP/2 rows turn red where an object had already arrived but was held behind another object's lost packet. HTTP/3 has none.
• Notice that at 1% loss HTTP/1.1 may finish first: six connections keep six congestion windows, and each loss cuts only one of them.

HTTP/2 is the second major version of the Hypertext Transfer Protocol. It keeps HTTP's meaning, the same methods, status codes and headers, and changes how messages travel: instead of text, each request and response is split into binary frames on a numbered stream, and many streams share one TCP connection. Headers are compressed with HPACK. Browsers use HTTP/2 only over TLS, negotiated with the ALPN extension as h2.

The point was latency. A web page needs dozens of files from the same server, and HTTP/1.1 makes them wait in line.

An HTTP/1.1 connection carries one response at a time: the next request on it waits until the previous response has been fully received. Pipelining, sending several requests without waiting, was in the standard but responses still had to come back in order, and buggy proxies made browsers disable it. So browsers open several connections to each server, typically six, and sites worked around the limit by spreading files over several hostnames (domain sharding), combining scripts into bundles and images into sprites.

Every extra connection costs a TCP and TLS handshake and starts with a small congestion window. With no loss, the 40-file page in the simulator (1007 KB) finishes at these times over a 20 Mbit/s link:

Every HTTP/2 frame starts with a 9-byte header: a 24-bit length, an 8-bit type, 8 bits of flags and a 31-bit stream identifier. The payload is at most 16,384 bytes unless the receiver allows more. The main frame types are HEADERS and CONTINUATION (a header block), DATA (the body), SETTINGS (connection parameters), WINDOW_UPDATE (flow control), RST_STREAM (cancel one stream), PING, GOAWAY (shut the connection down gracefully) and PUSH_PROMISE (server push).

A request is a HEADERS frame on a new stream, odd-numbered because the client opened it; the response comes back as HEADERS and DATA frames on the same stream. Because frames from different streams can be interleaved, a large response no longer blocks a small one behind it, and a request can be cancelled without closing the connection.

HTTP/2 removed head-of-line blocking from HTTP, but TCP has its own. TCP presents a single ordered byte stream, so when a packet is lost, every byte after it waits in the receiver's buffer until the retransmission arrives, roughly one round trip later, even bytes belonging to other HTTP/2 streams. HTTP/3 runs over QUIC, whose streams are ordered independently, so a loss holds back only the stream it belongs to.

The page over a 100 ms, 20 Mbit/s link, averaged over 5 loss patterns:

HTTP/2 adds flow control above TCP's: each stream and the whole connection have a receive window, 65,535 bytes initially, that the sender must stay within and the receiver reopens with WINDOW_UPDATE frames. It lets a receiver, often a proxy, pause one stream without stopping the rest.

With everything sent at once, the order matters: the stylesheet should arrive before the images. RFC 7540 defined a tree of stream dependencies and weights, which proved complex and was implemented inconsistently; RFC 9113 deprecated it, and RFC 9218 replaced it with a simpler scheme of an urgency level from 0 to 7 and an incremental flag, carried in a priority header. The simulator either interleaves all responses round-robin or sends them one at a time in request order, which is what RFC 9218 asks for when responses of equal urgency are not incremental.

Server push, where the server sends a response the client has not yet asked for, rarely helped in practice and was disabled by default in Chrome 106 in 2022. The 103 Early Hints status code now does the same job by telling the browser what to request.

The model sends packets of 1,200 bytes through a bottleneck of fixed rate and round-trip time, dropping a random fraction of data packets with a seeded generator. TCP and QUIC follow the same rules for sending, so the comparison isolates the protocols' differences: a congestion window starting at 10 packets, slow start until the first loss, a cut to 0.7 of the window on loss, and loss detection by the packet and time thresholds of RFC 9002. HTTP/1.1 uses up to six connections with one request each at a time; HTTP/2 one TCP connection; HTTP/3 one QUIC connection. TCP and TLS 1.3 take two round trips before the first request, QUIC one.

It leaves out TLS record overhead, delayed ACKs, pacing, receive windows, HTTP/2 flow control, request bodies and server think time. It is checked headless: every byte of every object is delivered exactly once, in order within the object; the link rate is never exceeded; with no loss HTTP/2 and HTTP/3 differ by exactly the extra handshake round trip; and HTTP/3 never shows cross-stream blocking.

Google announced SPDY in 2009 and shipped it in Chrome; it introduced multiplexed streams, header compression and server push over TLS. The IETF's HTTPbis working group took SPDY as the starting point for HTTP/2, published as RFC 7540 in May 2015 with HPACK as RFC 7541, and browsers dropped SPDY the following year. In June 2022 RFC 9113 replaced RFC 7540, deprecating the original priority scheme, alongside RFC 9114 for HTTP/3.