The encyclopedia · Software & IT · Technical decision · 2009-2015
HTTP/2 kept HTTP semantics but multiplexed many streams onto one connection
HTTP/2 added binary framing and multiplexing over one TLS connection, and dropped in without changing HTTP's meaning.
Google · IETF
the move
HTTP/1.1 opened a new connection for each request or reused a few, forcing browsers to open about six parallel connections to a site. Each connection paid a separate handshake, and a slow response on one blocked the others behind it. The web was slow for structural, not technical, reasons.
Google's SPDY proved the fix: keep HTTP's methods, headers and status codes exactly as they are, but move the traffic into a single connection carrying many multiplexed streams. The IETF took that work and standardized it as HTTP/2 in RFC 7540, with binary framing and HPACK header compression.
Because the semantics stayed identical, servers and browsers could adopt it without rethinking what an HTTP request means. The transport changed; the contract did not, so every site won the speedup for free.
why it works
- Because HTTP semantics were untouched, existing servers could add support without changing how applications write responses.
- One connection with many streams removes the six-connection bottleneck and the connection-setup tax on every resource.
- HPACK compresses repeated headers, so the same cookie and user-agent fields stop resending on each request.
- Server push let a server send assets before the client asked, cutting out a round trip.
what transfers
A compatibility-preserving transport can win even when the semantics do not change; keep the contract and swap the plumbing.
what came after
RFC 7540 was finalized in May 2015 and became the default for essentially all HTTPS traffic. Its main remaining problem was TCP head-of-line blocking, which led directly to QUIC and HTTP/3. HTTP/2 also enabled request smuggling and the HTTP/2 rapid reset DoS pattern discovered in 2023.
references
spotted an error? The archive wants to know.