CONCEPT Cited by 1 source

HTTP/3¶

HTTP/3 is the HTTP-over-QUIC version of HTTP — standardised in RFC 9114 (2022). Unlike HTTP/1.1 and HTTP/2 (which run over TCP), HTTP/3 runs over QUIC, a transport protocol that runs over UDP and fuses transport + TLS 1.3 cryptographic handshake into a single layer.

This wiki's interest in HTTP/3 is as a connection-handling latency primitive: adopting HTTP/3 reduces connection time because the handshake collapses round trips.

Why HTTP/3 shortens handshakes¶

TCP + TLS 1.3 over HTTP/1.1 or HTTP/2 requires:
TCP 3-way handshake (1 RTT)
TLS 1.3 handshake (1 RTT; 0-RTT resumption possible but restricted)
HTTP request (1 RTT → first byte) Total cold path: ~3 RTTs before any application data flows.
QUIC / HTTP/3 fuses transport and TLS into one handshake:
QUIC + TLS 1.3 fused handshake (1 RTT)
HTTP request piggy-backed on handshake completion Total cold path: ~1 RTT before application data can flow, with opportunistic 0-RTT for returning clients.

For a user ~50 ms from a CDN edge, this is a measurable reduction in connection time — a direct win on the metric Cloudflare uses in its network-performance posts (Source: sources/2026-04-17-cloudflare-agents-week-network-performance-update).

Other HTTP/3 wins¶

No head-of-line blocking at the transport layer. HTTP/2 multiplexed many streams over one TCP connection, but a lost TCP segment blocks all streams until retransmit. QUIC streams are independent at the transport layer; a lost packet affects only the stream it carries.
Connection migration. QUIC connection identity is a connection ID, not a 4-tuple (src-ip, src-port, dst-ip, dst-port). A client that switches networks (Wi-Fi → cellular) keeps the same QUIC connection, preserving TLS session state and eliminating a reconnect.
Faster recovery from packet loss. QUIC's ACK semantics and pacing give more information to the congestion controller than TCP's, enabling faster and more accurate recovery; often paired with modern congestion-control algorithms (BBR variants).
TLS-mandatory. QUIC has no unencrypted mode; HTTP/3 is encrypted by construction. Middleboxes that rewrite TCP headers have nothing to rewrite.

HTTP/3 serving costs (why it's a CDN engineering story)¶

Moving from kernel TCP to user-space QUIC shifts work:

CPU for packet handling. QUIC is typically implemented in user space; every packet is a syscall cross (unless the stack uses batched APIs like recvmmsg / sendmmsg or kernel-bypass). Cloudflare's performance posts repeatedly cite CPU efficiency in the core proxy as a focus area — HTTP/3 makes that focus economic.
Crypto at every packet. Each QUIC packet has an encryption overhead (header protection + payload AEAD); cheap per-packet but non-trivial at millions of pps. AES-NI / ChaCha20 SIMD paths matter.
Congestion control in user space. The congestion controller now lives in the HTTP/3 implementation, not the kernel — see concepts/congestion-window. Tuning is the CDN's own problem; wins compound with PoP densification.
UDP firewall hostility. Some enterprise networks block or throttle UDP/443. HTTP/3 implementations fall back to HTTP/2 over TCP for these clients; a production CDN must handle both.

Adoption posture¶

Cloudflare — HTTP/3 GA since 2020; alt-svc advertisement on HTTPS responses; 2026-04-17 performance post cites HTTP/3 as one of the protocol-level levers driving the 40 % → 60 % ranking shift.
Google — HTTP/3 by default on Google properties; QUIC originated at Google.
Meta / Amazon / Microsoft — all major edge networks ship HTTP/3 in 2025+.

Wiki-level framing¶

Adopting HTTP/3 is a protocol-level change that directly reduces connection time (one of the two orthogonal improvement axes in the CDN-performance playbook). The other axis, PoP densification, reduces physical RTT; HTTP/3 reduces the number of RTTs per connection setup. They compose.

Seen in¶

sources/2026-04-17-cloudflare-agents-week-network-performance-update — canonical wiki instance. Cloudflare names HTTP/3 as one of the "protocols" levers in the sentence "By leveraging protocols like HTTP/3 and changing how we manage congestion windows, we can reduce processing time by milliseconds in code, in addition to the improvements on the wire." — framed as a software-axis contributor to the Sept → Dec 2025 ranking shift from 40 % to 60 % fastest in top networks.