HTTP/3 and QUIC Are Now Supported on Agiler

The Agiler router now speaks HTTP/3 over QUIC. Every project on the platform advertises it automatically, alongside the HTTP/2 and HTTP/1.1 it already serves, and a returning visitor gets their request answered before the handshake has finished. You do not need to turn anything on.

How a visitor ends up on HTTP/3

A browser cannot open an HTTP/3 connection the way it opens an HTTP/2 one. The transport underneath is different, so there is no ALPN negotiation to rely on. The server has to advertise the protocol first, and the router does that with an Alt-Svc header on every TLS response:

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

The first request still arrives over TCP. The response carries the hint, the browser caches it for the advertised lifetime, and later requests go to QUIC on UDP port 443. No redirect, and no extra round trip on that first page load.

Clients without HTTP/3 support ignore the header and stay on TCP. So do clients on networks that block or degrade UDP: when the QUIC attempt fails, the browser falls back to HTTP/2 and stops retrying.

What QUIC changes

A lost packet only stalls its own stream. HTTP/2 multiplexes many requests over one TCP connection, and TCP hands up a single ordered byte stream. One dropped packet holds up everything queued behind it, including responses that already arrived complete. QUIC tracks each stream separately, so a retransmission delays only the stream that lost data. On a lossy mobile connection that is the difference between one slow image and a page that looks frozen.

The handshake is one round trip instead of two. TCP’s three-way handshake and the TLS handshake that follows it are separate exchanges. QUIC carries the cryptographic handshake inside its own. For a visitor who has been here before, it is now none at all.

Zero round trips for a returning visitor

A returning visitor holds a session ticket from the last connection, and the keys that came with it. 0-RTT lets them use those straight away: the client encrypts its request under the resumed keys and sends it in the opening flight, without waiting for the handshake. The request reaches WordPress while the handshake is still in progress. On a link with a 200ms round trip, that is 200ms off the first byte of the page.