JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

HTTP/1.1 to HTTP/2 to HTTP/3

The grammar of HTTP barely changed, but the way its words travel over the wire has been reinvented twice. This guide follows that journey, from a queue of requests waiting their turn, to many requests sharing one connection, all the way to HTTP running over a brand-new transport.

Same words, faster delivery

In the previous guides you learned HTTP as a request and a response made of plain text: a method, a path, some headers, a status code, a body. Here is the first thing to hold onto, because it surprises people: that grammar — the methods, the status codes, the meaning of the headers — barely changes across HTTP/1.1, HTTP/2, and HTTP/3. A GET is still a GET; a 404 is still a 404. What changes between the versions is not what you say, but how those messages are packed up and carried over a connection. So this whole story is about delivery, not vocabulary.

Why bother, if the meaning is the same? Because a modern web page is not one file; it is dozens or hundreds of them — the HTML, then stylesheets, scripts, images, fonts. Each one is a separate HTTP request, and the time it takes a request to go out and its response to come back is one round-trip time (RTT). On a connection across a continent that RTT might be 80 milliseconds; over a satellite link, much more. Loading a page can mean a great many of these little round trips, so how cleverly you can overlap them decides whether a page snaps in or crawls. That pressure is what drove three generations of design.

HTTP/1.1: one lane, and the cost of a line

HTTP/1.1's big improvement over the original was the persistent connection: instead of opening a fresh TCP connection — and paying the three-way handshake — for every single file, the browser keeps one connection open and reuses it for request after request. That alone saved a handshake per object and was a huge win. But it left a sharper problem in plain sight. On one HTTP/1.1 connection, requests are served strictly in order, one at a time: you send request, wait for its full response, then send the next. It is a single checkout lane.

Now picture a slow response stuck at the front: a big image that takes a while to generate. Every request queued behind it must wait, even tiny ones that would have finished instantly. This is head-of-line blocking at the HTTP level: one slow item at the head of the line holds up everyone behind it, just like a single shopper with a full cart freezes a checkout queue. Browsers worked around it with a blunt trick — open six or so parallel connections to the same server and spread requests across them — but that is six handshakes, six lots of memory, and still only six lanes. The real fix had to come from the protocol itself.

HTTP/2: many lanes on one road

HTTP/2 keeps the same single connection but breaks the one-at-a-time rule. Its core idea is multiplexing: many requests and responses are interleaved over one connection at the same time. To do this, HTTP/2 stops sending each message as one continuous block of text. Instead it chops every request and response into small labelled pieces called frames, where each frame carries a stream identifier saying which request it belongs to. The frames of different requests can then be mixed together on the wire, and the receiver sorts them back into separate streams by their labels.

HTTP/1.1 (one connection): requests served in order
  [---- request A ----][-- B --][------ C ------]   <- C waits for A and B

HTTP/2 (one connection): frames interleaved, labelled by stream
  [A1][B1][A2][C1][B2][A3][C2][B3]...               <- A, B, C make progress together
   |   |   |   |
   stream 1 (A)  stream 3 (C)
       stream 1 (B is stream 5), etc.
HTTP/1.1 serves one request fully before the next, so a slow A stalls B and C. HTTP/2 slices each request into frames stamped with a stream id and interleaves them, so all three progress over a single connection — that is multiplexing.

With multiplexing, that one slow image no longer freezes the queue: its frames simply take their turn among everyone else's, and the small fast responses can stream back in between. HTTP/2 also fixes the header waste from the last section with header compression (a scheme called HPACK) that remembers headers already sent and refers back to them instead of repeating the full text. The result is that one HTTP/2 connection does the job that used to need six HTTP/1.1 connections, with less overhead and no manual juggling.

HTTP/3: a new road underneath

HTTP/3 is, at heart, a simple sentence: HTTP/3 is HTTP/2's ideas carried over a brand-new transport called QUIC instead of TCP. QUIC runs on top of UDP — which by itself does nothing but deliver independent packets without ordering — and then rebuilds, in user space, the reliability, ordering, and congestion control that TCP gave us, but with one decisive change: QUIC understands streams. Because QUIC knows that frame belongs to stream 1 and that other frame belongs to stream 3, a packet lost on stream 1 only holds up stream 1. Stream 3's data, already arrived, is delivered immediately. The transport-level head-of-line blocking that haunted HTTP/2 is gone.

Why build all this on UDP rather than fixing TCP? Two honest reasons. First, TCP is baked into operating-system kernels and into countless middleboxes — routers, firewalls, NAT devices — along the path, many of which inspect or mangle anything that does not look like the TCP they expect. Changing TCP itself would take a decade to deploy across that frozen infrastructure. UDP, by contrast, is a thin, widely-allowed wrapper, so QUIC can ride inside UDP packets and evolve in software, updated as fast as an app updates. UDP here is a deliberate foundation, not a sign that anyone gave up on reliability.

Second, QUIC folds encryption in from the start. Recall that TCP by itself encrypts nothing; security comes from TLS layered on top, which costs extra round trips to set up — first the TCP handshake, then the TLS handshake. QUIC merges connection setup and TLS into a single handshake, so a fresh connection can often start sending data in one round trip, and a connection to a server you have spoken to recently can sometimes send data in the very first packet (called zero round-trip, or 0-RTT). Encryption is not an optional add-on in QUIC; it is mandatory and built in. That is why HTTP/3 is always encrypted in practice.

Following the journey end to end

It helps to see the three versions as answers to one steadily-deepening question. Each version solved the previous one's biggest pain, then exposed the next layer of the problem. Walk it once as a sequence and the whole arc clicks into place.

  1. HTTP/1.0: a new TCP connection (and handshake) for every file. Pain: an absurd number of handshakes per page.
  2. HTTP/1.1: reuse one persistent connection, but serve requests strictly in order. Pain: a slow response blocks everything queued behind it (head-of-line blocking at the HTTP level).
  3. HTTP/2: multiplex many streams over one connection by interleaving labelled frames, plus compress headers. Pain: it still rides one TCP stream, so a single lost packet stalls all streams (head-of-line blocking moved down into TCP).
  4. HTTP/3: run those same multiplexed streams over QUIC (on UDP), which is stream-aware, so a lost packet only stalls its own stream; and fold TLS into setup for fewer round trips. The blocking is finally gone at every layer.

Two honest caveats keep this from becoming a fairy tale. First, none of this beats physics: HTTP/3 cuts round trips and removes stalls, but it cannot make a signal travel faster than light, so a request to a distant server still costs real latency that no protocol version erases. More throughput and cleverer multiplexing do not shrink the underlying distance. Second, newer is not automatically faster for everyone — on a clean, low-loss network HTTP/2 and HTTP/3 perform similarly, and HTTP/3's advantage shows up most on lossy or high-latency links like mobile networks, exactly where TCP's in-order stalls hurt. Knowing when a tool wins is part of understanding it.