HTTP Request Lifecycle: Mermaid Sequence Diagram

About Source

The HTTP request lifecycle is the complete sequence of network operations that occur from the moment a client initiates a request to a URL — including DNS resolution, transport connection, optional TLS negotiation, the HTTP exchange itself, and connection teardown or reuse.

Most developers think of HTTP as a simple request/response pair, but understanding the full lifecycle reveals hidden latency sources and optimization opportunities.

Phase 1 — DNS Resolution: Before any connection is opened, the hostname must be resolved to an IP address. This involves checking browser cache, OS cache, recursive resolver, and potentially the full DNS hierarchy. See How DNS Works for details. This phase typically adds 0–100ms on a cold lookup.

Phase 2 — TCP Handshake: A TCP connection is established via the TCP Three-Way Handshake (SYN → SYN-ACK → ACK). This adds one round-trip time (RTT) of latency — typically 10–100ms depending on geography.

Phase 3 — TLS Negotiation: For HTTPS, TLS adds 1–2 more RTTs for certificate exchange, cipher negotiation, and key derivation. TLS 1.3 reduces this to 1 RTT. See TLS Handshake for the full exchange.

Phase 4 — HTTP Request/Response: The client sends the HTTP request (method, headers, optional body). The server processes it and returns a status code, headers, and body. For APIs, this is the REST call you think of; see REST API Request Lifecycle.

Phase 5 — Connection Reuse: HTTP/1.1 keep-alive, HTTP/2 multiplexing, and HTTP/3's QUIC streams all allow reusing the underlying connection for subsequent requests, amortizing the setup cost. HTTP/2 Multiplexing shows how multiple requests share a single connection.

Understanding each phase helps developers target the right optimization: CDN for DNS/TLS proximity, connection pooling to avoid repeated handshakes, and HTTP/2 push to eliminate sequential request waterfalls.

Frequently asked questions

The HTTP request lifecycle is the complete sequence of network operations from the moment a client initiates a request to a URL until the response is fully received. It encompasses DNS resolution, TCP connection establishment, optional TLS negotiation, the HTTP exchange itself, and connection teardown or reuse — not just the application-layer request/response pair.

Phase 1 is DNS resolution (0–100ms on a cold lookup). Phase 2 is the TCP three-way handshake (1 RTT, typically 10–100ms). Phase 3 is TLS negotiation for HTTPS (1–2 additional RTTs; TLS 1.3 adds 1 RTT). Phase 4 is the HTTP request and response (server processing + 1 RTT for small responses). Phase 5 is connection reuse, which amortises setup costs across multiple requests.

HTTP/1.1 keep-alive, HTTP/2 multiplexing, and HTTP/3 QUIC streams all allow subsequent requests to skip the TCP and TLS handshake phases by reusing an existing connection. This is particularly valuable for pages loading many resources — without reuse, each resource would incur 2–3 RTTs of setup overhead before transferring any data.

The HTTP request lifecycle describes the end-to-end phases for a single request, including transport setup. HTTP/2 multiplexing describes how multiple concurrent requests share a single established connection using stream IDs, eliminating the need for multiple TCP connections and reducing per-request overhead after the initial connection is open.

CDNs reduce latency in three ways: they terminate TLS and TCP connections at edge nodes close to the user (reducing RTT for phases 2 and 3), they serve cached content directly from the edge (eliminating the round trip to the origin), and they use anycast DNS to resolve to the geographically nearest PoP (reducing phase 1 latency).

mermaid

sequenceDiagram
    participant Client
    participant DNSResolver as DNS Resolver
    participant Server

    Client->&gt;DNSResolver: Resolve hostname (e.g. api.example.com)
    DNSResolver-->&gt;Client: IP address: 203.0.113.10

    note">Note over Client,Server: TCP Three-Way Handshake
    Client->&gt;Server: SYN
    Server-->&gt;Client: SYN-ACK
    Client->&gt;Server: ACK

    note">Note over Client,Server: TLS Handshake (HTTPS only)
    Client->&gt;Server: ClientHello (TLS)
    Server-->&gt;Client: ServerHello + Certificate
    Client->&gt;Server: Key exchange + Finished
    Server-->&gt;Client: Finished

    note">Note over Client,Server: HTTP Exchange
    Client->&gt;Server: GET /api/data HTTP/1.1\nHost: api.example.com\nAccept: application/json
    Server-->&gt;Client: HTTP/1.1 200 OK\nContent-Type: application/json\n{"data": "response_value"}

    note">Note over Client,Server: Connection Reuse (Keep-Alive)
    Client->&gt;Server: GET /api/other HTTP/1.1
    Server-->&gt;Client: HTTP/1.1 200 OK