Hyper Text Transfer Protocol (HTTP)

Purpose

Cover HTTP as the web’s request-response protocol, what a page fetch actually involves, and where the time goes, since most of HTTP’s evolution has been about cutting page load time.

Core idea

A web page is a set of related HTTP transactions. Each transaction is a request and a response, carried over TCP, typically on port 80. Protocol semantics, methods, and status codes are specified in RFC 9110.

Fetching a web page

URLs name the resource to fetch:

protocol://host:port/path

1. Resolve the host to an IP address using DNS
2. Establish a TCP connection to the server
3. Send an HTTP request for the page
4. Await the HTTP response
5. Fetch embedded resources, execute scripts, and render the page
6. Close the TCP connection

sequenceDiagram
    participant B as Browser
    participant D as DNS resolver
    participant S as Web server

    B->>D: resolve host name
    D-->>B: IP address
    Note over B,S: TCP handshake, one RTT before any data
    B->>S: SYN
    S-->>B: SYN ACK
    B->>S: ACK, then HTTP GET /path
    S-->>B: HTTP response (page)
    Note over B: Parse page, fetch embedded resources, render

Static pages are pre-built and served as-is. Dynamic pages are built on the server per request, or shipped as code, usually JavaScript, that runs in the client.

Methods

Status codes

Performance

Page load time

Page load time (PLT) is the time from request to the full page being displayed in the browser. Small increases in PLT measurably hurt user satisfaction, which is why so much engineering goes into it. PLT depends on the page’s content, the network RTT and bandwidth, and how well HTTP and TCP are being used.

Why HTTP/1.0 was slow

HTTP/1.0 opened one TCP connection per request and issued requests sequentially. Every resource paid a fresh connection setup, and fetches to the same server could not overlap, so RTTs stacked up linearly with resource count.

Cutting PLT

• Shrink the content, by minifying and compressing
• Use TCP more efficiently, which is what HTTP/2 does with multiplexing
• Cut round trips, with DNS prefetching, caching, and proxies
• Move content closer to the client, with CDNs and edge caching

Browsers first attacked this by opening several parallel HTTP connections to fetch resources. That backfires under load, since the parallel connections amplify network bursts and loss. The alternative is one TCP connection to the server with multiple HTTP requests multiplexed over it. That raises the question of how long to keep the connection open, and for some access patterns it is actually slower than parallel connections.

Where this leads

Multiplexing over one connection is exactly the HTTP/2 design, and the head-of-line blocking it exposes at the TCP layer is what QUIC and HTTP/3 fix. That evolution is covered in QUIC, HTTP/2, and HTTP/3.

Caching and proxies

Users revisit pages, so a lot of fetches can be answered without hitting the server. The standard strategies:

• The Expires header gives a date after which the resource is stale
• Heuristic expiration treats resources as fresh when they are cacheable, currently valid, and were not modified recently
• Revalidation asks the server whether the cached copy is still valid, and a 304 means yes without resending the body

A proxy caches on behalf of a pool of clients. The client sends its request to the proxy, and the proxy checks whether it holds a fresh copy. If it does, it serves the copy directly. Otherwise it fetches from the server, updates its cache using response metadata like Not-Modified, and returns the resource to the client.

Putting an intermediary between clients and servers also helps with load balancing, security, and privacy, and it moves cached data physically closer to clients. The benefits are capped by secure and dynamic content, which cannot be shared or stored, and by the long tail of resources that are rarely requested twice. CDNs push the same caching idea out to global scale, see content delivery networks.

Related notes

• DNS
• content delivery networks
• application layer overview
• TCP