The connection behaviour and the caching rules on this page are stated against RFC 9112 (HTTP/1.1 message syntax and connection management) and RFC 9111 (HTTP caching). The round-trip arithmetic is worked from first principles and every step is shown.
Read the vocabulary, then work the timing example with a pen before reading step 3. The arithmetic is the part people think they understand until they have to write it down. Solutions are at the bottom; do not open them early.
Persistent connections are the default in HTTP/1.1, so a Connection: keep-alive header is not what turns them on — it is a leftover from HTTP/1.0, where the default was the opposite. Course material often presents the header as the switch. This page follows the RFC: in HTTP/1.1 the connection stays open unless a message says Connection: close. Both answers describe the same capture; only one describes the standard.
The cost of opening a connection#
HTTP runs over TCP, and TCP connections are not free. Before a single byte of your request can be sent, the two ends exchange a handshake. That takes time, and the unit that time is measured in is the round-trip time.
RTT is the time for a small packet to travel from client to server and back again. It is a property of the path — distance, and the queuing and processing delay at every hop — and it does not depend on how big the object you are fetching is.
That last clause is the one to hold on to. Transmission time depends on file size and link rate. RTT does not. Every timing question in this topic is built on keeping those two separate.
Vocabulary, before anything uses it#
| Term | What it means |
|---|---|
| RTT | Round-trip time: how long a small packet takes to go from client to server and back. |
| Transmission time | How long it takes to push all the bits of a file onto the link, which is file size divided by link rate. |
| Non-persistent HTTP | A mode in which at most one object is sent per TCP connection, and the connection then closes. |
| Persistent HTTP | A mode in which the server leaves the connection open so several objects can travel over it. |
| Parallel connections | Several TCP connections opened at once to the same server so objects can be fetched simultaneously. |
| Pipelining | Sending the next request without waiting for the previous response to arrive. |
| Web cache | A machine that stores copies of objects and serves them without contacting the origin server; also called a proxy server. |
| Origin server | The server that actually holds the authoritative copy of an object. |
| Conditional GET | A GET that carries a condition, so the server sends the object only if the condition holds. |
| If-Modified-Since | The request header carrying the date of the copy the client already has. |
| 304 Not Modified | The response saying the copy is still current, sent with headers only and no body. |
| Access link | The link joining an institution’s network to the wider Internet, and usually the bottleneck. |
| Stale | Describing a cached copy that has passed its expiry and should be revalidated before reuse. |
Non-persistent HTTP, step by step#
The client wants a page. In non-persistent mode, this happens:
- The client opens a TCP connection to the server on port 80, and the server accepts it.
- The client sends an HTTP request for the base HTML file into that connection.
- The server receives it, forms a response containing the object, and sends it.
- The server closes the connection.
- The client receives the HTML, parses it, and finds references to ten images.
- Steps 1 to 4 happen again. Ten more times.
Now count the round trips for one object. One RTT is spent on the TCP handshake before any HTTP is sent. A second RTT covers sending the request and getting the first bytes of the response back. Then the file itself has to be transmitted.
Non-persistent response time per object = 2 × RTT + transmission time
For a page with a base file and ten images, that is eleven objects, and in the simplest sequential case 22 round trips before transmission time is counted at all.
Two RTTs, not one. The first is the connection handshake; the second is the request and the start of the response. Answering “one RTT plus transmission” is the standard error, and it comes from forgetting that TCP had to be set up before HTTP could say anything at all.
Persistent HTTP, and what it saves#
Non-persistent mode has two costs, and only one of them is the round trips. Each connection also costs the operating system memory and bookkeeping at both ends, and a busy server pays that eleven times for one page.
Persistent HTTP fixes both. The server leaves the connection open after sending a response. Subsequent requests and responses between the same client and server travel over the connection that is already there, so there is no second handshake. The client can send a request for a referenced object as soon as it sees the reference, without waiting.
Persistent HTTP: as little as one RTT for all the referenced objects
| Non-persistent | Persistent | |
|---|---|---|
| Objects per TCP connection | At most one | Many |
| Connection after a response | Closed | Left open |
| RTTs per object | 2 | Effectively 1, shared |
| OS overhead | Paid per object | Paid once |
| Default in HTTP/1.1 | No | Yes |
Browsers also open several TCP connections in parallel to fetch referenced objects at the same time. That is a separate trick from persistence and the two are often confused: parallel connections reduce wall-clock time by overlapping fetches, but each connection still pays its own handshake. Persistence removes handshakes. A browser typically does both.
Persistent is not parallel. Persistent means reusing one connection for several objects. Parallel means having several connections at once. A question asking “how does persistence reduce response time?” wants the removed handshakes, not the overlapping.
Web caches, and why an institution wants one#
A web cache, or proxy server, sits between the clients and the Internet. The browser is configured to send all its HTTP requests to the cache instead of straight out. If the cache holds the object, it returns it immediately. If not, it opens its own connection to the origin server, fetches the object, keeps a copy, and returns it.
A cache is both a server and a client. It is a server to the browser that asked it, and a client to the origin server it asks. That dual role is the thing to say out loud in an answer.
Two reasons an ISP, company or university installs one:
- Response time falls, because a hit is served from a machine on the local network instead of from across the Internet.
- Traffic on the access link falls, which is usually the real motivation. The access link is the bottleneck, and every cache hit is traffic that never crosses it — which is far cheaper than buying a faster link.
There is a third effect worth naming: caches spread throughout the Internet let a content provider with modest infrastructure serve a large audience effectively, because most requests never reach them.
The conditional GET#
A cache has a problem. Its copy might be out of date, and it has no way to know without asking. Fetching the whole object again to check would throw away the point of caching.
The conditional GET solves it. The cache sends an ordinary GET with one extra header carrying the date of the copy it holds:
GET /image.gif HTTP/1.1
Host: www.example.edu
If-Modified-Since: Tue, 01 Sep 2026 09:14:33 GMT
The server compares that date against the object and answers one of two ways:
| Situation | Response | Body included? |
|---|---|---|
| Object unchanged since that date | HTTP/1.1 304 Not Modified | No |
| Object changed since that date | HTTP/1.1 200 OK | Yes, the new object |
304 = your copy is still good, and I am not resending it
The saving is real: a 304 is a few hundred bytes of headers instead of however large the object is. The cache still pays a round trip to ask, but not the transmission time.
304 is not an error. It is in the 3xx class and it means success in the sense that matters: the client already has what it needs. Reading it as a failure because it is not 200 is a common misreading of a capture.
Last-Modified is a response header; If-Modified-Since is a request header. They carry the same kind of value and travel in opposite directions. The cache learns the date from Last-Modified on the way in, and quotes it back in If-Modified-Since on the way out.
Worked example#
A web page consists of a base HTML file and 8 small images. The RTT between client and server is 100 ms, and every object is small enough that transmission time can be ignored. How long does the page take with non-persistent HTTP fetched one object at a time, and how long with persistent HTTP?
Step 1 — Count the objects, not the images. The base file is an object too. 1 + 8 = 9 objects. Losing the base file here is the most common arithmetic slip in this topic.
Step 2 — Price one object in the non-persistent case. One RTT for the TCP handshake, one RTT for the request and the first bytes of the response, transmission ignored.
2 × 100 ms = 200 ms per object
Step 3 — Multiply, then do the persistent case separately. Nine objects sequentially is 9 × 200 ms. For persistent, the handshake is paid once for the whole page, and the base file still needs its own request-and-response round trip before the browser even knows the images exist.
Non-persistent: 9 × 200 = 1800 ms
Persistent: 1 RTT handshake + 1 RTT for the HTML + 1 RTT for the 8 images = 300 ms
Step 4 — Say what you assumed. The persistent figure assumes the browser requests all eight images back to back without waiting for each response, and that transmission time is negligible. State those; a marker cannot tell a justified answer from a lucky one otherwise.
The object count including the base file, the per-object cost written as 2 RTT with both RTTs named, the arithmetic shown rather than just the total, and the assumptions stated.
Practice#
Do the arithmetic on paper. Writing “2 RTT” is not the same as being able to say what each of the two is for.
- Define RTT in one sentence, and say what it does not depend on.
- Why is non-persistent HTTP 2 RTT per object rather than 1? Name each round trip.
- A page has a base file and 5 objects. RTT is 50 ms, transmission negligible. Give the non-persistent sequential total.
- Same page, persistent HTTP with the requests sent back to back. Give the total and say what you assumed.
- Name the two costs of non-persistent HTTP — one is round trips, what is the other?
- A cache is described as acting as both a client and a server. Explain both halves.
- Which is usually the stronger reason an institution installs a web cache, and why?
- A cache holds a copy from 1 September. Write the header it adds to check whether the copy is current, and give both responses it might get back.
- A capture shows a 304 with no body. Did something go wrong? What did the client gain?
Solutions#
Find the first line where your working diverged from the solution and redo the problem from there. On the arithmetic questions, check the object count first — it is where most wrong totals begin.
- Time out and back for a small packet. RTT is the time for a small packet to travel from client to server and back. It does not depend on the size of the object being fetched — that is transmission time, which is a separate term.
- Handshake, then request and response. The first RTT is the TCP connection handshake, which must complete before any HTTP is sent. The second covers sending the HTTP request and receiving the first bytes of the response. Transmission time is added on top.
- 600 ms. 6 objects in total — the base file plus 5. Each costs 2 × 50 = 100 ms. 6 × 100 = 600 ms.
- 200 ms. One RTT for the handshake, one for the HTML file, and one for all five objects requested back to back: 3 × 50 = 150 ms. Assumptions: transmission time negligible, and the browser issues the five requests without waiting for each response. If it waits for each one, it is 1 + 1 + 5 = 7 RTT = 350 ms — state which you assumed and either is defensible.
- Round trips and per-connection OS overhead. Two RTTs per object, and the operating-system overhead of establishing and maintaining a separate TCP connection for every object, paid at both ends.
- Server to the browser, client to the origin. It is a server to the browser that sent it the request, receiving requests and returning objects. It is a client to the origin server, opening its own connection and issuing its own requests when it does not hold the object.
- Reducing traffic on the access link. Reducing traffic on the institution’s access link. Response time improves too, but the access link is usually the bottleneck, and cutting the load on it is far cheaper than upgrading it.
- If-Modified-Since, answered by 304 or 200. It adds
If-Modified-Since:with the date of the copy it holds. If the object has not changed since then, the server replies304 Not Modifiedwith headers and no body. If it has changed, the server replies200 OKand includes the new object. - Nothing went wrong. Nothing went wrong. 304 means the copy the client already has is still current, so the server deliberately omitted the body. The client saved the transmission time of the whole object and paid only a round trip and a few hundred bytes of headers.
Test-readiness checklist#
- ☐ I can define RTT and say what it is independent of.
- ☐ I can derive 2 RTT + transmission time rather than reciting it, naming what each RTT buys.
- ☐ I can compute a page response time for both modes and remember to count the base HTML file.
- ☐ I can state the assumptions behind a persistent-mode figure.
- ☐ I can name both costs of non-persistent HTTP, not just the round trips.
- ☐ I can tell persistence apart from parallel connections.
- ☐ I can explain why a cache is simultaneously a client and a server.
- ☐ I can write a conditional GET header and name both possible replies.
- ☐ I can read a 304 in a capture and say what it saved.
Show the arithmetic. On timing questions the number alone earns very little, because the marker cannot tell whether you counted the base file, whether you knew what each RTT was for, or whether you guessed. Two extra lines of working are the cheapest marks in this topic.
Frequently asked questions#
Why does non-persistent HTTP take 2 RTT per object?
One round trip sets up the TCP connection, and it must complete before any HTTP message can be sent. A second round trip carries the HTTP request out and brings the first bytes of the response back. Transmission time for the object is then added on top of those two.
What does persistent HTTP actually save?
The repeated TCP handshakes and the per-connection operating-system overhead. The server leaves the connection open, so later requests and responses reuse it. With requests issued back to back, all the referenced objects on a page can cost as little as a single round trip.
Is persistent HTTP the same as opening parallel connections?
No. Persistence means reusing one connection for several objects, which removes handshakes. Parallel connections means opening several at once, which overlaps fetches but still pays a handshake on each. Browsers commonly do both.
What is a conditional GET and what does it save?
A GET carrying an If-Modified-Since header with the date of the copy the client or cache already holds. If the object has not changed the server replies 304 Not Modified with no body, so the transmission time of the whole object is saved and only a round trip and a few hundred bytes of headers are spent.
Why do institutions install web caches?
Mainly to cut traffic on the access link that joins them to the Internet, which is usually the bottleneck and is expensive to upgrade. Faster responses for users are a real benefit as well, but the link savings are normally what pays for the cache.
Something here not clear? A topic you wish we covered? Tell us. We read every message, and a request is the fastest way to get a guide written.
Test yourself in the free Kestrel Exams app
Topic-selectable practice — offline, no ads, no account. A networking question bank is not built yet; every other subject is open.
Choose your subject →