Why HTTP/3 matters for CDNs
HTTP/3 maps HTTP semantics onto QUIC, which uses UDP instead of TCP. The transport changes connection establishment, loss recovery, connection migration, and operational measurement at a CDN edge.
Latency and connection setup
QUIC integrates TLS 1.3 into its transport handshake. A full handshake permits application data after one round trip. A resumed connection can send 0-RTT application data when the client has suitable state from an earlier connection and the server accepts it.
These mechanisms can reduce connection-establishment delay, but they do not guarantee a faster page load. Network conditions, fallback, application behavior, and comparison with an existing TCP connection affect the result. Because an attacker can replay 0-RTT data, it is unsuitable for requests that can cause unwanted effects when repeated.
Connection handling
QUIC runs over UDP, so middleboxes and firewalls may treat it differently from TCP. A client can open a separate HTTP/2 connection when HTTP/3 is unavailable. A deployment therefore needs both HTTP/3 advertisement and a working TCP-based service.
Multiplexing and loss recovery
QUIC avoids transport-layer head-of-line blocking between streams. Lost data blocks progress on the affected stream, while other streams can continue. Connection-level congestion control can still affect all streams.
Anycast and routing
Many CDNs use Anycast to route clients to an edge location. QUIC supports connection migration when an endpoint’s address changes, subject to endpoint policy and path validation. CDN routing and load-balancing systems must keep migrated packets associated with the connection.
Operational considerations
- Logging: QUIC encrypts more transport information than TCP. Record HTTP version, handshake results, loss, fallback, and connection migration where the platform exposes them.
- Firewall rules: Network policy might need to allow UDP on port 443.
- Performance measurement: Existing synthetic tests built for TCP may not capture QUIC’s behavior accurately.
- Fallback: Test a separate HTTP/2 connection when QUIC is unavailable. Do not assume that every client retries in the same way.
Rollout experiences
Early adoption was gradual. Browser vendors like Chrome and Firefox enabled HTTP/3 in stages, often behind flags before turning it on by default. CDN providers such as Cloudflare and Fastly rolled out HTTP/3 support to their networks years before it was widely used, which meant customers could enable it early but only a fraction of clients benefited.
Client support does not remove deployment risk. Test UDP reachability, HTTP/2 fallback, Alt-Svc behavior, observability, and 0-RTT policy before broad rollout.
Practical impact for customers
Provider controls and defaults differ. Enable HTTP/3 in a test scope, confirm that clients negotiate it, and measure connection and application metrics against HTTP/2. Check provider pricing and logging behavior rather than assuming that they remain unchanged.