HTTP Versions

1HTTP/0.9 and HTTP/1.0 (Historical)

HTTP/0.9 (1991) was a single GET /path line, no headers, no status code, connection closed immediately after the response — enough to fetch a document and nothing else. HTTP/1.0 (1996) added headers, status codes, and other methods, but opened a new TCP connection per request by default, which is expensive (see the TCP handshake cost in the HTTP Fundamentals topic).

2HTTP/1.1 (1997) — Still Widely Used

HTTP/1.1 made connections persistent by default (Connection: keep-alive) so multiple requests could reuse one TCP connection, and added chunked transfer encoding, Host header (required — enables name-based virtual hosting on the same IP), and conditional requests (If-None-Match, etc.).

The unsolved problem: head-of-line (HOL) blocking on the connection. HTTP/1.1 is fundamentally a serial protocol on a given connection — the server must send complete response N before response N+1 can begin, even if response N+1 finished processing first. Browsers work around this by opening multiple parallel TCP connections per host (historically 6) — which just shifts the cost to more handshakes and more contention, it doesn't remove the blocking.

Connection 1: [--- Request A ---][--- Response A ---][--- Request B ---][--- Response B ---]
              (B cannot start until A's response is fully sent, on THIS connection)

3HTTP/2 (2015) — Binary Framing and Multiplexing

HTTP/2 keeps the same semantics (same methods, status codes, headers) but changes the wire format entirely: everything is split into small, length-prefixed, binary frames, and frames from many concurrent logical streams are interleaved over a single TCP connection.

One TCP connection:
  [stream 1 frame][stream 3 frame][stream 1 frame][stream 5 frame][stream 3 frame]...

Each stream carries one request/response pair and has an odd (client-initiated) or even (server-initiated, for now-deprecated Server Push) integer ID. The server can interleave frames from streams 1, 3, and 5 in any order — a large, slow response on stream 3 no longer blocks a small, fast response on stream 1 from being delivered first. Headers are additionally compressed with HPACK, which maintains a shared dynamic table between client and server so repeated header values (cookies, user-agent) across requests on the same connection are sent as small index references instead of full text.

4HTTP/3 (2022) — QUIC over UDP

HTTP/2 solved HOL blocking at the HTTP layer but not underneath it: all streams still share one TCP connection, and TCP itself guarantees in-order byte delivery — if a single packet is lost, TCP holds up every stream's data behind it until that packet is retransmitted, even though the lost bytes might belong to only one HTTP/2 stream. This is transport-level head-of-line blocking, and no amount of HTTP-layer cleverness can fix it while running on TCP.

HTTP/3 solves this by dropping TCP entirely and running over QUIC, a transport protocol built on UDP. QUIC implements its own reliability and multiplexing, but critically, each QUIC stream is independently ordered and independently recovers from loss — a lost packet only blocks the one stream it belonged to, not the others sharing the connection. QUIC also folds the transport and TLS 1.3 handshakes together (often 1 round trip total, sometimes 0 for resumed connections), versus HTTP/2's separate TCP + TLS handshakes.

5Version Comparison

⚠️ Common Pitfalls

1. Assuming HTTP/2 automatically makes an app faster — it removes HTTP-level HOL blocking and reduces connection overhead, but a slow backend or a network with real packet loss still bottlenecks it (and packet loss specifically is where HTTP/2 still suffers from TCP's transport-level HOL blocking).
2. Still domain-sharding assets under HTTP/2 — splitting assets across img1.example.com, img2.example.com was an HTTP/1.1 workaround for the 6-connections-per-host limit; under HTTP/2 it actively hurts, since it defeats multiplexing and forces multiple separate connections/handshakes instead of one.
3. Confusing HTTP/2's HPACK header compression with body compression — HPACK only compresses headers; response body compression (gzip/brotli) is a completely separate mechanism, covered in the Caching and Compression topic.
4. Assuming HTTP/3 needs no fallback — QUIC runs over UDP, which some corporate firewalls and older middleboxes block outright, so real deployments still need to advertise HTTP/3 (via the Alt-Svc header) and gracefully fall back to HTTP/2 over TCP.

📋 Quick Reference

HTTP/1.1: text, TCP, serial-per-connection, workaround = multiple connections
HTTP/2:   binary frames, TCP, multiplexed streams, HPACK headers
HTTP/3:   binary frames, QUIC/UDP, per-stream loss recovery, QPACK headers

HOL blocking fixed at HTTP layer:      HTTP/2, HTTP/3
HOL blocking fixed at transport layer: HTTP/3 only (needs UDP/QUIC, not TCP)

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: http_http_versions_theory.md · generated by tools/build_lessons.py