HTTP/2 kept HTTP semantics but multiplexed many streams onto one connection

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.

Freeze HTTP's semantics; run streams over one connection.

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.

A compatibility-preserving transport can win even when the semantics do not change; keep the contract and swap the plumbing.

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.