HTTP/1.1 vs HTTP/2 vs HTTP/3
Multiplexing, header compression, QUIC, head-of-line blocking
HTTP/1.1 (RFC 2616, 1999) introduced persistent connections but suffers from head-of-line blocking at the request level. HTTP/2 (RFC 7540, 2015) introduced binary framing, multiplexing (multiple streams over one TCP connection), header compression (HPACK), and server push — reducing latency by 20–50% for typical web pages. HTTP/3 (RFC 9114, 2022) replaces TCP with QUIC, eliminating transport-layer head-of-line blocking and enabling 0-RTT connection resumption, reducing median page-load time by a further 10–15%.
Key Points
- HTTP/1.1 pipelining (sending multiple requests without waiting for responses) was theoretically multiplexed but disabled by default in browsers due to proxy incompatibility — effectively limiting to 1 outstanding request per connection.
- Browser workaround for HTTP/1.1 HOL blocking: open 6–8 parallel TCP connections per host — a hack that wastes OS resources and causes TCP congestion interactions.
- HTTP/2 binary framing: data is split into frames (HEADERS, DATA, SETTINGS, WINDOW_UPDATE) — enabling true multiplexing where a slow large response does not block smaller ones on the same connection.
- HPACK header compression in HTTP/2 uses static (61-entry predefined table) and dynamic (session-level) huffman-coded tables — compresses headers by 80–90% vs HTTP/1.1 verbatim repetition.
- HTTP/2 server push has been deprecated in Chrome (2022) due to complexity and over-pushing — use `Link: rel=preload` header or `103 Early Hints` instead for resource hinting.
- HTTP/3 + QUIC solves transport HOL blocking: if a UDP packet is lost, only the stream waiting for that data stalls; other streams proceed — critical on lossy mobile networks.
- HTTP/3 0-RTT: when reconnecting to a known server, QUIC sends the first application data in the same datagram as the handshake — reducing effective connection time to ~0 ms on resumed sessions.
- HTTP/3 adoption (2024): ~30% of web traffic uses HTTP/3; all major CDNs (Cloudflare, Fastly, CloudFront) and browsers support it; backend-to-backend gRPC typically still uses HTTP/2.
| Feature | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Transport protocol | TCP | TCP | QUIC (over UDP) |
| Connection setup | 1 RTT TCP + 2 RTT TLS 1.2 | 1 RTT TCP + 1 RTT TLS 1.3 | 0–1 RTT (QUIC + TLS 1.3) |
| Multiplexing | No (HOL blocking) | Yes (binary streams) | Yes (independent QUIC streams) |
| Transport HOL blocking | Yes | Yes (TCP level) | No |
| Header format | Plain text | Binary + HPACK compressed | Binary + QPACK compressed |
| Header compression | None | HPACK (~80–90% reduction) | QPACK (HOL-block-free variant) |
| Server push | No | Yes (deprecated in Chrome) | Limited / not widely used |
| Connection migration | No | No | Yes (via Connection ID, mobile IP change) |
| Typical latency gain | Baseline | 20–50% faster page loads | Additional 10–15% on lossy networks |
| RFC | RFC 2616 (1999) | RFC 7540 (2015) | RFC 9114 (2022) |
Real-World Example
Cloudflare reports that HTTP/3 reduces median TTFB (Time To First Byte) by 12% and p99 latency by 34% compared to HTTP/2 for mobile users on high-packet-loss LTE networks, where QUIC's per-stream loss recovery has the most impact.