QUIC
ActiveGeneral-purpose transport protocol built on UDP providing multiplexed streams, built-in TLS 1.3 encryption, and 0-RTT connection resumption.
In one line
QUIC is a modern transport protocol standardized in RFC 9000 that runs over UDP and provides all TCP guarantees plus TLS encryption at the transport layer. It eliminates head-of-line blocking through multiplexed streams, achieves 0-RTT connection resumption, and enables connection migration across network changes. QUIC is the underlying transport for HTTP/3.
Quick Reference
| Field | Size | Description |
|---|---|---|
| Header Form | 1 bit | Long (1) or Short (0) header |
| Version | 4 bytes | QUIC version negotiation |
| DCID Length | 1 byte | Destination Connection ID length |
| Destination CID | 0–20 B | Identifies the connection on the receiver side |
| Packet Number | 1–4 B | Per-packet number for ACK and loss detection |
| Payload | Variable | Encrypted QUIC frames (STREAM, ACK, CRYPTO, etc.) |
Key Characteristics
0-RTT Resumption
Resumed connections skip handshake – data in first packet.
Built-in Encryption
TLS 1.3 is mandatory, not optional. All packets are encrypted.
No Head-of-Line Blocking
Stream multiplexing – one lost packet doesn't block others.
Connection Migration
Connections survive IP/port changes (roaming between WiFi and cellular).
Implementations
Edge cases
- •UDP blocking by firewalls or middleboxes forces fallback to TCP.
- •0-RTT data is vulnerable to replay attacks if not handled carefully.
- •Connection IDs must be kept secret to prevent tracking.
- •Many enterprise networks rate-limit UDP, degrading QUIC performance.
History
QUIC originated at Google in 2012 as an experiment to reduce latency for Chrome. Google deployed it across all their services. The IETF standardized it in 2021 as RFC 9000, diverging somewhat from Google's original design. HTTP/3 (RFC 9114) mandates QUIC as its transport.