HTTP/2 and HTTP/3

HTTP/1.1 shipped in 1999 and ruled the web for 16 years. But by 2010, web pages had ~100 resources each (images, scripts, styles), and HTTP/1.1's one-request-per-connection model was creaking. Browsers opened 6 parallel TCP connections per host to work around it, wasting connections and confusing servers. Something had to give.

In 2009, Google engineers Mike Belshe and Roberto Peon shipped an experimental protocol called SPDY (pronounced "speedy") that multiplexed many requests over one connection. Chrome and Firefox supported it. In 2015 SPDY became HTTP/2 (RFC 7540). Then in 2018, Google shipped QUIC (Quick UDP Internet Connections), which solved TCP's head-of-line blocking. In 2022, HTTP/3 (RFC 9114) standardized HTTP over QUIC.

These aren't academic upgrades. They fundamentally change how the web performs. HTTP/2 alone typically cuts page-load time 20-30%. HTTP/3 shaves another 10-15% on top, especially on mobile networks with packet loss. As of 2024, ~35% of internet traffic runs on HTTP/3, and it's growing fast.

HTTP/1.1 — the bottleneck

HTTP/1.1's core rule: one request per TCP connection at a time. If you have 100 resources to fetch, that's 100 sequential requests over 1 connection. Browsers cheated by opening 6 parallel connections — but 6 < 100. The result: head-of-line blocking at the application layer. If request #1 is slow, request #2 can't start.

HTTP/1.1 also has verbose text headers. Every request repeats: Host: example.com, User-Agent: Mozilla/5.0 …, Cookie: session=…, etc. A typical page fetches 100 resources, each with ~800 bytes of duplicated headers = ~80 KB of overhead. That's the target HTTP/2 attacks.

HTTP/2 — multiplex it all

HTTP/2 breaks the request-per-connection rule. Instead: one TCP connection carries many concurrent streams, each stream is an independent request-response pair. All streams share the connection but can complete in any order.

Three big innovations enable this:

• Binary framing: HTTP/2 is a binary protocol. Every message is a series of framed chunks tagged with a stream ID. Requests, responses, headers, and body all coexist on the wire.
• HPACK header compression: HTTP headers are compressed with a state-machine encoding. Common headers get 1-2 bytes instead of 40-800. Cumulative bandwidth savings on typical pages: 40-70%.
• Server push (mostly deprecated): server can proactively send resources it knows the client will need. In practice this was too hard to use safely; Chrome removed support in 2022.

HTTP/2's Achilles heel — TCP head-of-line blocking

HTTP/2 solved application-level HoL blocking (many streams per connection). But it kept TCP as the transport — and TCP itself does HoL blocking. TCP delivers bytes in order. If one packet is lost, TCP holds every subsequent packet in a kernel buffer, waiting to reassemble in order — even if those subsequent packets belong to different HTTP/2 streams.

On a lossless network HTTP/2 is fantastic. On a lossy mobile network, HTTP/2 can be worse than HTTP/1.1 — because HTTP/1.1's parallel connections isolate each stream from the loss on the others. This is the specific problem QUIC solves.

HTTP/3 — HTTP over QUIC over UDP

HTTP/3 abandoned TCP. It runs on QUIC, a new transport protocol built on UDP that provides TCP's reliability + ordering per-stream — with independent streams that don't block each other.

Four QUIC innovations:

• Independent streams: loss on stream 1 doesn't block stream 2. Solves TCP HoL blocking at the transport layer.
• Integrated TLS 1.3: QUIC handshake and TLS handshake are one operation. 1-RTT from cold start to encrypted app data.
• 0-RTT resumption: reconnecting clients can send encrypted data in the first packet, before the handshake completes.
• Connection migration: connection ID stays stable across IP changes. Your phone switches WiFi → LTE, QUIC connection continues without dropping.

Version comparison — HTTP/1.1 vs 2 vs 3

Applied in real systems

Key takeaways

• HTTP/1.1 → HTTP/2: single TCP connection with binary framing + multiplexed streams + HPACK header compression. Solves application-level HoL blocking.
• HTTP/2's weakness: TCP still does HoL blocking at the transport layer. One dropped packet stalls all streams. Bad on lossy mobile networks.
• HTTP/3: runs on QUIC (UDP-based) with independent streams. Loss on one stream doesn't block others. 1-RTT handshake (0-RTT resumption). Connection ID survives IP changes.
• QUIC integrates TLS 1.3: encryption is mandatory and combined with transport handshake. No plain-text QUIC exists in production.
• Adoption: HTTP/2 is nearly universal (~99% of top-10K sites support it). HTTP/3 is ~35% and rising fast, with Google, Cloudflare, Meta, YouTube leading.
• Server push (HTTP/2 feature) failed — Chrome removed support 2022. HTTP/3 doesn't have it. The replacement is 103 Early Hints.
• The next version, HTTP/3+ or MASQUE, is being drafted — layers a VPN-like tunnel on top of QUIC.

References

• RFC 7540 (2015) — HTTP/2 specification.
• RFC 7541 (2015) — HPACK header compression.
• RFC 9000 (2021) — QUIC v1 protocol.
• RFC 9114 (2022) — HTTP/3 semantics.
• Ilya Grigorik — High Performance Browser Networking. Free online. The definitive treatment.
• Robin Marx — HTTP/3 explainer blog posts (calendar.perfplanet.com). Best deep-dive for engineers.