Chapter 4 — Our running example: what happens when you open a website

This is the map for the whole guide. Skim it now; you won't understand every step yet. Each step names the chapter that explains it. Come back and re-read this chapter after Part 7 — it'll feel completely different.

The setup

Your laptop on home Wi-Fi, address 192.168.1.50
Your router at 192.168.1.1
You type https://example.com and press Enter

The journey

Step 0 — You already have an address. (Chapter 17) When you joined the Wi-Fi, your laptop asked "does anyone here give out addresses?" and your router replied with your IP address, the router's own address (your default gateway), and which DNS server to use. That conversation is called DHCP.

Step 1 — Turn the name into a number. (Chapter 18) Your laptop has no idea what example.com means. It asks a DNS server: "what's the IP address for example.com?" The answer comes back: 93.184.216.34. This might take one round trip, or zero if it's cached.

Step 2 — Decide where to send it. (Chapter 13) 93.184.216.34 is not on your home network, so your laptop consults its routing table and finds the rule "anything I don't recognise, send to 192.168.1.1" — the default route.

Step 3 — Find the router's hardware address. (Chapter 6) To put a packet on the Wi-Fi, your laptop needs the router's MAC address, not its IP. It shouts to everyone on the local network: "who has 192.168.1.1?" The router answers with its MAC address. This is ARP.

Step 4 — Open a connection. (Chapter 21) Your laptop and the web server perform a three-way handshake: SYN → SYN-ACK → ACK. Three small packets, one round trip, and now there's a TCP connection. Your laptop picks a random local port number (say 51000) so it can tell this connection apart from all the others.

Step 5 — Your router rewrites the address. (Chapter 12) Your home router performs NAT: it swaps your private 192.168.1.50 for its own public address, remembers the swap in a table, and forwards the packet on. Everything coming back gets swapped in reverse.

Step 6 — Cross the internet. (Chapter 13) Ten to twenty routers each do the same simple thing: look at the destination IP, consult a table, decide the next hop, decrement a counter (TTL), rewrite the link-layer header, forward. None of them knows about your connection.

Step 7 — Set up encryption. (Chapter 29) Over the fresh TCP connection, your browser and the server perform a TLS handshake: agree on ciphers, exchange keys, and the server proves its identity with a certificate. That's the padlock in the address bar. Roughly one more round trip.

Step 8 — Finally, ask for the page. (Chapter 28) Your browser sends an HTTP request — a few hundred bytes of text: GET / HTTP/1.1, Host: example.com. All encrypted now.

Step 9 — The response streams back. (Chapter 22, 24, 25) The server sends the HTML. TCP chops it into segments, numbers them, and the two sides use acknowledgements to make sure nothing is lost. TCP's congestion control ramps the speed up carefully rather than blasting at full rate.

Step 10 — Repeat, then hang up. (Chapter 23) The browser parses the HTML, finds CSS/JS/images, and fetches them — reusing the same connection where possible. When idle, the connection closes with FIN packets, and one side waits in a state called TIME_WAIT for about a minute.

The latency budget (why distance costs you)

On a cold connection to a server ~90 ms away (round trip), the unavoidable sequential round trips are:

Phase	Round trips	Time
DNS lookup (not cached)	1	90 ms
TCP handshake	1	90 ms
TLS handshake (TLS 1.3)	1	90 ms
HTTP request → first byte	1	90 ms
Total before you see anything	~4	~360 ms

That's before a single byte of the page arrives. This table explains the entire existence of CDNs, connection reuse, caching, and HTTP/3 (Parts 6, 7, 9). Your bandwidth is irrelevant here — only the number of round trips and the distance matter.

Practice (10 min) — measure it on your own machine

curl -w '
  dns lookup:   %{time_namelookup}s
  tcp connect:  %{time_connect}s
  tls setup:    %{time_appconnect}s
  first byte:   %{time_starttransfer}s
  total:        %{time_total}s
' -o /dev/null -s https://example.com

Each number is cumulative from the start. So:

DNS took time_namelookup
TCP handshake took time_connect − time_namelookup
TLS took time_appconnect − time_connect
The server's thinking + first byte took time_starttransfer − time_appconnect

Now run it again immediately. DNS should drop to nearly zero (it's cached). Run it against a server far away and compare (try https://www.gov.au or https://www.japan.go.jp). You have just measured the physics of the internet.

Common confusions

"That's a lot of steps for one page." It is — and modern browsers do many of them in parallel and cache aggressively. But every step is real, and when a page is slow, it's slow at one of these steps. Knowing the list is how you find out which.
"Why so many round trips just to say hello?" Historical layering, plus security. HTTP/3 (Chapter 30) merges the TCP and TLS handshakes to cut this from ~3 round trips to 1.

Check yourself

List the ten steps from memory, in order.
Which step turns a name into a number?
Which two steps involve a handshake?
If a page loads slowly, name three different steps that could be responsible.

End of Part 1 — Milestone check

I can name the four layers and one protocol at each
I can explain encapsulation using the postal analogy
I know which header changes at every hop and which doesn't
I can list the main steps of loading a web page
I have run the curl -w timing command and understood the output