HTTP/2, HTTP/3 and QUIC

What each one fixed

HTTP/1.1

One request at a time per connection, so browsers opened six connections and developers concatenated everything.

HTTP/2

Many streams multiplexed over one TCP connection, plus header compression. Fixed the application-level queue — but a lost packet still stalls every stream, because TCP delivers in order.

HTTP/3

The same multiplexing over QUIC, which runs on UDP and keeps streams independent. A lost packet now stalls one stream. It also establishes a connection in fewer round trips, and survives a change of network — wifi to mobile — without reconnecting.

Who actually benefits

HTTP/3's advantages are proportional to packet loss and latency. On a clean fibre path from Amsterdam to a European user, the difference is small. On a mobile network in a moving train, it is large.

So: if your traffic is heavily mobile or geographically distant, it is worth enabling. If your users are on fixed connections in western Europe, HTTP/2 with good caching gets you nearly everything.

Enabling it in nginx

nginx 1.25.0 and later support HTTP/3 without a patched build:

listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=86400';

The Alt-Svc header is what tells browsers HTTP/3 is available; the first request still arrives over TCP. Use reuseport on exactly one listen directive per address and port, or nginx will not start.

UDP matters now

QUIC is UDP/443. Two consequences:

• Open UDP 443 in your firewall as well as TCP. A half-configured firewall gives you a site that works but never actually uses HTTP/3.
• Your tools change. tcpdump udp port 443, and curl --http3 to test. Many corporate networks block UDP 443 outright, which is fine — browsers fall back to HTTP/2 automatically.

Stop doing the HTTP/1 workarounds

With multiplexing, domain sharding actively hurts: each extra hostname is another connection and another handshake. Concatenating all your CSS into one file is also less useful than it was, and costs you cache granularity. If you enabled HTTP/2 years ago but never undid the workarounds, there is free performance sitting there.

On our network

UDP passes normally and nothing special is needed from us. If you see HTTP/3 working from some networks and not others, that is usually a middlebox on the user's side rather than anything here — but if you suspect a path problem, send us the detail and we will look. See routing problems.

---

Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base