HTTP (HyperText Transfer Protocol) HyperText Transfer Protocol The application-layer protocol that requests and transfers Web documents. introduced in ch. 1 is a simple, stateless, plain-text protocol, and almost all of the time it takes to load a page is spent waiting for round trips rather than moving bytes.
Words you will meet
- Web page — a document made of several files that a browser shows as one page.
- Object — one file, with its own web address.
- URL — Uniform Resource Locator: which server has a file, and where on that server.
- Stateless protocol — one whose server remembers nothing about earlier requests.
- Non-persistent connection — a new TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 connection per object, closed straight after.
- Persistent connection — one connection kept open and reused.
- RTT — round-trip time: how long a small packet takes to go there and back.
- Pipelining — sending the next request without waiting for the previous answer.
Why this matters
HTTP (HyperText Transfer Protocol) HyperText Transfer Protocol The application-layer protocol that requests and transfers Web documents. introduced in ch. 1 is the protocol you will meet most often, and it is deliberately the first one this book studies in detail, because it is straightforward and easy to understand.
But the real content of this section is a piece of engineering that recurs everywhere: the cost of setting up a connection. Section 2.2.6 rebuilds HTTP around it. Chapter 3 explains where the handshake comes from. Section 3.8 introduces QUIC (Quick UDP Internet Connections) Quick UDP Internet Connections A transport-like protocol built in the application layer over UDP, carrying HTTP/3. The IETF now treats QUIC as a name rather than an abbreviation. introduced in ch. 2 , a protocol whose main selling point is making that cost smaller still.
What HTTP is
Until the early 1990s the Internet was used mainly by researchers and students, to log in to remote hosts, transfer files, and send news and e-mail. Then the World Wide Web arrived. It was the first Internet application that caught the general public’s eye. It turned the Internet from one of many data networks into essentially the one and only data network.
What appeals most is that the Web operates on demand. Users receive what they want, when they want it — unlike broadcast radio and television, which force users to tune in when the content provider chooses.
Pages, objects and URLs
Some vocabulary first, because the rest of the section depends on it.
A web page web page Simple A document made of several files that a browser fetches and shows as one page. Precise Also called a document. It consists of objects. Most Web pages consist of a base HTML file and several referenced objects; the base HTML file references the other objects by their URLs. introduced in ch. 2 — open in glossary , also called a document, consists of objects object Simple One file — an image, a script, a style sheet — that has its own web address. Precise A file that is addressable by a single URL. It may be an HTML file, a JPEG image, a JavaScript file, a CSS style sheet file or a video clip. A page with HTML text and five images has six objects. introduced in ch. 2 — open in glossary . An object is simply a file — an HTML (HyperText Markup Language) HyperText Markup Language The document format of the Web, created by Tim Berners-Lee at CERN between 1989 and 1991. introduced in ch. 1 file, a JPEG (Joint Photographic Experts Group) Joint Photographic Experts Group The image format used in the book’s ten-image Web page example. introduced in ch. 2 image, a JavaScript file, a CSS (Cascading Style Sheets) Cascading Style Sheets A style sheet file is one of the objects a Web page is built from. introduced in ch. 2 style sheet, a video clip.
What makes a file an object is that it is addressable by a single URL (Uniform Resource Locator) Uniform Resource Locator The address of a single Web object: hostname plus path name. introduced in ch. 2 uniform resource locator Simple A web address: which server holds the file, and where on that server it sits. Precise A URL, the address of a Web object, with two components: the hostname of the server that houses the object and the object’s path name. In http://www.someSchool.edu/someDepartment/picture.gif the hostname is www.someSchool.edu and the path name is /someDepartment/picture.gif. introduced in ch. 2 — open in glossary .
Count the base file
If a web page contains HTML text and five JPEG images, the page has six objects: the base HTML file plus the five images. The base HTML file references the others by their URLs.
Getting this count right matters, because every calculation in this section multiplies by it.
Each URL has two components: the hostname hostname Simple The readable name of a host, such as www.example.edu. Precise A mnemonic identifier for a host, made of variable-length alphanumeric characters. Hostnames are appreciated by humans but give little information about where the host sits in the Internet, and their variable length makes them difficult for routers to process. This is why hosts are also identified by IP addresses. introduced in ch. 2 — open in glossary of the server that houses the object, and the object’s path name.
Because web browsers browser Simple The program on your device that fetches web pages and draws them on the screen. Precise A program that implements the client side of HTTP. In the context of the Web the words browser and client are used interchangeably. HTTP has nothing to do with how a browser chooses to display a page. introduced in ch. 2 — open in glossary implement the client side of HTTP, in the context of the Web the words browser and client are used interchangeably. Web servers web server Simple The program that stores web objects and sends them when they are asked for. Precise A program that implements the server side of HTTP and houses Web objects, each addressable by a URL. Popular Web servers include Apache and Microsoft Internet Information Server. introduced in ch. 2 — open in glossary implement the server side and house the objects. Popular ones include Apache and Microsoft Internet Information Server.
Request and response
HTTP is implemented in two programs, a client and a server, executing on different end systems and talking by exchanging HTTP messages. HTTP defines the structure of those messages and how the two sides exchange them.
HTTP uses TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 as its underlying transport protocol, not UDP (User Datagram Protocol) User Datagram Protocol A simple transport protocol with no reliability, no flow control and no congestion control. introduced in ch. 1 . The client first initiates a TCP connection. Once it is established, the browser and server processes reach TCP through their sockets. The client sends request messages into its socket and receives responses from it; the server does the mirror image.
In plain words — why layering earns its keep here
Once the client pushes a message into its socket, the message is out of the client’s hands and in the hands of TCP. And section 2.1.4 told you TCP provides reliable data transfer.
So every HTTP request eventually arrives intact at the server, and every response arrives intact at the client. HTTP need not worry about lost data, or about how TCP recovers from loss or reordering. That is the job of TCP and the layers below it.
This is a great advantage of a layered architecture, and it is worth noticing how much shorter it makes the HTTP specification.
HTTP is stateless
The server sends requested files to clients without storing any state information about the client. If a client asks for the same object twice within a few seconds, the server does not say that it just served that object. It resends the object, having completely forgotten what it did earlier.
Because an HTTP server maintains no information about its clients, HTTP is called a stateless protocol stateless protocol Simple A protocol whose server remembers nothing about earlier requests. Precise A protocol whose server maintains no information about its clients. An HTTP server sends requested files without storing any state about the client. If a client asks for the same object twice within a few seconds, the server simply resends it, having completely forgotten what it did earlier. This simplicity is what lets Web servers handle thousands of simultaneous connections. introduced in ch. 2 — open in glossary .
That sounds like a weakness. It is a deliberate strength: it is what has allowed engineers to develop high-performance web servers that handle thousands of simultaneous TCP connections. Section 2.2.4 shows how cookies put state back on top when an application genuinely needs it.
Which version
Each version of the protocol is defined by its own RFC (Request For Comments) Request For Comments The name of an IETF standards document. There are currently nearly 9000 of them. introduced in ch. 1 .
| Version | RFC | Status |
|---|---|---|
| HTTP/1.0 | RFC (Request For Comments) Request For Comments The name of an IETF standards document. There are currently nearly 9000 of them. introduced in ch. 1 1945 | The original, from the early 1990s. Uses non-persistent connections. |
| HTTP/1.1 | RFC 7230 | As of 2020, the majority of HTTP transactions. Persistent connections with pipelining by default. |
| HTTP/2 | RFC 7540 | Increasingly supported by browsers and servers. Section 2.2.6 covers it. |
What a connection costs
In many Internet applications the client and server communicate for an extended period, with the client making a series of requests. The developer faces a decision: should each request/response pair go over a separate TCP connection, or should all of them share one?
The first is a non-persistent connection non-persistent connection Simple One new TCP connection for each object, closed as soon as that object has been sent. Precise A connection arrangement in which each request/response pair is sent over a separate TCP connection, which does not persist for other objects. HTTP/1.0 employs non-persistent connections. Each object then costs two round-trip times: one to set the connection up and one to request and receive the object. introduced in ch. 2 — open in glossary ; the second is a persistent connection persistent connection Simple One TCP connection kept open and reused for all the objects of a page. Precise A connection arrangement in which all of the requests and their corresponding responses are sent over the same TCP connection. The server leaves the connection open after sending a response, and typically closes it after a configurable timeout interval. Multiple Web pages on the same server can share one connection. This is HTTP/1.1’s default mode. introduced in ch. 2 — open in glossary . HTTP can use either. It uses persistent connections in its default mode, but clients and servers can be configured otherwise.
Non-persistent, step by step
Suppose a page consists of a base HTML file and 10 JPEG images, all on the same
server, and the base file’s URL is
http://www.someSchool.edu/someDepartment/home.index. Here is what happens:
- The HTTP client process initiates a TCP connection to
www.someSchool.eduon port 80, the default port for HTTP. A socket is created at the client and one at the server. - The client sends an HTTP request message via its socket, including the path
name
/someDepartment/home.index. - The server process receives the request and retrieves the object from its storage — its memory or its disk. It puts the object in an HTTP response message and sends it via its socket.
- The server tells TCP to close the connection. TCP does not actually terminate until it knows the client received the response intact.
- The client receives the response and the connection terminates. The message says the object is an HTML file. The client extracts it, examines it, and finds references to the 10 JPEG objects.
- Steps 1–4 repeat for each of those 10 objects.
Each non-persistent connection transports exactly one request message and one response message. So when a user requests this page, 11 TCP connections are generated.
What HTTP does not decide
As the browser receives the page, it displays it. Two different browsers may display the same page somewhat differently. HTTP has nothing to do with how a page is interpreted. The specifications define only the communication between the client program and the server program.
The back-of-the-envelope calculation
How long does one object take? Define the round-trip time round-trip time Simple How long a small packet takes to travel to the other side and back. Precise The RTT: the time it takes for a small packet to travel from client to server and then back to the client. It includes packet-propagation delays, packet-queuing delays in intermediate routers and switches, and packet-processing delays. introduced in ch. 2 — open in glossary ( RTT (Round-Trip Time) Round-Trip Time How long a small packet takes to travel to the other side and back. The unit almost every §2.2 result is counted in. introduced in ch. 2 ): the time for a small packet to travel from client to server and back. It includes propagation delays, queuing delays in intermediate routers and switches, and processing delays — all of them from section 1.4.
Click any arrow to see what that message says and why it is sent.
Click any arrow to see what it carries. Two round trips pass before a single byte of the file moves.
Read this diagram as text
- Lin’s laptop sends SYN — initiate TCP connection to www.example.edu. Part 1 of the three-way handshake. A small TCP segment carrying no application data at all. The browser has not yet said what it wants.
- www.example.edu sends SYN, ACK to Lin’s laptop. Part 2. The server agrees. These first two parts together take exactly one RTT — the first of the two the book counts.
- Lin’s laptop sends ACK + GET /index.html to www.example.edu. Part 3 of the handshake and the HTTP request travel together. This is why the total is two RTTs and not two and a half: the acknowledgement was going to be sent anyway, so the request rides along for free.
- www.example.edu sends HTTP/1.1 200 OK + index.html to Lin’s laptop. The second RTT completes as the response arrives. Only now do the file’s bits start to move. Pushing 100 kB into a 100 Mbps link takes a further 8.00 ms — small next to a 180 ms round trip, which is the whole point of this section.
Lifelines, left to right: Lin’s laptop (host), www.example.edu (server).
Opening the connection involves a three-way handshake. The client sends a small TCP segment; the server acknowledges and responds with a small segment; the client acknowledges back. The first two parts take one RTT.
Then something neat happens. After the first two parts, the client sends the HTTP request message combined with the third part of the handshake — the acknowledgement it was going to send anyway. Once the request arrives, the server sends the file. That request/response consumes another RTT.
The book’s result
Thus, roughly, the total response time is two RTTs plus the transmission time at the server of the HTML file.
Persistent connections
Non-persistent connections have two shortcomings.
First, a brand-new connection must be established and maintained for each requested object. For each connection, TCP buffers must be allocated and TCP variables kept in both the client and the server. That is a significant burden on a web server serving hundreds of clients at once.
Second, each object suffers a delivery delay of two RTTs — one to establish the connection, one to request and receive.
With HTTP/1.1 persistent connections the server leaves the connection open after sending a response. Subsequent requests and responses between the same client and server travel over the same connection. An entire web page can be sent over one connection, and so can several pages from the same server. Typically the server closes a connection when it has not been used for a configurable timeout interval.
Requests can also be made back-to-back, without waiting for replies to pending requests. That is pipelining pipelining Simple Sending the next request without waiting for the previous answer to come back. Precise Sending the next unit without waiting for the reply to the previous one. At the application layer (§2.2.2) a browser makes requests for objects back-to-back over a persistent connection and the server sends the objects back-to-back; this is the default mode of HTTP/1.1. At the transport layer (§3.4.2) a sender transmits several packets before any acknowledgement returns, so that packets fill the link the way liquid fills a pipe. It is one idea at two layers, not two ideas. introduced in ch. 2 — open in glossary , and it is part of HTTP/1.1’s default mode.
Click any arrow to see what that message says and why it is sent.
The base file, then the first of three referenced objects. Watch the pattern repeat: open, ask, receive, close. Two more objects follow, identically.
Read this diagram as text
- Lin’s laptop sends SYN to www.example.edu. Connection 1 of 4 opens.
- www.example.edu sends SYN, ACK to Lin’s laptop.
- Lin’s laptop sends ACK + GET /index.html to www.example.edu.
- www.example.edu sends index.html (100 kB) to Lin’s laptop. The base file arrives after 2 RTT = 360 ms. The server now closes the connection. Everything just spent is spent again for the next object.
- Lin’s laptop sends SYN to www.example.edu. Connection 2 of 4. A brand-new connection must be established and maintained for each requested object. TCP buffers are allocated and TCP variables kept, at both ends, all over again.
- www.example.edu sends SYN, ACK to Lin’s laptop.
- Lin’s laptop sends ACK + GET /style.css to www.example.edu.
- www.example.edu sends style.css (12 kB) to Lin’s laptop. A 12 kB file takes 0.96 ms to transmit. It cost 360 ms to fetch. The file itself is almost free; the waiting is everything.
Lifelines, left to right: Lin’s laptop (host), www.example.edu (server).
Click any arrow to see what that message says and why it is sent.
The same four objects. The three requests go back-to-back without waiting, and the three objects come back the same way.
Read this diagram as text
- Lin’s laptop sends SYN to www.example.edu.
- www.example.edu sends SYN, ACK to Lin’s laptop.
- Lin’s laptop sends ACK + GET /index.html to www.example.edu.
- www.example.edu sends index.html (100 kB) to Lin’s laptop. Two RTTs, exactly as before. Nothing is saved on the base file — it is the *only* object whose URL the browser knew in advance.
- Lin’s laptop sends GET /style.css to www.example.edu. The browser has now read the HTML and knows the other three URLs. It sends all three requests back-to-back, without waiting for any reply. That is pipelining.
- Lin’s laptop sends GET /logo.png to www.example.edu.
- Lin’s laptop sends GET /app.js to www.example.edu.
- www.example.edu sends style.css (12 kB) to Lin’s laptop. The server received the back-to-back requests, so it sends the objects back-to-back.
- www.example.edu sends logo.png (40 kB) to Lin’s laptop.
- www.example.edu sends app.js (220 kB) to Lin’s laptop. All four objects are in, after 3 RTT plus 29.76 ms of transmission — 569.76 ms against 1,469.76 ms for the non-persistent case. The connection stays open in case more is wanted.
Lifelines, left to right: Lin’s laptop (host), www.example.edu (server).
Pipelining costs three round trips, not two
It is tempting to say that with one connection and pipelining the whole page costs 2 RTT. It does not, and the reason is worth holding on to.
The browser cannot ask for the referenced objects until it has read the base HTML file, because that file is where their URLs are written. So:
- 1 RTT to open the connection;
- 1 RTT to request and receive the base file — the book’s two-RTT result;
- 1 RTT for all the remaining objects together, pipelined.
Three round trips for a four-object page. Also three for a forty-object page. The object count has dropped out of the round-trip term entirely, and that is the gain.
A page with only one object is the exception: there is nothing to pipeline, so it
costs the book’s 2 RTT exactly. Try objects = 1 in the calculator below.
Put numbers on it
What each symbol means
- n — objects in the page, counting the base HTML file (—)
- L — total size of the page (bytes)
- R — link rate of the bottleneck link (bits/s)
- RTT — round-trip time to the server (s)
- p — parallel connections the browser opens (—)
Read aloud: Every object fetched over its own connection costs two round trips; keeping one connection open and asking for everything at once costs three round trips in total, no matter how many objects there are.
Non-persistent, one at a time1.47 s
each object costs 2 RTT: one to open the connection, one to ask and receive 4 objects x 2 x 180 ms = 1.44 s transmission = 2,976,000 bits / 100 Mbps = 29.8 ms total = 1.44 s + 29.8 ms = 1.47 s
Persistent, no pipelining930 ms
the connection is opened once: 180 ms then one RTT per object, because each request waits for the last reply 4 x 180 ms = 720 ms transmission = 29.8 ms total = 180 ms + 720 ms + 29.8 ms = 930 ms
Non-persistent, parallel750 ms
the base file must arrive first — the browser cannot know the other URLs until it does base file: 2 x 180 ms = 360 ms remaining 3 objects, 3 at a time = ceil(3 / 3) = 1 round(s) 1 x 2 x 180 ms = 360 ms transmission = 29.8 ms (unchanged — the same bits cross the same link) total = 720 ms + 29.8 ms = 750 ms
Persistent + pipelining (HTTP/1.1 default)570 ms
one RTT to open the connection: 180 ms one RTT to request and receive the base file: 180 ms only now does the browser know the other 3 URLs one more RTT for all 3 of them: the requests go back-to-back, without waiting for replies, and the objects come back back-to-back transmission = 29.8 ms total = 3 x 180 ms + 29.8 ms = 570 ms the object count has dropped out of the RTT term — 3 objects or 300, still 3 RTT
Change any number above and the arithmetic re-runs, carrying the units through.
The defaults are the running example: Lin’s 372 kB page over a 100 Mbps access link, 180 ms to Frankfurt. Drag RTT down to 20 ms and watch the four answers collapse together — the round trips are the whole story only while the link is fast and the server is far away.
Worked example — Lin’s page from Bangkok
Lin’s laptop loads www.example.edu: a 372 kB page in four objects, over a
100 Mbps access link, 180 ms round-trip to Frankfurt.
Transmission time for the whole page is 2,976,000 bits ÷ 100 Mbps = 29.76 ms. Every strategy below moves exactly those bits over exactly that link, so that 29.76 ms is common to all of them. Everything else is waiting.
| Strategy | Round trips | Total |
|---|---|---|
| Non-persistent, one object at a time | 8 | 1,469.8 ms |
| Persistent, no pipelining | 5 | 929.8 ms |
| Non-persistent, 3 in parallel | 4 | 749.8 ms |
| Persistent + pipelining | 3 | 569.8 ms |
The page loads 2.58× faster, and not one byte of it changed. The time was never in the file; it was in the waiting.
Notice also that the transmission time is 2 % of the fastest total. Doubling Lin’s link rate to 200 Mbps would save 14.88 ms out of 569.76 — under 3 %. Removing one round trip saves 180 ms. This is why the rest of §2.2 is about round trips and not about link rates.
| Non-persistentHTTP/1.0 | PersistentHTTP/1.1 default | |
|---|---|---|
| Connections for an n-object page | ||
| Round trips (n = 4) | ||
| Burden on the server | ||
| Pipelining possible? | ||
| When does the connection close? | ||
| What browsers do about it |
Cells marked ⓘ have a reason behind them — click to read it.
Click any ⓘ for the reasoning behind the cell.
Parallel connections
The six steps above were deliberately vague about one thing: whether the client fetches the 10 JPEGs over 10 serial connections, or some of them in parallel. Users can configure some browsers to control the degree of parallelism. Browsers may open multiple TCP connections and request different parts of the page over each.
As chapter 3 will show, parallel connections shorten the response time — the calculator above lets you watch that happen. Section 2.2.6 returns to the practice and shows that browsers have a second, less innocent motive for it.
Check yourself
Check yourself
0 of 6 answered1.A web page contains HTML text and five JPEG images. How many objects is that, and how many TCP connections does HTTP/1.0 use to fetch it?
2.Why does one object over a non-persistent connection cost two RTTs rather than one?
Count what happens before any HTML is asked for.
3.predictIn the calculator, set the page to 4 objects and RTT to 180 ms. Persistent-with-pipelining costs 3 RTT. Why not 2, since the connection is opened only once?
What does the browser know at the moment the connection opens?
4.Which change makes the largest difference to how long Lin's four-object page takes: opening the same number of connections in parallel, or keeping one connection open and pipelining on it?
5.An HTTP server has just sent you an object. Ten seconds later you ask for exactly the same object. What does the server do?
6.Browsers may open several parallel TCP connections to one server. Given that the section shows this speeds a page up, why is it also a problem?
Recall what section 2.1.4 said congestion control is for.
What to remember
- A web page is made of objects, each addressed by a URL of two parts: hostname and path name. The base HTML file is an object too — count it.
- HTTP is stateless: the server keeps no information about clients. That is what lets one server hold thousands of connections.
- Non-persistent HTTP costs 2 RTT per object. Persistent with pipelining costs 3 RTT for the whole page, whatever the object count. For a page over a long path, almost all the time is round trips, not bytes.