HTTP/2 vs HTTP/3

HTTP/2 and HTTP/3 solve the same problem – multiplexing many requests efficiently over one connection – but at different layers of the stack. HTTP/2 runs over TCP. TCP guarantees reliable, ordered delivery at the transport layer. If a single TCP packet is lost, all streams on that connection pause until the packet is retransmitted, even streams that have nothing to do with the lost packet. This is TCP head-of-line blocking. HTTP/2's application-layer multiplexing cannot escape the TCP constraint it runs on. HTTP/3 runs over QUIC, which uses UDP as its transport. QUIC implements reliable delivery per stream rather than per connection. A lost UDP packet only blocks the stream it belongs to – other streams continue unaffected. This is the fundamental architectural difference. QUIC loss recovery mechanism: Each QUIC packet has a unique packet number (monotonically increasing, never reused). The receiver sends ACK frames acknowledging received packet numbers. QUIC detects loss via: (1) three ack-eliciting packets sent after the lost packet without it being acknowledged (rack-based detection), or (2) a probe timeout (PTO). On detection, QUIC retransmits the stream data (not the original packet – new packet numbers always). This per-stream retransmission means stream 5's lost packet does not hold up stream 3's data. 0-RTT connection resumption – replay risk: QUIC 0-RTT allows a client to send data in the first packet using a pre-shared key from a previous connection (PSK). This eliminates the connection establishment RTT for repeat visits. Critical caveat: 0-RTT data can be replayed by a network attacker. An attacker can capture a 0-RTT packet and retransmit it to the server – the server sees it as a new request. RFC 9001 §8.1 requires that servers only process 0-RTT for idempotent operations (GET, HEAD) and that applications take care not to process non-idempotent 0-RTT requests without replay protection (e.g., session tickets with replay tracking). QPACK vs HPACK – why they differ: HPACK (HTTP/2) uses a single shared dynamic table across all streams on a connection. Entries are added and referenced in order. This requires perfectly ordered delivery – a dynamic table entry added on stream 1 must be visible to stream 3. This works in TCP because TCP guarantees order. QPACK (HTTP/3, RFC 9204) separates the encoder and decoder streams from request/response streams. The encoder sends table updates on a dedicated unidirectional QPACK encoder stream. The decoder acknowledges them on a QPACK decoder stream. Request streams reference table entries only after the decoder confirms they're available. This allows QPACK to avoid head-of-line blocking that HPACK would cause on QUIC's out-of-order streams. In practice the difference matters most on lossy networks (mobile, high-latency links). On a typical low-loss wired connection, HTTP/2 and HTTP/3 perform similarly. On mobile networks where 1–2% packet loss is common, HTTP/3's elimination of TCP head-of-line blocking produces measurable latency improvements. Connection migration: TCP connections are identified by the 4-tuple (src IP, src port, dst IP, dst port). When a mobile device switches from Wi-Fi to cellular, all four values change – every TCP connection breaks. QUIC connections are identified by a Connection ID (an opaque byte sequence in every QUIC packet). When the IP changes, the client sends a PATH_CHALLENGE on the new path, the server responds with PATH_RESPONSE, and the connection migrates without interruption. Active HTTP/3 streams survive a network change. Migration path: HTTP/3 is negotiated via Alt-Svc header or HTTPS DNS record. Clients fall back to HTTP/2 automatically when QUIC is blocked. There are no API-level changes between HTTP/2 and HTTP/3 – the same request/response semantics apply.