You press Enter on example.com and a page appears. In the time it takes to blink, a machine that knew nothing about that name has learned an address, negotiated a cipher with a stranger, and requested a document. None of that is magic, and all of it is inspectable.

This is the article I wish I had read first, because every later topic — VLANs, firewalls, Wi-Fi roaming, TLS inspection — is a variation on one of the steps below. If you can narrate this sequence from memory, the rest of networking becomes a set of footnotes about where it can go wrong.

The short version

Before the browser sends anything to a web server, four things have to happen:

  1. Resolve a name to an address. DNS turns example.com into an IP address.
  2. Find a path off your own network. Your machine compares that address to its own subnet and decides whether to talk directly or hand the packet to a router.
  3. Open a connection. TCP performs a three-way handshake so both sides agree they are talking.
  4. Agree on encryption. TLS negotiates keys, and only then does the HTTP request travel.

Each step depends on the one before it. That dependency is why a "site is down" report is almost never about the site.

Step 1 — DNS: a name becomes a number

Computers route packets by IP address, not by name. So the first packet your machine sends is not to example.com; it is to your DNS resolver, asking what example.com means.

Your resolver is usually your router, a domain controller, or a public service. If it has the answer cached, it replies in under a millisecond. If not, it walks the DNS hierarchy — root, then the .com servers, then the domain's own nameservers — and caches the result for a period called the TTL.

The first packet is not the web request

This is the detail that makes troubleshooting tractable. If DNS fails, nothing else happens, and the browser reports a name-resolution error rather than a connection error. Those are different failures with different fixes, and they are reported differently on purpose.

Step 2 — The local decision: same subnet or somewhere else?

Now the machine has an address, say 203.0.113.10. It also knows its own address and its subnet mask. The mask is the part beginners skip, and it is the part that decides everything that follows.

If the destination falls inside your own subnet, you can reach it directly: you ask "who has 203.0.113.10?" on the local network, and the owner answers with its hardware address. If the destination is outside your subnet, you cannot reach it directly at all. You hand the packet to your default gateway instead — the router that agrees to carry traffic you cannot deliver yourself.

Either way, the next thing that happens is the same: your machine needs a MAC address to put on the Ethernet frame. It has an IP address, but the wire does not understand IP. This is the ARP lookup, and it is the last step before a packet leaves your network card.

The path of one request: name resolution, local gateway decision, then three hops to the server.

Step 3 — TCP: agreeing to talk

IP is a delivery service with no memory. It will happily drop packets, deliver them out of order, or deliver the same one twice. TCP sits on top and turns that into a reliable stream.

The handshake is three packets:

Direction Flag Meaning
Client → Server SYN "I want to open a connection, my sequence starts here"
Server → Client SYN-ACK "Accepted, my sequence starts there"
Client → Server ACK "Understood, we are connected"

Only after the third packet can data flow. This is why a firewall that permits SYN but blocks the return path produces a connection that "hangs" rather than fails — the client is waiting for an answer that a stateful device silently discarded.

Ports are part of this step. The server listens on a well-known port (443 for HTTPS), and your client picks a random high port for its side of the conversation. The pair of addresses plus the pair of ports identifies the connection, which is what a state table remembers.

Step 4 — TLS: agreeing on secrecy

The connection exists, but it is plaintext. TLS wraps it.

In TLS 1.3 the client sends a ClientHello with a key share and a list of cipher suites. The server answers with its own key share and a certificate. Both sides derive the same session keys, and the certificate proves the server is who it claims — verified against a certificate authority your machine already trusts.

Two round trips after TCP, and the channel is encrypted. Then, finally, the browser sends:

GET / HTTP/1.1
Host: example.com

The server replies with HTML. The browser parses it and discovers it needs a stylesheet, two scripts, and four images — and every one of those starts the whole sequence again, minus the DNS lookup if the name is cached.

Worked example

A student Chromebook at 10.40.12.57, mask 255.255.248.0, gateway 10.40.8.1, opens a page:

  1. DNS query to 10.0.0.3 (the domain controller): example.com → 203.0.113.10.
  2. 203.0.113.10 is not inside 10.40.8.0/21, so the packet goes to the gateway.
  3. ARP for 10.40.8.1 returns the router's MAC. The frame is addressed to the router, not the server.
  4. The router forwards it, and NAT rewrites the source to the district's public address on the way out.
  5. TCP handshake, TLS handshake, HTTP request, response.

The student never types an IP address, and the server never learns the student's private one. Both facts are the result of the four steps above, in order.

What "the internet is down" usually means

Nine times out of ten it means one of these four steps failed, and the four have distinct signatures. Name resolution failure, no gateway reachable, TCP timeout, and certificate error look different in a browser and behave differently under ping, nslookup, and curl. Learn the signatures and you stop guessing.

What breaks in production

  • DNS points at the wrong resolver. The page fails before a single packet reaches the gateway, and everything else on the machine still works — which makes it look like a browser problem.
  • The subnet mask is wrong. A /24 host on a /21 network believes half its neighbors are remote, sends everything to the gateway, and the gateway sends it back. Intermittent, maddening, and invisible in a ping.
  • The default gateway is missing or wrong. Local traffic works, nothing else does. The classic symptom is "the printer is fine but the internet is broken."
  • A stateful firewall sees one direction only. The SYN leaves, the SYN-ACK never returns, and the client retries until it times out.

Checklist

  1. Can you name the four steps without notes?
  2. Do you know your own subnet mask and gateway, and can you tell whether a given address is local?
  3. Can you explain why the destination MAC is the router's, not the server's?
  4. Do you know which port your DNS resolver uses, and which one your browser does?
  5. Can you tell a DNS failure from a TCP failure from a TLS failure by symptom alone?

Next

The mask decided whether the packet went direct or to a gateway, and that decision deserves its own article. Continue with IP Addresses, Subnets, and Why /24 Isn't Magic.

  • DNS
  • TCP
  • TLS
  • Fundamentals