HTTP/1.1 vs HTTP/2 vs HTTP/3: real differences developers should know

HTTP/1.1 vs HTTP/2 vs HTTP/3

The HTTP version determines how requests are serialized over the wire, not what the messages contain. The headers and methods are the same — the transport changes.

HTTP/1.1: one request at a time

Each request blocks the connection until the response completes — head-of-line blocking. Browsers work around this by opening 6 parallel TCP connections per origin. Domain sharding (splitting assets across subdomains) was a hack to get more parallel connections.

HTTP/2: multiplexing on one connection

HTTP/2 sends multiple requests and responses interleaved over a single TCP connection using binary frames. Each request gets a stream ID. The receiver reassembles streams independently.

Stream 1: GET /api/users   →  200 response frames
Stream 3: GET /api/orders  →  200 response frames
Stream 5: GET /style.css   →  200 response frames
# All concurrent, one TCP connection

HTTP/2 also compresses headers with HPACK (sending only deltas between requests) and supports server push — though push was removed from Chrome and is rarely used.

HTTP/3: built on QUIC (UDP)

HTTP/2 multiplexing over TCP still has head-of-line blocking at the TCP level — one lost packet stalls all streams. HTTP/3 uses QUIC over UDP where packet loss only affects the one stream it belongs to. QUIC also combines TLS 1.3 into the handshake, reducing connection setup from 3 round-trips to 1 (and 0-RTT for repeat visits).