For almost twenty years, HTTP/1.1 and later HTTP/2 traveled over TCP, the transport protocol that guarantees packets arrive in order and without loss. But TCP has a structural problem that becomes obvious precisely when speed matters most: if a single packet is lost, the whole flow slows down. HTTP/3 was born to solve exactly that, changing the foundation on which all web traffic rests.
Why TCP was slowing the web down
TCP (Transmission Control Protocol) offers reliability: it establishes a connection, numbers the packets and retransmits the ones that are lost. The cost of that reliability is head-of-line blocking at the transport level: when a packet goes missing, the receiver does not hand over to the application the data that did arrive until the lost packet is retransmitted and received. In HTTP/2 this is worse because many logical streams share a single TCP connection; a lost packet belonging to one stream holds back all the others, even though their contents have nothing to do with one another.
In addition, opening a TCP connection requires the famous three-way handshake (SYN, SYN-ACK, ACK), and on top of that you still need to negotiate TLS 1.3, the encryption protocol. That process adds several round-trips of latency before the first useful byte is sent.
QUIC: the transport that lives on UDP
HTTP/3 does not use TCP. It uses QUIC (Quick UDP Internet Connections), a transport protocol originally designed by Google and standardized by the IETF in RFC 9000. QUIC runs over UDP, the lightweight connectionless protocol usually associated with video streaming and online gaming.
That choice is no accident. By moving to UDP, QUIC can implement all the transport logic in user space (inside the application, not the kernel): congestion control, retransmissions, encryption and multiplexing. That allows the protocol to evolve without depending on updating the operating system of every server.
The three technical keys of QUIC
1. Blocking-free multiplexing. Each logical stream (each resource the browser requests) is independent. If a packet of an image is lost, the other streams keep being delivered without waiting. TCP’s head-of-line blocking is eliminated.
2. Encryption built into the transport. Unlike TCP, where TLS sits “on top”, in QUIC the encryption (TLS 1.3) is embedded in the protocol itself. Packets travel end-to-end encrypted and the negotiation is merged: the transport and encryption handshakes happen at the same time.
3. 0-RTT connection. With traditional TCP+TLS, several round-trips are needed to get started. QUIC allows that, if you have already connected to that server before (resumed connection), the client can send application data in the very first packet. 0-RTT dramatically reduces perceived latency.
Another practical advantage: QUIC connections use a connection identifier that does not depend on the IP. If the user switches networks (from Wi-Fi to mobile data), the connection is maintained without redoing the handshake. That connection migration is essential on mobile devices.
Where HTTP/3 fits in the stack
HTTP/3 is not a new application protocol; it is the same HTTP semantics (GET/POST methods, status codes, headers, cookies) rewritten on top of QUIC. The mapping is defined in RFC 9114. At the stack level: HTTP/3 (application layer) rests on QUIC (transport layer, with integrated TLS 1.3 encryption), which in turn runs on UDP (network layer).
Protocol negotiation is done via ALPN (Application-Layer Protocol Negotiation) in the handshake itself: the server and client agree on whether they speak HTTP/1.1, HTTP/2 or HTTP/3. Headers are still compressed with QPACK, the equivalent of HTTP/2’s HPACK but adapted to QUIC’s multiplexing.
What this means in practice
Today the main browsers (Chrome, Firefox, Safari, Edge) have HTTP/3 enabled by default, and giants such as Google, Cloudflare, Facebook or Netflix serve it in production. Content delivery systems measure latency improvements especially on connections with packet loss and on mobile networks, where connection migration avoids annoying restarts.
It is not a revolution you will notice in the interface, but in the timings: pages that load sooner, video that starts without waiting, and connections that survive a Wi-Fi switch. It is the invisible infrastructure that makes the internet “feel” faster, and its adoption is one of the most important transport changes since TCP itself became widespread in the nineties.
