HTTP/3 is the third major version of the Hypertext Transfer Protocol, standardized by the IETF in RFC 9114 (2022), that carries the familiar HTTP semantics over QUIC instead of TCP. Among Internet protocols it keeps methods, status codes and headers unchanged while replacing the transport underneath them, so the gains come from how bytes move, not from what the requests mean.
The motivation is practical. HTTP/2 multiplexed many requests on one TCP connection, but a single lost packet still stalled every request behind it. HTTP/3 removes that transport-level head-of-line blocking, shortens the handshake by merging transport and encryption setup, and lets connections survive network changes such as a phone moving from Wi-Fi to a cellular network.
How HTTP/3 runs on top of QUIC
HTTP/3 delegates reliability, ordering, congestion control and encryption to QUIC, a transport protocol that runs over UDP port 443 in practice. QUIC provides independent bidirectional streams inside one connection, and HTTP/3 maps each request and response pair to its own stream. A loss on one stream delays only that stream, while the others continue to deliver data to the application.
Encryption is not optional. QUIC integrates TLS 1.3 directly into its handshake, so every HTTP/3 connection is encrypted and most transport headers are also protected. There is no cleartext variant comparable to unencrypted HTTP/1.1, which means HTTP/3 always implies the security properties of HTTPS.
Inside the streams, HTTP/3 uses its own framing layer with frame types such as DATA, HEADERS, SETTINGS and GOAWAY. Header compression is handled by QPACK (RFC 9204) rather than the HPACK scheme of HTTP/2, because HPACK assumed in-order delivery that independent QUIC streams no longer guarantee. QPACK uses separate encoder and decoder streams so that a delayed table update does not block unrelated requests.
The following table shows which layer performs each job in an HTTP/3 connection.
| Function | Handled by | Notes |
|---|---|---|
| Request semantics | HTTP/3 | Methods, status codes and fields as in HTTP/1.1 and HTTP/2 |
| Header compression | QPACK | Dynamic table updated on dedicated streams |
| Multiplexing | QUIC streams | One stream per request and response |
| Reliability and ordering | QUIC | Per stream, not per connection |
| Encryption | TLS 1.3 inside QUIC | Mandatory, also protects packet numbers |
| Datagram delivery | UDP and IP | Typically port 443 |
Connection setup and discovery
A new HTTP/3 connection usually needs one round trip before the first request, compared with two or three round trips for HTTP/2 over TCP with TLS. On a resumed connection, QUIC can send request data in the very first flight using 0-RTT, which saves another round trip but exposes that early data to replay attacks. Servers should therefore accept 0-RTT only for idempotent requests such as simple GET requests.
Clients do not know in advance whether a server speaks HTTP/3. The usual method is the Alt-Svc header sent over an HTTP/1.1 or HTTP/2 response, which advertises an h3 endpoint and how long the advertisement is valid. A newer method publishes the same information in the DNS HTTPS record (SVCB type), allowing a client to try HTTP/3 on the first visit. Browsers commonly race QUIC against TCP and fall back quietly when UDP is blocked.
The table below compares typical handshake costs before the first request byte can be sent.
| Protocol stack | New connection | Resumed connection |
|---|---|---|
| HTTP/1.1 or HTTP/2 over TLS 1.2 | 3 round trips | 2 round trips |
| HTTP/2 over TLS 1.3 | 2 round trips | 1 round trip, or 0-RTT with TLS early data |
| HTTP/3 over QUIC | 1 round trip | 0-RTT for permitted requests |
HTTP/3 compared with HTTP/1.1 and HTTP/2
All three versions express the same HTTP semantics, so applications, caches and APIs generally work without changes. The differences lie in multiplexing, transport and loss behavior, which matter most on networks with latency, packet loss or frequent address changes.
| Property | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Transport | TCP | TCP | QUIC over UDP |
| Multiplexing | None, several connections | Streams in one TCP connection | Independent QUIC streams |
| Head-of-line blocking | Per connection | At the TCP layer | Only within one stream |
| Encryption | Optional | Optional, almost always used | Always required |
| Header compression | None | HPACK | QPACK |
| Connection migration | No | No | Yes, by connection ID |
Connection migration is a distinctive feature. QUIC identifies a connection by connection IDs rather than by the IP address and port pair, so a client whose address changes can validate the new path and continue the same connection instead of starting over.
Deploying HTTP/3 in practice
Most deployments add HTTP/3 alongside HTTP/2, not instead of it. The server or CDN listens on UDP 443 as well as TCP 443, advertises support, and lets clients choose. Because QUIC runs in user space in most implementations, upgrades arrive with the server software rather than with the operating system kernel.
The decision table summarizes common situations and reasonable choices.
| Situation | Recommended choice | Reason |
|---|---|---|
| Mobile audience on lossy networks | Enable HTTP/3 | Loss affects only individual streams |
| Site behind a CDN | Enable at the edge | The CDN terminates QUIC for clients |
| Internal service mesh in a data center | Keep HTTP/2 | Low loss gives little benefit |
| Networks that block UDP | Keep HTTP/2 fallback | Clients must still reach the site |
| APIs with non-idempotent requests | Disable 0-RTT for them | Prevents replayed side effects |
Limitations and common mistakes
HTTP/3 is not automatically faster. On low-latency, low-loss links it often performs similarly to HTTP/2, and its CPU cost per byte can be higher because UDP processing and per-packet encryption in user space are less optimized than mature TCP stacks with hardware offload.
- Blocked UDP traffic in corporate firewalls forces fallback to TCP, so HTTP/2 must remain available.
- Missing Alt-Svc or HTTPS records mean clients never discover the HTTP/3 endpoint.
- Enabling 0-RTT for every request risks duplicated payments, form submissions or other side effects.
- Middlebox visibility drops because QUIC encrypts most headers, which affects traditional traffic inspection.
- Load balancers that route by address break connection migration unless they route by connection ID.
Explained without jargon
When a browser loads a page, it asks a server for many small pieces at once: text, pictures, scripts and styles. Older versions sent all of them down one shared lane. If one piece got lost on the way, everything behind it had to wait until the missing piece was resent.
HTTP/3 gives every piece its own lane. A lost packet now slows only the item it belongs to, and the rest of the page keeps arriving. It also introduces itself to the server faster and can keep the conversation going when a phone switches networks. The pages look the same; they simply tend to arrive more smoothly on imperfect connections.
A typical use case
A news publisher serves a large mobile audience, many of whom read on trains with patchy coverage and packet loss of several percent. The site already runs HTTP/2 behind a CDN. The operations team enables HTTP/3 at the CDN edge, keeps HTTP/2 as a fallback, publishes a DNS HTTPS record and configures 0-RTT only for cacheable GET requests.
After rollout, real-user monitoring shows that a majority of mobile visits now use HTTP/3. The improvement is largest on the slowest connections, where article pages stop stalling while one lost image packet is retransmitted. Users on office broadband see little difference, which matches expectations. The team concludes that HTTP/3 helps most where the network is worst and keeps it enabled as the default for all public traffic.