HTTP/2, HTTP/3, and QUIC: CDN Protocol Evolution

Q: What is Enabling HTTP/3 in CDN?

HTTP/3 is negotiated via the Alt-Svc header. The CDN sends:

June 26, 2026 · Mei-Lin Wu · 4 min read

Protocol Evolution

HTTP protocol versions have evolved to address web performance bottlenecks. CDNs are at the forefront of protocol adoption — they're often the first to support new protocols and can serve them to clients while maintaining older protocols to origin. For foundational context, read CDN Performance Metrics: What to Measure — FlyFish NWA.

HTTP/2: Multiplexing

HTTP/2 solved HTTP/1.1's head-of-line blocking by multiplexing multiple requests over a single TCP connection:

Performance Comparison: Edge vs Origin Processing
Metric	Edge Processing	Origin Processing	Improvement
Latency (p50)	8–15 ms	120–300 ms	15–20x faster
Cache Hit Ratio	85–95%	N/A	Reduces origin load
TLS Handshake	1–5 ms (nearby PoP)	50–150 ms	10–30x faster
Bandwidth Cost	$0.01–0.04/GB	$0.05–0.12/GB	3–5x cheaper
Availability	99.99% (multi-PoP)	99.9% (single DC)	10x fewer outages

Figure 1: CDN Protocol Stack — Layered network architecture

Multiplexing — Multiple requests and responses on one connection, interleaved
Header compression (HPACK) — Headers compressed using a shared dictionary, reducing redundant header bytes
Stream prioritization — Client hints which resources are most important
Server push — Server proactively sends resources the client will need

Performance impact: HTTP/2 eliminates the need for domain sharding, sprite sheets, and CSS inlining — hacks that were necessary with HTTP/1.1's 6-connection limit.

HTTP/3: QUIC Transport

HTTP/3 replaces TCP with QUIC (UDP-based transport), addressing TCP's remaining limitations:

Key Improvements

No TCP head-of-line blocking — In HTTP/2, a lost TCP packet stalls all multiplexed streams. In HTTP/3, only the affected stream pauses.
Faster handshake — QUIC combines transport + TLS handshake in 1 RTT (vs TCP's 1 RTT + TLS's 1-2 RTT). Repeat connections: 0-RTT.
Connection migration — Connections survive IP changes (WiFi → cellular) because QUIC uses connection IDs, not IP+port.
Better congestion control — QUIC implements congestion control in userspace, enabling faster iteration.

Performance Impact

Scenario	HTTP/2 (TCP)	HTTP/3 (QUIC)
New connection	2-3 RTT (TCP + TLS 1.3)	1 RTT (combined)
Resumed connection	1-2 RTT	0 RTT
Packet loss (2%)	All streams stall	Only affected stream stalls
Network switch	Connection drops, re-establish	Connection migrates seamlessly

CDN Protocol Support

Cloudflare — HTTP/3 enabled by default. One of the first to support QUIC at scale.
CloudFront — HTTP/3 supported. Configurable per distribution.
Fastly — HTTP/3 with QUIC. Early adopter with custom H2O server.
Akamai — HTTP/2 standard, HTTP/3 available on supported configurations.

Client-to-CDN vs CDN-to-Origin

CDNs typically use the newest protocol for client connections but HTTP/1.1 or HTTP/2 for origin connections:

Figure 2: Protocol Handshake Flow — Connection establishment sequence

Client ←HTTP/3 (QUIC)→ CDN Edge ←HTTP/1.1 or HTTP/2 (TCP)→ Origin

This is fine because the CDN-to-origin connection benefits less from HTTP/3: it's a single persistent connection (no multiplexing benefit), on a stable network (no connection migration needed), with low packet loss (data center to data center).

Enabling HTTP/3

HTTP/3 is negotiated via the Alt-Svc header. The CDN sends:

Alt-Svc: h3=":443"; ma=86400

The browser notes this and uses QUIC for subsequent requests. First-visit: HTTP/2; subsequent visits: HTTP/3. This ensures graceful fallback.

Monitoring Protocol Usage

Track which protocols your users actually use. Check CDN analytics for HTTP/1.1 vs HTTP/2 vs HTTP/3 distribution. High HTTP/1.1 rates may indicate outdated CDN configuration or clients.