Capstone: What Happens When You Visit https://example.com

Start at the altitude where every step is a noun the interviewer recognises and the chain is complete: the browser parses the URL; DNS turns the name into an IP; the OS routes toward that IP; TCP opens a connection; TLS secures it and proves the server’s identity; HTTP asks for the page; the server produces a response; the response comes back and the browser renders it. Say it in one breath, then stop and let them choose where to zoom. The stopping is the skill: a candidate who dives into TCP window scaling before finishing the story has shown they cannot summarise.

The "open a website" journey renders this same chain with four zoom levels, and the interactive here lets you expand any rung into its sub-steps and inject a failure at each — the way an interviewer will.

When the interviewer says "go deeper", the second ladder adds the layers the first one skipped: the socket API and the kernel between browser and network, the link layer between IP and the router, and the return trip. Now each rung has a mechanism to name: socket()/connect() and the descriptor; the kernel’s TCP state machine and buffers; the IP header with TTL; ARP or neighbor discovery to find the gateway’s MAC; the Ethernet or Wi-Fi frame; NAT at the home router rewriting the source; BGP-chosen paths across autonomous systems; the destination’s NIC, kernel, accept(), and the process.

At this altitude the interviewer is listening for which state changes where: DNS caches populated, a socket in SYN_SENT then ESTABLISHED, a NAT table entry, sequence numbers advancing, a TLS session key, a keep-alive connection left open for the next request. Follow a Web Request Through Every Layer and Follow One Packet trace these state changes explicitly; Follow send() Through the OS to recv() covers the kernel half.

Answer in rounds. Round one is the nine-step story with no detail — sixty seconds. Round two, on request, expands one rung they pick, to the level-2 mechanisms, naming the state that changes. Round three, if they keep pushing, is internals: SYN cookies, TLS 1.3 key schedule, HTTP/2 HPACK, epoll on the server. You do not choose the rung; they do, and following their choice cheaply is what distinguishes understanding from recitation.

At every layer, be ready with three things: the mechanism (what happens), a number (how long it takes, how big it is), and a failure (what breaks here and what it looks like). "TLS handshake — one round trip on 1.3, two on 1.2, so ~30 ms in-region; fails as an expired certificate, a hostname mismatch or a missing intermediate that browsers hide and curl exposes" is a complete answer for that rung. A candidate who can name the failure at each layer has clearly debugged it, and that is what the question is for.

Half-answers stop at "the server sends the response". Complete it: the response travels the reverse path — but not necessarily the reverse route, since each direction is routed independently — through the NAT mapping the outbound packet created, into the client’s kernel receive buffer, and up to the browser through the same socket. Then the browser parses HTML, discovers stylesheets, scripts and images, and issues a dozen or a hundred more requests, multiplexed on the same HTTP/2 connection (or on a small pool of HTTP/1.1 connections), most of them to a CDN whose DNS answer put an edge server a few milliseconds away. The first page load is dominated by round trips — DNS, TCP, TLS, then request — which is why Where the Time Goes: The Request Timeline is mostly about counting them.

End with the cross-domain picture if invited: the server side is a process the OS scheduled, reading from a socket via epoll, hitting a database whose buffer pool may or may not have the page — Capstone: A Server With 50,000 Concurrent Connections and Capstone: Three Seconds from Warsaw are the OS and together versions of this same walk.

They skip DNS or say "the browser looks up the IP" without saying where. They say "the packet is sent to the server" with no routing, no gateway, no NAT. They confuse TCP with TLS, or put the TLS handshake before the TCP one. They describe HTTP as "the request" without a method, a Host header or a status code. They say "the server processes it" and stop. And they cannot name a single failure at any layer, which is the difference between having read about the stack and having debugged it. The Why Can’t I Connect? ladder is this lesson’s debugging twin: every rung there is a failure to name here.