What is HTTP/3 and QUIC?

The problem was TCP, not HTTP

HTTP/2 multiplexed many exchanges over one TCP connection, but TCP only knows about a single ordered byte stream. When one packet goes missing, every byte behind it is held back from the application until the retransmission arrives, even bytes that belong to completely different files. RFC 9114 puts it bluntly: a lost or reordered packet causes all active transactions to experience a stall. On lossy mobile networks that head-of-line blocking is noticeable.

Setup cost is the other issue. A TCP handshake is followed by a separate TLS handshake, and on a high-latency link those round trips visibly push back the first byte.

What QUIC changes

QUIC reimplements what TCP provides (reliable delivery, flow control, congestion control) on top of UDP. UDP was chosen because existing networks already pass it, which made deployment possible without waiting for every router and middlebox to learn a new protocol. Three properties matter most:

• Per-stream reliability. Each stream keeps its own ordering, so loss on one stream does not hold up the others.
• Encryption is built in. TLS 1.3 is part of the QUIC handshake (RFC 9001). There is no unencrypted QUIC, and transport and crypto negotiation complete in a single round trip.
• Connection migration. Connections are identified by connection IDs rather than by IP address and port, so a phone moving from Wi-Fi to mobile data can keep its connection instead of starting over.

HTTP/3 maps unchanged HTTP semantics onto QUIC. HPACK is replaced by QPACK (RFC 9204), because HPACK assumed in-order delivery that QUIC deliberately does not guarantee across streams.

0-RTT and the replay trade-off

A client returning to a server it has talked to before can resume the session and send application data in its very first flight. That is 0-RTT, and the speed-up is real. The catch, in the words of RFC 9000, is that 0-RTT provides no protection against replay attacks: an attacker who captures that first flight can send it again, and the server may process the request twice. Servers therefore usually accept early data only for safe, idempotent requests such as GET. A server that does not want to act on early data can answer 425 Too Early (RFC 8470), telling the client to retry once the handshake has finished.

How browsers discover HTTP/3

On a first visit the browser has no way of knowing that a server speaks QUIC, so it typically connects over TCP with HTTP/2. The server then advertises its HTTP/3 endpoint in a response header:

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

This says the same origin is available over HTTP/3 on UDP port 443 and that the browser may remember this for 86,400 seconds. Subsequent requests try QUIC. DNS HTTPS records (RFC 9460) can deliver the same hint before the first connection is made. Where UDP is blocked, as on some corporate networks, browsers quietly fall back to HTTP/2, so enabling HTTP/3 does not lock anyone out.

Where it helps and how to verify it

Current versions of Chrome, Edge, Firefox and Safari support HTTP/3. The benefit is largest on lossy, high-latency mobile connections; on a fast wired line the difference from HTTP/2 is often small. Many sites get HTTP/3 from their CDN without touching their own servers. If you enable it on your own server, remember that the firewall must allow UDP on port 443.

• In Chrome DevTools, the Protocol column of the Network panel shows h3, usually from the second request onwards rather than the first.
• A curl build with HTTP/3 support can test it directly with curl -I --http3 https://example.com/.
• The SEO Checker lists the alt-svc header among the response headers it reports.

The full protocol is defined in RFC 9114. It still specifies server push, but browsers do not use push over HTTP/3 either.