HTTP/3
HTTP/3 runs HTTP over QUIC and UDP, eliminating TCP head-of-line blocking so one lost packet does not stall unrelated streams.
Definition
HTTP/3 is the third major version of HTTP, carrying HTTP semantics over QUIC instead of TCP. QUIC runs on UDP and implements streams, reliable delivery, and congestion control in user space, so a lost packet affects only its own stream rather than every stream sharing the connection. It also folds the transport and cryptographic handshake together, so connections establish in fewer round trips, especially on a resumed session.
Context and scope
Deployed by major CDNs and browsers to improve performance on lossy or mobile networks, negotiated via the Alt-Svc mechanism or DNS HTTPS records.
Common misconceptions
- HTTP/3 is faster on every network — on clean, low-loss connections TCP-based HTTP/2 is often comparable; the gain appears under loss
- It is a different application protocol — HTTP semantics are unchanged; the transport beneath them changes
- It removes the need for TLS — QUIC integrates TLS 1.3; encryption is mandatory, not optional
Anti-patterns
- Enabling HTTP/3 without correctly advertising it, so clients fail to discover it
- Assuming load balancers and middleboxes handle UDP as reliably as TCP without testing
- Choosing HTTP/3 solely for benchmarks on a low-loss internal network
Related concepts
Related examples
Authoritative source
What it is
HTTP/3 keeps HTTP methods, status codes, and headers but replaces the transport. Instead of TCP plus TLS, it uses QUIC: streams are a first-class QUIC concept, so the loss of a packet delays only the stream whose data it carried. QUIC lives in user space over UDP, which lets it evolve faster than the operating system TCP stack, and it integrates the crypto handshake so connection setup and encryption negotiate together.
Why it matters
Under TCP, all multiplexed HTTP/2 streams share a single ordered byte stream, so one lost segment stalls every stream until it is retransmitted — a real penalty on mobile and lossy links. HTTP/3 removes that coupling, delivering on the multiplexing promise precisely where loss is common. It also shortens handshakes, so repeated visits connect faster, and it lets applications control the transport rather than waiting on OS changes.
How to use it well
Advertise HTTP/3 through Alt-Svc or DNS HTTPS records so clients discover it, and keep HTTP/2 available for clients that cannot or should not use it. Verify that load balancers, firewalls, and monitoring handle UDP correctly, because many assume TCP. Measure performance on realistic lossy networks rather than a clean lab, and be aware that QUIC is CPU-heavier than TCP in some stacks.