HTTP
The Hypertext Transfer Protocol of the web: clients and servers, URLs, the request and response messages (request line, header lines, blank line, body; status line and status codes), methods, the stateless protocol and cookies, conditional GET and caching, non-persistent and persistent connections with and without pipelining, and the response-time arithmetic for a page with embedded objects (2 RTT per object without persistence); the messages come from a real server, the connection counts from real clients, and the times from a closed formula checked against an event timeline.
Why it exists
The web is built on a simple request-response protocol: a client (the browser) asks a server for an object, and the server sends it. HTTP (HyperText Transfer Protocol) defines the messages. It is the standard example of an application layer protocol: it uses TCP through the socket API (socket API) after the server's name has been resolved by DNS (DNS).
Prerequisites
You need sockets and TCP connections (socket API) and the name lookup (DNS).
Precise definitions
A web page consists of a base HTML file and several referenced objects (images, style sheets, scripts). Each object is addressed by a URL (uniform resource locator) such as http://www.example.com/dir/index.html: protocol, host name (resolved by DNS), optional port (default for HTTP, for HTTPS) and path.
HTTP is a client-server, request-response, stateless protocol over TCP: the server keeps no information about earlier requests of a client. (State is added by cookies, below.)
Request message (text, lines end with carriage return and line feed):
GET /index.html HTTP/1.1
Host: www.example.com
Connection: keep-alive
The first line is the request line: a method, the path, the HTTP version. Then header lines (Host names the web site and is mandatory in HTTP/1.1; others describe the client and what it accepts), then an empty line, then an optional body (used by POST).
Methods (quoted): GET (fetch an object), POST (send data to the server, for example form contents), HEAD (like GET but the server returns only the headers), PUT (store an object), DELETE (remove it).
Response message: a status line (version, status code, reason phrase), header lines, an empty line and the body (the object).
| class | meaning | common examples |
|---|---|---|
| 1xx | informational | |
| 2xx | success | 200 OK |
| 3xx | redirection | 301 Moved Permanently (new URL in Location), 304 Not Modified |
| 4xx | client error | 400 Bad Request, 404 Not Found |
| 5xx | server error | 500 Internal Server Error, 505 HTTP Version Not Supported |
(The status codes are quoted; 200, 304 and 404 were produced by the test server.)
How it works
A real exchange
A real HTTP/1.1 request and response (loopback): start
Computed by a script, not typed| direction | line | meaning |
|---|---|---|
| request | ||
| request | ||
| request | ||
| request | ||
| response | ||
| response | ||
| response | ||
| response | ||
| response |
Step 0
Captured from a raw TCP socket talking to a real HTTP server on 127.0.0.1 (the Date and Server headers, which vary, are left out here).
The client sends the request line and two header lines and an empty line; the server replies with the status line HTTP/1.1 200 OK, headers (Content-Length tells the client where the body ends, Last-Modified supports caching), an empty line and bytes of body.
Cookies and conditional GET
Because HTTP is stateless, a server that wants to recognise a returning user sends a cookie in a Set-Cookie header of the response; the browser stores it and sends it back in a Cookie header with later requests to that site. A web cache (browser cache or proxy server) keeps copies of objects; to check whether its copy is still current it sends a conditional GET with If-Modified-Since: date. If the object has not changed the server answers 304 Not Modified with an empty body (the test server did exactly this), saving the transfer of the object.
Connections
In non-persistent HTTP (HTTP/1.0) every request/response uses a new TCP connection, closed by the server after the response. In persistent HTTP (HTTP/1.1 default) the connection stays open for further requests. With pipelining the client may send the next request before the previous response has arrived.
How many TCP connections do the requests use? (real server, counted): start
Computed by a script, not typed| client behaviour | requests | connections accepted by the server |
|---|---|---|
| 10 requests, one HTTP/1.1 connection (persistent) | ||
| 10 requests, Connection: close each time (non-persistent) | ||
| curl fetching 3 URLs | ||
| curl fetching 3 URLs with Connection: close |
Step 0
A real HTTP/1.1 server on the loopback interface counts the connections that it accepts while real clients (Python's http.client and curl) fetch objects.
A real server, real clients: ten requests on a persistent connection use one TCP connection, with Connection: close ten connections; curl uses one connection for three URLs of the same server unless told to close.
Response time
The time to fetch one object with a new connection is two round trips plus the transmission time: one RTT for the TCP handshake (the client sends the request together with the third segment), and one RTT for the request to reach the server and the first bits of the response to return, plus the time to transmit the object. With embedded objects, round-trip time RTT, transmission time of the base file and of each object (they share one bottleneck link):
| strategy | total time |
|---|---|
| non-persistent, one connection after the other | |
| non-persistent with parallel connections | |
| persistent, no pipelining | |
| persistent with pipelining |
Time to load a page with a base file and 10 objects: start
Computed by a script, not typed| HTTP version / strategy | total time | in round-trip times |
|---|---|---|
| non-persistent, one connection after the other | ||
| non-persistent, 5 parallel connections | ||
| persistent, requests one at a time | ||
| persistent with pipelining |
Step 0
RTT = 100 ms, transmission time of every file 10 ms on the shared bottleneck link, one-way delay = RTT/2; no DNS lookup, no TCP slow start, no processing. The totals were computed twice (closed formula and an event timeline).
For a page with the base file and objects, RTT ms, every transmission ms: ms (non-persistent), ms (five parallel connections), ms (persistent) and ms (pipelined). Parallel connections save round trips but not transmission time because the bottleneck is shared; pipelining sends the requests together and removes nearly all waiting.
Page load time against the number of embedded objects: start
Computed by a script, not typed| page | non-persistent | non-persistent, 5 parallel | persistent | pipelined |
|---|---|---|---|---|
| 0 embedded objects | ||||
| 1 embedded objects | ||||
| 5 embedded objects | ||||
| 10 embedded objects | ||||
| 50 embedded objects |
Step 0
Same parameters as the previous table. The advantage of persistent connections and pipelining grows with the number of objects.
With a single embedded object persistence saves one RTT; with objects the pipelined page needs ms against ms.
(Real browsers combine parallel connections with persistent ones, and newer versions of HTTP multiplex many requests on one connection; they are not in the syllabus line and are mentioned only as the direction of development.)
Worked examples
EX 1One object, new connection
EasyRTT ms, a file of kbit on a Mbps link ( ms): the time is ms after the DNS lookup. With a DNS lookup of ms: ms.
EX 2A page with objects
MediumBase file and images, RTT ms, ms for each file. Non-persistent: ms. Persistent without pipelining: ms. Pipelined: ms. Non-persistent with parallel connections: ms.
EX 3Counting TCP connections
MediumA page has a base file and images. Non-persistent, serial: connections. Non-persistent with parallel connections: still connections (opened in rounds). Persistent: connection. A browser that opens persistent connections: .
EX 4Typical questions
GATE level(a) "Is HTTP stateless?" Yes; cookies add state outside the protocol. (b) "Which transport protocol and default port?" TCP, . (c) "Which status code means the object was not changed?" . (d) "Which header makes a GET conditional?" If-Modified-Since. (e) "RTTs to fetch a base file with images using non-persistent HTTP without parallel connections?" RTT (plus transmission times). (f) "With persistent HTTP without pipelining?" RTT. (g) "With pipelining?" RTT. (h) "What is the difference between GET and HEAD?" HEAD returns only the headers.
Cheat box
Cheat box
- Request: method, path, version; headers; blank line; body. Response: version, status code, reason; headers; blank line; body.
- 200 OK, 301 moved, 304 not modified, 404 not found, 500 server error. TCP port ( for HTTPS).
- Stateless; cookies add state. Conditional GET with
If-Modified-Sincereturns . - Non-persistent: RTT per object; persistent: handshake once, RTT per object; pipelined: all requests together.
- Page with objects: RTT, RTT, RTT (plus transmission times).
Traps and GATE patterns
Connections
Builds on
Across subjects
No cross-subject links yet.
HTTP uses a TCP connection obtained through the socket API (socket API, TCP basics); the host name is resolved first (DNS). The response-time arithmetic is that of performance metrics.
PYQs
8 previous year questions from your book. I re-solved each one myself (2 by running or simulating, 6 by reasoning only); the book's key is shown next to my answer. All PYQs
Which of the following statements is/are true with respect to the interaction of a web browser with a web server using HTTP 1.1?
- (a)HTTP 1.1 facilitates downloading multiple objects of the same webpage over the same TCP connection, if the objects are stored in the same server
- (b)HTTP 1.1 facilitates downloading multiple objects of the same webpage over the same TCP connection, even if they are stored in different servers
- (c)HTTP 1.1 facilitates sending a request for downloading one object without waiting for a previously requested object to be downloaded completely
- (d)HTTP 1.1 facilitates downloading multiple webpages on the same server to be downloaded over a single TCP connection
A user starts browsing a webpage hosted at a remote server. The browser opens a single connection to fetch the entire webpage from the server. The webpage consists of a top-level index page with multiple embedded image objects. Assume that all caches (e.g., DNS cache, browser cache) are all initially empty. The following packets leave the user's computer in some order. (i) HTTP GET request for the index page. (ii) DNS request to resolve the web server's name to its IP address. (iii) HTTP GET request for an image object. (iv) TCP SYN to open a connection to the web server. Which one of the following is the CORRECT chronological order (earliest in time to latest) of the packets leaving the computer?
- (a)(iv), (ii), (iii), (i)
- (b)(iv), (ii), (i), (iii)
- (c)(ii), (iv), (i), (iii)
- (d)(ii), (iv), (iii), (i)
Suppose in a web browser, you click on the www . gate-2023 . in URL. The browser cache is empty. The IP address for this URL is not cached in your local host, so a DNS lookup is triggered (by the local DNS server deployed on your local host) over the 3- tier DNS hierarchy in an iterative mode. No resource records are cached anywhere across all DNS servers. Let RTT denote the round trip time between your local host and DNS servers in the DNS hierarchy. The round trip time between the local host and the web server hosting www.gate-2023.in is also equal to RTT. The HTML file associated with the URL is small enough to have negligible transmission time and negligible rendering time by your web browser, which references 10 equally small objects on the same web server. Which of the following statements is/are CORRECT about the minimum elapsed time between clicking on the URL and your browser fully rendering it?
- (a)7 RTTs, in case of non-persistent HTTP with 5 parallel TCP connections.
- (b)5 RTTs, in case of persistent HTTP with pipelining.
- (c)9 RTTs, in case of non-persistent HTTP with 5 parallel TCP connections.
- (d)6 RTTs, in case of persistent HTTP with pipelining. COMPUTER NETWORK
Assume that you have made a request for a web page through your web browser to a web server. Initially, the browser cache is empty. Further, the browser is configured to send HTTP requests in non-persistent mode. The web page contains text and five very small images. The minimum number of TCP connections required to display the web page completely in your browser is _________.
Which of the following is/are examples of stateful application layer protocols? (i) HTTP (ii) FTP (iii) TCP (iv) POP3
- (a)(i) and (ii) only
- (b)(ii) and (iii) only
- (c)(ii) and (iv) only
- (d)(iv) only
Identify the correct sequence in which the following packets are transmitted on the network by a host when a browser requests a webpage from a remote server, assuming that the host has just been restarted.
- (a)HTTP GET request, DNS query, TCP SYN
- (b)DNS query, HTTP GET request, TCP SYN
- (c)DNS query, TCP SYN, HTTP GET request
- (d)TCP SYN, DNS query, HTTP GET request
In one of the pairs of protocols given below, both the protocols can use multiple TCP connections between the same client and the server. Which one is that?
- (a)HTTP, FTP
- (b)HTTP, TELNET
- (c)FTP, SMTP
- (d)HTTP, SMTP
Consider the different activities related to email. ml : Send an email from mail client to mail server m 2 : Download an email from mailbox server to a mail client m3 ; Checking email in a web browser Which is the application level protocol used in each activity?
- (a)m1: HTTP m2: SMTP m3: POP
- (b)m1 : SMTP m2 : FTP m3 : HTTP
- (c)m1: SMTP m2: POP m3: HTTP
- (d)m1 : POP m2 : SMTP m 3 : IMAP
Self-check
Question 1
A page has a base file and images; non-persistent HTTP, serial. How many RTTs are spent on handshakes and requests?
Show answerHide
objects RTT RTT (plus transmission times).
Question 2
What is the response to a conditional GET if the object is unchanged?
Show answerHide
304 Not Modified with no body.
Question 3
Why can a server not tell that two requests come from the same user without cookies?
Show answerHide
HTTP is stateless: each request is independent, and the server keeps no information about earlier ones.
Revision card
One-screen revision
- Request: method, URL, version, headers; response: status code and body. Stateless; cookies.
- Non-persistent: RTT per object. Persistent: handshake. Pipelining: requests together.
- for conditional GET; not found; port over TCP.
References
- ·Kurose, Ross, Computer Networking: A Top-Down Approach (8th edition), Chapter 2, Sections 2.2 and 2.3 (The Web and HTTP)
- ·Tanenbaum, Wetherall, Computer Networks (5th edition), Chapter 7, Section 7.3 (The World Wide Web)
- ·Forouzan, Data Communications and Networking (5th edition), Chapter 22 (Application layer: HTTP)
Verification
scripts/enum-checks/cn_app_check.py against a REAL HTTP/1.1 server on 127.0.0.1 that counts the connections it accepts: 10 requests with http.client on one connection use 1 accepted connection; 10 requests with 'Connection: close' use 10; curl fetching 3 URLs uses 1, with 'Connection: close' 3; a raw socket request 'GET /index.html HTTP/1.1' with a Host header gets 'HTTP/1.1 200 OK' with Content-Length equal to the body and the connection stays open; an HTTP/1.0 request is answered and the connection is closed; a missing path gives '404 Not Found'; a request with If-Modified-Since for an unchanged object gives '304' and an empty body. The response times come from the closed formulas of scripts/cn_app.py (http_time) and equal, on 3000 random parameter sets, an event timeline with explicit one-way delays and a FIFO transmitter at the server (http_time_events); the ordering pipelined <= persistent <= non-persistent and 'parallel connections are never slower' held on all of them. MODEL: one shared bottleneck link, all objects of equal size, no DNS lookup, no TCP slow start, no server processing, transmission time of requests and handshake segments ignored, the browser knows the embedded objects after receiving the base file; real browsers open several connections at once and start the requests before the whole base file has arrived. The text of the 'statelessness', cookies, proxy / web cache behaviour, the list of methods and status codes, HTTP/2 and HTTP/3 are QUOTED from the RFCs and textbooks and are not tested here (only 200, 304 and 404 were observed). Textbook chapter references are from memory. SECOND PASS (2026-11-02, done by the assistant, not a human check): every Self-check question was solved before the printed answer was read and all agreed; the definitions, worked examples, cheat box and traps were read claim by claim and the numbers re-derived by hand or by a small script (CRC remainders, binomial tail, checksums); long C programs were not re-read line by line (they are compiled and compared by npm run verify:c, and their printed outputs were checked against the prose). No defect found. Status raised to self-checked; verified needs a textbook or human check.
last verified: never
My notes (saved in this browser)