QUIC Protocol

How It Works

QUIC started as an experiment at Google in 2012. Jim Roskind and the Chrome team had a radical idea: what if we stopped trying to fix TCP and built something better on top of UDP? By 2021, it was an IETF standard (RFC 9000). Today, over 40% of Google's traffic and a growing share of the internet runs on QUIC.

The core insight is this: TCP was designed in 1981. It's been patched, extended, and optimized, but its fundamental architecture — connection setup, head-of-line blocking, cleartext headers — cannot change because middleboxes (firewalls, NATs, load balancers) depend on being able to inspect and sometimes modify TCP headers. TCP is ossified.

QUIC breaks free by running over UDP. To middleboxes, QUIC traffic looks like opaque UDP datagrams. The actual transport logic runs in userspace, controlled by the application.

Connection Establishment

This is QUIC's killer feature for latency. Compare:

TCP + TLS 1.3: 3 round trips minimum

1. TCP SYN → SYN-ACK → ACK (1 RTT)
2. TLS ClientHello → ServerHello (1 RTT)
3. TLS Finished + first HTTP request (1 RTT)

QUIC new connection: 1 round trip

1. Initial packet contains both transport parameters AND TLS ClientHello
2. Server responds with transport parameters, ServerHello, and certificate
3. Client sends encrypted application data in the third packet

QUIC repeat connection: 0 round trips

1. Client sends Initial packet with 0-RTT data — the HTTP request is in the first packet
2. Server processes the request and responds immediately

On a 100ms RTT mobile connection, this saves 200ms on new connections and 300ms on repeat connections. For a web page loading 50 resources, the impact is massive.

# Test HTTP/3 with curl
curl --http3-only -I https://www.google.com
# Look for: HTTP/3 200 in the response

# Chrome: check QUIC connections
# Navigate to chrome://net-internals/#quic

Stream Multiplexing Without Head-of-Line Blocking

HTTP/2 over TCP has a fundamental problem: all HTTP requests share one TCP connection. If one TCP segment is lost, every stream stalls until it's retransmitted. This is TCP-level head-of-line blocking, and no amount of HTTP-level multiplexing can fix it.

QUIC solves this by implementing streams at the transport layer. Each QUIC stream has independent ordering and reliability. If a packet carrying data for stream 4 is lost, only stream 4 stalls. Streams 1, 2, 3, and 5 continue unaffected.

HTTP/2 over TCP (head-of-line blocking):
Stream 1: ████████░░░░░░ (blocked)
Stream 2: ████████░░░░░░ (blocked waiting for Stream 1's lost packet)
Stream 3: ████████░░░░░░ (blocked waiting for Stream 1's lost packet)

HTTP/3 over QUIC (independent streams):
Stream 1: ████████░░████ (retransmitting, others unaffected)
Stream 2: ██████████████ (delivered)
Stream 3: ████████████░░ (progressing independently)

This matters most on lossy networks. At 2% packet loss (common on cellular), HTTP/2 over TCP shows significant degradation. HTTP/3 over QUIC maintains much better performance because only the affected stream pays the retransmission cost.

Connection Migration

TCP connections are identified by the 4-tuple: (source IP, source port, destination IP, destination port). When a device moves from WiFi to cellular, the IP address changes, and every TCP connection dies. The browser must re-establish all connections, re-negotiate TLS, and re-send in-flight requests.

QUIC connections are identified by Connection IDs — opaque tokens negotiated during the handshake. When the IP changes, the client sends a QUIC packet from the new address with the same Connection ID. The server recognizes it, validates a path challenge, and the connection continues without interruption.

This is transformative for mobile. Walking through a building, switching between WiFi access points, transitioning from WiFi to cellular in an elevator — QUIC connections survive all of these.

Built-in Encryption

TCP was designed for a trusted network. Its headers are cleartext, allowing any middlebox to inspect or modify them. Over the decades, this has caused two problems:

1. Privacy: ISPs can inspect TCP traffic, inject ads, or modify content
2. Ossification: Middleboxes that parse TCP headers break when new TCP extensions are deployed

QUIC encrypts everything. The initial handshake uses connection-level encryption. After the handshake, even packet numbers and ACK frames are encrypted. Only the connection ID and a few bits needed for routing are visible. This makes QUIC resistant to inspection, modification, and ossification.

QUIC Packet Structure:
┌───────────────┬─────────────────────────────────┐
│ Header (clear)│ Payload (encrypted)             │
│ - Conn ID     │ - Packet Number                 │
│ - Version     │ - Frames (STREAM, ACK, etc.)    │
│ - Flags       │ - All application data           │
└───────────────┴─────────────────────────────────┘

0-RTT: Speed and Security Trade-offs

0-RTT is remarkable: the client can send application data in its very first packet to a server it has previously connected to. The server resumes the TLS session and processes the request immediately. Zero round trips of latency.

But 0-RTT data has a critical limitation: it is replayable. An attacker who captures a 0-RTT packet can resend it, and the server may process it again. This means:

• Safe for 0-RTT: GET requests, idempotent operations, resource fetches
• Unsafe for 0-RTT: POST requests, payments, state-changing operations

Servers MUST implement replay protection (RFC 9001 Section 8) and SHOULD limit 0-RTT to safe methods.

Google's Deployment Story

Google didn't just design QUIC — they deployed it at a scale no one else could match. The rollout strategy:

1. 2013: gQUIC (Google QUIC) deployed in Chrome and Google servers
2. 2015: ~50% of Chrome-to-Google traffic on gQUIC
3. 2016: IETF standardization begins, protocol diverges from gQUIC
4. 2021: RFC 9000 published, IETF QUIC standardized
5. 2023: HTTP/3 (RFC 9114) standardized, broad adoption begins

Key metrics from Google's deployment:

• Search: 8% reduction in page load time on desktop, 3.6% on mobile
• YouTube: 15% reduction in rebuffering, especially on mobile
• Global: Over 40% of Google traffic now uses QUIC

Production Deployment

Server Configuration (nginx)

server {
    listen 443 quic reuseport;
    listen 443 ssl;
    
    ssl_certificate     /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;
    
    # Advertise HTTP/3 support
    add_header Alt-Svc 'h3=":443"; ma=86400';
    
    # Enable 0-RTT (with replay protection)
    ssl_early_data on;
    proxy_set_header Early-Data $ssl_early_data;
}

Monitoring QUIC

# Check if a server supports HTTP/3
curl -sI https://example.com | grep -i alt-svc
# Look for: alt-svc: h3=":443"

# Force HTTP/3 and measure timing
curl --http3-only -w "time_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_total: %{time_total}\n" -o /dev/null https://www.cloudflare.com

# Compare HTTP/2 vs HTTP/3
curl --http2 -w "h2 total: %{time_total}\n" -o /dev/null -s https://www.cloudflare.com
curl --http3-only -w "h3 total: %{time_total}\n" -o /dev/null -s https://www.cloudflare.com

The UDP Firewall Problem

The biggest practical challenge for QUIC adoption is UDP filtering. Many corporate firewalls, hotel networks, and some ISPs block or rate-limit UDP traffic on port 443. When this happens, browsers fall back to TCP+TLS silently.

This is why every QUIC implementation includes a fallback mechanism. Chrome, for example:

1. Tries QUIC if the server advertised Alt-Svc h3
2. Simultaneously opens a TCP connection as a race
3. If QUIC fails (firewall, timeout), uses TCP
4. Remembers which servers have QUIC issues and avoids retrying for a period

In practice, QUIC works for about 90-95% of users. The remaining 5-10% fall back to TCP transparently. Monitor the Alt-Svc hit rate to understand actual QUIC adoption.

What's Next

QUIC is still evolving rapidly:

• QUIC v2 (RFC 9369): Updated packet protection to resist ossification
• Multipath QUIC: Use WiFi and cellular simultaneously for redundancy and bandwidth aggregation
• QUIC datagrams (RFC 9221): Unreliable delivery over QUIC connections, useful for gaming and real-time media
• WebTransport: Browser API for bidirectional QUIC streams, potential WebSocket replacement

The broader trend is clear: transport protocol innovation has moved from the kernel to userspace. QUIC proved that a better TCP can be built without changing the OS, and the industry is rapidly following.