What "loading a page" really means

I typed itsnetacad.com in my browser and hit Enter without thinking about it. Then I stopped and asked myself: what actually happens between that keystroke and the page rendering on my screen. It turns out almost every module I've studied so far, ARP, routing, TCP, is involved in that single request.

A URL looks like one action. It isn't. It's a chain of independent protocols, each solving one narrow problem, stacked on top of each other. Break the chain at any layer and the page never loads.

This post traces that chain end to end, from the browser cache to the server and back.

Step 1 : DNS resolution, turning a name into an address

The browser doesn't know what itsnetacad.com is. Only an IP address means anything on the network. So the first job is translation.

The lookup goes through a cascade, cheapest source first:

1. Browser cache        -> already resolved recently?
2. OS cache              -> resolv.conf / hosts file
3. Recursive resolver    -> usually the ISP's DNS, or 1.1.1.1 / 8.8.8.8
4. Root server           -> "who handles .com?"
5. TLD server            -> "who handles netacad.com?"
6. Authoritative server  -> "here is the A record for itsnetacad.com"

If nothing is cached, the resolver walks that whole tree. In practice it's fast because root and TLD answers are cached aggressively across the internet, but the first time, it's a real round trip through the hierarchy.

At the end of this step, the browser holds one thing: an IPv4 or IPv6 address.

Step 2 : finding the way out, ARP and the default gateway

Here's where CCNA stops being theory. My machine now has a destination IP, but it can't send an IP packet directly, Ethernet only understands MAC addresses.

The machine checks: is the destination IP on my local subnet? It isn't, itsnetacad.com is somewhere on the internet. So the packet has to leave the LAN, which means it has to go through the default gateway first.

If the gateway's MAC address isn't already in the ARP cache:

ARP Request (broadcast, ff:ff:ff:ff:ff:ff):
  "Who has 192.168.1.1? Tell 192.168.1.42"

ARP Reply (unicast, from the gateway):
  "192.168.1.1 is at aa:bb:cc:dd:ee:ff"

Now the machine can build an Ethernet frame with the gateway's MAC as the destination, wrapping an IP packet whose destination IP is the actual server, not the gateway. That distinction, MAC address for the next hop, IP address for the final destination, is the whole idea behind routing.

Step 3 : the packet's trip across the internet

From the gateway onward, it's router to router. Each router looks at the destination IP, checks its routing table, and forwards the packet toward the next hop. It doesn't know the full path, just the next step, the same way a static route only tells you where to send traffic for a given network.

Two mechanics from module 8 matter here:

- Each hop decrements the TTL (Time To Live) by 1.
  If TTL hits 0, the packet is dropped, this is what traceroute exploits.

- Each router re-encapsulates the packet in a NEW Ethernet frame
  for the next hop's local segment. Source and destination MAC change
  at every hop. Source and destination IP stay the same the whole way.

That last point took me a while to internalize. IP addresses are the constant across the whole journey, they identify source and destination end to end. MAC addresses are local and disposable, they only mean something for the current hop.

Step 4 : the TCP handshake, agreeing to talk

Once the packet physically arrives at the server's network, there's still no connection. HTTP runs on top of TCP, and TCP requires a handshake before a single byte of actual data moves.

Client -> Server : SYN         (seq=x)
Server -> Client : SYN, ACK    (seq=y, ack=x+1)
Client -> Server : ACK         (ack=y+1)

Three packets, no payload yet. This is purely the two sides agreeing on sequence numbers so they can track what's been sent and what's been acknowledged, TCP's whole reliability model rests on this.

Only after this handshake completes does a connection formally exist.

Step 5 : TLS, before HTTP even gets a word in

itsnetacad.com is HTTPS, so before any HTTP request is sent, there's a second handshake, on top of the first one, to set up encryption.

Client Hello  -> "here are the ciphers I support, plus a random number"
Server Hello  <- "here's the cipher we'll use, my certificate, my random number"
Key Exchange  -> both sides derive the same session key independently
Finished      <-> both sides confirm, encryption is now active

The server's certificate is what lets the browser verify it's actually talking to the real itsnetacad.com and not something sitting in the middle pretending to be it. From this point on, every byte exchanged is encrypted with the session key, including the HTTP request itself.

Step 6 : the actual HTTP request

Only now, after DNS, ARP, routing, TCP, and TLS, does the browser send what most people think of as "the request":

GET / HTTP/1.1
Host: itsnetacad.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

The server processes it and replies:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 48213

<!DOCTYPE html>...

The browser starts parsing the HTML immediately, and for every image, script, or stylesheet referenced inside it, this entire chain, or a shortened version of it, reusing the existing TCP/TLS connection, runs again.

Takeaway

What looks like one instant action, typing a name and hitting Enter, is really six layers of independent negotiation stacked on top of each other: name resolution, local delivery, routing, reliability, encryption, and finally the application-level request. Each layer solves exactly one problem and hands off to the next.

The CCNA material stops being abstract once you trace it through something you do a hundred times a day. ARP isn't a diagram anymore, it's the reason your browser knows which MAC address to put on the frame carrying your DNS query.

Part of a series on networking fundamentals, written as I connect CCNA theory to what actually happens on the wire.