For more than two decades, every time you opened a website you were using almost the same protocol designed back in the 1970s. TCP and HTTP/1.1 got the job done, but at the cost of time and resources: every connection had to be negotiated before the first byte was served, and a single lost packet could stall the whole page. QUIC and its HTTP/3 layer arrived precisely to break that pact.
The underlying problem: head-of-line blocking
The internet we use daily rests on TCP (the transport protocol that guarantees bytes arrive in order and without errors) and on HTTP, which shapes the content. The structural flaw of that pair is head-of-line blocking. When a page loads an image, a script and a CSS file at the same time, all of those resources travel as packets within the same flow. If packet 3 is lost, packets 4, 5 and 6 are not delivered even if they have already arrived: TCP only forwards the sequence in order, and the browser is left waiting. HTTP/2 tried to fix this by multiplexing several requests onto a single TCP connection, but head-of-line blocking still happened at the transport level: even so, one packet lost in the middle stalled the entire flow.
QUIC: a new transport on top of UDP
QUIC (Quick UDP Internet Connections) attacks the problem by changing its foundations. It does not run over TCP, but over UDP (the connectionless transport protocol, far simpler and faster to handle). The move is elegant: instead of rewriting the transport protocol at the operating-system level —a task that takes years to roll out—, QUIC is implemented entirely in user space, that is, in the application’s own logic. That lets browsers and servers ship updates in weeks rather than in years.
Within each QUIC connection, multiple streams (independent logical flows) are opened. Each stream is like a lane on a highway: if one lane gets congested, the traffic in the others keeps flowing without waiting. Head-of-line blocking between different resources thus disappears: a delayed image no longer holds up the CSS or the JavaScript the user needs to see the page.
Fewer negotiation round trips: 0-RTT and TLS 1.3
Another huge leap is in the startup phase. With classic TCP, several round trips between client and server were needed —the famous three-way handshake— plus the cryptographic negotiation of encryption. In practice, the first request was slow to get going. QUIC integrates TLS 1.3 encryption directly into its connection design, so the key exchange happens in parallel with connection establishment. In the best case, a client that previously met the server can send encrypted data on the very first round trip: that is 0-RTT, zero round trips before data is sent.
Security, incidentally, improves too: every QUIC connection is end-to-end encrypted by default, and encryption is neither optional nor partially negotiable the way it sometimes was with TLS over TCP.
The connection that survives a network change
TCP tied a conversation to an exact pair of IP addresses and ports: server and client. If a phone moved from WiFi to mobile data —changing its IP mid-conversation— the connection broke and had to be rebuilt, losing all context. QUIC introduces the Connection ID: a token that identifies the conversation regardless of the IP addresses. That is why, when your phone switches networks, the QUIC connection can survive the jump without the server even noticing you changed addresses. An improvement that matters especially for live video, calls and games.
Congestion control with room to evolve
QUIC also takes over congestion control —the mechanism that decides how fast data can be injected into the network without saturating it— and lets you modify it without touching the operating system. Because it lives in user space, every application can use different or even cutting-edge algorithms. And to gauge the state of the network more accurately, every QUIC packet carries timing and delay information that used to be guessed only approximately, feeding finer RTT (round-trip time) estimates and, with them, more precise sending policies.
HTTP/3: the application protocol built on QUIC
HTTP/3 is exactly that: the version of HTTP that uses QUIC as its transport instead of TCP. It keeps what the protocol already did well —such as multiplexing and header compression— but packaged on QUIC’s independent streams. The world is moving to it en masse: Chrome, Firefox, Safari, Edge and the main web servers (nginx, Apache with modules, Cloudflare, Caddy’s h3) have supported it for years, and more and more sites deliver the lowest possible latency thanks to this combination.
It is neither magic nor marketing: it is an architectural bet on moving transport intelligence to a plane where it can evolve fast. And, with encryption on by default and resilience to network changes, QUIC does not only make websites faster: it removes one of the biggest historical entanglements of the protocol that carried the web for decades.
