QUIC

QUIC is a secure, general-purpose transport protocol. It runs over UDP rather than TCP. RFC 9000 defines version 1. QUIC is not an HTTP protocol. It is not a replacement for TLS, either. HTTP/3 is a mapping of HTTP semantics over QUIC. QUIC integrates TLS 1.3 rather than discarding it. Other applications can use QUIC as their transport, too. RFC 9000 is explicit that “QUIC” is a name, not an acronym. Google started work on an early version in 2012. The IETF adopted it in 2016. RFC 9000 was published in May 2021.

The helicopter view: QUIC folds the transport and cryptographic handshakes into one exchange. It carries many independent streams, so a lost packet stalls only its own stream. It names a connection by connection ID, rather than by IP address, so the connection survives a network change. It protects its own transport headers. It brings its own loss detection and congestion control, instead of inheriting the kernel’s.

How it works

1. It runs over UDP but keeps connection state. QUIC is a connection-oriented protocol. It creates a stateful interaction between a client and server. Its packets are carried in UDP datagrams. UDP contributes ports and a checksum. QUIC supplies the handshake, reliability, flow control and congestion control on top.
2. One handshake covers transport and cryptography. QUIC integrates TLS 1.3 instead of layering on top of it. RFC 9001 states that, absent packet loss, most new connections can be established and secured within a single round trip. That single round trip replaces the separate TCP handshake and TLS handshake used before.
3. 0-RTT resumption. This can happen on a subsequent connection between the same client and server. The client can often send application data immediately. This is a zero round-trip setup. It uses information the client has previously learned about the server.
4. Many independent streams. A connection carries multiple simultaneous ordered byte streams. QUIC provides no means of ensuring ordering between bytes on different streams. As a result, loss on one stream does not hold up the others.
5. Connection IDs, not addresses, identify the connection. Each endpoint selects one or more connection IDs for its peer. The peer includes these IDs in packets sent towards the endpoint. That value is opaque to the peer. A QUIC connection is not strictly bound to a single network path. So it can migrate to a new path. Only clients are able to migrate in QUIC version 1.
6. Packets carry their own protection. QUIC packets have confidentiality and integrity protection. This protection covers transport header fields that TCP leaves in the clear. Initial packets are the exception: their keys are derived from a value visible on the wire. So they have no effective confidentiality protection. They exist only to show the sender is on the network path.
7. Loss detection and congestion control belong to QUIC. RFC 9002 specifies them separately from the transport core, with a sender-side controller similar to TCP NewReno. The signals QUIC provides are generic. A sender can unilaterally choose a different algorithm, such as CUBIC.
8. Clients must discover HTTP/3 before they use it. An HTTP origin advertises an equivalent HTTP/3 endpoint. It does this through the Alt-Svc response header field, or through the HTTP/2 ALTSVC frame. The advertisement uses the “h3” ALPN token. The same token is then selected during the TLS handshake. Servers may serve HTTP/3 on any UDP port, so the advertisement always includes an explicit port.

Why it matters for a CDN

• Head-of-line blocking stops at the stream. The parallel nature of HTTP/2’s multiplexing is not visible to TCP’s loss recovery. So a lost or reordered packet causes all active transactions to stall. This happens regardless of whether a given transaction was directly impacted. QUIC provides reliability at the stream level, with congestion control across the whole connection. So an edge serving many objects over one connection keeps the rest moving when one packet drops.
• Fewer round trips before the first byte. Most new connections are established and secured in a single round trip. A resuming client can often send its request with no handshake wait at all. Those are round trips removed from TTFB. That happens on the leg a CDN already works hardest to shorten.
• Connections survive a network change. A viewer moving from WiFi to cellular keeps the same QUIC connection. This works because a connection ID, rather than an address, identifies the connection. A smartphone switching from WiFi to cellular data can cause sluggish performance. Reducing that was an explicit design goal. CloudFront documents HTTP/3 connection migration, so the viewer can switch networks without losing the connection.
• Congestion control becomes the operator’s choice. RFC 9002’s signals are generic, and a sender may unilaterally pick a different algorithm. So an edge operator can change congestion control inside its own QUIC implementation. It does not have to wait on a kernel TCP stack. CloudFront’s implementation, for instance, is built on the open-source s2n-quic.

What CDNs do

Availability and controls differ by provider, so check the one you run on.

• Cloudflare: HTTP/3 is available on all plans, from Free through Enterprise. It does require an SSL certificate at Cloudflare’s edge network. You control it with a zone toggle under Speed, then Settings, then Protocol Optimization. You can also send a PATCH request for the http3 setting through the API. Cloudflare documents the setting as covering the connection between the user and Cloudflare. HTTP/3 to the origin is not yet supported.
• Fastly: HTTP/3 is an optional per-service upgrade. The domain must have TLS 1.3 first. Then you use the HTTP/3 switch in the service settings, or call h3.alt_svc() in vcl_recv. QUIC requires all connections to be secured with TLS 1.3. So configuring a domain to offer HTTP/3 also configures it to offer TLS 1.3 to HTTP/1.1 and HTTP/2 clients. Fastly supports HTTP/3 for end user connections only, not between Fastly and your origin servers.
• Amazon CloudFront: HTTP/3 is a per-distribution choice under Supported HTTP versions. You edit it through the console, the UpdateDistribution API action, or CloudFormation. Viewers must support TLS 1.3 and Server Name Indication. CloudFront supports HTTP/3 connection migration. If you use Route 53, you can also allow protocol negotiation through HTTPS DNS records.

Watch out for

• The first request is never HTTP/3. A client only attempts QUIC once it has seen the offer. So the first request from a browser will always use a lower version of HTTP. The same is true for its first request after a timeout period set by the browser’s developers. Reload before concluding that h3 is broken.
• Blocked or degraded UDP ends the QUIC leg. Connectivity problems, such as blocking UDP, can cause a QUIC connection to fail to establish. RFC 9114 says clients SHOULD then attempt to use TCP-based versions of HTTP. Fastly likewise expects clients to fall back automatically to HTTP/1.1 or HTTP/2 over TCP. Fastly tells you to verify that your particular client implements that fallback. Check that the advertised UDP port, not just 443, is open.
• 0-RTT data can be replayed. Application data sent in a 0-RTT handshake can be replayed by an attacker. So RFC 9001 states that 0-RTT is not suitable for carrying instructions that might initiate any action that could cause unwanted effects if replayed.
• Client IP is not trustworthy in early data. Fastly warns that the authenticity of client IP addresses cannot be guaranteed with 0-RTT when using access control lists. Fastly recommends responding with 425 Too Early when an early data request matches an ACL. Early data requests are identified by the Early-Data: 1 header from RFC 8470.
• TLS 1.3 is not optional. QUIC version 1 uses TLS version 1.3 or greater as its handshake protocol. An HTTP/3 client must indicate the target host during the TLS handshake. It does this by sending SNI when the server is identified by a domain name, unless some other mechanism is used. No TLS 1.3 at the edge means no HTTP/3.
• The win is on the viewer-to-edge leg. Cloudflare does not yet support HTTP/3 to the origin. Fastly does not support it between Fastly and your origin servers, either. So those fetches stay on TCP-based HTTP. Do not measure end to end and credit QUIC with the result.

Best practice

• Enable HTTP/3 where traffic is mobile or crosses a lossy last mile. That is where stream independence and connection migration actually pay off. Keep the TCP path working, too, because clients still need it.
• Keep TLS 1.3 and a valid certificate at the edge. Every major provider gates HTTP/3 on them.
• Advertise HTTP/3 with Alt-Svc, using the h3 token and the UDP port you actually serve. Expect repeat visits, rather than first visits, to use it.
• Send only replay-safe requests as early data. Return 425 Too Early instead of trusting a client IP address on a 0-RTT connection.
• Verify with curl --http3-only against the host, and inspect the Alt-Svc response header. In a browser, reload once before reading the protocol column.
• Establish where HTTP/3 terminates before you measure. If it is viewer to edge only, that is the only leg your numbers can move.