HTTP and the Web

HTTP defines a request-response model: a client opens a connection to a server, sends a request message, and the server sends back a response message. Each request names a method (the action requested), a target (usually a path and query string), a version, a set of header fields (metadata as key-value pairs), and an optional message body. Each response mirrors this structure with a status code in place of a method — a three-digit number plus a short reason phrase indicating how the request was handled. Critically, HTTP is stateless: by design, the server retains no memory of previous requests from the same client. Each request must be self-contained, carrying whatever context it needs. This simplicity is what let HTTP scale to billions of clients — servers need not track per-client session objects at the protocol level. But real applications do need state (shopping carts, login sessions), so the ecosystem layers state on top using cookies: small pieces of data the server asks the client to store and resend on every future request to that domain. A second core idea is resource identification. Every HTTP request targets a URI (Uniform Resource Identifier), typically a URL like `https://example.com/products/42?ref=email`. The scheme (`https`) tells the client to use TLS; the authority (`example.com`) is resolved via DNS to an IP address; the path and query identify a specific resource on that server. HTTP methods express what to do with that resource — retrieve it (`GET`), create or update it (`POST`, `PUT`), remove it (`DELETE`) — following a design philosophy sometimes called REST, where URIs name resources and methods name verbs applied to them.

Step 1 — Connection establishment. The client resolves the hostname via DNS, then opens a TCP connection (usually port 443 for HTTPS, 80 for plain HTTP), performing a TCP three-way handshake and, for HTTPS, a TLS handshake on top.

Step 2 — Request construction. The client builds a request message with a start line, headers, a blank line, and an optional body: ``` GET /products/42?ref=email HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Accept: text/html Cookie: session=abc123 Connection: keep-alive ```

Step 3 — Transmission. The request is sent over the (possibly encrypted) TCP stream.

Step 4 — Server processing. The server parses the request line and headers, locates or computes the requested resource, and decides on a status code.

Step 5 — Response construction. The server builds a response: ``` HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Length: 4210 Cache-Control: max-age=3600 Set-Cookie: session=abc123; HttpOnly; Secure Connection: keep-alive ... ```

Step 6 — Connection reuse or close. If `Connection: keep-alive` (the default in HTTP/1.1) is negotiated, the same TCP connection remains open for subsequent requests to the same server, avoiding a new handshake per resource. Otherwise the connection closes after the response.

Step 7 — Client rendering / follow-up requests. The client parses the response; if it's HTML, it discovers embedded resources (images, CSS, scripts) and issues further requests, often over the same persistent connection or over additional parallel connections. Below is a simplified pseudocode model of a client's request lifecycle, including cache and cookie handling: ```pseudocode function fetch(url, method="GET", body=None): scheme, host, path, query = parse_url(url) // 1. Check local cache first cached = cache_lookup(host, path, query) if cached is not None and not cached.is_stale(): return cached.response // cache hit, no network trip // 2. Reuse or open a connection conn = connection_pool.get(host, scheme) if conn is None or conn.closed: conn = open_tcp_connection(host, port_for(scheme)) if scheme == "https": conn = tls_handshake(conn, host) connection_pool.put(host, conn) // 3. Build request headers = default_headers(host) cookie_value = cookie_jar.get(host, path) if cookie_value is not None: headers["Cookie"] = cookie_value if cached is not None: // conditional revalidation if cached.etag is not None: headers["If-None-Match"] = cached.etag if cached.last_modified is not None: headers["If-Modified-Since"] = cached.last_modified request = build_request(method, path, query, headers, body) // 4. Send and receive send(conn, request) response = receive_response(conn) // 5. Handle 304 Not Modified if response.status == 304: cached.refresh_validity(response.headers) return cached.response // 6. Update cookie jar if "Set-Cookie" in response.headers: cookie_jar.store(host, response.headers["Set-Cookie"]) // 7. Update cache if is_cacheable(method, response): cache_store(host, path, query, response) // 8. Close connection if server requested it if response.headers.get("Connection") == "close": conn.close() connection_pool.remove(host, conn) return response ```

Latency cost model. Let RTT be the round-trip time between client and server. Establishing a fresh TCP connection costs 1 RTT (handshake), and TLS 1.3 adds roughly 1 RTT (or 0 with session resumption / 0-RTT). Each HTTP request-response pair costs at least 1 RTT for the data exchange itself. Without persistent connections, fetching n resources from the same server costs approximately:

because each resource requires its own connection setup. With persistent connections, the handshake cost is paid once:

(assuming requests are pipelined or sent back-to-back rather than each waiting fully for the previous response — a limitation that HTTP/1.1 partially addresses and that HTTP/2 and HTTP/3 solve more thoroughly with multiplexing). This is why persistent connections were one of the most impactful additions from HTTP/1.0 to HTTP/1.1: the savings scale linearly with the number of subresources on a page, and a typical page has dozens.

Caching correctness. A cache is correct if it never serves a response that the origin server would disavow as stale, subject to the freshness rules the server itself specified. The key invariant: > A cached response may be served without contacting the origin only if its age is within the freshness window the server declared (via `Cache-Control: max-age` or an `Expires` date), or the client has revalidated it (via a conditional request) and received confirmation (`304 Not Modified`) that it is unchanged. This invariant is maintained by construction in the pseudocode above: `is_stale()` checks the freshness window, and revalidation always attaches `If-None-Match` / `If-Modified-Since` before trusting a cached body past its freshness window. The server, not the cache, is the source of truth for what "unchanged" means, so correctness reduces to the server computing `ETag`/`Last-Modified` faithfully — a comparison of resource identity, which is a simple equality check server-side, not a client-side heuristic.

Statelessness and cookies. Because HTTP itself carries no session state, correctness of "logged-in" behavior depends entirely on the cookie mechanism functioning as an out-of-band key-value store keyed by domain and path, per the same-origin rules. The protocol's statelessness is not a limitation to work around silently — it is an explicit design tradeoff: simplicity and horizontal scalability of servers (any server behind a load balancer can handle any request, since no server-local session state is required) in exchange for applications needing an explicit state layer (cookies plus server-side session stores or JWTs).

Complexity of request routing. Server-side URL routing (mapping a path to a handler) is typically implemented as a trie or hash-map lookup over registered route patterns, giving average-case $O(L)$ dispatch time where $L$ is the path length — independent of the number of registered routes if a trie is used, versus $O(R)$ for naive linear pattern matching over $R$ routes.

Honest tradeoffs.

• Persistent connections reduce handshake overhead but consume server memory/file descriptors per open connection — a scalability tension addressed by connection timeouts and, later, multiplexed protocols.
• Aggressive caching improves latency but risks serving stale content; `Cache-Control: no-cache` forces revalidation at the cost of an extra round trip even when content hasn't changed.
• Cookies restore statefulness but introduce privacy and security surface area (session hijacking, cross-site tracking), which is why `HttpOnly`, `Secure`, and `SameSite` attributes exist as mitigations.

Trace a browser loading `http://www.example.org/index.html`, which references one image, with a plain (non-persistent) HTTP/1.0-style interaction versus an HTTP/1.1 persistent-connection interaction. Assume RTT = 50 ms, and DNS is already resolved.

Step	HTTP/1.0 (new connection per object)	HTTP/1.1 (persistent connection)
1	TCP handshake to fetch `index.html`: 50 ms	TCP handshake (once): 50 ms
2	GET `/index.html` request/response: 50 ms	GET `/index.html` request/response: 50 ms
3	Parse HTML, discover ``	Parse HTML, discover ``
4	New TCP handshake for image: 50 ms	(connection already open — no handshake)
5	GET `/logo.png` request/response: 50 ms	GET `/logo.png` request/response over same connection: 50 ms
Total	200 ms	150 ms

With just one extra object the saving is 50 ms (25%); with 20 subresources (typical of a media-rich page), HTTP/1.0-style behavior would cost roughly `50 + 20×(50+50) = 2050` ms versus `50 + 20×50 = 1050` ms for persistent connections — nearly a 2× improvement, purely from eliminating repeated handshakes, before any consideration of parallelism. Now trace a caching scenario for the same image on a repeat visit, assuming the first response included: ``` Cache-Control: max-age=86400 ETag: "d41d8cd98f00b204" ```

This demonstrates the core caching tradeoff precisely: within the freshness window, caching eliminates the network round trip entirely; outside it, revalidation still saves bandwidth (no body transferred) even though it cannot save the round trip itself.

HTTP emerged from a very specific, concrete need: physicists at CERN wanted to share documents across incompatible computer systems without manually converting formats. Tim Berners-Lee's proposal combined three simple ideas — URLs to name resources, HTML to structure documents, and HTTP to transfer them — into what became the World Wide Web.

Every browser, mobile app backend, and REST API depends on the request-response semantics described here. Content Delivery Networks like Cloudflare and Akamai exist largely to exploit HTTP caching semantics at scale, placing edge servers close to users so that `Cache-Control` and `ETag` validation happen with minimal latency — a mechanism explored further in Content Delivery Networks. Web application frameworks (Django, Express, Spring) are fundamentally HTTP request routers layered with session/cookie management. Browsers' developer tools (the Network tab) expose exactly the request/response headers and status codes described here, and debugging a "why is my page slow" or "why is stale data showing" problem almost always comes down to reasoning about persistent connections, caching headers, or cookie scope. The security properties layered on top — via TLS and Secure Channels — protect the confidentiality and integrity of every request and response, including the cookies that carry session identity. And the performance limitations of HTTP/1.1's connection model (head-of-line blocking, one request "in flight" per stream) directly motivated the multiplexed, binary framing of HTTP/2 and HTTP/3. Even email retrieval protocols like those covered in Email Protocols: SMTP, IMAP, POP3 share the same request-response philosophy, though tuned for message delivery rather than document retrieval.

Ask the tutor: How does HTTP/2's multiplexing change the request-response model described here, and why does HTTP/3 need a new transport protocol to fully solve head-of-line blocking?