Questions › Networking/Security
Trace what the network does when a browser needs to reach example.com: DNS resolution through the first bytes of the response. Where does caching happen?
End-to-end grasp of name resolution and connection setup — the layers beneath fetch() that determine latency.
Before any HTTP flows, the browser must turn the hostname into an IP address (DNS) and open a connection. DNS RESOLUTION walks a cache hierarchy, stopping at the first hit: (1) the browser's own DNS cache; (2) the OS resolver cache (and the hosts file); (3) the configured RECURSIVE RESOLVER (your ISP's, or 1.1.1.1 / 8.8.8.8), which itself caches. On a full miss the recursive resolver does the iterative lookup: ask a ROOT server (which delegates to the .com TLD servers), ask the TLD server (which returns the AUTHORITATIVE nameserver for example.com), then ask that authoritative server for the A/AAAA record. Each record carries a TTL that governs how long every layer may cache it — which is why DNS changes take time to propagate and why a low TTL is set before a planned migration. (DNS traditionally runs over UDP port 53; DNS-over-HTTPS/TLS now encrypts it.) With an IP in hand the browser sets up the connection: a TCP handshake (SYN, SYN-ACK, ACK — one round trip), then for HTTPS a TLS handshake (validate the certificate, derive session keys — one more round trip in TLS 1.3, more in older versions). Only now does the browser send the actual HTTP request; the server processes it and streams back the response, whose first byte you see as TTFB (time to first byte). Then the real cost surfaces: the browser parses the HTML and discovers subresources (CSS, JS, images), each of which may need its own DNS + connection unless it's same-origin or the connection is reused. This is why latency optimizations target these steps: DNS PREFETCH and PRECONNECT warm up resolution/handshakes for known third-party origins before they're needed; keep-alive and HTTP/2/3 REUSE one connection for many requests instead of paying the handshake tax repeatedly; a CDN shortens every leg by putting the server (and often the DNS answer) physically closer. The mental model: reaching a server is DNS lookup (cached at several layers) → TCP → TLS → request → response, and each round trip is latency you can sometimes cache away or parallelize, but never wish away entirely.
Explaining latency sources; justifying preconnect/dns-prefetch; understanding DNS propagation and TTL.
Reaching example.com:
1. DNS resolution (first cache hit wins):
browser cache -> OS cache/hosts -> recursive resolver (ISP/1.1.1.1)
full miss: root -> .com TLD -> example.com authoritative NS -> A/AAAA
each record cached per its TTL (why changes "propagate" slowly)
2. TCP handshake SYN / SYN-ACK / ACK (~1 RTT)
3. TLS handshake cert validation + keys (~1 RTT in TLS 1.3)
4. HTTP request --> server processes --> response (first byte = TTFB)
5. parse HTML, discover CSS/JS/img -> more DNS+connections (or reuse)
Speedups: dns-prefetch / preconnect warm steps 1-3 for third-party origins;
keep-alive + HTTP/2/3 reuse one connection; a CDN shortens every leg.