Tracing a Request End to End

In Article 0 we sketched the journey of a request when you open a web page. Now — having studied each layer — we trace it completely, fitting all the pieces together. This is the synthesis article, and also a check on whether you've grasped the big picture.

The full picture: one request, real per-phase timing

The curl tool can measure the time of each phase of a request, mapping straight onto the layers we've learned:

curl -s -o /dev/null -w 'DNS:  %{time_namelookup}s\nTCP:  %{time_connect}s\nTLS:  %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTong: %{time_total}s\n' https://example.com

DNS lookup:    0.009s   ← name resolution (Article 7)
TCP connect:   0.041s   ← TCP handshake done (Article 6)
TLS handshake: 0.077s   ← TLS done, encrypted channel ready (Article 9)
Server process: 0.126s  ← first byte of the response (HTTP — Article 8)
Total:         0.126s
HTTP 200 (HTTP/2)  →  172.66.147.243:443

The numbers are cumulative, so their differences are the time per phase: DNS ~9ms, then TCP adds ~32ms, TLS adds ~36ms, the server handles the rest. This isn't theory — it's each layer in the series, measured in milliseconds.

Tracing it step by step

Type https://example.com and hit Enter. Here's the whole journey, tied to each article:

┌───────────────────────────────────────────────────────────────────┐
│ 0. The browser needs to connect to example.com                    │
│                                                                   │
│ 1. NAME RESOLUTION (DNS — Article 7)                              │
│    "what IP is example.com?" → ask resolver → root/TLD/auth       │
│    → 172.66.147.243   (cached per TTL)                            │
│                                                                   │
│ 2. ROUTING (Articles 2,4) + LEAVING HOME NETWORK (NAT — Art. 5)   │
│    The machine has a private IP 192.168.x.x; the packet goes to   │
│    the default gateway, through NAT (swapped to a public IP),     │
│    hops across routers to the destination. Each leg: ARP/MAC      │
│    within the LAN (Article 3), IP stays the same.                 │
│                                                                   │
│ 3. TCP HANDSHAKE (Article 6)                                      │
│    SYN → SYN-ACK → ACK to port 443. Connection ESTABLISHED.       │
│                                                                   │
│ 4. TLS HANDSHAKE (Article 9)                                      │
│    Negotiate TLS 1.3 + cipher; server presents its certificate;   │
│    browser verifies the chain of trust to a Root CA; set up the   │
│    session key.                                                   │
│                                                                   │
│ 5. HTTP REQUEST/RESPONSE (Article 8)                              │
│    Send "GET / HTTP/2, Host: example.com" (encrypted).            │
│    The server (possibly via a load balancer/reverse proxy —       │
│    Article 11, behind a firewall — Article 10) returns            │
│    "HTTP/2 200" + HTML.                                           │
│                                                                   │
│ 6. The browser renders the page (repeats for each image/CSS/JS).  │
└───────────────────────────────────────────────────────────────────┘

Each step is one (or a few) articles. If any step breaks, you now know exactly which tool to check with (Article 12): dig for step 1, traceroute for step 2, nc for step 3, openssl for step 4, curl -v for step 5.

Why this view is valuable

Seeing it by layers, you can answer questions you might only have guessed at before this series:

• "The page loads slowly" — curl -w shows which phase is slow: slow DNS? slow TLS? the server taking long (high TTFB)? Each cause has a different fix.
• "The API errors sometimes" — at which layer? Unstable DNS? Connection reset (TCP)? A certificate about to expire? A 5xx from the server?
• "No one can reach the service" — DNS, routing, firewall (port), or the service not listening? The Article 12 workflow pinpoints it.

This is what separates someone who just "writes code" from someone who "can operate a system": when there's a network incident, you don't panic — you ask "which layer?" and go check.

Series wrap-up

Fourteen articles, going from "what happens when you open a web page" to tracing a complete request:

• The mental framework (Article 1): a network stacks into layers, each doing one job — a tool for understanding and for troubleshooting.
• The lower layers (Articles 2–5): IP & subnets, MAC/ARP within the LAN, routing between networks, NAT out to the Internet.
• The transport layer (Article 6): TCP (reliable, handshake) vs UDP (fast), and ports.
• The application layer (Articles 7–9): DNS, HTTP/HTTPS, TLS (encryption + certificates).
• Operations (Articles 10–12): firewalls, load balancers/reverse proxies, and diagnosis.

A few threads worth keeping throughout:

• Ask "which layer?" when troubleshooting — the most powerful mindset this series gives you.
• The end-to-end IP stays the same, the MAC changes each hop — distinguishing logical identity from local delivery.
• Default-deny, open the minimum — the recurring security principle (firewall, security group).
• TLS = confidentiality + integrity + authentication — and certificates expire, so remember to auto-renew.

Where to learn next

• Connect to the other series: you now understand the network beneath containers (Docker — bridge/overlay/NAT), the cloud (AWS — VPC/subnet/security group/load balancer), and Linux (ip/ss/dig). They're all concepts from this series, realized in each place.
• Go deeper: IPv6 (replacing NAT), QUIC/HTTP3, BGP (Internet routing), VPN/WireGuard, eBPF (modern network observability), zero-trust networking.
• Practice observing: use tcpdump/Wireshark to capture and read the real packets of the very steps above — the most effective way to learn networking "with your own eyes."

Thanks for following the whole series. Computer networking is broad and deep, but with a layered mental framework and a diagnostic toolkit in hand, you can confidently face most network incidents — and trace any request, from end to end.