Visual walkthrough — HTTP - 1.1 — methods, status codes, headers, persistent connections
Step 1 — What "one round-trip" even means
WHAT. Before any HTTP talk, we agree on the single unit we will count: the round-trip time, written . It is the time for a signal to travel from client to server and back.
WHY this unit and not seconds? Because on a network the thing that dominates delay is not how fast the wire is — it is how far apart the two machines are. Light in fibre is fixed, so every "ask something, wait for the answer" costs one full there-and-back. Counting RTTs makes the whole story machine-independent: it works the same on a fast desktop or a slow phone.
PICTURE. The client (left) sends a pulse; the server (right) sends one back. That whole loop is — our ruler for everything below.
Step 2 — The cost hidden before HTTP: the handshake
WHAT. TCP is the reliable pipe HTTP rides on. You cannot send an HTTP byte until TCP is connected, and connecting takes the TCP three-way handshake: SYN → SYN-ACK → ACK.
WHY it costs one RTT. Look at the arrows: the client's SYN goes right, the server's SYN-ACK comes back — that is already there-and-back = . The final ACK travels right with or just before your first real data, so we count the handshake as one RTT of pure setup before any web content moves.
PICTURE. The red block is dead time — you have paid a full RTT and received zero bytes of your web page yet. Remember its height; every new connection pays it again.
Step 3 — HTTP/1.0: pay the toll on every single file
WHAT. In HTTP/1.0 the pattern for each resource is: open a connection, do one request/response, close. Repeat for the next file.
WHY it hurts. A web page is not one file — it is HTML plus images/scripts/styles, so resources total. Each one repeats Step 2's red setup block and a request/response block. That is RTTs per resource stacked times.
PICTURE. Watch the staircase: setup (red), fetch, close — then the whole thing restarts. The red toll appears separate times. This visual repetition is the problem.
Step 4 — The idea: keep the pipe open
WHAT. HTTP/1.1's move is embarrassingly simple to draw: do the handshake once, then send request after request down the same open pipe without closing.
WHY it works. The setup toll (red) was the villain, and it was charged per connection. If we open one connection and never close it, we pay red exactly once and then every extra resource costs only its own request/response loop.
PICTURE. One red setup block at the very start, then a clean run of fetch blocks — no red restarts. Compare its short height to Step 3's tall staircase.
Step 5 — Read off the saving
WHAT. Subtract the two totals to get the payoff of persistence.
WHY subtract. The difference is the wasted time we deleted — the stack of red tolls we no longer pay.
PICTURE. The two bars side by side; the red gap between their tops is the saving.
Step 6 — The catch persistence forces: where does a body end?
WHAT. In HTTP/1.0 the client knew a response was finished because the server closed the socket — end-of-file was the end-of-body marker. In 1.1 we deliberately keep the socket open, so that marker is gone.
WHY this is a real bug, not a nitpick. If two responses arrive back-to-back on one open pipe and there is no length marker, the client cannot tell where reply #1 stops and reply #2 starts. It would glue them together or hang forever waiting for an EOF that never comes.
PICTURE. Two responses flowing down one pipe. Without a boundary the client sees one confusing
blob (top). With Content-Length it knows to read exactly bytes, then start fresh (bottom).
Step 7 — Edge cases: when the saving shrinks or vanishes
WHAT. We check the corners of the formula so no scenario surprises you.
WHY. A formula you cannot break at its extremes is a formula you do not yet trust.
PICTURE. Three columns: a single-file page, a huge page, and the pipelining trick — with a warning label on the last.
- (one resource): . Persistence buys you nothing when there is only one file — there is no second request to reuse the pipe for. Correct and unsurprising.
- large: saving , so persistence matters most on image-heavy pages and on high-latency links (mobile, satellite) — the same conclusion as the parent's Forecast-then-Verify.
- Pipelining (fire the next request before the previous reply lands): pushes the serial fetches down toward — but a slow first reply now blocks everyone queued behind it. This head-of-line blocking is the flaw that HTTP-2 multiplexing later fixes by letting independent streams pass each other.
- Slow start still applies: even on the reused pipe, TCP slow start means early requests ride a smaller congestion window; persistence keeps the grown window instead of resetting it each time — a second, quieter win our RTT-only model ignores.
Recall Why is
the degenerate case? Persistence saves the setup toll on every file after the first ::: with only one file there is nothing after the first, so saved.
The one-picture summary
The whole story in one frame: HTTP/1.0's tall red staircase (a setup toll per file) versus HTTP/1.1's single toll followed by clean fetches — the red gap between them being the we deleted, with the small print that each reply must now carry its own length.
Recall Feynman retelling — say it plainly
Every time two computers open a fresh connection, they waste one full there-and-back just saying hello (the handshake). Old HTTP said hello before every file, so a 30-image page said hello 30 times — 30 wasted round-trips. HTTP/1.1 says hello once and then keeps chatting down the same line, so it wastes only that first hello: it saves one round-trip per file after the first, which is of them. The only price for keeping the line open is that each reply must now say how long it is up front, because nobody hangs up to signal "I'm done" anymore.
Prev/parent: HTTP/1.1 topic note · Related: TCP three-way handshake · TCP slow start · HTTP-2 multiplexing · Caching, ETag and conditional GET