4. End-to-end walkthrough: opening `https://example.com`

This chapter ties Parts II–XI together. Follow one HTTPS page load from a laptop on home Wi-Fi. Every step names the chapter that covers it in depth.

4.1 Setup assumed

Laptop: 192.168.1.50/24, gateway 192.168.1.1, DNS 192.168.1.1.
Home router does NAT to public IP 203.0.113.7.
example.com resolves to 93.184.216.34 (IPv4) via an authoritative server.

4.2 The steps

Step 0 — Is the network up? (Ch. 5, 19) The laptop already has an IP because at join time it did DHCP: DISCOVER → OFFER → REQUEST → ACK, learning address, mask, gateway, DNS, and lease time. The NIC link is up (Layer 1/2 negotiated speed and duplex).

Step 1 — Name resolution (Ch. 20) The app calls getaddrinfo("example.com", "443"). The stub resolver checks the local cache, then sends a DNS query (UDP/53) to 192.168.1.1: example.com. IN A?. The home router is a forwarding resolver; it recurses (or asks upstream), gets A 93.184.216.34 with a TTL, caches it, and answers the laptop. Total added latency: one or two RTTs, or ~0 ms if cached.

Step 2 — Route lookup (Ch. 13) The kernel needs to send to 93.184.216.34. It consults the routing table. 93.184.216.34 is not in 192.168.1.0/24, so it matches the default route 0.0.0.0/0 via 192.168.1.1 dev wlan0. Next hop = 192.168.1.1.

Step 3 — Link-layer address of the next hop (Ch. 6) The laptop needs the MAC address of 192.168.1.1. It checks the ARP cache. On a miss it broadcasts ARP: who-has 192.168.1.1 tell 192.168.1.50. The router replies with its MAC. Now the laptop can build frames.

Step 4 — TCP three-way handshake (Ch. 24) The kernel picks an ephemeral source port (say 51000) and sends:

SYN seq=X, options: MSS=1460, SACK-permitted, window scale=7, timestamps.
Server replies SYN, ACK seq=Y, ack=X+1, its own options.
Laptop sends ACK ack=Y+1. Connection is ESTABLISHED.

Each of these is one IP packet in one Ethernet frame. The frame's dst MAC is the router's; the packet's dst IP is the server's. The MAC changes at every hop; the IP addresses do not (until NAT — see next step).

Step 5 — NAT at the home router (Ch. 12) The router rewrites the outbound packet's source from 192.168.1.50:51000 to 203.0.113.7:62000 (a port it allocates), records the mapping in its NAT table, recomputes checksums, and forwards it toward its ISP via its default route. Return packets to 203.0.113.7:62000 get rewritten back to 192.168.1.50:51000.

Step 6 — Routing across the internet (Ch. 13, 50) Each router along the path does the same thing: strip the incoming Ethernet frame, look up the destination IP in its (BGP-populated) forwarding table, decide the next hop, decrement TTL, rewrite src/dst MAC for the outgoing link, recompute the IP header checksum, transmit. Typically 10–20 hops. No router keeps per-connection state.

Step 7 — TLS handshake (Ch. 38) Over the now-open TCP byte stream, the client sends ClientHello (TLS 1.3: supported ciphers, key share, SNI = example.com). Server responds with ServerHello, certificate, and a key share. Both derive session keys. One round trip in TLS 1.3 (or zero with resumption). After this, all TCP payload bytes are encrypted application_data records.

Step 8 — The HTTP request (Ch. 39) The client writes:

GET / HTTP/1.1
Host: example.com
User-Agent: ...
Accept: */*

This is a few hundred bytes → one TCP segment → one IP packet → one frame.

Step 9 — The response and TCP reliability (Ch. 27–29) The server streams the HTML. TCP breaks it into MSS-sized segments with increasing sequence numbers. The client ACKs (often one ACK per two segments — delayed ACK). If a segment is lost, the client sends duplicate ACKs; after three, the server does a fast retransmit without waiting for a timeout. The server ramps its sending rate via slow start then congestion avoidance / CUBIC.

Step 10 — Rendering, then teardown (Ch. 25) Browser parses HTML, opens more connections (or HTTP/2 streams) for CSS/JS/images — each repeating steps 4–9, but DNS and often TCP/TLS are cached/reused. When idle, connections close: FIN/ACK in each direction (4 packets, or 3 if piggybacked). The initiator sits in TIME_WAIT for 2×MSL (~60 s on Linux) to absorb stragglers.

4.3 The latency budget

For a cold load from Europe to a US server (~90 ms RTT), the unavoidable serialized round trips are roughly:

Phase	Round trips	~Time
DNS (uncached, one level)	1	90 ms
TCP handshake	1	90 ms
TLS 1.3 handshake	1	90 ms
HTTP request + first byte	1	90 ms
Total to first byte	~4	~360 ms

This is why CDNs (Ch. 50 anycast), TLS resumption, HTTP/3's 0-RTT, and connection reuse matter so much: each eliminated round trip saves one whole RTT.

4.4 War story

"The site is slow only for our Sydney office." Traceroute showed traffic from Sydney going to a data center in Virginia. DNS was returning the US IP because the office's recursive resolver was in Virginia, and the CDN used DNS-based geo-routing keyed on resolver location, not client location. Fix: move the resolver, or adopt EDNS Client Subnet, or use an anycast CDN. Lesson: every step in Chapter 4 is a place performance can go wrong; know the whole chain.

Try it yourself

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

4. End-to-end walkthrough: opening https://example.com

4.1 Setup assumed

4.2 The steps

4.3 The latency budget

4.4 War story

4. End-to-end walkthrough: opening `https://example.com`