HTTP/2 vs HTTP/3

HTTP/1.1: Persistent Connections and Their Limits serialises: one request in flight per connection (pipelining never worked in practice), so browsers open ~6 connections per host and sites resorted to domain sharding, sprites and inlining. Headers are repeated as text on every request — hundreds of bytes of cookies per image. HTTP/2 (HTTP/2: Streams on One Connection) keeps HTTP’s semantics and changes the wire: a binary framing layer, many streams multiplexed over one TCP connection, HPACK header compression with a shared dynamic table, stream priorities, and (rarely useful, since removed from Chrome) server push. One connection means one handshake, one slow start and one congestion window instead of six.

What it leaves behind is everything below it. All streams share a single ordered TCP byte stream, so one lost packet stalls every stream until retransmission — HTTP/2 concentrates the loss that HTTP/1.1 spread across six connections (Head-of-Line Blocking). The connection still costs a TCP round trip plus one or two for TLS. It is bound to a four-tuple, so a phone moving from Wi-Fi to cellular loses every in-flight stream. And TCP is implemented in kernels and inspected by middleboxes, so changing it (new options, new loss recovery) takes years to reach users — the protocol has *ossified*.

HTTP/3 (HTTP/3 and QUIC) runs over QUIC, a transport in user space over UDP with TLS 1.3 built in. Streams are the unit of loss recovery, so a lost packet blocks only the streams it carried — cross-stream HOL is gone, intra-stream HOL is not. The transport and crypto handshakes merge into one round trip, 0-RTT on resumption. Connections are identified by a connection ID rather than the four-tuple, so they survive an address change. Packet numbers never repeat, which makes loss detection unambiguous, and being in user space means Chrome or a CDN can ship a congestion-control change in weeks. Header compression becomes QPACK, redesigned so a lost header packet does not necessarily block other streams.

When *not* to: when UDP is blocked or throttled — some corporate networks and ISPs do exactly that — so every deployment must keep a TCP fallback and discovery is via Alt-Svc or the HTTPS DNS record, meaning the *first* visit is still TCP. When server CPU per byte matters: user-space packet handling without the offloads TCP enjoys (segmentation, checksum, kTLS) costs measurably more CPU, though UDP GSO has narrowed the gap. When observability and tooling matter — L4 load balancers must route on connection ID rather than four-tuple, firewalls and packet captures see opaque UDP, and existing dashboards are TCP-shaped. And when the network is already good: inside a datacenter or on a wired LAN with ~0 loss and sub-millisecond RTT, the wins are near zero; the gains are at the tail on lossy, high-latency, mobile paths. gRPC between services stays on HTTP/2 for good reason.