Capstone — Tracing a Real Request End to End

net1-1 promised this exact moment: "the capstone, net1-11, walks through this exact same journey again — this time with nothing left unexplained." A user types https://www.example.com and hits enter. Here is everything that actually happens, step by step, in order.

Step 1 — DNS Resolution

The browser and OS check their own caches first; if nothing is cached, the recursive resolver walks the full hierarchy — root server, then .com TLD server, then example.com's own authoritative server — exactly the nine-step process from net1-9. The answer comes back: an A record, say 203.0.113.10, cached going forward for however long its TTL allows.

Step 2 — Determining the Path

With a destination IP now in hand, the device checks whether 203.0.113.10 falls within its own local subnet, using the subnet-mask math from net1-5. It doesn't — the device is almost certainly sitting on a private address (net1-4), and 203.0.113.10 is a public internet address. The packet is handed to the default gateway (net1-6), which consults its own routing table and forwards it onward — in reality, through many more routers and ISP networks than shown here, coordinated at internet scale by dynamic routing protocols like BGP (net1-6's own honest mention).

Step 3 — The TCP Handshake

Before any real data moves, the OS establishes a TCP connection to 203.0.113.10 on port 443 — HTTPS's own well-known port (net1-8). The three-way handshake runs in full: SYN, SYN-ACK, ACK (net1-7). The OS assigns a random ephemeral source port for this specific connection — say, 52341 — completing the full four-value socket pair from net1-8: (local IP):52341 → 203.0.113.10:443.

Step 4 — TLS, Layered On Top

Once the TCP connection is fully established, a genuinely separate TLS handshake begins over it — certificate exchange, key negotiation — building an encrypted channel on top of the already-reliable connection underneath. This is exactly the resolution net1-7 gave to the gap net1-1 first named in https1: two handshakes, strictly sequential, not one. It's also net1-2's own "session/presentation" concerns made concrete, folded into the Application layer in practice per net1-3.

Step 5 — The HTTP Request and Response

With an encrypted, fully-established TCP connection now in place, the browser sends the actual HTTP GET request — an Application-layer protocol (net1-3) traveling over the exact socket identified in Step 3 (net1-8). The server processes the request and sends back the page content, riding over that same connection, using TCP's own sequencing (net1-7) to guarantee it arrives complete and in the correct order.

Step 6 — If Something Had Gone Wrong

At any of the five steps above, something could genuinely fail: DNS could fail to resolve, routing could break down somewhere along the path, the handshake could hang on a silently dropped SYN-ACK (net1-7's own warn-box), or the HTTP exchange itself could error out. net1-10's own tools — ping, traceroute, ss, tcpdump — are exactly what isolates which specific step actually failed, rather than treating "the website won't load" as one undifferentiated mystery. This directly closes the loop on net1-1's own Exercise 3, which asked for exactly these three distinct failure points before any of this course existed to explain them.

Chapter Attribution Table

Hands-On Exercises