What are the differences between HTTP/1.1, HTTP/2, and HTTP/3?

Question

IT Interview Practice · Accepted Answer

All three deliver the same HTTP semantics (methods, headers, status codes) but differ in *how* they move bytes over the wire — each version fixes a bottleneck of the previous one. The theme is **removing head-of-line (HOL) blocking**, where one stuck request holds up others.

```text
HTTP/1.1  over TCP     one request at a time per connection
  conn ──[req A]──[req B]──[req C]──▶   B waits for A (HOL blocking at HTTP layer)

HTTP/2    over TCP     many streams multiplexed on ONE connection
  conn ══[A|B|C interleaved]══▶        but a lost TCP packet stalls ALL streams
                                       (HOL blocking moves down to TCP)

HTTP/3    over QUIC (UDP)   independent streams, per-stream delivery
  conn ══[A][B][C]══▶                  a lost packet stalls only its own stream
```

**HTTP/1.1** sends one request per connection at a time; browsers work around this by opening ~6 parallel connections per host, and text headers are sent uncompressed. **HTTP/2** adds **multiplexing** — many concurrent **streams** over a single connection — plus binary framing, header compression (HPACK), and server push. But because it still runs on TCP, a single lost packet blocks *every* stream until it's retransmitted: HOL blocking simply moved from the HTTP layer down to TCP.

**HTTP/3** solves that by running on **QUIC**, a new transport built on **UDP**. QUIC implements streams itself, so loss on one stream doesn't stall the others. It also merges the transport and TLS handshakes (1-RTT, often 0-RTT on resume) for faster connection setup, and supports **connection migration** so a session survives a network change (Wi-Fi → cellular).

## Why it matters

This is a favorite middle-level question because the answer is a story of *problem → fix → new problem → fix*, which is exactly how a strong engineer reasons about evolving systems. The key insight interviewers look for is understanding **head-of-line blocking at two layers**: HTTP/2 solved it at the application layer but was still trapped under TCP, and HTTP/3 had to change the transport itself to finish the job. It's also practical: knowing this guides real decisions about connection reuse, whether to still shard domains, and what you gain by enabling HTTP/3 at your CDN.

Why it matters

Related questions