Client-Server Basics — HTTP, DNS, and How a Request Travels

Client-Server Basics — HTTP, DNS, and How a Request Travels

You've typed a URL into a browser thousands of times. Almost nobody can actually trace what happens in the ~100-300ms between hitting Enter and seeing a page — and you can't reason about caching, CDNs, or load balancing later in this path without understanding that path first.

Step 1: DNS Resolution

The browser needs an IP address for api.example.com. It first checks its own cache, then the OS cache, then queries a configured DNS resolver (often your ISP's, or a public one like 1.1.1.1). If that resolver doesn't have it cached, it walks the DNS hierarchy: a root server points it to the .com TLD server, which points it to example.com's authoritative nameserver, which finally returns the IP. A cold lookup can take 20-120ms; a cached one is near-instant. This is why DNS TTLs matter — too long and you can't fail over quickly, too short and every client re-resolves constantly.

Step 2: TCP Handshake

With an IP in hand, the client opens a TCP connection: SYN, SYN-ACK, ACK — one round trip before a single byte of your actual request is sent. On a connection with 50ms latency each way, that's already 50ms spent just establishing the pipe.

Step 3: TLS Handshake (for HTTPS, which is nearly everything now)

Another round trip (or two, depending on TLS version) to negotiate encryption: the server presents its certificate, the client validates it against a trusted certificate authority, and both sides derive a shared session key. TLS 1.3 collapsed this to effectively one round trip versus TLS 1.2's two — a meaningful latency win at scale, which is part of why TLS 1.3 adoption mattered.

Step 4: The Actual HTTP Request/Response

Only now does the browser send GET /api/user HTTP/1.1 with headers, and the server processes it and responds. With HTTP/1.1 keep-alive, that same TCP connection is reused for subsequent requests, avoiding steps 2-3 again. HTTP/2 goes further and multiplexes many requests over one connection in parallel, which is why moving from HTTP/1.1 to HTTP/2 was a real, measurable performance win for pages with many assets.

Why This Matters for System Design

Every one of these steps is a lever. CDNs (covered later in this path) reduce effective RTT by serving from a location physically closer to the user. Connection reuse and HTTP/2 reduce the number of handshakes paid per page load. DNS TTL tuning trades off failover speed against resolution overhead. None of these optimizations make sense until you can see where the time is actually going.