RFC 9000 / START HERE
QUIC, before the details
QUIC, pronounced “quick”
QUIC is a transport protocol: it carries conversations between applications across a network. It combines secure connection setup with reliable streams, and is used by HTTP/3. This RFC uses QUIC as a name, not an expanded acronym.
The idea in one picture
A browser needs page data
QUIC carries secure streams
The server exchanges responses
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
A connection may carry several independent conversations. QUIC lets them share a secure connection without a missing packet on one stream blocking delivery on every other stream.
A familiar example
An HTTP/3 browser uses QUIC to exchange page data with a web server. A connection can also survive some changes of network address, such as a phone changing networks.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Streams progress independentlyA connection multiplexes ordered byte streams. A gap in one stream does not inherently block delivery on another.→
- Stream IDs describe directionThe low two bits encode the initiator and whether the stream is bidirectional or unidirectional.→
- Establish a protected connectionQUIC integrates a cryptographic handshake and transport-parameter negotiation. The cryptographic details are in RFC 9001.→
- Limit data and stream countsA receiver advertises absolute byte limits for each stream and the whole connection, plus separate stream-count limits.→
- Recover data, not packetsLost information can be carried again in new frames and new packets. A sent packet number is never reused in its number space.→
- Move a connection to a new pathConnection IDs help route packets to an existing connection when a client address changes. New paths need reachability validation.→
This introduction explains RFC 9000 (2021). Read the original RFC ↗