QUIC and HTTP/3

// Chapter 1

The Problem QUIC Was Designed to Solve

QUIC is a general-purpose encrypted transport protocol running over UDP. It provides: reliable ordered delivery per stream, multiplexed independent streams, integrated TLS 1.3 encryption, congestion control, flow control, and connection migration — all in userspace. HTTP/3 is HTTP semantics running over QUIC streams instead of TCP+TLS.

The key insight driving QUIC's design: UDP is a blank canvas. It provides no reliability, no ordering, no connection — just datagrams. When you rebuild reliability on top, you can make better decisions than the 1974 TCP spec allowed. You own the entire protocol and can change it with a software update, not a kernel patch.

// Chapter 2

TCP Head-of-Line Blocking: The Core Problem

TCP guarantees that bytes are delivered in order. If segment #3 is lost and #4, #5, #6 arrive, they buffer in the kernel until #3 is retransmitted and received. The application sees nothing until the gap is filled. This is correct for a byte stream — but catastrophic for multiplexed HTTP requests.

HTTP/2 multiplexes many logical requests over one TCP connection by interleaving bytes from different streams. TCP has no awareness of stream boundaries — it is one byte stream. If a TCP segment carrying bytes from stream 1 is lost, streams 2, 3, and 4 are stalled even though all of their data arrived intact. The kernel buffers it, waiting for the retransmit that will allow TCP to advance its delivery pointer past the gap.

The Quantified Problem

Measurements by Google and academic researchers show: at 0% packet loss, HTTP/2 over one TCP connection outperforms HTTP/1.1 with six parallel connections. At 1% packet loss, they are approximately equal. At 2%+ packet loss, HTTP/1.1 with six connections wins. Mobile networks and satellite links routinely hit 1–5% loss. This means HTTP/2 — a significant engineering achievement — delivered its theoretical benefits only on high-quality networks.

// Chapter 3

QUIC Connection Establishment

How 1-RTT Works

QUIC combines the transport handshake and TLS 1.3 into a single exchange. The client's first packet — an Initial packet — contains QUIC transport parameters (stream limits, flow control windows, idle timeout) and the TLS 1.3 ClientHello (including the key_share extension with the client's ECDHE public key). The server's response contains QUIC acknowledgment and the TLS 1.3 ServerHello, EncryptedExtensions, Certificate, and Finished. Both sides derive traffic keys from this single exchange. The server can send application data before the client's Finished arrives.

Three Encryption Levels

QUIC bootstraps encryption through three levels: Initial (keys derived from the connection ID — provides integrity but not confidentiality, any observer can decrypt), Handshake (keys from the TLS handshake secret — authenticated and encrypted), Application (keys from the TLS master secret — full TLS 1.3 protection). Each level uses different packet types so that middleboxes cannot confuse them.

# Check HTTP/3 support
curl -I --http3 https://example.com      # curl compiled with QUIC support
curl -v https://example.com 2>&1 | grep "alt-svc"
# alt-svc: h3=":443"; ma=86400  ← server advertises HTTP/3

# First connection: typically HTTP/2 (TCP)
# Browser caches Alt-Svc, upgrades to HTTP/3 on next visit

# Check in Chrome DevTools → Network → Protocol column
# "h3" = HTTP/3 over QUIC, "h2" = HTTP/2 over TLS/TCP

# Inspect QUIC connection details
openssl s_client -connect example.com:443  # does NOT speak QUIC
# Use quiche-client or ngtcp2 for actual QUIC inspection

// Chapter 4

QUIC Packets and Frames

QUIC has a two-layer structure. Packets are UDP datagrams with a QUIC header (connection ID, packet number, packet type) plus an encrypted payload. Frames are typed structures inside the payload — a single UDP datagram can carry multiple frames from multiple streams simultaneously. This multiplexing at the datagram level is what eliminates HoL blocking.

Packet Numbers and Retransmit Disambiguation

TCP reuses sequence numbers for retransmissions, creating the classic "retransmit ambiguity": did the ACK acknowledge the original or the retransmit? QUIC uses monotonically increasing packet numbers that are never reused. A retransmitted STREAM frame gets a new packet number but carries the original stream offset. ACK timestamps are therefore always unambiguous, enabling more accurate RTT estimates and better congestion control.

// Chapter 5

Multiplexing Without Head-of-Line Blocking

QUIC streams are fully independent within a connection. Each stream has its own byte offset space and its own flow control budget. A lost UDP datagram stalls only the stream(s) whose data was in that datagram. Other streams receive their data and deliver it to the application without waiting.

Stream IDs encode direction in their low 2 bits: 0x0 = client-initiated bidirectional, 0x1 = server-initiated bidirectional, 0x2 = client-initiated unidirectional, 0x3 = server-initiated unidirectional. HTTP/3 request/response pairs use client-initiated bidirectional streams (IDs 0, 4, 8, 12…). HTTP/3 also uses three pairs of unidirectional streams for control, QPACK encoder, and QPACK decoder.

Two-Level Flow Control

QUIC flow control operates at two levels simultaneously. Stream-level (MAX_STREAM_DATA): per-stream byte limit, allowing the receiver to give different budgets to different streams — a video stream gets more headroom than a control channel. Connection-level (MAX_DATA): total byte limit across all streams, preventing memory exhaustion regardless of how many streams are open.

// Chapter 6

Connection Migration

Connection migration is transformative for mobile users who switch between WiFi and cellular multiple times per hour. With TCP, each switch breaks all connections — ongoing video calls, uploads, WebSocket sessions, long-running RPC streams. With QUIC, all survive.

Path Validation

QUIC cannot simply trust any packet claiming to be from a connection — an attacker could spoof a source IP to redirect traffic. Path validation requires the migrating endpoint to respond to a PATH_CHALLENGE with a matching PATH_RESPONSE from the new address. Only after receiving a valid response does the server switch its sending path. Until then, it continues sending on the old path (if still reachable) or buffers data.

Connection ID Privacy

Connection IDs are visible in packet headers (outside encryption). An observer watching traffic before and after a migration can correlate packets via the connection ID, revealing movement. QUIC addresses this with ID rotation: NEW_CONNECTION_ID frames provide fresh IDs, and RETIRE_CONNECTION_ID retires old ones. Clients concerned about mobility privacy should rotate IDs on each migration event.

// Chapter 7

QUIC Congestion Control

QUIC ships with NewReno as the default congestion control algorithm (RFC 9002), but its design explicitly supports pluggable congestion control. Because QUIC runs in userspace, deploying BBR, CUBIC, Copa, or a custom algorithm requires only a software update — not a kernel patch and multi-year OS distribution cycle.

Google's production QUIC has used BBR (Bottleneck Bandwidth and RTT) for years. BBR models the network bottleneck by estimating bandwidth and minimum RTT, then probes for bandwidth in cycles rather than backing off at every loss event. On high-bandwidth, high-latency paths (cross-continental, satellite), BBR significantly outperforms CUBIC.

Accurate RTT Estimation

Every QUIC ACK carries an ack_delay field — the time between receiving the acknowledged packet and generating the ACK. The sender subtracts this delay from the raw RTT sample, producing a more accurate smoothed RTT. TCP ACKs carry no such information; RTT estimates include unpredictable ACK batching and interrupt coalescing delays. Better RTT estimates mean more accurate congestion window calculations and fewer spurious retransmits.

QUIC also supports ECN (Explicit Congestion Notification) — ACK frames report counts of IP packets marked CE (Congestion Experienced) by routers. This enables congestion signals without packet loss, reducing the latency spikes of loss-based congestion control.

# Enable HTTP/3 in nginx (nginx 1.25+ with --with-http_v3_module)
server {
    listen 443 quic reuseport;
    listen 443 ssl;
    ssl_protocols TLSv1.3;
    ssl_certificate     /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

# Verify QUIC is working
curl -v --http3-only https://your-server.com 2>&1 | grep -E "HTTP|QUIC|proto"

# h3spec: HTTP/3 conformance test suite
h3spec https://your-server.com:443

// Chapter 8

HTTP/3: HTTP Semantics over QUIC

HTTP/3 (RFC 9114) preserves all HTTP/1.1 and HTTP/2 semantics — methods, status codes, headers, trailers — but replaces the framing layer. HTTP/2 framing was designed around TCP's ordered byte stream; HTTP/3 redesigns it for QUIC's independent streams.

QPACK: Header Compression Redesigned for QUIC

HTTP/2 used HPACK for header compression. HPACK maintains a shared dynamic table between encoder and decoder, with entries referenced by index. This works perfectly over TCP's ordered delivery — but QUIC delivers streams out of order. If a dynamic table update (in one stream) hasn't arrived yet and a header references that entry (in another stream), HPACK would stall. This would reintroduce HoL blocking at the header layer.

QPACK (RFC 9204) redesigns this. It uses two dedicated unidirectional streams — an encoder stream and a decoder stream — for table updates and acknowledgments. A header can reference dynamic table entries only if those entries have already been acknowledged by the decoder. Headers that reference unconfirmed entries are encoded as literals (never blocked). The result: zero HoL blocking from header compression, at the cost of two extra streams per connection.

HTTP/3 Request/Response Flow

Each request/response pair uses a client-initiated bidirectional QUIC stream. The client sends a HEADERS frame (QPACK-encoded request headers) followed by optional DATA frames (request body). The server responds with a HEADERS frame (response headers) and DATA frames (response body). Trailers are sent in a final HEADERS frame. Each stream is independent — 100 parallel requests use 100 independent QUIC streams with no shared stall point.

// Chapter 9

Deployment Challenges

QUIC's UDP foundation creates friction that TCP never faced. Network equipment has been TCP-optimized for 50 years. UDP was historically used only for DNS and media streaming, and was often treated as second-class traffic.

UDP Blocking

Enterprise firewalls frequently block or rate-limit UDP on port 443. Google reports that approximately 3–8% of connections cannot use QUIC due to UDP blocking, falling back to HTTP/2 over TCP. QUIC clients must implement this fallback — without it, those users would lose HTTPS access entirely. The fallback adds latency on first connection to affected networks (connection attempt timeout before fallback).

NAT and Firewall Idle Timeouts

NAT tables track UDP state with shorter idle timeouts than TCP — typically 30–60 seconds for UDP vs 300+ seconds for TCP. A QUIC connection idle for more than 30 seconds may have its NAT mapping expire. When the client sends the next packet, it arrives at the server from a "new" source (from the server's perspective) and is dropped. QUIC mitigates this with PING frames (sending keepalives) and the max_idle_timeout transport parameter to negotiate shorter connection idle times.

Load Balancer Routing

Traditional load balancers route by TCP 5-tuple. QUIC connection migration changes the source IP/port, breaking 5-tuple routing. QUIC-aware load balancers must route by connection ID. RFC 9000 defines a convention where servers encode routing information into connection IDs they generate — the load balancer extracts this without packet decryption. Cloudflare's implementation embeds a 1-byte routing key into the connection ID for stateless L4 routing.

// Chapter 10

QUIC Security Design

TLS 1.3 is not bolted onto QUIC — it is integrated into QUIC's handshake. Every byte of QUIC application data and post-Initial handshake data is encrypted. Even QUIC's internal framing (ACKs, flow control, stream IDs) is encrypted after the Initial exchange. This encryption prevents ossification: middleboxes cannot read and depend on QUIC internal fields, which means QUIC can evolve those fields without breaking middleboxes.

Compare to TCP: TCP options, timestamps, and even the window scale option have been partially ossified by middleboxes that inspect and rewrite them. QUIC's encryption makes this manipulation impossible, preserving the protocol's ability to evolve. This is why QUIC's version field and connection ID format are the only invariants (RFC 8999) — everything else can change.

Packet Injection Attacks

An attacker who observes QUIC packets and knows the connection ID could try to inject forged packets. QUIC prevents this: application-level packets use per-packet AEAD authentication with keys derived from the TLS session — a forged packet without the session key produces an authentication failure and is silently dropped. The connection ID alone provides no decryption capability.

# QUIC version negotiation
# If client sends an unknown QUIC version, server responds with
# a Version Negotiation packet listing supported versions
# Client retries with a version from that list

# QUIC invariants (must remain constant across all QUIC versions):
# - First bit of first byte (fixed bit, currently 1)
# - Next 4 bytes are the version field
# - Remaining long-header fields may change in future versions

# QUIC v2 (RFC 9369) changes the Initial salt to force new implementations
# Prevents ossification by ensuring old QUIC v1 code cannot parse v2 packets
# Check if server supports QUIC v2:
curl --http3 -v https://example.com 2>&1 | grep "QUIC version"

// Chapter 11

QUIC Beyond HTTP

QUIC is a general transport protocol, not HTTP-specific. Several applications have adopted it for its properties independently of HTTP/3.

DNS over QUIC (DoQ) — RFC 9250

Each DNS query runs in its own QUIC stream. Subsequent queries on an established connection take zero additional RTTs for connection setup. Unlike DNS-over-TCP (which prefixes a 2-byte length), DoQ uses QUIC stream framing. 0-RTT enables sub-millisecond DNS resolution on warm connections. The privacy benefit: every query is encrypted, the server is authenticated, and queries cannot be correlated by packet timing because streams are independent.

WebTransport

WebTransport (W3C + IETF) exposes QUIC stream and datagram semantics to browser JavaScript. A web application can open multiple independent streams (reliable, ordered) and send unreliable datagrams — like a low-level socket API in the browser. Use cases: game networking (unreliable datagrams for position updates), live streaming (parallel audio/video streams), collaborative editing (low-latency independent updates). Chrome shipped WebTransport in 2023; it runs over HTTP/3 as a protocol extension.

MASQUE and VPN-style Use Cases

MASQUE (Multiplexed Application Substrate over QUIC Encryption) defines HTTP/3 extensions for proxying IP and UDP traffic through QUIC tunnels. This enables QUIC-native VPN architectures where the outer tunnel is QUIC (surviving IP changes, benefiting from connection migration) and inner traffic is encapsulated with CONNECT-IP or CONNECT-UDP. Apple's iCloud Private Relay uses a variant of this approach.

// Chapter 12

Performance in Practice

QUIC's benefits are real on certain paths and marginal or negative on others. The deployment decision requires understanding your specific traffic patterns.

Where QUIC Wins

• Lossy, high-latency paths: mobile in fringe coverage, satellite. Per-stream HoL blocking elimination has measurable impact above 1% loss rate.

• Frequent IP changes: mobile users switching WiFi/cellular. Connection migration keeps sessions alive vs TCP teardown+restart.

• Short-lived connections to known servers: 0-RTT saves one full RTT. For search results and API calls where every millisecond matters, this is significant at scale.

• Many parallel requests: a page loading 80 resources benefits from 80 independent QUIC streams vs HTTP/2's all-on-one-TCP-connection approach.

Where QUIC Underperforms

• Reliable, low-latency LANs and data center networks: TCP with kernel-optimized zero-copy and hardware offload is highly efficient. QUIC's userspace implementation has additional context-switch and memory copy overhead.

• High-throughput bulk transfers: CDNs report 20–30% higher CPU per byte for QUIC vs TLS/TCP on the same hardware — hardware AES acceleration works for both, but QUIC's per-packet processing overhead is higher in userspace.

• UDP-blocked networks: falls back to TCP transparently, no benefit.

// Chapter 13

Common Misconceptions

// Chapter 14

IQ Depth Check