HTTP/3

HTTP/3 is the third major version of HTTP, published in June 2022 as RFC 9114. It carries the same HTTP semantics as HTTP/2: the same methods, status codes and header fields. HTTP/3 just sends them over a different transport. It runs on QUIC version 1, a multiplexed, encrypted stream transport. QUIC packets travel in UDP datagrams, not over TCP. HTTP/3 is not a new way of writing web applications. It changes nothing about what a request means. RFC 9114 calls it “a mapping of HTTP semantics over the QUIC transport protocol”. Its early IETF drafts were titled “Hypertext Transfer Protocol (HTTP) over QUIC”. Three things improve with HTTP/3. Connection-wide head-of-line blocking ends. A handshake usually completes in one round trip. A connection survives when a client moves to another network. Two costs come with it. UDP is a dependency, and some networks break it. An optional 0-RTT fast start trades replay risk for latency.

How it works

Because HTTP/3 uses a different transport, a client must first learn that an HTTP/3 endpoint exists. There are two discovery routes, and a CDN typically uses both:

• Alt-Svc over an existing HTTP/1.1 or HTTP/2 response. The origin advertises an equivalent HTTP/3 endpoint. It uses an Alt-Svc response header field, or the HTTP/2 ALTSVC frame. Both name the “h3” ALPN token. RFC 9114's own example is Alt-Svc: h3=":50781" (RFC 9114 section 3.1.1). A server may serve HTTP/3 on any UDP port. An alternative service advertisement always includes an explicit port (RFC 9114 section 3.1). On receipt the client may try QUIC. Doing so costs one earlier TCP connection to find out.
• An HTTPS DNS record. A ServiceMode HTTPS resource record such as @ 7200 IN HTTPS 1 . alpn=h3 publishes the same offer in DNS. The client can then pick QUIC on the very first connection, instead of bootstrapping over TCP (RFC 9460 section 10.4.1). Akamai exposes this as HTTPS Service Binding. CloudFront points at Route 53 HTTPS records.

Discovery is only a hint. The transport change becomes real when both sides select the “h3” ALPN token during the TLS handshake. HTTP/3 relies on QUIC version 1. QUIC version 1 uses TLS 1.3 or greater. An HTTP/3 client must also signal the target host to the server, normally with the SNI extension (RFC 9114 section 3.2). The “http” scheme is defined in terms of accepting TCP connections. So HTTP/3 cannot be used for direct access to the authoritative server for an “http” URI. In practice, HTTP/3 is an https-scheme protocol (RFC 9114 section 3.1.2).

Four properties of QUIC then do the work:

1. Combined handshake. QUIC integrates the TLS 1.3 handshake directly into the transport handshake, instead of layering TLS on top (RFC 9114 section 1.2). Absent packet loss, most new connections are established and secured within a single round trip. On a later connection to the same server, the client can often send application data immediately. This is the 0-RTT mode. It needs prior communication or configuration to enable (RFC 9001 section 1).
2. Independent streams. Each request-response pair consumes a single QUIC stream. Streams are independent, so one stream that is blocked or loses a packet does not stop the others (RFC 9114 section 2). When a packet is lost, only the streams with data in that packet wait for the retransmission (RFC 9000 section 13). Under HTTP/2 over TCP, a lost or reordered packet instead stalls every active transaction, whether or not it was directly affected (RFC 9114 section 1.1).
3. Loss-tolerant field compression. HPACK relies on in-order transmission of compressed field sections. QUIC does not provide that guarantee, so HTTP/3 replaces HPACK with QPACK (RFC 9114 section 2). QPACK reuses HPACK's core concepts, but it is redesigned for correctness under out-of-order delivery. It aims at HPACK's compression ratio, with substantially less head-of-line blocking under the same loss conditions (RFC 9204 section 1).
4. Connection migration. A QUIC connection is identified by connection IDs, not by the address pair. So it survives a change of IP address and port without a new handshake. For example, a handset might leave Wi-Fi for cellular, or a NAT might rebind. Only the client may migrate in QUIC version 1. Migration cannot start before the handshake is confirmed, and the endpoint must revalidate the new path (RFC 9000 section 9).

HTTP/3 connections are persistent. Once a connection to a server endpoint exists, it may be reused for requests to other URI authorities. This requires the client to validate the presented certificate for each new origin (RFC 9114 section 3.3). That coalescing is what makes a single edge connection serve a whole page.

Why it matters for a CDN

The leg between the viewer and the edge server is the long, lossy, variable part of CDN delivery. The edge-to-origin leg is short and usually well provisioned. HTTP/3 targets exactly the viewer leg. It cuts round trips before the first byte. A lost packet delays one object instead of the whole page. A connection does not have to be rebuilt when a phone switches network. That is why the biggest wins show up on mobile and congested Wi-Fi, rather than on a wired office link.

It is also cheap to adopt through a CDN, because the CDN terminates QUIC for the viewer and keeps talking to your origin over HTTP/1.1 or HTTP/2. Cloudflare states that HTTP/3 “is implemented as standard in all major Web browsers and can be enabled by all Cloudflare customers without any changes to their origin” (Cloudflare learning centre). Its own product docs say HTTP/3 to the origin is “not yet supported” (Cloudflare docs). So HTTP/3 is normally an edge-side setting, not an origin migration.

The catch for a CDN operator is that HTTP/3 is a third protocol to run, not a replacement. UDP must reach the edge. The client's address can change mid-connection. 0-RTT interacts badly with anything that writes state. All three problems land on the edge tier, not on the origin.

What CDNs do

• Cloudflare serves HTTP/3 on the connection between the user and Cloudflare. It is available on all plans, but it requires an SSL certificate at Cloudflare's edge network. You toggle it under Speed → Settings → Protocol Optimization, or with the http3 setting over the API. HTTP/3 to the origin is “not yet supported” (Cloudflare docs).
• Akamai offers HTTP/3 as an opt-in behavior added to a property, with only one instance allowed per property. The certificate on the property hostname must have TLS 1.3 enabled in its deployment settings. You can gate rollout by hostname, or by a percentage of requests. Including the behavior automatically generates an Alt-Svc header. It presets a max-age (ma) of 93600 seconds, and you can override it with the Alt-Svc Header behavior (Akamai TechDocs).
• AWS CloudFront lets you choose which HTTP versions the distribution offers to viewers. For HTTP/3, viewers must support TLS 1.3 and SNI. CloudFront also supports HTTP/3 connection migration, so a viewer can switch networks without losing the connection. With Route 53, you can also publish HTTPS records so negotiation happens during the DNS lookup (AWS CloudFront docs).
• Fastly describes its HTTP/3 support as currently in limited availability. Fastly writes Alt-Svc into responses itself. It notes that HTTP/3 requires an Alt-Svc header to upgrade from HTTP/1 or HTTP/2, because HTTP/3 uses UDP while those use TCP. In VCL services, it advises the h3.alt_svc function, so the offer always matches Fastly's current support (Fastly docs).
• Self-hosted edges lag the CDNs. nginx's ngx_http_v3_module arrived in 1.25.0. It still describes itself as experimental, and it is not built by default (nginx docs).

Watch out for

• UDP gets blocked. QUIC needs UDP. Firewalls, captive portals and some corporate networks drop or throttle it. RFC 9114 says connectivity problems, such as blocking UDP, can cause QUIC establishment to fail. It also says clients SHOULD attempt to use TCP-based versions of HTTP in that case (RFC 9114 section 3.1). So HTTP/1.1 and HTTP/2 must stay enabled. HTTP/3 is an addition, never a replacement.
• 0-RTT is replayable, and a CDN edge carries extra duty. Use of TLS early data comes with an exposure to replay attack. 0-RTT in QUIC is similarly vulnerable. The replay protections in TLS 1.3 are acknowledged to be imperfect, and disabling 0-RTT entirely is the most effective defence (RFC 9001 section 9.2). HTTP/3 makes the mitigations in RFC 8470 mandatory when 0-RTT is used (RFC 9114 section 10.9). Concretely, an intermediary that forwards a request before its client's TLS handshake completes MUST add Early-Data: 1. The intermediary sets that header, not the browser. A gateway MUST NOT forward early-data requests unless it knows the origin understands Early-Data and will return 425 (Too Early) (RFC 8470 section 5.1 and 6.1).
• Head-of-line blocking is reduced, not abolished. Loss still blocks the streams whose data was in the lost packet. If several streams share one QUIC packet, its loss blocks all of them (RFC 9000 section 13). QPACK aims only at substantially less header blocking under the same loss conditions (RFC 9204 section 1). QUIC provides reliability at the stream level, but congestion control applies across the entire connection (RFC 9114 section 1.2). So a saturated path is still a saturated path.
• The client address is no longer stable. A QUIC client's address can change during a connection. So edge logic that logs or access-controls on client IP must actively re-read the current address, or explicitly accept that the original one may change (RFC 9114 section 10.10). This quietly breaks IP-based rate limits, geo rules and allowlists written for TCP. A server that cannot tolerate it can send the disable_active_migration transport parameter (RFC 9000 section 9).
• Mixed protocols across your own hostnames defeat discovery. Akamai warns that if the base domain is served only over HTTP/1 or HTTP/2, HTTP/3 may not work for its subdomains, even when enabled there, because the reused connection to the HTTP/2-only domain never sends the Alt-Svc header. Separate certificates for base and subdomains let clients open independent connections (Akamai TechDocs). Connection reuse across origins is exactly the behaviour RFC 9114 permits (RFC 9114 section 3.3).
• QUIC is not a synonym for HTTP/3. QUIC is the transport. HTTP/3 is one application protocol mapped onto it, identified by the registered ALPN identification sequence h3 (RFC 9114 section 11.1). The naming moved during standardisation. draft-ietf-quic-http-01 was titled “Hypertext Transfer Protocol (HTTP) over QUIC” and used the token hq (draft-ietf-quic-http-01). By the later drafts the token was h3. Draft implementations, though, were forbidden from using the bare string, and had to append a hyphen and the draft number. That is where tokens such as h3-29 in older blog posts and configuration snippets come from (draft-ietf-quic-http-29 section 3.1). Neither is RFC 9114.

Best practice

• Turn HTTP/3 on at the edge, and leave HTTP/1.1 and HTTP/2 on beside it. Clients on UDP-hostile networks are meant to fall back to TCP-based HTTP (RFC 9114 section 3.1). If you disable the fallback, they simply fail.
• Advertise the endpoint both ways. Use an Alt-Svc header with the h3 token and an explicit port, for clients already connected over TCP. Use an HTTPS DNS record with alpn=h3, so first-time clients skip the TCP bootstrap. Note that Alt-Svc lifetime is the ma parameter, while the HTTPS record's lifetime is its DNS TTL (RFC 9460 section 9.2.3).
• Pick an ma value deliberately. nginx's own reference configuration uses add_header Alt-Svc 'h3=":8443"; ma=86400'; (nginx docs). Long values keep clients on QUIC across visits. Short values let you back out quickly if the UDP path misbehaves.
• Serve HTTP/3 on the same port as HTTPS where you can. nginx recommends this for compatibility. Doing so also keeps the Alt-Svc offer trivially correct (nginx docs).
• Test the two halves separately. curl --http3-only https://example.com/ proves the QUIC endpoint answers. But curl documents that this option “allows a user to avoid using the Alt-Svc method of upgrading to HTTP/3”. So it does not test discovery at all. It also needs a libcurl built with HTTP/3 support (curl manual). Check the advertisement itself on an HTTP/1.1 or HTTP/2 response. Check the DNS side with an HTTPS record query.
• Leave 0-RTT off unless you have done the replay work. If you enable it, confirm your origin honours Early-Data and can return 425 (Too Early). A gateway that cannot establish that must not forward early data at all (RFC 8470 section 6.1). Disabling 0-RTT is the most effective defence against replay (RFC 9001 section 9.2).
• Audit anything keyed on client IP before enabling HTTP/3. That includes logs, rate limits, geo rules and allowlists. This matters because the viewer's address can now change inside one connection (RFC 9114 section 10.10).
• Terminate QUIC at the CDN edge, and keep the origin on HTTP/1.1 or HTTP/2. HTTP/3 to origin is not widely documented. Cloudflare, for instance, states it is “not yet supported” (Cloudflare docs). The short, well-provisioned edge-to-origin hop is not where HTTP/3's loss and migration benefits pay off anyway.