QUIC Protocol: How HTTP/3 Transport Works

Understanding QUIC: The Foundation of HTTP/3

QUIC (originally Quick UDP Internet Connections) is a general-purpose transport protocol developed by Google and standardized by the IETF as RFC 9000. It is the transport layer that makes HTTP/3 possible.

Why a New Transport Protocol?

TCP has served the internet well for decades, but its design has fundamental limitations for modern web traffic:

1. Head-of-line blocking: TCP delivers all bytes in order, so one lost packet stalls everything
2. Slow handshake: TCP and TLS are separate layers requiring sequential handshakes
3. Ossification: TCP is implemented in OS kernels, making it nearly impossible to deploy changes quickly
4. No connection migration: TCP connections are identified by IP:port tuples

QUIC Architecture

QUIC runs in userspace (not the kernel), uses UDP as its transport, and integrates TLS 1.3 directly:

┌───────────────────────────────┐
│         QUIC Layer              │
│  ┌───────────┐ ┌───────────┐ │
│  │ Stream 1  │ │ Stream 2  │ │
│  └───────────┘ └───────────┘ │
│  ┌─────────────────────────┐ │
│  │  TLS 1.3 (integrated)   │ │
│  └─────────────────────────┘ │
│  ┌─────────────────────────┐ │
│  │  Congestion Control     │ │
│  └─────────────────────────┘ │
└───────────────────────────────┘
           │
    ┌───────────┐
    │    UDP    │
    └───────────┘

Connection IDs

Unlike TCP, QUIC identifies connections using Connection IDs rather than IP:port tuples. This means a mobile device switching from Wi-Fi to cellular can continue the same QUIC connection without interruption.

Userspace Implementation

Because QUIC runs in userspace, it can be updated independently of the operating system. This avoids the decades-long ossification problem that TCP suffers from and allows rapid iteration on congestion control algorithms and protocol features.