Day 19: HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP's evolution: solving the same problem three times

Each HTTP version exists because the previous one hit a real, specific limitation — not because someone wanted a bigger version number.

HTTP/1.1

Text-based, one request per TCP connection by default (though keep-alive lets you reuse a connection sequentially). Requests on the same connection are processed strictly in order — if one is slow, everything queued behind it waits (head-of-line blocking). Browsers worked around this by opening multiple parallel connections per domain, which has its own overhead (each pays its own slow-start cost, Day 16).

HTTP/2

Introduces multiplexing: many requests and responses interleave over a *single* TCP connection using binary framed streams, so one slow response no longer blocks unrelated ones on the same connection. Also adds header compression (HPACK) and server push (largely unused in practice).

HTTP/3

Replaces TCP entirely with QUIC, built on UDP. This solves HTTP/2's remaining problem: because HTTP/2 still runs over one TCP connection, a single lost *packet* stalls every multiplexed stream waiting on TCP's in-order delivery (TCP-level head-of-line blocking). QUIC implements its own reliability per-stream, so one lost packet only stalls the stream it belongs to.