Open a restaurant on Tiffin and the app fires off a burst of requests: the menu JSON, the restaurant banner, about 40 dish photos, the cart, the delivery estimate. How quickly all of that arrives depends heavily on which version of HTTP carries it.
HTTP has had three major wire formats since 1997. Each version keeps the same meaning (methods, URLs, headers, status codes) but changes how requests are packed onto the network. Every change was driven by one problem: getting many requests through without one slow request holding up the rest.
Quick recap. HTTP is the request and response language between the Tiffin app and its servers (see Module 2, "Designing the API"). It runs on top of a transport: TCP for HTTP/1.1 and HTTP/2, QUIC for HTTP/3. The previous lesson covered round trips, TCP's handshake and head-of-line blocking. You'll need all three here.
HTTP/1.1: one at a time
HTTP/1.1 has been around since 1997. It's plain text, which makes it easy to read. Here's a real exchange, as curl -v shows it:
$ curl -v --http1.1 https://api.tiffin.app/restaurants/77/menu
> GET /restaurants/77/menu HTTP/1.1
> Host: api.tiffin.app
> User-Agent: curl/8.7.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 18342
< Cache-Control: max-age=60
<
{"restaurant_id":77,"dishes":[ ...
Lines starting with > are what curl sent. Lines starting with < came back. (The --http1.1 flag forces the old version; without it, curl would negotiate HTTP/2 with most servers.)
The key rule of HTTP/1.1: one connection carries one request at a time. The client sends a request, waits for the whole response, then sends the next. Connections can be reused (keep-alive), which avoids a new handshake each time. But they can't overlap.
There was a feature called pipelining that let a client send several requests without waiting. The responses still had to come back in order, so one slow response blocked the rest, and buggy proxies broke it. Browsers turned it off.