What is QUIC? The protocol under HTTP/3, compared with HTTP/2

QUIC is a transport protocol, standardised by the IETF in 2021 as RFC 9000, that carries HTTP/3. It does the job TCP and TLS do together for HTTP/1.1 and HTTP/2, but runs over UDP, sets up the connection and the encryption in a single round trip, and keeps each file in its own stream so that one lost packet no longer holds up everything else. For a website, the QUIC protocol mostly means a faster start and a steadier load on mobile and long-distance connections.

This guide is for site owners and developers who have seen "h3" or "QUIC" in a test result or a CDN dashboard and want to know what it is, how HTTP/3 compares with HTTP/2 and whether it is worth switching on. For the whole picture of both protocols, start with the guide to HTTP/2 and HTTP/3.

Quick answer

• QUIC is the transport, HTTP/3 is the HTTP that runs on it. HTTP/3 (RFC 9114, 2022) is HTTP mapped onto QUIC, the same way HTTP/2 is mapped onto TCP.
• It runs over UDP port 443 and has TLS 1.3 built in, so there is no unencrypted QUIC.
• A new connection needs one round trip before the first request, against two for TCP plus TLS 1.3. Repeat visits can use 0-RTT and send the request immediately.
• Lost packets only stall their own stream, not every file on the connection as they do over TCP.
• Connections survive a network change, such as walking out of Wi-Fi range onto mobile data.
• HTTP/3 helps most on slow, lossy or distant connections. On a fast wired line near the server, HTTP/2 and HTTP/3 are hard to tell apart.
• Check whether your site advertises HTTP/3 with the free HTTP/2 and HTTP/3 test.

What is QUIC?

Every page load needs a transport: something that moves bytes between the browser and the server reliably, in order and securely. Since the start of the web that has been TCP, with TLS on top for encryption. QUIC replaces both layers with one protocol.

QUIC started at Google around 2012 and ran in Chrome and on Google's servers for years as an experiment, usually called "Google QUIC" or gQUIC. The IETF took it on in 2016 and published the standard in May 2021 as a set of RFCs:

The IETF version is not the same as Google's early one; browsers and servers today speak the standard. A second version, QUIC v2 (RFC 9369), changes little beyond the version number and exists mainly to keep middleboxes from hard-coding version 1.

QUIC is not only for the web: DNS over QUIC (RFC 9250) uses it too. For websites, QUIC and HTTP/3 come as a pair.

How QUIC works

It runs over UDP, in the application

TCP lives in the operating system's kernel, and changing it means waiting years for every phone, laptop and router to update. UDP is a bare protocol that just sends packets. QUIC builds reliability, ordering and congestion control on top of UDP inside the browser and the server software. That is why it could be deployed and improved quickly: a browser update ships a new QUIC.

The trade-off is that UDP on port 443 must get through. Most networks let it, but some company firewalls, VPNs and antivirus products block or disturb it. Browsers expect that and fall back to HTTP/2 over TCP; when the fallback itself goes wrong, visitors see ERR_QUIC_PROTOCOL_ERROR.

Encryption is part of the handshake

With TCP, the browser first does the TCP handshake (one round trip), then the TLS 1.3 handshake (another round trip), and only then sends the request. With TLS 1.2 it is three round trips in total. QUIC merges the transport and TLS 1.3 handshakes into one, so a brand-new connection is ready after a single round trip.

For a visitor 150 ms away from your server, every saved round trip is 150 ms earlier for the first byte, the first paint and the Largest Contentful Paint. That is the part of time to first byte HTTP/3 shortens; it does nothing for the time your server spends building the page.

QUIC also encrypts almost all of its own packet headers, not just the content. Networks in between can see much less about the connection than they could with TCP, which is good for privacy and makes it harder for middleboxes to interfere.

0-RTT on repeat visits

When a browser has connected to your server before, it can resume the session and send its first request in the very first packet, with no round trip at all. This is 0-RTT. The catch is that 0-RTT data can be replayed by an attacker who captures it, so servers only accept it for requests that are safe to repeat, such as plain page GETs, and many leave it off. The enable guide shows where the setting lives.

Streams without head-of-line blocking

HTTP/2 already sends many files at once over one connection. But TCP delivers bytes strictly in order, so if one packet is lost, every file on the connection waits until it is sent again. On a phone with a weak signal this happens often, and one lost packet of an image can hold up the CSS the page needs to render.

QUIC knows about streams. Each file travels in its own stream, and a lost packet only delays the stream it belonged to; the rest keep flowing. This is the main reason HTTP/3 behaves better on lossy networks.

Connection IDs and migration

A TCP connection is tied to the IP addresses and ports on both ends. When a phone switches from Wi-Fi to mobile data, its address changes and every connection has to start again. QUIC identifies connections by an ID instead, so a connection can move to the new network and carry on without a new handshake.

HTTP/3 vs HTTP/2: what actually changes

HTTP/3 keeps what HTTP/2 introduced (requests and responses as streams, many files over one connection, compressed headers, priorities) and moves it from TCP to QUIC. For your pages, URLs, headers, status codes and caching, nothing changes.

Two things do not change. The server still has to build the page, so a slow uncached WordPress page is just as slow on HTTP/3. And a 2 MB hero image is still 2 MB: QUIC moves bytes more gracefully, it does not remove them. If you are still deciding between HTTP/1.1 and HTTP/2, HTTP/2 vs HTTP/1.1 is the bigger step and the one to take first.

How a browser finds HTTP/3

A browser cannot know in advance that a server speaks QUIC, so the first connection to a site is normally made over TCP with HTTP/2. The response carries an Alt-Svc header such as:

alt-svc: h3=":443"; ma=86400

It means "HTTP/3 is available on UDP port 443 for the next 86,400 seconds". The browser remembers that and tries QUIC for its next connection, keeping TCP as a fallback. Sites can also publish an HTTPS record in DNS (RFC 9460) that lists h3, which lets browsers that read it try HTTP/3 on the very first connection.

That is why your developer tools can show h2 for the first load and h3 after a reload, and why a test that makes one fresh connection reports HTTP/2 even when HTTP/3 is on.

When HTTP/3 helps, and when it does not

HTTP/3 makes the most difference where the network is the problem:

• Mobile visitors, especially on the move, where packet loss and network changes are common.
• Visitors far from your server, where each round trip is long and saving one or two per connection is noticeable.
• Pages that open several connections, because each new connection saves its handshake.

It makes little difference when the visitor is on a good wired connection close to the server, when the page is slow because of server time or heavy files, or when most of the page comes from third-party hosts that do not support HTTP/3 anyway.

There are costs, mostly for whoever runs the server. QUIC in software uses more CPU per byte than kernel TCP, UDP port 443 must be open through every firewall and load balancer, and a load balancer has to keep all packets of a QUIC connection on the same server. On a CDN such as Cloudflare these are the CDN's problem, which is why turning on HTTP/3 there is a single switch. On your own nginx, HTTP/3 support is still labelled experimental.

For search, neither protocol is a ranking factor in its own right. A faster first byte and LCP for real visitors can show up in Core Web Vitals, which Google does use; the HTTP/2 and HTTP/3 guide covers what Google has said about protocols and crawling.

How to check whether your site uses QUIC

The test makes a TLS handshake with your server and records the protocol it picks through ALPN, reads the Alt-Svc header of the page to see whether HTTP/3 is advertised, and then loads the page in Chromium and groups every response by the protocol it actually used (h3, h2 or http/1.1). A single fresh visit usually arrives over HTTP/2; the Alt-Svc row is what tells you HTTP/3 is on for the next one.

In your own browser, open developer tools → Network, right-click a column header and add Protocol, then reload twice. h3 in that column means the file came over QUIC. From a terminal, a curl build with HTTP/3 support can test it directly:

curl -sI --http3-only https://example.com/ | head -1

A response such as HTTP/3 200 means QUIC works end to end. An error while curl -sI --http2 succeeds means HTTP/3 is advertised or expected but not answering, which is worth fixing before visitors run into it.

Should you turn on HTTP/3?

For most sites, yes, as long as HTTP/2 stays on beside it:

1. On a CDN, switch it on. Cloudflare, most other large CDNs and many managed hosts support HTTP/3 at the edge regardless of what your origin speaks.
2. On Caddy or LiteSpeed, it is usually on already; make sure UDP 443 is open in the firewall.
3. On nginx, it needs version 1.25.0 or newer built with the HTTP/3 module, a listen 443 quic line, the Alt-Svc header and UDP 443 open. Test with curl before announcing it.
4. On Apache, there is no HTTP/3 in the stable server; put a CDN or an HTTP/3-capable proxy in front.

The step-by-step settings for each of these are in how to enable HTTP/2 and HTTP/3. The one rule that matters: never advertise h3 from a server that is not listening on UDP 443. Browsers try it, wait, and fall back, which is slower than not advertising it at all.

Common mistakes

• Expecting HTTP/3 to fix a slow server. It saves round trips before the request; server think time and page weight stay the same.
• Advertising h3 without opening UDP 443. The browser tries QUIC, times out and falls back to HTTP/2 on every new connection.
• Turning HTTP/2 off. HTTP/3 always needs HTTP/2 (or HTTP/1.1) beside it, for the first visit and for networks that block UDP.
• Enabling 0-RTT without thinking about replays. Keep it off unless your application treats repeated GET requests safely.

Questions people ask

What does QUIC stand for?

Nothing, officially. It began at Google as an abbreviation of "Quick UDP Internet Connections", but the IETF standard, RFC 9000, treats QUIC as a name rather than an acronym. Whatever you call it, it is the same thing: a transport protocol over UDP with TLS 1.3 built in, used as the base for HTTP/3 and for some other protocols such as DNS over QUIC.

Is QUIC the same as HTTP/3?

No. QUIC is the transport layer that moves encrypted bytes between browser and server, the role TCP and TLS play for HTTP/2. HTTP/3 is the version of HTTP that runs on top of QUIC, defined separately in RFC 9114. In practice they arrive together on the web, so "turn on QUIC" and "turn on HTTP/3" usually mean the same switch in a CDN or server.

Why is QUIC built on UDP instead of TCP?

Because TCP is built into operating systems and network hardware, and changing it takes years. UDP simply delivers packets, which lets QUIC implement reliability, ordering, streams and congestion control inside browsers and servers, where it can be updated with a normal software release. The price is that some firewalls and VPNs block or disturb UDP, so browsers keep HTTP/2 over TCP as a fallback.

Is HTTP/3 faster than HTTP/2 for every visitor?

Not for every visitor. HTTP/3 saves a round trip on new connections and copes better with packet loss and network changes, so it helps most on mobile networks and over long distances. On a fast wired connection close to the server, the difference is small. It never speeds up a slow server or a heavy page; fix those first, then add HTTP/3 alongside HTTP/2.

Can QUIC be blocked by a firewall?

Yes. Some company networks, VPNs and security products block UDP port 443 or inspect traffic in ways that break QUIC. Browsers then fall back to HTTP/2 over TCP, usually without the visitor noticing. When the fallback does not happen cleanly, the visitor sees an error such as ERR_QUIC_PROTOCOL_ERROR. Site owners should keep HTTP/2 enabled and UDP 443 open on their own servers.