Chapter 13: Full Walkthrough: What Happens When You Type a URL and Press Enter

Why this matters

Chapter 1 opened with a deliberately incomplete six-step sketch of this exact question. Every chapter since has filled in one piece of that sketch in depth. This chapter reassembles all of it into the complete, correct sequence — the single most common "tie it all together" question in networking interviews, and a genuinely useful mental model for real debugging.

The complete sequence

You type https://www.example.com and press Enter.

Step 1 — URL parsing. The browser parses the URL: scheme (https), host (www.example.com), path (/, implied). The scheme tells the browser this needs TLS (Chapter 7) and defaults to port 443.

Step 2 — Check local caches. The browser checks its own DNS cache and HTTP cache first. If a valid, non-expired cached response exists for this exact request, the browser might be able to skip everything below entirely (Chapter 8's caching discussion). Assume a cold cache for the rest of this walkthrough.

Step 3 — DNS resolution (Chapter 5). The browser needs an IP address for www.example.com. It queries a recursive resolver, which — if nothing is cached anywhere along the chain — walks the full hierarchy: root server → .com TLD server → example.com's authoritative server → the actual IP address, returned and cached at every level per its TTL.

Step 4 — TCP connection (Chapters 3, 4, 9). With an IP address in hand, the browser initiates a TCP connection to that IP on port 443: the three-way handshake (SYN, SYN-ACK, ACK). This is a real round-trip cost, and the connection begins in TCP's "slow start" phase (Chapter 9) — it won't reach full throughput immediately.

Step 5 — TLS handshake (Chapter 7). Once TCP is established, the TLS handshake begins: the server presents its certificate, the browser verifies the chain of trust back to a trusted root CA, and both sides establish a shared symmetric session key. (If this is HTTP/3/QUIC instead, per Chapter 6, this step and Step 4 are combined into QUIC's own integrated handshake, over UDP instead of TCP — with automatic fallback to TCP-based HTTP/2 if QUIC doesn't work, per Chapter 12's middlebox discussion.)

Step 6 — Possible intermediary hops (Chapter 8). The actual TCP/TLS connection may terminate not at the origin server directly, but at a CDN edge server (if the site uses one) or a load balancer — which may itself be terminating TLS and then forwarding the request onward (potentially over a separate, internal connection to the actual origin, with X-Forwarded-For added so the origin knows the real client IP).

Step 7 — The HTTP request is sent (Chapter 6). Over the now-established, encrypted connection, the browser sends an HTTP request: GET / HTTP/2 (or whichever version was negotiated), with headers (Host, User-Agent, Accept, cookies, etc.).

Step 8 — The server processes the request and responds. The receiving server (or the CDN, if it has a valid cached response — Chapter 8) generates a response: a status code, headers, and a body (the page's HTML). If the CDN/load balancer is involved, the response travels back through the same intermediary chain to the browser.

Step 9 — The browser parses the response and repeats this entire process for every additional resource. The HTML response likely references additional resources — CSS, JavaScript, images — each of which may require its own DNS resolution (often already cached, or handled by the same connection via HTTP/2 multiplexing, Chapter 6, if from the same host), and potentially its own new TCP/TLS connections (if from a different host, like a CDN-hosted asset or a third-party analytics script).

Step 10 — The connection is kept alive (or closed). Rather than closing the TCP connection after one request, HTTP's keep-alive behavior (and HTTP/2's multiplexing) typically keeps it open for reuse by subsequent requests to the same host — avoiding paying the Step 4 and Step 5 costs again for every single resource on the page.

The full sequence, as one diagram

Browser
  |
  | (1) parse URL: scheme=https, host=www.example.com
  | (2) check local DNS + HTTP caches -- assume MISS for this walkthrough
  v
DNS Resolution (Ch. 5): recursive resolver -> root -> .com TLD -> authoritative -> IP
  v
TCP Handshake (Ch. 3, 4, 9): SYN / SYN-ACK / ACK -- connection established, slow start begins
  v
TLS Handshake (Ch. 7): certificate presented, chain of trust verified, session key established
  v
[Possible CDN / Load Balancer hop (Ch. 8): TLS may terminate HERE, request forwarded onward]
  v
HTTP Request sent (Ch. 6): GET / HTTP/2, with headers
  v
Server (or CDN cache) generates/returns a Response
  v
Browser parses HTML -> discovers more resources (CSS/JS/images)
  v
REPEATS steps above per additional host, REUSES existing connections for the same host
  v
Page fully rendered

Common mistakes

1. Treating this as a purely linear, one-shot sequence rather than recognizing that a real page load repeats large parts of it (DNS, TCP, TLS) for every distinct host referenced by the page's resources, while reusing connections where possible for resources on the same host.
2. Forgetting the local cache-check steps (DNS cache, HTTP cache) at the very beginning — a "warm" browser might skip most of this sequence entirely for a recently-visited site, which is worth mentioning explicitly as it demonstrates awareness of caching's real-world impact.
3. Not mentioning HTTP/3's combined QUIC handshake as an alternative to the separate TCP+TLS steps, when relevant — a strong answer notes that the exact steps 4-5 differ depending on which protocol version is actually negotiated.
4. Skipping the CDN/load balancer intermediary step entirely, describing a direct browser-to-origin connection as if every website works that way — most real, large-scale websites involve at least one intermediary hop.

Discussion / interview questions

1. "Walk me through everything that happens, at the network level, from typing a URL to seeing a rendered page." Strong answer: Produces the ten-step sequence above (or a reasonably complete subset) in the correct order, explicitly naming DNS resolution, TCP handshake, TLS handshake, possible CDN/load balancer involvement, the HTTP request/response itself, and the repetition of this process for additional page resources.

2. "Where in this sequence would you look first if the page loads, but very slowly?" Strong answer: Systematically checks each stage's latency (DNS resolution time, TCP+TLS handshake time, time-to-first-byte for the HTTP response, and time spent loading additional resources) — typically using curl -v's or browser dev tools' timing breakdown — rather than guessing which stage is slow.

3. "How does this walkthrough change if the site uses HTTP/3 instead of HTTP/2?" Strong answer: Steps 4 (TCP handshake) and 5 (TLS handshake) combine into QUIC's own integrated handshake over UDP, with the browser falling back to TCP-based HTTP/2 automatically if the QUIC connection attempt fails (Chapter 12's middlebox compatibility discussion) — showing the sequence isn't rigid across every protocol combination.

4. "Why does loading a second page from the same site tend to be much faster than the first?" Strong answer: DNS is likely still cached (Chapter 5's TTL), the TCP connection may already be established and past slow start's ramp-up (Chapter 9), TLS session resumption may avoid a full handshake, and browser HTTP caching may serve some resources without a network request at all — several independent caching/reuse mechanisms compounding together.

Chapter summary / cheat sheet

• The full sequence: parse URL → check local caches → DNS resolution (Chapter 5) → TCP handshake (Chapters 3, 4, 9) → TLS handshake (Chapter 7) → possible CDN/load balancer hop (Chapter 8) → HTTP request/response (Chapter 6) → parse and repeat for additional resources → connection reuse where possible.
• HTTP/3 combines the TCP and TLS handshake steps into one integrated QUIC handshake, with automatic fallback if it doesn't succeed.
• A real page load repeats large parts of this sequence per distinct host referenced, while reusing connections for resources on the same host — it's not purely linear or one-shot.
• This walkthrough is a practical debugging checklist as much as an interview answer: when a page is slow, breaking it into these exact stages (via curl -v or browser dev tools timing) localizes the actual bottleneck precisely.

---