TLS Performance: QUIC and HTTP/3

HTTP/2 multiplexes multiple streams over a single TCP connection, solving HTTP/1.1's per-connection head-of-line blocking. However, TCP itself causes head-of-line blocking at the transport layer: if one TCP segment is lost, all data behind it in the queue waits for retransmission, blocking all HTTP/2 streams simultaneously. A 1% packet loss can degrade HTTP/2 performance below HTTP/1.1 with multiple connections. QUIC (Quick UDP Internet Connections) solves this by implementing multiplexed streams over UDP, where stream-level loss recovery does not block other streams.

QUIC is a transport protocol built on UDP, developed by Google (2012-2015) and standardized by IETF as RFC 9000 (2021). QUIC integrates TLS 1.3 at the transport layer — there is no separate TLS handshake on top of QUIC; TLS is woven into the QUIC handshake itself. QUIC provides: multiplexed streams without head-of-line blocking, connection migration (maintaining the connection when switching networks, e.g., WiFi to LTE), 0-RTT connection establishment for repeat connections, and built-in loss detection and congestion control. HTTP/3 (RFC 9114) is HTTP semantics over QUIC streams.

The QUIC handshake combines connection establishment and TLS negotiation. In the first flight (0 RTT in QUIC terminology), the client sends Initial packets containing TLS ClientHello. The server responds with its own Initial (ServerHello) plus Handshake packets (encrypted extensions, certificate, Finished). The client sends Handshake Finished and is then ready to send application data — this is 1-RTT. For 0-RTT connections, the client sends 0-RTT packets (application data) alongside the ClientHello using a key derived from the previous session's resumption secret, achieving zero additional round trips for cached sessions.

QUIC uses four distinct encryption levels corresponding to TLS key schedule phases: Initial (QUIC-derived AEAD using a known constant key — provides integrity but not confidentiality against sophisticated attackers), Handshake (derived from TLS handshake_secret — provides confidentiality for TLS handshake messages), 0-RTT (derived from previous session early_secret — encrypts 0-RTT application data), and 1-RTT (derived from TLS master_secret — encrypts all application data). QUIC headers are partially encrypted: the packet number and payload are encrypted but some routing information (Connection ID) remains visible for load balancers.

QUIC connections are identified by a Connection ID (CID) rather than a 4-tuple (src IP, src port, dst IP, dst port). This allows connections to survive network changes: when a mobile client switches from WiFi to LTE, the IP address changes but the CID remains the same. The client sends a PATH_CHALLENGE frame on the new path; the server responds with PATH_RESPONSE, validating the new address. The connection continues seamlessly without renegotiation. TCP cannot support this — a TCP connection is bound to its 4-tuple and must be re-established on network change, requiring a new TLS handshake. QUIC migration improves perceived performance for mobile users significantly.

HTTP/3 maps HTTP semantics to QUIC streams. Each HTTP request-response pair occupies a separate bidirectional QUIC stream. QUIC streams are independent: loss on stream 3 does not block stream 7. HTTP/3 uses QPACK for header compression (replacing HTTP/2's HPACK) — QPACK was redesigned to work without requiring in-order delivery. Two dedicated unidirectional control streams carry settings and decoder/encoder instructions. Server push in HTTP/3 uses push streams (unidirectional). The overall effect: HTTP/3 outperforms HTTP/2 most significantly under packet loss conditions (mobile networks, congested paths) where TCP head-of-line blocking is most harmful.

Real-world measurements of QUIC and HTTP/3 performance show mixed results depending on network conditions. On high-quality networks (low latency, low packet loss), HTTP/3 and HTTP/2 perform similarly — the QUIC overhead (larger headers, UDP processing overhead) can even make HTTP/3 slightly slower. On lossy networks (> 1% packet loss, common on mobile and satellite), HTTP/3 outperforms HTTP/2 significantly. Google reported 7-8% reduction in rebuffering in YouTube when switching to QUIC. Facebook (Meta) reported 7-15% improvement in request latency for Instagram feeds over QUIC. The gains are most visible in tail latency (p95, p99) where TCP retransmission stalls are most impactful.

QUIC load balancing is more complex than TCP because QUIC is UDP-based and stateless UDP load balancers cannot do connection affinity. IETF draft-ietf-quic-load-balancers defines an approach: servers encode routing information into the Connection ID so that load balancers can route packets from the same connection to the same server without tracking per-connection state. The Connection ID carries an encrypted server ID using a shared key between the load balancer and servers. Cloudflare, Fastly, and Nginx implement variants of this approach. NAT traversal is another concern: QUIC connections must survive NAT rebinding, handled by the connection migration mechanism.

Major CDNs have deployed QUIC and HTTP/3 at scale. Cloudflare has served HTTP/3 since 2019 and reports that approximately 20% of traffic uses QUIC where supported by both client and server. Fastly, Akamai, and AWS CloudFront support HTTP/3 at their edge. Google's own infrastructure (Search, YouTube, Gmail) has used QUIC since 2013 internally and exposes HTTP/3 publicly. CDN deployments benefit from QUIC's 0-RTT resumption: repeat visitors establish connections faster, and connection migration improves performance for mobile users roaming between access points during content delivery.

QUIC's UDP-based design introduces specific security considerations. Amplification attacks: an attacker can spoof a source IP and send small Initial packets, causing the server to send large Handshake responses to the victim — QUIC mitigates this by limiting server responses to 3x the received data until address validation completes (via the RETRY mechanism). Connection flooding: QUIC servers must rate-limit new connection attempts from the same IP. Version negotiation attacks are prevented by including version in the cryptographically protected handshake. QUIC's built-in encryption means inspection appliances cannot analyze QUIC payload without being on-path with the server certificate — improving privacy compared to inspectable TCP traffic.

Deploying HTTP/3 requires: (1) A QUIC-capable server (nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed, or application-level via quic-go, aioquic, ngtcp2 libraries). (2) UDP port 443 open on firewalls — many corporate firewalls block UDP 443, causing QUIC to fall back to TCP/TLS. (3) Advertising HTTP/3 support via the Alt-Svc response header: Alt-Svc: h3=":443"; ma=86400, prompting HTTP/2 clients to upgrade. (4) QUIC-aware load balancers or L4 UDP pass-through. (5) Monitoring QUIC-specific metrics: connection migration events, 0-RTT acceptance rate, protocol fallback rate. Gradual rollout with fallback to HTTPS is transparent to clients that do not support QUIC.

How does QUIC solve the head-of-line blocking problem that affects HTTP/2 over TCP?

QUIC integrates TLS 1.3 at the transport layer over UDP, eliminating TCP head-of-line blocking with independent per-stream loss recovery. Connection IDs enable migration across network changes without renegotiation. HTTP/3 maps HTTP to QUIC streams using QPACK header compression. 0-RTT connection resumption reuses TLS session secrets. QUIC outperforms HTTP/2 most significantly under packet loss (mobile, congested networks). Load balancing QUIC requires encoding server routing in Connection IDs. Deployment requires UDP 443, QUIC-capable servers, and Alt-Svc headers for protocol advertisement.