Increase and evolve HTTP/3 & QUIC

Status quo

Different ways of measuring

• Cloudflare’s likely-human request share sits ~30%, roughly flat over the past year (Cloudflare Radar).
• Firefox’s own view is lower: HTTP/3 is ~17% of desktop top-level page loads, ~25% on Android (performance.mozilla.org). This counts only the main document the user navigated to, not the ad and tracker subresources that inflate a per-request count.
• It runs higher by other measures: site support ~40% (W3Techs), hyperscaler first-party far higher (Meta ~75%, 2020).
• Requests vs connections changes the answer, too: HTTP/3 multiplexes many requests per connection.

Is ~30% already good enough, or is the plateau a problem worth solving?

Server and CDN support

✓ shipped   ✓ experimental   ✗ none · surveyed 2026-07-11.

Is QUIC supported widely enough, or does the application-framework layer still hold it back?

“Security” software breaks QUIC

• Avast fed neqo an ACK for a packet it never sent, crashing it (a top crash in Nightly 133). neqo now closes the connection instead (bug 1919678, neqo#2150); the close is correct, the proxy is at fault (1923943, INVALID).
• Bitdefender broke Facebook in Firefox 150: a default-off feature (SCONE) still padded every Initial with the bytes 0xc8 0x13, which tripped its HTTP/3 inspection. The handshake completed, so no h3-to-h2 fallback fired. Rolled back in neqo#3573 (bug 2034178).
• CrowdStrike Falcon dropped QUIC crypto frames, so HTTP/3 connections stalled. neqo fell back to h2 correctly, but that fallback path was itself broken (bug 1990699).
• Kaspersky: a spec-wrong unknown_ca alert on shutdown, despite a trusted root (bug 1990210).

Hard to root-cause, and users blame the browser, not the middlebox.

Firefox turns HTTP/3 off under interception

• A third-party root CA in the chain signals the TLS connection is being intercepted (antivirus, enterprise MITM). Firefox then disables HTTP/3 for it (bug 1925014, refined in 1929368).
• Why: interception middleware often proxies QUIC incorrectly, causing bugs users blame on Firefox; HTTP/2 and HTTP/1.1 are assumed better handled (bug 1985341, c7). Chrome does the same (chromium.org/quic: to run a MITM proxy, block QUIC and intercept TLS).

Should we stop disabling, or find a more specific mechanism than any third-party root?

QUIC in enterprise environments

Enterprises have real reasons to block or drop QUIC. The goal is to remove those reasons, not to blame the admin (IETF 124 notes).

• Firewalls often block UDP/443 outright.
• MITM proxies cannot yet inspect QUIC correctly, so it gets disabled on any third-party root.
• Operators lose the flow visibility TCP gave them.
• Banks and regulated networks must audit their traffic. They still can where they own the servers: inspect at the endpoint, not as a passive middlebox.

How do we get vendors to proxy QUIC correctly (conformance testing, RFC 9312), and can qlog give operators back the visibility they need?

QUIC server-side performance is not yet on par with TCP

For many deployments, the honest answer is that switching is not yet worth it on a technical level.

• Usually in user space. Every packet crosses the syscall boundary; io_uring is the emerging zero-copy path, and QUIC can even run in the kernel (msquic). TCP has decades of kernel tuning and NIC-offloaded TLS behind it.
• Offload is less mature. UDP segmentation and receive offload (GSO/GRO) are newer and less universal than TCP’s TSO/LRO, so more of the work happens in software (Cloudflare).
• Higher CPU per byte. QUIC costs more to send than TCP; where infrastructure is weak it can be a net loss. Netflix fills a NIC at 800 MB/s on TCP, not yet on QUIC (IETF 124 notes).
• Congestion control is the hard part. Matching TCP throughput has been more work than QUIC itself, and immature client-side control can make uploads slower, enough that some operators disable QUIC (IETF 124 notes).
• Less operational expertise. Fewer engineers have run QUIC at scale, and the encrypted user-space stack gives operators less visibility than TCP.

The gap is closing (kernel and offload work, maturing stacks): is QUIC worth the switch today, and what closes it fastest?

New use cases that encourage QUIC adoption

HTTP/3-native protocols, each running over QUIC with an HTTP/2 fallback:

QUIC also makes L4S easier to deploy: every ACK frame already carries precise ECT(0)/ECT(1)/CE counts (RFC 9000), the feedback L4S needs, while TCP is still rolling out AccECN. The sender’s response runs in user space, so no kernel change is required (L4S).

Alt-Svc → HTTPS RR: the upgrade path

Do we deprecate Alt-Svc, or bridge it (draft-thomson-httpbis-alt-svcb)?

The wasted round trip

savearoundtrip.com: check whether a domain publishes the record.

Proposal: Optimistic QUIC, Happy-Eyeballs style

• Still listen for an h3 signal (HTTPS RR): it also carries ECH, so it remains useful.
• Signal present: try HTTP/3 first, as today.
• No signal: try HTTP/3 anyway, racing it against HTTP/2 instead of waiting for a later Alt-Svc hint.
• With Happy Eyeballs v3 and a low connection-attempt delay, a failed QUIC race costs little: TCP is already in flight beside it.

QUIC ossification: v2 is barely deployed

• RFC 9369 is functionally identical to v1: only crypto salts, labels and codepoints differ (anti-ossification).
• Firefox Nightly telemetry: v1 ~100%, v2 ~0% of version-labeled QUIC handshakes (GLAM).
• Wider measurement agrees: v2 is on < 0.003% of QUICv1 domains (IMC 2024).
• Is adoption low because there is no technical incentive? v2 buys no new feature, only anti-ossification.
• Probe any origin’s live v1/v2 support at savearoundtrip.com (cold h3 handshake, reports the versions).

Who implements QUIC v2, and who runs it?

Implementing v2 is common, deploying it is rare. Google’s stack implements v2 but its servers run v1; Microsoft runs v2 on Outlook but v1 on Bing. Every visible deployment adds pressure on the holdouts, even those with no technical need. Probed via savearoundtrip.com, 2026-07-15.