HTTP/1.1 vs HTTP/2 vs HTTP/3
The Question
What are the key differences between HTTP/1.1, HTTP/2, and HTTP/3?
What a Strong Answer Covers
- HOL blocking" term
- HTTP/2 multiplexing
- "HTTP/3 = QUIC/UDP
Senior-Level Answer
HTTP has evolved through three major versions, each addressing the performance limitations of its predecessor.
**HTTP/1.1** (1997) is text-based and sequential. Each request-response pair uses a TCP connection, and without pipelining (which was poorly implemented), only one request can be in-flight per connection. Browsers work around this by opening 6-8 parallel TCP connections per origin, but each connection incurs its own TCP handshake and TLS negotiation overhead. Head-of-line (HOL) blocking is a fundamental problem: a slow response on connection 1 blocks all subsequent requests on that connection.
**HTTP/2** (2015) is binary and multiplexed. Key improvements: - **Binary framing**: data is split into binary frames rather than text, enabling efficient parsing and mixing of frames from multiple streams on a single TCP connection. - **Multiplexing**: multiple request/response streams share a single TCP connection. A slow response does not block other streams — eliminating HTTP-level HOL blocking and removing the need for multiple parallel connections. - **Header compression (HPACK)**: HTTP headers are compressed using a shared dynamic table, reducing overhead significantly for repetitive headers (cookies, authorization). - **Server push**: the server can proactively send resources (CSS, JS) before the client requests them.
HTTP/2 still suffers from **TCP-level HOL blocking**: a single lost TCP packet blocks all multiplexed HTTP/2 streams until the packet is retransmitted, because TCP delivers bytes in order.
**HTTP/3** (2022) replaces TCP with **QUIC** (Quick UDP Internet Connections) built on UDP. Key improvements: - **No TCP HOL blocking**: QUIC tracks streams independently. A lost packet only blocks the stream it belongs to, not all streams. - **0-RTT and 1-RTT connection establishment**: QUIC combines the transport and TLS 1.3 handshakes. Returning users can send data with 0 round trips (0-RTT), vs. 3+ round trips for a new TCP+TLS 1.2 connection. - **Connection migration**: QUIC connections are identified by a connection ID, not a 4-tuple (src IP, src port, dst IP, dst port). Mobile clients moving between Wi-Fi and cellular maintain their connections without re-establishing. - **Improved congestion control**: QUIC implements congestion control in user space, enabling faster iteration and per-stream flow control.
In practice: HTTP/2 is now universal for HTTPS. HTTP/3 is supported by ~30% of web traffic (all major CDNs). The performance gains from HTTP/3 are most pronounced on lossy networks (mobile, high-latency connections).
Key Differences
| Aspect | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Transport | TCP | TCP | QUIC (UDP) |
| Encoding | Text | Binary frames | Binary (QUIC) |
| Multiplexing | No (1 req/connection) | Yes (single TCP conn) | Yes (independent QUIC streams) |
| HOL blocking | HTTP + TCP level | TCP level only | Eliminated |
| Header compression | None | HPACK | QPACK |
| Connection setup | TCP + TLS (2-3 RTT) | TCP + TLS (2-3 RTT) | QUIC (0-1 RTT) |
| Connection migration | No | No | Yes (connection ID) |
What Separates a 2/3 from a 3/3
2/3 — Passing but Incomplete
Correctly explains HTTP/2 multiplexing and binary framing, explains that HTTP/2 still has TCP-level HOL blocking, and explains QUIC's role in HTTP/3.
3/3 — Strong Answer
Distinguishes HTTP-level vs. TCP-level HOL blocking, explains HPACK vs. QPACK header compression, covers 0-RTT connection establishment, and discusses connection migration and its mobile use case.
Common Mistakes
- Saying HTTP/2 eliminates HOL blocking completely — it eliminates HTTP-level HOL but TCP-level HOL remains.
- Describing HTTP/3 as just 'HTTP/2 over UDP' — QUIC is a full transport protocol with its own reliability, flow control, and congestion control.
- Forgetting server push in HTTP/2 — it was widely implemented but largely abandoned due to complexity; worth mentioning as a design intent.
- Not explaining why QUIC uses UDP rather than TCP — UDP allows user-space implementation of transport semantics without OS kernel involvement.
Follow-Up Questions
- If HTTP/2 already multiplexes streams, why does HTTP/3 still provide a significant improvement on mobile networks? — TCP HOL blocking — a single dropped packet stalls all HTTP/2 streams; QUIC's independent streams only stall the affected one, which matters significantly on lossy mobile networks.
- What is 0-RTT in QUIC and what are its security implications? — 0-RTT resumes connections without a handshake using cached session state — improves latency for returning users but is vulnerable to replay attacks; applications must make 0-RTT requests idempotent.
- How does HPACK header compression work and why was QPACK needed for HTTP/3? — HPACK uses a shared dynamic compression table that requires in-order delivery — works on TCP but breaks on QUIC where frames arrive out of order; QPACK separates encoder/decoder streams to handle reordering.
- When would you NOT want to enable HTTP/2 server push? — Server push guesses what the client needs — if the client has the resource cached, you've wasted bandwidth; browser support is being removed; HTTP Early Hints (103) is the emerging replacement.
Related Questions
Can You Explain This Cold?
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment