HTTP/3 and QUIC

A user is streaming video on your app. They walk out of WiFi range and their phone switches to LTE — the IP address changes. Over HTTP/2, the TCP connection is dead; the phone re-handshakes TCP and TLS from scratch, the video buffers for 1–2 seconds, and your engagement metrics dip every time someone walks down a hallway. Over HTTP/3, the connection survives the IP change because it’s identified by an opaque Connection ID, not a 4-tuple — playback never stutters. That single property, plus stream-independent loss recovery, is the reason HTTP/3 exists.

HTTP/3 (RFC 9114, 2022) replaces TCP with QUIC (RFC 9000) as the transport layer. QUIC is built on UDP and reimplements reliable transport in user space, solving the two remaining problems of HTTP/2: TCP-level HOL blocking and slow connection establishment.

Why Not Fix TCP?

TCP is implemented in the OS kernel. Deploying changes requires OS updates across billions of devices — a process that takes years. QUIC runs in user space (as part of the application), enabling rapid iteration.

QUIC Streams — No TCP-Level HOL Blocking

In HTTP/2, all streams share one TCP connection. A single lost packet blocks every stream:

HTTP/2 over TCP — packet loss stalls ALL streams

Stream 1: [■■■ LOST ■■■ ■■■ ■■■]  ← all frames behind lost packet wait
Stream 3: [■■■ ■■■ ■■■ ■■■ ■■■]  ← stalled
Stream 5: [■■■ ■■■ ■■■ ■■■ ■■■]  ← stalled

QUIC streams are independent at the transport layer. Packet loss on one stream has no effect on others:

HTTP/3 over QUIC — packet loss isolated to one stream

Stream 1: [■■■ LOST ■■■ ■■■ ■■■]  ← retransmits only what's needed
Stream 3: [■■■ ■■■ ■■■ ■■■ ■■■]  ← unaffected, keeps flowing
Stream 5: [■■■ ■■■ ■■■ ■■■ ■■■]  ← unaffected, keeps flowing

Connection Establishment

HTTP/2 over TCP requires at minimum 2 round trips before the first byte of application data:

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: TCP + TLS 1.3 — 2 RTT minimum (new connection)
    C->>S: SYN
    S->>C: SYN-ACK
    C->>S: ACK + ClientHello (TLS)
    S->>C: ServerHello + Finished (TLS)
    C->>S: HTTP/2 Request
    S->>C: HTTP/2 Response

    Note over C,S: QUIC — 1 RTT (new connection)
    C->>S: Initial (QUIC + TLS ClientHello combined)
    S->>C: Handshake complete + HTTP/3 Response data
    C->>S: HTTP/3 Request (can send alongside handshake)

0-RTT (Resumed Connections)

When reconnecting to a known server, QUIC can send application data with the very first packet — zero round trips before data:

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: QUIC 0-RTT — resumed connection
    C->>S: Initial + Early Data (HTTP/3 Request) ← data sent immediately
    S->>C: HTTP/3 Response

QUIC saves a session ticket from the previous connection. On reconnect, the client uses it to derive keys and encrypt data before receiving any server response.

Connection Migration

TCP connections are bound to the client’s IP address and port. A network change (WiFi → cellular, VPN connect/disconnect, IP reassignment) kills the connection — the client must re-establish a new TCP connection and TLS session from scratch.

QUIC uses a Connection ID instead of IP:port to identify connections:

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C: Client on WiFi (192.168.1.5)
    C->>S: QUIC packet [Conn ID: abc123] via 192.168.1.5

    Note over C: Network switches to LTE (10.0.0.42)
    C->>S: QUIC packet [Conn ID: abc123] via 10.0.0.42
    Note over S: Same Connection ID → same connection, no re-handshake
    S->>C: Response continues seamlessly

The connection ID is a cryptographically opaque byte string chosen by the server. The server uses it to look up connection state regardless of which IP packet it arrives from.

Practical impact: Streaming video, file downloads, and real-time apps survive network transitions without interruption.

TLS 1.3 — Built In

TLS is not optional in QUIC. The TLS 1.3 handshake is integrated into the QUIC handshake, not layered on top:

• In TCP: TCP handshake → TLS handshake → data
• In QUIC: single combined handshake → data

QUIC encrypts everything — not just the payload. Packet numbers are always encrypted (preventing on-path traffic analysis), and most header fields are protected; the connection IDs that have to be visible for routing remain in cleartext in the long header during the initial handshake. The result still prevents middlebox interference far better than TLS-over-TCP, where the entire TCP header is exposed.

QPACK — Header Compression for HTTP/3

HTTP/2 uses HPACK, which has a problem in a QUIC context: the dynamic table assumes headers arrive in order. QUIC streams can deliver packets out of order.

QPACK (RFC 9204) adapts HPACK for QUIC:

QPACK uses two dedicated unidirectional QUIC streams:

• Encoder stream: server sends dynamic table updates
• Decoder stream: client acknowledges which updates it has applied

HTTP/3 Frame Types

HTTP/3 defines its own frame types over QUIC streams. QUIC already handles reliability and multiplexing, so HTTP/3 has a simpler set:

Deployment Considerations

Discovery — Alt-Svc

Browsers don’t know a server supports HTTP/3 in advance. The server advertises it via the Alt-Svc response header on an HTTP/1.1 or HTTP/2 connection:

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

The browser then attempts HTTP/3 on the next connection (or in parallel). ma is the max-age in seconds for how long to remember the advertisement.

CDN and Proxy Termination

Connection Coalescing

If multiple hostnames resolve to the same IP and share a TLS certificate, a QUIC connection can be reused across origins — reducing connection overhead for CDN-hosted assets.

Protocol Comparison

Test Your Understanding