HTTP/3 and QUIC: Who, what, where, when and, WHY? by Robin Marx

HTTP/3 and QUIC aim to replace TCP over the coming decades, with QUIC acting as a “TCP 2.0” that deeply integrates with TLS 1.3

QUIC solves TCP’s head-of-line blocking problem by treating data streams independently, allowing unaffected streams to continue even if one experiences packet loss

HTTP/3 can be up to 50% faster than HTTP/2 for time-to-first-byte in some scenarios, with typical improvements of 30-33% due to reduced handshake overhead

QUIC includes built-in connection migration capability, allowing connections to survive network changes (like switching from WiFi to cellular) without interruption

Deployment challenges exist because many firewalls and middleboxes block UDP traffic or aren’t updated to handle QUIC, leading to conservative adoption

QUIC encrypts most transport-level headers for improved security, while using Connection IDs instead of IP/port tuples for connection identification

Zero RTT (0-RTT) in QUIC allows faster connection establishment but requires careful implementation to avoid security issues like replay attacks

CDNs like Cloudflare, Fastly, and Akamai are the easiest way to enable HTTP/3 today, as they handle the complexity of proper configuration

Most existing HTTP/2 optimizations work equally well for HTTP/3 since the protocols are conceptually similar at the application layer

Full HTTP/3 adoption will take years, with TCP and HTTP/2 remaining important for the foreseeable future, especially in corporate environments blocking UDP