CDN HTTP/3 Migration Guide: From HTTP/2 to QUIC in Production

Migrating a CDN from HTTP/2 to HTTP/3 is not a simple protocol toggle. It is a transport-layer change from TCP+TLS 1.3 to QUIC over UDP, with implications for load balancing, loss recovery, congestion control, and observability. Done correctly, HTTP/3 eliminates head-of-line blocking, cuts handshake latency to 0-RTT, and dramatically improves performance on lossy and mobile networks. Done poorly, it creates UDP blackholes, inconsistent Alt-Svc behavior, and hard-to-debug fallback storms.

This guide provides a production-tested migration path used by large edge networks. We assume your CDN already terminates HTTP/2 at the edge, supports TLS 1.3, and operates anycast or regional PoPs. You will learn how to enable QUIC alongside HTTP/2, validate with real user metrics, and roll forward safely.

1. Why Migrate: HTTP/2 Limitations That QUIC Solves

HTTP/2 solved HTTP/1.1 multiplexing but inherited TCP's fundamental constraints. All streams in an HTTP/2 connection share a single TCP byte stream. If one packet is lost, every stream stalls until retransmission — TCP head-of-line (HOL) blocking. On 4G, satellite, or congested Wi-Fi, this translates to tail latency spikes and stalled rendering.

QUIC rebuilds the transport in user space over UDP. Each HTTP/3 stream has independent flow control and loss recovery. Packet loss in stream A does not block stream B. QUIC also integrates the cryptographic handshake: TLS 1.3 is embedded, not layered. That reduces connection establishment from 2-3 RTTs (TCP + TLS) to 1-RTT, and 0-RTT for resumed connections.

For CDNs, the benefits compound at the edge:

• Connection migration: QUIC uses connection IDs, not 4-tuple. A client switching from Wi-Fi to cellular keeps the same connection — critical for mobile users and long-lived API connections.
• Improved loss resilience: Independent streams + modern congestion control (BBR, CUBIC over QUIC) improve throughput on 1-5% loss links by 15-30% in field tests.
• Faster edge handshakes: 0-RTT resumption cuts Time to First Byte (TTFB) by 80-120ms on high-RTT routes, directly improving LCP.
• No TCP ossification: QUIC encrypts transport headers, preventing middlebox interference that plagues TCP optimizations.

If your audience is mobile-heavy or global, the performance ROI is immediate. Review your current performance baseline in our CDN benefits and performance analysis before setting migration KPIs.

2. Architecture Shift: TCP vs QUIC Stack

Understanding the stack change prevents misconfiguration. HTTP/2 runs over TLS over TCP. HTTP/3 runs over QUIC over UDP — QUIC replaces both TCP and the TLS record layer.

This architectural difference explains why you cannot simply “enable UDP/443” and expect stability. Your edge load balancers, firewalls, and CDN architecture must be QUIC-aware to route and persist connections correctly.

3. Pre-Migration Assessment Checklist

Before advertising HTTP/3, audit these four layers. Skipping any creates silent failures where clients attempt QUIC, time out, and fall back to TCP after 300ms — worse than never offering HTTP/3.

Network & Firewall Readiness

QUIC uses UDP/443. Many enterprise firewalls and older DDoS scrubbers rate-limit or block UDP. Verify: (1) all PoPs allow inbound UDP/443, (2) outbound UDP is not throttled by your origin shields, (3) ECMP hashing preserves QUIC CID affinity. Test from residential ISPs, not just cloud probes — carrier-grade NATs are where UDP breaks.

TLS & Certificate Hygiene

QUIC mandates TLS 1.3. If your edge still negotiates TLS 1.2 for compatibility, QUIC will fail. Ensure certificates support both RSA and ECDSA, and that your SSL/TLS configuration enables ALPN h3 and h3-29 for draft compatibility. Rotate to short-lived certs if you plan 0-RTT — replay risk requires anti-replay windows.

Origin & Edge Compute Compatibility

Your origin does not need to speak QUIC if your CDN terminates HTTP/3 at the edge and fetches over HTTP/1.1 or HTTP/2 to origin — the common “edge-only” model. However, if you run edge compute (Workers, Lambda@Edge) that inspects transport, update runtimes to expose QUIC metadata (connection ID, migration events). Otherwise, edge logic that keys on client IP will break during migration.

Observability Baseline

Instrument before you migrate. Capture p50/p95 TTFB, handshake time, retransmit rate, and HTTP version distribution for at least 14 days. Enable qlog and QUIC connection close frame logging at the edge. Without this baseline, you cannot prove migration impact. See our guide to CDN monitoring and observability for dashboard templates.

4. Phased Migration Strategy

Never cut over globally. Use a dual-stack, Alt-Svc driven rollout that keeps HTTP/2 as the reliable fallback while clients discover QUIC opportunistically.

Phase 1 — Shadow Enable (0% advertised)

Enable QUIC listeners on 2-3 PoPs but do not send Alt-Svc headers. Validate with synthetic clients using curl --http3 and interop runners. Confirm UDP GRO/GSO is enabled on NICs — without segmentation offload, QUIC throughput collapses under CPU pressure.

Phase 2 — Canary via Alt-Svc (1-5% traffic)

Advertise HTTP/3 on canary hostnames or for a percentage of responses. The canonical header:

# Edge response header — tells client to upgrade next time
alt-svc: h3=":443"; ma=86400; persist=1
# For canary, scope to 5% via edge logic or cookie
add_header alt-svc 'h3=":443"; ma=86400' always;

Clients that support HTTP/3 will attempt QUIC on the next connection. Monitor fallback rate: healthy is <2% failed QUIC handshakes. If you see >5%, stop and check UDP blocking by ASN.

Phase 3 — Progressive Rollout (25% → 100%)

Expand PoP by PoP, region by region. Keep TCP/443 fully operational — HTTP/3 is additive, not replacement. Use weighted DNS or edge feature flags to control exposure. For managed CDNs (Cloudflare, Fastly, Akamai, CloudFront), this is often a dashboard toggle with gradual rollout; for self-hosted Nginx/Envoy, it is config-driven.

Phase 4 — Optimize & Enforce

After 30 days at 100% advertised, tune congestion control (BBR works well for CDN edge with mixed RTTs) and enable 0-RTT where safe (idempotent GETs only). Do not enable 0-RTT for non-idempotent APIs without replay protection.

5. CDN Edge Configuration

Configuration varies by platform, but the primitives are identical: enable QUIC listener, set ALPN, publish Alt-Svc, and ensure load balancer persistence.

Nginx (with QUIC patch) Example

server {
  listen 443 ssl http2;
  listen 443 quic reuseport;
  ssl_protocols TLSv1.3;
  ssl_certificate /etc/ssl/cdn.example.com.crt;
  ssl_certificate_key /etc/ssl/cdn.example.com.key;

  # Advertise HTTP/3 — clients will upgrade on next visit
  add_header Alt-Svc 'h3=":443"; ma=86400' always;
  add_header QUIC-Status $quic always;

  location / {
    proxy_pass http://origin;
    proxy_http_version 1.1;
  }
}
# sysctl tuning for UDP
# net.core.rmem_max = 67108864
# net.ipv4.udp_mem = 102400 524288 1048576

Envoy / Cloudflare / AWS CloudFront Notes

Envoy: Set quic_options.enabled: true on the listener and configure udp_listener_config with quic_protocol_options. Ensure downstream CID load balancing uses consistent_hash_lb_config on QUIC CIDs.

Managed CDNs: Cloudflare enables HTTP/3 via Network → HTTP/3 toggle (adds Alt-Svc automatically). CloudFront requires HTTP/3 opt-in per distribution and automatically handles ALPN. Always verify with curl -I --http3 https://yourdomain.com and check for alt-svc and x-quic headers.

6. Validation, Monitoring & Rollback

Migration success is measured by Real User Monitoring (RUM), not synthetic green lights.

Validation Checklist

• Protocol negotiation: Verify >40% of capable clients (Chrome, Edge, Firefox, iOS 16+) actually use h3 within 48 hours of Alt-Svc. Use chrome://net-internals/#quic and server logs.
• Performance delta: Compare LCP and p95 TTFB for h3 vs h2 cohorts. Expect 5-12% LCP improvement on mobile, neutral on desktop fiber.
• Error budget: Track QUIC_CONNECTION_CLOSE, VERSION_NEGOTIATION, and UDP loss. Alert if QUIC error rate exceeds 1.5x TCP error rate.
• Fallback latency: Measure time from failed QUIC Initial to successful TCP fallback. Should be <350ms; higher indicates Alt-Svc or timeout misconfig.

Monitoring Queries (Prometheus / Datadog)

# Share of HTTP/3 vs total requests
sum(rate(cdn_requests_total{proto="h3"}[5m])) / sum(rate(cdn_requests_total[5m]))
# QUIC handshake failures
sum(rate(quic_handshake_failed_total[5m])) by (pop, reason)
# 0-RTT replay rejections (should be low)
sum(rate(quic_zero_rtt_rejected_total[5m]))

Rollback Plan

Rollback is instant: remove the Alt-Svc header. Clients will naturally expire the advertisement after ma seconds and revert to HTTP/2. For emergency rollback, set alt-svc: clear or ma=0 to actively clear cached alternatives. Keep QUIC listeners running but unadvertised during rollback to avoid connection failures for clients mid-migration. Document the runbook and test it in staging — the worst time to discover your header removal requires a full edge deploy is during an incident.

HTTP/3 migration is a one-way ratchet in practice. Once you see stable h3 share above 60% for modern browsers and neutral-to-positive RUM, you can consider HTTP/3 the primary protocol and keep HTTP/2 indefinitely as fallback. TCP is not going away — QUIC augments it.

Next steps: audit your edge for UDP/443, instrument RUM by protocol, and run a canary on a low-risk hostname. When ready, expand using the phased Alt-Svc approach above and track p95 LCP as your north-star metric.