learninfra · Linux · Networking · Kubernetes · System Design · AI Infrastructure · Exam blueprints · Drills

HTTP/1.1 vs 2 vs 3

One page is many requests. Three versions of HTTP, three answers to where those requests queue and what one lost packet costs.

An interactive Networking lesson: 22 steps, about 32 minutes, on a live simulation in your browser.

Ada opens https://shop.example/. Her laptop connects to web, sets up TCP and then TLS (each has its own lesson), and sends one request: GET /. Back comes 1256 bytes of HTML.

That HTML is only a list of what the page needs: a stylesheet app.css, a script app.js, a logo logo.svg. Nothing can be drawn properly until those arrive too. One address typed, four requests to make, and real pages need fifty to a hundred.

What you will learn

  1. HTTP/1.1: one at a time

    • One page is many requests: A page is one HTML file plus everything it references, so page speed is decided by how fast many small requests can be made.
    • Three more files, one connection: An HTTP/1.1 connection is a single-lane road: one request, its entire response, then the next.
    • A small file stuck behind a big one: Head-of-line blocking: the item at the front of a queue delays everything behind it, however small or urgent.
    • The workaround: more connections: HTTP/1.1 gets parallelism by opening up to six connections per host, and pays a full handshake and a cold start for each one.
    • Keep-alive: the first fix: Keep-alive leaves the connection open after a response, so the next request skips the TCP and TLS handshakes.

  2. HTTP/2: one connection, many streams

    • HTTP/2: every request gets a number: HTTP/2 is one connection carrying many numbered streams; frames from different streams are interleaved, so no request waits for another.
    • Binary frames, compressed headers
    • Break it: lose one segment
    • The queue moved down a layer: HTTP/2 moved head-of-line blocking from HTTP down into TCP: one lost segment stalls every stream on the connection.

  3. HTTP/3: QUIC

    • QUIC: a new transport under HTTP: QUIC does TCP's job and TLS's job in one protocol over UDP, so a new connection costs one round trip where TCP plus TLS cost two.
    • Streams, this time in the transport
    • Break it: the same loss over QUIC: In QUIC each stream is ordered on its own, so a lost packet delays only the stream whose data it carried.
    • Inside a QUIC packet
    • A connection that survives a new address: A TCP connection is its four-tuple of addresses and ports. A QUIC connection is an ID inside the packet, so it can outlive a change of address.

  4. Finding HTTP/3, and falling back

    • How a client finds out about HTTP/3: A client learns about HTTP/3 from an Alt-Svc header on a TCP-based response, remembers it, and only then tries UDP.
    • Break it: UDP 443 is blocked: HTTP/3 is always optional: if UDP 443 does not get through, clients fall back to HTTP/2 or 1.1 over TCP, and servers must keep serving both.

  5. Choosing and checking

    • When each version wins: HTTP/1.1 for single requests, HTTP/2 for many requests on a clean network, HTTP/3 when packets get lost, addresses change or connections are short-lived.
    • Reading curl -v, three times
    • Drill: force a version
    • Drill: which version did I get?

  6. Recap & playground

    • Cheat sheet
    • Playground