What Is HTTP/3? The QUIC-Powered Web

HTTP/3 is the third major version of the Hypertext Transfer Protocol, and it changes something fundamental: it no longer runs on TCP. Instead, it runs on QUIC, a transport protocol built on UDP that bakes in encryption, faster connection setup, and true stream multiplexing. The result is a web protocol that performs better on the lossy, high-latency networks real users encounter — especially mobile.

A brief history of HTTP versions

To understand what HTTP/3 fixes, it helps to see what each version added.

HTTP/1.1 (1997) — the workhorse of the early web. One request per TCP connection at a time. Browsers worked around this by opening six or more parallel connections per origin, but head-of-line blocking meant a stalled response blocked everything behind it on that connection.

HTTP/2 (2015) — introduced multiplexing: many requests over a single TCP connection, with frames interleaved so responses don’t have to wait for each other. A major improvement, but with a catch: TCP treats the connection as a single ordered stream of bytes. If one packet is lost, TCP stalls the entire connection until that packet is retransmitted — even for requests that had nothing to do with the lost data. This is TCP head-of-line blocking.

HTTP/3 (standardized 2022, RFC 9114) — moves the transport layer from TCP to QUIC. QUIC runs over UDP and manages streams independently, so a lost packet only delays the one stream it belongs to. The rest of the connection keeps moving.

What QUIC changes

QUIC isn’t just UDP with a thin wrapper. It redesigns the transport layer from scratch:

• Independent streams. Each HTTP/3 request is a separate QUIC stream. Packet loss on one stream doesn’t block others.
• 1-RTT connection setup. A fresh QUIC connection completes the transport handshake and TLS 1.3 negotiation in a single round trip — versus TCP’s three-way handshake plus a separate TLS handshake for HTTPS.
• 0-RTT resumption. For repeat connections to a known server, QUIC can send the first application data in the same packet as the handshake — zero additional round trips, though with some replay-attack caveats.
• Built-in TLS 1.3. Encryption isn’t optional or bolted on; it’s part of the QUIC spec. All QUIC connections are always encrypted. This also means HTTPS benefits from the 1-RTT savings by default.
• Connection migration. QUIC identifies connections by a connection ID, not by the four-tuple of IP addresses and ports. When a mobile device switches from Wi-Fi to cellular, the IP address changes — but a QUIC connection can survive that switch without restarting.

Version comparison

	HTTP/1.1	HTTP/2	HTTP/3
Transport	TCP	TCP	QUIC (UDP)
Encryption	Optional (HTTPS)	Practically required	Always (built into QUIC)
Multiplexing	No	Yes, but TCP HOL blocks	Yes, independent streams
Head-of-line blocking	Yes	TCP level	Eliminated
Connection setup	TCP + TLS handshakes	TCP + TLS handshakes	1-RTT (0-RTT on resume)
Connection migration	No	No	Yes

Real-world impact

The gains are most noticeable where packet loss and latency are high. On a reliable fiber connection, HTTP/2 and HTTP/3 perform similarly. On a 4G or 5G network with variable signal, or a congested Wi-Fi environment, HTTP/3’s independent streams mean a single dropped packet doesn’t freeze the page.

Faster handshakes help too. A user on a high-latency connection — say 80ms RTT — saves one full round trip on first load (1-RTT vs 2-RTT), and even more on repeat visits with 0-RTT resumption. Those savings add up for Core Web Vitals metrics like Time to First Byte.

Adoption

HTTP/3 is widely deployed at the infrastructure level. Cloudflare, Google, Meta, and Akamai have supported it since before the RFC was finalized. Major browsers — Chrome, Firefox, Safari, Edge — all support it. CDNs are the easiest on-ramp: if your site sits behind a CDN that supports HTTP/3, your users get it automatically. Cloudflare’s developer platform enables HTTP/3 by default on all proxied domains.

Server-side adoption is more varied. nginx and Caddy have experimental or stable HTTP/3 support. Node.js and others are catching up. For most sites, the CDN layer handles HTTP/3 to the browser while the CDN continues using HTTP/2 or HTTP/1.1 on the origin leg — still a net win for the end user.

One operational note: QUIC runs over UDP, and some firewalls and middleboxes block or throttle UDP at scale. Clients detect this and fall back to HTTP/2 over TCP. The protocol was designed with graceful fallback in mind.

How it connects to the rest of the stack

HTTP/3 is the transport layer. What rides on top — DNS lookups, HTTPS certificates, API calls — stays the same. From a developer standpoint there’s nothing to change in your application code. The protocol negotiation happens via the Alt-Svc response header (the server advertises h3 support) and the HTTPS DNS record type. Your users benefit automatically once your infrastructure supports it.

The takeaway

HTTP/3 is the same HTTP you know, rebuilt on QUIC to eliminate TCP head-of-line blocking, speed up connection setup, and handle real-world network conditions more gracefully. For developers, it’s mostly transparent — CDN or server infrastructure handles it. The meaningful wins are on mobile and high-latency networks, where independent stream handling and 1-RTT handshakes translate directly into faster page loads.