HTTP/3 is the third major version of the protocol that moves the web: the set of rules your browser and servers use to exchange pages, images and data. What you are reading right now has most likely travelled over HTTP/2 or the veteran HTTP/1.1, both of them built on TCP, a transport protocol that dates back to 1974. HTTP/3 breaks with that legacy: it leaves TCP behind and sits on top of UDP with a brand-new protocol called QUIC.
The core problem: one lost packet stalls everything
TCP has a virtue that is also its biggest burden: it guarantees data arrives complete and in order. To achieve that, if a packet is lost along the way, the receiver does not deliver anything that comes after it until the sender retransmits the missing packet. This is known as head-of-line blocking: a single stray packet stalls the whole queue behind it.
HTTP/2 tried to soften this by introducing multiplexing: several resources (the HTML, the stylesheets, the images) travel as independent streams inside a single TCP connection. But they were still inside TCP, and TCP does not distinguish between streams: if a packet from one image is lost, every stream waits. Head-of-line blocking shrank, but it did not disappear.
QUIC: reliability on demand, built on UDP
UDP is TCP’s minimalist sibling: it sends datagrams with no guarantee of order or delivery. It establishes no connection, confirms no receipts, retransmits nothing. That is exactly why it is so fast and light. QUIC takes that base and builds on top of it, in user space (inside the application itself), everything TCP implements in the operating system kernel: reliability, ordering, flow control and congestion control.
That change of location has one huge practical consequence: because QUIC does not live in the kernel, it can be updated and iterated without waiting for Microsoft, Apple or Linux to change their network stacks. Protocol changes ship with the application, not with the operating system.
Three technical ideas that explain its speed
1. Multiplexing without head-of-line blocking
In QUIC every stream is truly independent: if a packet from one stream is lost, only that stream waits; the rest keep flowing. That is the key difference from HTTP/2 and the whole reason to move to UDP.
2. A handshake in one or zero round trips
An RTT (round-trip time) is the time a packet takes to go from your device to the server and back. Setting up a secure HTTP/2 connection with TCP + TLS 1.2 typically cost two RTTs before the first useful byte was sent. QUIC merges the transport handshake with the TLS 1.3 one into a single trip: a brand-new connection is established in 1 RTT. And if you had already connected to that server before, resumption allows 0-RTT: the client sends data in the very first packet, without waiting for the server to confirm.
3. Connection ID and migration
TCP identifies a connection by the tuple (source IP, source port, destination IP, destination port). If you change networks —you leave home and your phone switches from WiFi to 5G— that tuple changes and TCP drops the connection. QUIC uses a connection ID, a random identifier independent of the addresses: you can switch networks and the connection stays alive without renegotiating. This is connection migration, and it is why video does not cut out when you hop between antennas.
Almost fully encrypted
In QUIC almost everything travels encrypted: not only the content, but most of the control header too, including the packet numbers. Only the connection ID and a few fields essential for routing remain in clear. This makes life harder for middleboxes (the intermediate boxes that inspect traffic) and makes tampering with the flow much more difficult.
The price: UDP in a world built for TCP
It is not all advantages. For decades, firewalls and carriers have been configured assuming TCP traffic. Some boxes block or degrade UDP on port 443 (the one QUIC uses), which forces browsers to fall back to TCP when QUIC does not succeed. On top of that, implementing reliability in user space carries a higher CPU cost than delegating it to the kernel, and network monitoring that only understood TCP has to relearn how to read an encrypted protocol.
Where you are already using HTTP/3 without knowing it
HTTP/3 was standardized by the IETF in June 2022. Today a substantial share of the world’s web traffic already flows over it: Google, YouTube, Facebook, Cloudflare and most large CDNs serve it by default. Chrome, Firefox, Safari and Edge support it, and tools like curl enable it with the --http3 flag. Every time a heavy page paints instantly or a video does not cut out when you change networks, QUIC is very likely behind it.
