Back to all articles
HTTP/3QUICTCPUDPWeb Performance

HTTP/3 and QUIC: Why the Internet is Abandoning TCP

Elena RostovaAugust 22, 2024

If you load a webpage on a modern browser today—especially a Google property like YouTube—there is a very high probability that you are not using TCP.

This sounds like heresy. For 40 years, the golden rule of networking was simple:

  • If you need reliable, guaranteed delivery (like a webpage or file download), you use **TCP**.
  • If you need fast, unreliable delivery (like a live video call or gaming), you use **UDP**.

    • TCP is meticulous. It establishes a strict connection (the 3-way handshake), numbers every packet, and if a packet gets lost in transit, TCP halts everything and demands a retransmission.

    But as the modern web evolved, TCP's meticulous nature became its greatest weakness. To fix it, the engineers at Google (and later the IETF) created QUIC and HTTP/3.

    The Problem with TCP: Head-of-Line Blocking

    When you load a modern webpage, you aren't just downloading one HTML file. You are downloading dozens of images, CSS files, and JavaScript libraries simultaneously over a single TCP connection.

    Imagine these files as a train of boxcars moving down a single track.

    Because TCP guarantees strict, ordered delivery, what happens if the 4th boxcar (a small image) derails and gets lost on the network?

    TCP slams on the brakes. The 5th, 6th, and 7th boxcars arrive safely at your computer, but TCP refuses to give them to the web browser. It says, "No, I promised ordered delivery. We have to wait for the server to retransmit the 4th boxcar."

    This is called Head-of-Line Blocking. A single lost packet for a minor image completely halts the loading of the essential CSS and JavaScript that were right behind it. On a spotty mobile network, this makes websites feel incredibly sluggish.

    The Solution: Moving to UDP

    To fix this, engineers realized they had to bypass TCP entirely. But they couldn't just use raw UDP, because UDP drops packets entirely, which would result in corrupted webpages.

    The solution was QUIC (Quick UDP Internet Connections).

    QUIC is a brand new transport protocol built entirely on top of UDP. It takes all the good parts of TCP (reliability, congestion control) and rebuilds them in a smarter way, while dodging TCP's flaws.

    When you use HTTP/3 (which runs on QUIC), the different files (HTML, CSS, images) are sent as independent "streams" within the single UDP connection.

    If we return to the train analogy, QUIC is like putting the files on separate trucks on a highway, rather than a single train on a track. If the truck carrying the small image gets a flat tire and is delayed, the other trucks carrying the CSS and JavaScript simply drive past it and deliver their payload to the browser immediately.

    There is no Head-of-Line Blocking. The webpage renders the text and styling instantly, and the missing image just pops in a second later when it finally arrives.

    Zero Round-Trip Time (0-RTT)

    HTTP/3 solves another massive problem: the handshake delay.

    In the old HTTP/2 over TCP/TLS model, setting up a secure connection took a lot of back-and-forth:

    1. TCP Handshake: SYN -> SYN-ACK -> ACK (1 Round Trip)

    2. TLS Handshake: Exchange certificates and keys (1-2 Round Trips)

    If you are on a phone with 100ms of latency, you've just wasted a third of a second doing nothing but saying hello before a single byte of the webpage is requested.

    QUIC integrates the cryptographic handshake (TLS 1.3) directly into the transport handshake. It does it all at once.

    Even better, if you have visited the website before, QUIC remembers the cryptographic parameters. It can perform a 0-RTT (Zero Round-Trip Time) resumption. Your browser essentially sends the cryptographic "hello" and the HTTP request for the webpage in the exact same initial packet. The server starts sending the webpage immediately.

    The Transition is Invisible

    The brilliant part of HTTP/3 is that it requires absolutely no changes to the actual websites. Web developers don't have to rewrite their code.

    The transition is handled entirely by the web browsers (Chrome, Edge, Firefox) and the web servers (like Nginx or Cloudflare). If both support HTTP/3, they quietly upgrade the connection to UDP in the background. If a corporate firewall blocks UDP on port 443, they seamlessly fall back to the old HTTP/2 over TCP.

    TCP will never truly die; it is still the perfect protocol for countless applications. But for the World Wide Web, the era of TCP dominance is quietly coming to an end.