HTTP: the request-response language of the web

What HTTP does in one sentence

Have you ever wondered why loading a page sometimes feels fast on one network and sluggish on another, even on the same site? Often, the culprit is which HTTP version is running underneath. HTTP (HyperText Transfer Protocol) is the request-response language browsers and servers use to exchange web pages, APIs, images — everything you see in a browser. The client asks, the server answers. That’s it. But how they ask and answer is where the versions diverge.

The restaurant metaphor

Think of HTTP as a waiter taking orders at a restaurant.

HTTP/1.1: One waiter per table, one order at a time per waiter — you wait for each plate before ordering the next. To go faster, the restaurant hires six waiters per customer (six parallel connections). It works, but it’s wasteful.

HTTP/2: One waiter takes ten orders at once and brings dishes back in whatever order the kitchen finishes them. One connection, many requests in flight simultaneously.

HTTP/3: Same as /2, but a delayed dish in the kitchen no longer makes other dishes wait — they come out independently. Built on a different transport (QUIC over UDP) that isolates delays per request.

One scenario end to end

You navigate to a site. The browser does DNS, TCP, TLS, then sends the first HTTP request. The page’s HTML names dozens more files; the browser fires those requests using whatever HTTP version the server agreed to during ALPN (Application Layer Protocol Negotiation — a TLS extension that lets the client and server pick h2, h3, or http/1.1 during the handshake). Modern sites get HTTP/2 or HTTP/3; old origins still see HTTP/1.1.

Bea · Browser the browser to Sven · Origin server the server: “GET /index.html.” Sven replies with the HTML. Bea sees <script src="app.js"> inside and immediately says: “GET /app.js.” In HTTP/1.1, Bea waits for each file to finish on the same connection before asking for the next. In HTTP/2 and /3, Bea fires all the GETs at once and Sven streams them back interleaved.

The core antagonist: head-of-line blocking

Head-of-line (HOL) blocking is the pattern where a slow item at the front of a queue stalls everything behind it. HTTP/1.1 has HOL blocking at the request level — each connection can carry only one in-flight request-response at a time. HTTP/2 fixed HOL blocking at the HTTP layer by multiplexing streams, but TCP underneath still has HOL blocking at the transport layer. HTTP/3 fixed HOL at both layers by using QUIC, which has stream-level loss recovery.