Networking 101: What Actually Happens When You Load a Web Page

Abstract network of nodes representing a web request

You type an address, hit enter, and a page appears. It feels instant, and it feels like magic — which is exactly the problem, because the day it stops working you’re left staring at a spinning tab with no idea where in the chain things fell over. So let’s pull the magic apart. This is a back-to-basics tour of what actually happens on the wire when you load a web page: enough to demystify it, and enough to make you quicker when something breaks.

It’s all just addresses and delivery

At its heart a network does one boring, brilliant thing: it moves a chunk of data from one address to another. Every switch, router and firewall you’ll ever meet is elaborate scaffolding around that single idea. Two kinds of address do the heavy lifting, and conflating them is the root of a surprising amount of confusion.

MAC addresses — who you are

Every network interface ships with a MAC address baked in at the factory — think of it as the hardware’s name. It’s used for delivery within a single network segment: the switch on your desk shifts frames from port to port by MAC address and neither knows nor cares about the wider internet.

IP addresses — where you are

An IP address is more like the street address of wherever you happen to be plugged in. It changes when you move networks, and crucially it’s routable — designed to be found from anywhere. If the MAC is your name, the IP is the hotel you’re staying at this week: post reaches the building by address, and the front desk (your local switch) hands it over by name.

Switches vs routers, once and for all

A switch moves traffic within one network — same street, house to house. A router moves traffic between networks — the junction that gets you off your street and onto the motorway. The router you lean on to reach everything beyond your own network has a name worth knowing: the default gateway. When a device wants to talk to something that isn’t local, it hands the packet to the gateway and trusts it to know a way there.

The layered model, without the yawn

You’ll hear about the OSI model and its seven layers. It’s a handy mental filing cabinet, but you rarely need all seven in anger. Four earn their keep day to day:

  • Link — MAC addresses and the physical hop to the next device.
  • Internet — IP: getting a packet across networks toward its destination.
  • Transport — TCP and UDP, plus ports: which application gets the data, and whether delivery is guaranteed.
  • Application — HTTP, DNS, SSH: the thing you actually came here to use.

Data travels down the stack on the way out — each layer wrapping the last in its own envelope — and back up the stack at the far end, each envelope opened in turn. That wrapping is called encapsulation, and it’s why one web request quietly becomes a MAC frame carrying an IP packet carrying a TCP segment carrying your HTTP request. Russian dolls, all the way down.

flowchart TD
  U["You: type the address"] --> DNS{"DNS: name to IP"}
  DNS --> GW["Default gateway"]
  GW --> NET["Router to router across the internet"]
  NET --> TCP["TCP handshake, port 443"]
  TCP --> HTTP["HTTP request and response"]
  HTTP --> PAGE["Browser renders the page"]

So: loading a web page

Put it together and the “magic” becomes a short, orderly sequence:

  1. Name → number. Your machine asks a DNS resolver to turn mitchreynolds.au into an IP address. Nothing routes on names.
  2. Find the way out. That IP isn’t local, so the packet goes to your default gateway and hops router to router across the internet.
  3. Knock on the right door. A TCP connection opens to port 443 (HTTPS), with a quick three-way handshake so both ends agree they’re really talking.
  4. Ask, and receive. Your browser sends an HTTP request; the server sends the page back; your browser renders it. Usually in well under a second.

You can watch the first two steps with a couple of everyday tools:

# Name -> number
$ dig +short mitchreynolds.au
203.0.113.42

# The router-by-router path out to it
$ traceroute mitchreynolds.au
 1  _gateway        0.4 ms      # your default gateway
 2  10.20.0.1       3.1 ms      # ISP edge
 3  103.x.x.x      11.7 ms      # ...and off across the internet

When it breaks, walk the layers

Here’s the practical payoff. Most field troubleshooting is just walking up the stack in order and refusing to skip a rung:

  • Link: is there a carrier? Cable in, link light on, interface up.
  • Internet: a sensible IP, subnet mask and gateway? ip a and ip r tell you in seconds.
  • Reachability: can you ping the gateway (local delivery works), then a public IP like 1.1.1.1 (routing works)?
  • Names: can you resolve DNS? If 1.1.1.1 pings but cloudflare.com doesn’t, you’ve found it.
  • Application: only now is it fair to blame the web server, the certificate, or the app itself.

If you can ping 1.1.1.1 but not cloudflare.com, it’s DNS. It’s almost always DNS.

That’s the skeleton the rest hangs off. Once addresses, routing and the layered model click into place, networking stops being magic and starts being a sequence you can reason about — and, when it misbehaves, a checklist you can work top to bottom. Next time I’ll take the scariest-looking rung on that ladder — subnets and the maths behind them — and show it’s far tamer than the notation makes it look.