What Happens When You Type google.com?

This series built a network one layer at a time: what a network is for, the seven-layer model, the real stack, signals, frames, packets, connections, HTTP, and TLS. Every post assumed the network already worked. This one stops assuming and follows a single request from the moment a key is pressed to the moment a page appears, watching all nine posts happen at once.

Step 0: the key press

You type google.com and press enter. Before a single packet moves, your browser decides four things:

• What kind of request this is. No scheme typed means the browser applies its default, and for any domain it recognizes, that default is now https.
• Whether it already knows the answer. If you have visited this site before, the address may be in the DNS cache and even in the TLS session store, and parts of this whole journey are skipped.
• Where to look first. The browser checks its own cache, then the operating system’s cache, then the hosts file, then the resolver’s cache, and only then asks the network.
• What to do with the response. How to render it, and which parts of the page it will need next.

This is worth pausing on: a large fraction of page loads never touch the network at all. Everything below describes the slow path, the one that happens when nothing is cached.

Step 1: a name becomes an address

Your program cannot send anything to google.com. It can only send to an address, so the first question is DNS¹.

browser: any cached address for google.com?
   └─ no

OS resolver: hosts file? cache?
   └─ no

ask the resolver (your provider):
   ├─ cache still valid? (TTL not expired) → return 142.250.78.100
   └─ not cached → walk the hierarchy:
        root       "where does .com live?"        → the .com servers
        .com       "where does google.com live?" → the authoritative servers
        google     "ask me"                      → 142.250.78.100

Each answer in that chain comes back with a TTL, and every machine along the way caches it. When you visit the site an hour later, the answer comes from a cache in microseconds and no question is asked anywhere.

DNS answers with more than an address. It may return several, choose between IPv4 and IPv6, and record other things about the domain, like which servers handle email.

Step 2: local or remote

Your machine now holds an address. The next decision is the one from the link layer post and the network layer post: is that address on my network?

your machine: 192.168.0.15, netmask /24  → 192.168.0.0/24 is "mine"
destination:  142.250.78.100               → not in 192.168.0.0/24

→ longest match in my routing table is the default route
→ the next hop is my gateway, 192.168.0.1

The IP layer now knows a fact it could not know before: the frame leaving this machine is not addressed to the destination. It is addressed to the router, because the router is the only machine on this wire that can help.

Step 3: the local address question, again

To send that frame, your machine needs the router’s MAC address, and IP addresses do not tell it. So the same question from the ARP² section returns:

"who has 192.168.0.1? tell aa:bb:cc:dd:ee:ff"
   ◀── everyone on the LAN hears it (broadcast)
       the router replies, and your machine caches the answer

This is the only broadcast in the whole journey, and it never leaves your local network. From this moment on, every frame of this request is addressed to the router’s MAC and carries the destination IP inside its payload.

Step 4: opening the connection

The transport layer does its handshake³, one round trip of three packets:

client ── SYN      seq 1000 ─────────────▶ server
client ◀── SYN ACK  seq 5000, ack 1001 ── server
client ── ACK      ack 5001 ────────────▶ server

Each packet is wrapped on the way down: TCP header inside an IP header inside an Ethernet frame inside signal changes on the wire. The client’s kernel assigns an ephemeral source port, say 54321, and the server’s is 443, so the four-tuple identifies this conversation uniquely. The kernel now knows the server will not lose data, reorder it, or duplicate it. It still has not encrypted anything.

Step 5: making it private

Then the TLS handshake⁴, another round trip, and the reason nobody reads your traffic:

client ── ClientHello: TLS 1.3, cipher suites, server name: google.com ──▶

client ◀── ServerHello + certificate + key share ──

      client verifies the chain up to a root it trusts,
      runs the key exchange, derives the shared secret

client ── Finished ─────────────────────────────────────────────────────▶

      from here, every byte is encrypted

Three things just happened in about one round trip: the server proved its identity by presenting a certificate your browser can chain to a trusted root, both sides derived a key nobody watching could compute, and the channel became authenticated, so nobody can sit in the middle and relay it. In HTTP/3 this happens over QUIC on UDP, in one round trip total, with the transport rebuilt in the browser rather than in the kernel.

Step 6: the request

Now the top layer finally speaks, and the actual request is about 500 bytes of plain text:

GET / HTTP/2
Host: google.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
Cookie: ...

HTTP/2 200 OK
content-type: text/html; charset=utf-8
content-encoding: br
set-cookie: ...

Somewhere on the far side, a machine that was waiting on port 443 accepts the connection, decrypts it, reads the request, and hands it to a web server. The web server may find the answer in a cache a few kilometers away, or ask a database, or construct the page. Whatever happens there is application logic. From this network’s point of view, the server simply answers.

The answer comes back, and the browser starts rendering while the rest is still arriving.

Step 7: the journey back, layer by layer

The response is the same machinery in reverse, and this is where the layering becomes visible in one place:

encapsulation, sending side:

  [ HTTP 200 ]                         application
  [ TCP | port 443 | ack | HTTP 200 ]  transport   ← reliable, ordered
  [ IP | 142.250.78.100 | TCP | ... ] network    ← addressed to the server
  [ Eth | router's MAC | IP | ... ]   link        ← addressed to the next door
  10110010 0011...                     physical     ← volts, light, or waves

at each hop, in the middle of the network:

  router takes in a frame
    ├─ reads the destination MAC: not me? → forward
    ├─ reads the destination IP: not mine? → look up the routing table
    ├─ longest prefix match says "next hop is this neighbour"
    ├─ rewrite the IP header: my address becomes the source, next hop's the destination
    ├─ decrement the TTL
    ├─ rebuild the frame with the next neighbour's MAC address
    └─ push it out the next port

Watch the two identity swaps on every single hop, because they are the elegant part of the whole design. The IP addresses stay the same from source to destination, end to end, carrying the identity of the conversation. The MAC addresses change every time, because each link is a separate physical world with its own neighbours. The payload is never opened. The router does not know or care whether the bytes are a video, a bank transfer, or a page; it is moving an envelope forward.

And somewhere on this path, a packet is lost. Nothing notices yet: the loss only exists as the absence of an acknowledgment. The receiver’s acknowledgment for that range stops advancing, the sender sees it, resends the segment, and the receiver recognizes the number as one it already has and silently discards the duplicate. From your side, the page simply takes a few milliseconds longer.

Step 8: what it all cost

The interesting question is not what happened but where the time went, because the answer is mostly not the network moving data.

around a server 30 ms away:

  DNS lookup                5-30 ms   one round trip to a resolver
  TCP handshake             30 ms     1 RTT
  TLS handshake             30 ms     1 RTT (HTTP/3 saves this one)
  request + first bytes    ~30 ms     1 RTT, plus the server's work
                           ───────
  first paint             ~100-150 ms

moving the megabytes that follow is mostly bandwidth, not latency

The same page from another continent adds about 100 ms to every single round trip, which is exactly why protocols moved to one-round-trip handshakes and why streaming starts rendering before the page is complete. This is the concrete payoff of the numbers in the physical layer post: distance is measured in hops and milliseconds, not in kilometers, and no amount of bandwidth changes it.

Then the browser asks for the stylesheet, the logo, and the script. Each one is another request over the same connection in HTTP/2 or HTTP/3, multiplexed so a slow script never delays the logo, and cached so a second visit asks for almost nothing at all.

The big picture

One typed string, and every post in this series happens in the space of a few hundred milliseconds: a name resolved through a distributed caching hierarchy, a local decision about which machine to hand the frame to, an ARP broadcast to learn a hardware address, a three-message handshake to open a reliable connection, a certificate and a key exchange to make it private, a five-hundred-byte text request, and a response that travels back through nineteen hops⁵, each rewriting its envelope and forwarding by longest prefix match, while a lost packet is noticed only as a missing acknowledgment.

you type google.com
  │
  ├─ DNS: name → address              (a cached hierarchy)
  ├─ routing table: not local → gateway
  ├─ ARP: gateway's MAC address        (the one broadcast)
  ├─ TCP: SYN, SYN-ACK, ACK           (reliable, ordered, byte stream)
  ├─ TLS: certificate + key exchange   (private, authenticated)
  ├─ HTTP: GET /  →  200 OK           (meaning, finally)
  │
  ▼
the same machinery in reverse, plus a renderer

Three series now sit on one shelf. The Computers Explained series built the machine that runs your browser: bits, logic, a processor, memory, storage, and I/O. The Operating Systems Explained series explained how that machine stays yours while a hundred programs share it, and how it boots from a cold press of power. This series took the last step: how that machine talks to other machines it knows nothing about, and how a string of characters typed into a browser becomes a page by agreeing, layer by layer, on what a bit, a frame, a packet, a connection, a request, and a private conversation are.

The protocols will keep changing. HTTP/4 will eventually replace HTTP/3, and something will replace TCP. But the questions will not: who is this for, where is it going, how do I know it arrived, and can I trust the answer? Those four questions are the network, and they are older than the machines carrying them.

Footnotes

1. Domain Name System - Wikipedia

2. Address Resolution Protocol - Wikipedia

3. Three-way handshake - Wikipedia

4. Transport Layer Security - Wikipedia

5. Border Gateway Protocol - Wikipedia