Typing a URL triggers a pipeline, not a single network request. The browser must determine where the host is, establish the appropriate transport/security context, send an HTTP request, receive bytes, parse the response, and request additional resources. DNS, ARP/NDP, routing, TCP or QUIC, TLS and HTTP are all parts of the visible 'page load'.
Remember the shape, not the sentence
“Think of a restaurant reservation. First you discover the correct restaurant, then establish a connection, verify that you are talking to the right place, place the order, receive the meal, and then ask for side dishes such as images, stylesheets and scripts.”
Name resolution first
A browser or operating system often consults local caches before asking a DNS resolver. The resolver may obtain an answer by following the DNS hierarchy until an authoritative server provides the requested record.
Reachability is multi-hop
The destination IP is not enough by itself. The host must choose a route, reach the next hop on the local link, and encapsulate frames for every hop.
Security precedes application data
For HTTPS, TLS authenticates the server and establishes cryptographic keys before protected HTTP data is exchanged. Modern HTTP/3 runs inside QUIC rather than TCP.
See the mechanism before you memorize it
One diagram, one causal story, one reconstruction task.
What happens when you type google.com — causal map
1. Resolve
URL → DNS lookup → destination address.
2. Reach
Routing + next-hop link resolution move packets toward the server.
3. Establish
TCP+TLS for classic HTTPS, or QUIC for HTTP/3.
4. Request
The browser sends an HTTP request and receives headers/body bytes.
Draw the idea yourself
Rebuild the core flow on a real canvas before moving to the worked walkthrough.
Walk the system
1. Resolve
URL → DNS lookup → destination address.
2. Reach
Routing + next-hop link resolution move packets toward the server.
3. Establish
TCP+TLS for classic HTTPS, or QUIC for HTTP/3.
4. Request
The browser sends an HTTP request and receives headers/body bytes.
5. Render
The browser parses HTML and issues follow-up requests for dependent resources.
Debugging checklist
These commands answer different questions: DNS answer, HTTP/TLS reachability, path visibility and local socket state. Good debugging uses tools that test separate hypotheses.
dig +short google.com
curl -I https://google.com
traceroute google.com
ss -tuna | headWhat usually goes wrong
Close the tab. Rebuild it from memory.
Read the question, answer aloud, then reveal.
What must succeed before an HTTPS request can complete?Reveal answer
At minimum, name resolution or an equivalent address source, path/link reachability, the chosen transport, and the TLS/application protocol negotiation must all succeed.
Why does one page cause many requests?Reveal answer
HTML frequently references stylesheets, JavaScript, fonts, images and API endpoints that are fetched separately, subject to caching and browser policies.
Where would you start when a site fails?Reveal answer
Separate the failure into DNS, connectivity, TLS, HTTP response, or browser/application behavior instead of treating 'the network' as one system.
Make this idea travel.
Connect it next to: signals-media • dns • tcp-handshake.