HTTP/2 and HTTP/3

HTTP/1.1 sends one request at a time per connection; a slow response blocks the ones behind it (head-of-line blocking). Browsers work around this by opening about six connections per origin, and developers used to bundle files, sprite images and shard domains.

HTTP/2 (2015) keeps the same semantics but changes the framing:

• Binary frames and streams: many requests and responses are multiplexed over a single TCP connection, interleaved, so one slow response doesn't block the others at the HTTP level.
• HPACK header compression, which matters because headers (cookies, user agents) repeat on every request.
• Prioritisation hints, later simplified by the Priority header (RFC 9218).
• In browsers it requires TLS; the version is negotiated in the TLS handshake via ALPN (h2).

But TCP itself still delivers bytes in order: one lost packet stalls all streams until it's retransmitted, which hurts on lossy mobile networks.

HTTP/3 (2022) runs over QUIC, a transport built on UDP:

• Streams are independent at the transport level, so packet loss only stalls the affected stream.
• TLS 1.3 is built in, combining transport and crypto handshakes into one round trip, and resumed connections can send data in 0-RTT.
• Connection migration: a connection survives a switch from Wi-Fi to cellular because it's identified by a connection ID, not the IP/port tuple.

Servers advertise HTTP/3 with the Alt-Svc response header or the DNS HTTPS record; browsers then switch. For developers: serve over HTTP/2 or 3, stop domain sharding, and bundle only as much as makes sense for caching.