HTTP/2 Protocol

What is HTTP/2?

HTTP/2 is the second major version of the HTTP protocol, standardized in 2015, that dramatically improved web performance over HTTP/1.1 without changing HTTP’s semantics (methods, status codes, headers all stay the same). Its central innovation is multiplexing: sending many requests and responses concurrently over a single TCP connection, interleaved, instead of HTTP/1.1’s one-request-at-a-time-per-connection limitation. Along with header compression and other efficiencies, this made pages load faster, and HTTP/2 became widely adopted across the web — though it has since been partly succeeded by HTTP/3.

What it fixed — the HTTP/1.1 bottlenecks

To appreciate HTTP/2 you need HTTP/1.1’s problems. Under HTTP/1.1, a connection handles one request at a time — the browser sends a request and must essentially wait for the response before reusing the connection (pipelining existed but was problematic), so loading a page with dozens of assets meant either serializing them or opening many parallel connections (browsers cap around 6 per domain), each with its own setup overhead. This caused head-of-line blocking at the application layer and wasted resources. HTTP/2 addressed this with several features: multiplexing (many concurrent request/response streams over one connection, so a slow asset doesn’t block others at the HTTP layer and you don’t need a pile of connections); header compression (HPACK) (HTTP headers are repetitive and verbose, and compressing them saves meaningful bandwidth, especially for many small requests); stream prioritization (hinting which resources matter most); binary framing (a binary protocol rather than HTTP/1.1’s text, more efficient to parse); and server push (the server proactively sends resources it knows the client will need). Together these cut latency and connection overhead substantially, and because HTTP/2 kept HTTP’s semantics unchanged, adoption mostly required server/CDN support rather than application rewrites.

The catch, and the move to HTTP/3

HTTP/2’s important limitation is subtle and is exactly what motivated HTTP/3: HTTP/2 still runs over TCP, and TCP guarantees in-order delivery of its single byte stream — so while HTTP/2 removed head-of-line blocking at the application layer, a single lost packet at the TCP layer stalls all the multiplexed streams on that connection until the packet is retransmitted (TCP head-of-line blocking). On lossy networks (mobile, congested Wi-Fi) this can erode HTTP/2’s gains. HTTP/3 solves it by running over QUIC (a UDP-based transport with independent streams), so a lost packet affecting one stream doesn’t block the others. Practical notes for engineers: server push turned out to be a disappointment — it was hard to use effectively (pushing resources the client already had wasted bandwidth), most implementations found little benefit, and it’s been deprecated/removed in practice (replaced by techniques like 103 Early Hints), so don’t reach for it. Some HTTP/1.1-era optimizations became anti-patterns under HTTP/2: domain sharding (spreading assets across domains to get more parallel connections) and aggressive asset concatenation were workarounds for HTTP/1.1’s connection limits, and under HTTP/2’s multiplexing they can hurt (extra connections, poor caching granularity) — so old performance advice should be re-examined. Enabling HTTP/2 is largely a matter of turning it on at your server/CDN/load balancer (it requires TLS in practice, since browsers only do HTTP/2 over HTTPS), with automatic fallback to HTTP/1.1 for clients that don’t support it. The recurring mistakes: carrying forward HTTP/1.1 optimizations (sharding, over-concatenation) that backfire under HTTP/2, and expecting server push to help (it doesn’t).

What people get wrong

• Keeping HTTP/1.1 optimizations — domain sharding and heavy asset concatenation were workarounds for HTTP/1.1’s connection limits and can hurt under HTTP/2’s multiplexing.
• Relying on server push: it proved ineffective and is effectively deprecated — use 103 Early Hints and normal caching instead.
• Forgetting TCP head-of-line blocking — HTTP/2 fixed application-layer blocking but not TCP’s; on lossy networks a lost packet still stalls all streams, which is exactly why HTTP/3 (over QUIC) exists.

Primary source: RFC 9113: HTTP/2