How a Request Travels the Network

DNS, packets, hops — what actually happens between typing a URL and seeing a response.

From URL to IP — DNS in Plain English

When you type google.com into your browser, your computer doesn't actually know where Google lives. Domains are for humans. The internet runs on numeric IP addresses. The system that translates between them is DNS (Domain Name System) — basically the internet's address book.

The lookup, simplified:

1. Browser cache — Has my browser asked for this domain recently? If yes, use the cached IP and we're done. (Browsers cache for a few minutes.)

2. Operating system cache — Same idea, one level higher.

3. Router / ISP resolver — Your home router asks your ISP's DNS server. Most ISPs cache popular domains.

4. Root servers (".") — If still no luck, the resolver asks one of the 13 root server clusters: "where can I find .com domains?"

5. TLD servers (".com") — The .com authority answers: "for google.com, ask Google's name servers."

6. Authoritative name servers — Google's own DNS servers respond with the actual IP: 142.250.190.78.

7. The IP gets cached at every level on the way back, so the next request is much faster.

google.com  →  [browser cache]  →  [OS cache]  →  [ISP resolver]
                                                       │
                                                       ▼
                                            [root server (.)]
                                                       │
                                                       ▼
                                            [TLD server (.com)]
                                                       │
                                                       ▼
                                       [google.com authoritative NS]
                                                       │
                                                       ▼
                                                142.250.190.78

This whole dance usually finishes in 20–80 milliseconds. When DNS is broken, nothing else works — which is why DNS issues are some of the most painful production outages.

Finding the Nearest Server (Anycast)

Google doesn't have one server. They have thousands, in data centers across every continent. When your DNS query returns "142.250.190.78", that IP isn't a single physical machine — it's an Anycast IP, advertised from many locations at once.

Anycast = "send my packet to whichever server with this IP is closest, network-wise."

Your packet leaves your laptop and hops through routers — your home router, your ISP, regional backbones, peering points. Each router looks at the destination IP and decides "which next router gets me closer?" Eventually it lands on the Google data center physically nearest to you.

Your laptop (192.168.1.100)
    │
    ▼  (WiFi)
Home router → ISP local node → ISP regional → backbone
    │
    ▼
Google's edge data center (e.g. Mumbai, if you're in India)

This is why a video on YouTube loads fast even though Google's headquarters is in California. The byte you receive probably traveled less than 50 km — not 14,000 km — because Google has an edge node near you.

CDNs like Cloudflare and Fastly use the same trick to serve images, JavaScript, and even cached API responses from edge locations close to users.

Packets — The Internet's True Currency

Everything on the internet — every email, video frame, API response — is broken into small packets. A packet is a chunk of data wrapped with metadata that tells the network where to send it.

A typical packet:

┌─────────────────────────────────────┐
│ Header (the metadata)               │
│  • Source IP / port                 │
│  • Destination IP / port            │
│  • Sequence number                  │
│  • Checksum (integrity check)       │
├─────────────────────────────────────┤
│ Payload (your actual data)          │
│  • A piece of an HTTP request       │
│  • Or part of a video frame         │
│  • Or anything else                 │
└─────────────────────────────────────┘

Packets are typically small — around 1500 bytes is the standard maximum size on the public internet. A single HTTP request might be one packet; a 4K video stream is millions of packets per second.

Why packets and not just streaming bytes continuously?

• Resilience — If one packet is dropped, only that one needs to be resent. The whole connection doesn't restart.
• Multiplexing — Multiple connections can share the same wire because their packets are interleaved.
• Routing flexibility — Different packets in the same conversation can take different paths through the network.

Protocols decide what's in the packet's payload:
• HTTP / HTTPS — web traffic
• FTP — file transfer
• SMTP — email
• DNS queries — domain lookups
• WebSocket frames — real-time chat
• gRPC — service-to-service calls

When you write fetch('/api/users'), you're not really writing a network call. You're writing the top of a stack that turns into HTTP, which gets serialized to bytes, which get chunked into packets, which fly through the network, which get reassembled on the server. The abstraction is incredible — and worth understanding even when it works.

TCP Handshake — How Connections Begin

Before two machines can exchange HTTP messages, they need to establish a TCP connection. That setup uses a three-way handshake.

Client                                Server
  │                                       │
  │ ──── SYN (let's talk) ────────────►  │
  │                                       │
  │ ◄── SYN-ACK (sure, let's talk) ────  │
  │                                       │
  │ ──── ACK (great) ─────────────────►  │
  │                                       │
  │  ════ Connection established ════    │
  │                                       │
  │ ──── HTTP request ────────────────►  │
  │ ◄── HTTP response ─────────────────  │
  │                                       │
  │  ════ Connection closes ═════════    │

For HTTPS, after the TCP handshake there's a TLS handshake on top — exchanging certificates and agreeing on encryption keys — before any actual HTTP can flow.

This setup overhead is why HTTP/1.1 introduced "keep-alive" (reuse one connection for many requests), why HTTP/2 multiplexes many requests over one connection, and why HTTP/3 (over QUIC/UDP) skips the TCP handshake altogether to cut latency further.

Everything in the request lifecycle ultimately rests on this foundation. The next time someone says "the API is slow," the actual culprit might be DNS, TLS handshakes, packet loss, or a far-away server — long before the application code even starts running.