What happens when you visit a website
You've met every piece on its own — DNS, the TCP handshake, TLS, HTTP, packets, routing. Now watch them snap together. You type an address and press enter; less than a second later a page appears. In between, seven steps happen in a fixed order, each one a topic you already know. This is the moment it all clicks into a single story.
The whole journey, top to bottom
Picture typing example.com and pressing enter. From that instant to the page showing up, your computer marches through these steps in order — each waiting for the one before. Nothing here is new; it's the whole track told as a single trip.
1 · DNS turns the name into an address
Your computer doesn't know where example.com lives — it only knows names, but the network delivers to numbers. So first it asks DNS, the internet's phonebook: 'what's the IP address for example.com?' DNS walks its chain (resolver → root → .com server → the site's own server) and hands back an IP, like 93.184.216.34. (And because results are cached, the next visit skips most of this.) Now your computer has an address to aim at.
2 · TCP handshake opens the connection
Knowing the address isn't enough — you have to make sure the server is awake and listening before sending anything real. That's the three-step TCP handshake: your computer sends SYN ('let's talk'), the server replies SYN-ACK ('heard you, hi back'), your computer sends ACK ('got it'). One quick round trip, and now there's an open, reliable connection between the two machines.
3 · TLS locks it (the padlock)
If the site uses HTTPS (almost all do now), a second handshake happens on top: TLS. The server shows its certificate — its signed ID card proving it's really example.com and not an impostor — and the two sides agree on a secret key so everything from here on is scrambled. This is the moment the padlock appears. Now nobody sitting between you and the server (on that coffee-shop Wi-Fi) can read or tamper with what you send.
4 · The browser sends an HTTP request
With a secure connection open, your browser finally asks for the page in the language of the web: HTTP. It sends a request like 'GET /' — meaning 'fetch me the home page.' That's the actual ask; everything before it was just getting a safe channel ready to carry it.
5 · The request routes across the internet as packets
That request doesn't teleport. It's chopped into packets, each stamped with the destination IP, and handed to the nearest router. Router to router to router, each one reads the address and forwards the packet one hop closer — like a letter passed hand to hand across the world. Different packets might even take different paths. (If the site is on a CDN, the nearest copy answers, so the trip is shorter than you'd think.)
6 · The server answers: 200 OK + the page
The server receives your request, finds the home page, and sends back a response: a status code (200 OK = 'here you go, all good' — or 404 if the page is missing, 500 if it broke) plus the page itself. That answer is chopped into its own packets and routed back to you the same hop-by-hop way.
7 · Packets reassemble and the page appears
The response packets arrive — maybe out of order, since they took different paths. This is exactly the job TCP promised to do: it sorts them back into the right order, re-asks for any that got lost, and hands your browser the clean, complete page. The browser reads it and draws it on your screen. Type, enter, page — and now you know every step in between.
Questions you might have
▸All that happens every time I open a page? How is it so fast?
It really does — but it's fast because computers do it in milliseconds and skip work when they can. DNS answers are cached, so the lookup is often instant. A connection, once open, gets reused for many requests, so you don't redo the handshakes for every image. And a CDN keeps copies nearby. The full seven-step trip mostly happens on the very first visit.
▸Which step is the 'slowest' one?
Usually the round trips — DNS lookup, the TCP handshake, the TLS handshake, and the request/response each cross the network and back. The further the server, the longer each round trip (that's latency). It's why putting servers and CDN copies physically closer to users makes sites feel snappier.
▸What if one step fails?
Each failure looks different. DNS fails → 'server not found.' The connection can't open → it times out. TLS can't verify the certificate → the browser warns you the site may be unsafe. The server replies with an error code → you see a 404 (missing page) or 500 (server broke). Reading where it broke tells you which step failed.
▸Why secure the connection (TLS) AFTER the TCP handshake instead of first?
Because TLS needs a working connection to talk over — you can't lock a door you haven't built yet. TCP builds the reliable channel; TLS then secures that channel. Order matters: connection first, lock second, then your actual request rides through the locked, reliable channel.
Best read after: DNS — the internet's phonebook, TCP vs UDP, HTTP & HTTPS, What is TLS? (the padlock), Packets & routing