HTTP/3

Pronunciation: aych-tee-tee-pee THREE

Updated October 6, 20262 min read

In short

HTTP/3 is the third major version of HTTP, which runs over the QUIC protocol on UDP instead of TCP to load pages faster, especially on unreliable networks.

What is HTTP/3?

HTTP/3 was published by the IETF in 2022 as RFC 9114. It keeps everything developers know from earlier versions, the same methods, status codes, headers and URLs, but replaces the transport underneath: instead of TCP with TLS on top, it runs over QUIC, a protocol built on UDP with TLS 1.3 encryption built in. Like HTTP/2, it multiplexes many requests over one connection, and it compresses headers with QPACK, a variant of HTTP/2's HPACK adapted to QUIC.

The gains come from QUIC. A new connection is usually ready after a single round trip instead of two or three, and a returning visitor can send a request in the very first packet. Because each stream is delivered independently, a lost packet delays only the file it belongs to, not every request on the connection, and a download can continue when a phone switches from Wi-Fi to mobile data.

Browsers don't start with HTTP/3, since they can't know in advance that a server supports it. The first response over HTTP/2 or HTTP/1.1 carries an Alt-Svc header, or the site publishes an HTTPS record in DNS, and the browser switches to HTTP/3 for later requests, falling back to TCP if a network blocks UDP. All major browsers and CDNs support it, as do servers such as NGINX and Caddy, so turning it on is usually a configuration change rather than a code change.

HTTP/3 is often confused with QUIC, and its relation to HTTP/2 is often misunderstood. QUIC is the transport protocol, while HTTP/3 is the mapping of HTTP onto it; other protocols, such as DNS over QUIC, use QUIC too. HTTP/3 doesn't make HTTP/2 obsolete: both are used side by side with similar features, and the real difference is that HTTP/2's streams share one TCP connection, so a single lost packet stalls them all, while HTTP/3's streams don't.

Key takeaways

HTTP/3 was standardized in 2022 as RFC 9114 and runs over QUIC on UDP.
HTTP semantics stay the same: methods, status codes and headers don't change.
Faster connection setup and independent streams avoid TCP's head-of-line blocking.
Servers advertise it with Alt-Svc or DNS, and browsers fall back to HTTP/2 when UDP is blocked.
It helps most on slow, lossy or changing mobile networks.

Example

Enabling HTTP/3 in NGINXnginx

server {
    # HTTP/3 over QUIC on UDP port 443; HTTP/1.1 and HTTP/2 on TCP port 443
    listen 443 quic reuseport;
    listen 443 ssl;
    http2 on;

    ssl_certificate     /etc/ssl/example.com.crt;
    ssl_certificate_key /etc/ssl/example.com.key;

    # Tell browsers that HTTP/3 is available on the same port
    # (the firewall must also allow UDP port 443)
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Readers ask

What is the difference between HTTP/2 and HTTP/3?

They offer the same HTTP features, but HTTP/2 runs over TCP and HTTP/3 over QUIC on UDP. That lets HTTP/3 set up connections faster, keep streams independent when packets are lost, and survive network changes.

Do I need to change my code to use HTTP/3?

No. Requests, responses and headers work the same way, so applications don't change. It is enabled in the web server, load balancer or CDN, which also needs UDP port 443 open.

Is HTTP/3 always faster?

Not always. On fast, stable connections the difference is small, and QUIC can use more server CPU than TCP. The biggest gains are on mobile and long-distance connections with packet loss.

Sources

Spotted a mistake or something missing on this page?Suggest an edit