How the Internet Works

1The core idea#

The internet is not one thing. It is millions of independent networks that agreed to speak the same language so they can forward each other's traffic.

• No central owner, no master switch.
• Your home router, your ISP, a backbone carrier overseas, and the rack hosting this page are all separate networks cooperating.

The mental model I give juniors: a postal system for very small envelopes.

• Each envelope (a packet) has a destination address written on it.
• Nobody along the route knows the whole path. Each post office (a router) looks at the address and forwards the envelope one hop closer.
• If an envelope gets lost, somebody notices and sends another copy.
• A single web page might be thousands of these envelopes, each taking its own route and arriving out of order.

Two ideas make the whole thing work.

• Addressing. Every machine has an IP address, like 142.250.72.78. That is how packets know where to go. IPv4 gives you about 4.3 billion addresses, which is exactly why NAT and IPv6 exist.
• Layering. The system splits into layers that each do one job and hide the layer below. Your app talks HTTP, which rides on TCP, which rides on IP, which rides on actual wires and radio. Each layer trusts the one beneath it to deliver.

2How it works#

I will trace one real request: you type example.com and hit enter. I keep a running latency budget so you can see where the time actually goes, assuming a server 80 ms away.

Step 1: DNS resolution. Turn the human name into a number.

• example.com is a name for humans. The network needs the IP.
• Your machine asks a DNS resolver "what is the IP for example.com?"
• On a cache miss the resolver walks the hierarchy: root servers point to the .com servers, which point to example.com's authoritative server, which returns something like 93.184.216.34.
• First time: 20 to 120 ms. After that: near zero, because the answer is cached for its TTL (say 300 seconds).
• Running budget: about 50 ms on a miss, roughly 0 ms on a hit.

Step 2: TCP connection. Open a reliable pipe before any data moves.

• Your machine opens a connection to that IP on port 443 (HTTPS).
• TCP does a three-way handshake: SYN, SYN-ACK, ACK. That is one full round trip before real data.
• A server 80 ms away means the handshake alone costs 80 ms.
• Running budget: about 130 ms.

Step 3: TLS handshake. Agree on keys and verify the server.

• For HTTPS, another negotiation agrees on encryption keys and checks the server's certificate.
• TLS 1.3 needs one round trip, so another 80 ms.
• The older TLS 1.2 needed two round trips, which is one reason 1.3 is worth the upgrade.
• Running budget: about 210 ms, and no HTML has moved yet.

Step 4: The HTTP request. Finally ask for the page.

• Your browser sends GET / with some headers.
• The server processes it and streams back the response: status code, headers, then the HTML body.
• Say 20 ms of server work plus one more 80 ms round trip for the request and first byte.
• Running budget: about 310 ms to first byte, and we have not even fetched the CSS yet.

Step 5: Packets and routing. How the bytes actually get there.

• All of the above is chopped into IP packets.
• Each packet hops through routers using BGP, the protocol that lets networks advertise "to reach these addresses, send traffic through me."
• No single router knows the whole path.
• TCP reassembles packets in order and asks for retransmits when something drops.

Here is the same journey as a flow of hops, which is the picture I actually draw on the whiteboard:

The thing to internalize: a page load is rarely one request.

• It is a DNS lookup, then dozens of HTTP requests for CSS, JS, images, and API calls, often to different domains.
• If that first 310 ms is just the HTML, and the page then pulls 40 more resources, latency compounds fast.
• This is why we obsess over cutting round trips with connection reuse, CDNs, and fewer domains.

3Worked example: why an Asia user waits 1.2 seconds#

Real numbers on a case I see constantly. Your servers sit in Virginia (us-east-1). A user in Singapore loads your page. Singapore to Virginia is roughly 230 ms one way over real fiber paths, so call it a 230 ms round trip.

Count the round trips before the first byte of HTML:

• DNS on a cache miss: 1 round trip to a nearby resolver, maybe 40 ms. Resolvers are usually close, so this one is cheap.
• TCP handshake: 1 round trip to Virginia, 230 ms.
• TLS 1.3 handshake: 1 round trip to Virginia, 230 ms.
• HTTP request and first byte: 1 round trip to Virginia plus 20 ms server work, 250 ms.

The lesson an interviewer wants:

• No amount of CPU on the Virginia box fixes this. The bottleneck is the speed of light.
• Put a CDN point of presence in Singapore and the TCP and TLS handshakes now terminate about 5 ms away instead of 230 ms away.
• The same page drops under 200 ms for cached assets, because you cut three 230 ms round trips down to three 5 ms round trips.
• That single move, getting the bytes closer, is worth more than a year of server tuning.

You are not buying speed. You are buying back round trips.

4Trade-offs#

The internet gives you reach and interoperability. What you give up is control and predictability: you do not own the path your packets take, and that path changes.

A few decisions come up constantly in design:

The one I probe most: TCP versus UDP.

• Weak candidates say "TCP is reliable so always use TCP."
• Strong candidates know reliability is not free. TCP's ordering guarantee causes head-of-line blocking: one lost packet stalls everything behind it, even packets that already arrived.
• For a live stream, waiting on a retransmit is worse than skipping a frame.
• That is exactly why QUIC and HTTP/3 were built on UDP and rebuild just the reliability they need, per stream, so one lost packet does not stall the others.

The other real trade-off: every round trip costs you.

• The speed of light is fixed. New York to London is roughly 28 ms one way in fiber, and real paths are slower because routes are not straight lines.
• A handshake that needs three round trips is 170 ms gone before any data moves, no matter how fast your server is.
• This is why connection reuse, CDNs near the user, and TLS 1.3 matter so much.

5Where it is used#

This is not abstract. These mechanics drive concrete design choices.

CDNs. Move the bytes closer.

• A static asset host puts copies of your files in hundreds of locations worldwide.
• The whole point is to cut the physical distance so the round trips are short, exactly like the Singapore example above.
• When you say "use a CDN" in an interview, you are really saying "move the bytes closer to reduce latency and offload the origin."

DNS-based load balancing and failover. Steer traffic by changing the answer.

• Big sites return different IPs based on your location or server health.
• If a data center dies, they change the DNS answer and traffic shifts.
• The TTL decides how fast that failover happens: a 60 second TTL means clients recover in about a minute, a 3600 second TTL means some clients stay broken for an hour.

API clients and connection pooling. Stop paying the handshake tax.

• Any backend calling another service over HTTP should reuse connections.
• A service doing 10,000 requests per second that opens a fresh TCP and TLS connection each time burns CPU and adds 160 ms of handshake latency per call for nothing.
• Pooling is standard practice, and it is often the first thing I check when a client is mysteriously slow.

Real-time systems. Pick the transport that matches the deadline.

• Game servers, voice, and video lean on UDP because a late packet is useless.
• Chat and messaging often use WebSockets, which start as an HTTP request and then upgrade to a long-lived connection so the server can push without the client polling.

When do you reach for this knowledge? Any time the question involves latency numbers, geographic distribution, "why is this slow," or "how does the client find the right server." That is most of them.

6Common pitfalls and gotchas#

Forgetting DNS is a dependency.

• DNS is a system that can be slow, cached wrong, or down.
• I have seen outages where the app was fine but the DNS provider was not, so nobody could resolve the name.
• In a design, DNS is a box that can fail like any other.

Ignoring the handshake cost.

• Candidates design a chatty client that makes 50 sequential calls and never mentions that each one might pay connection setup.
• Batch requests, reuse connections, or move logic server-side.

Confusing bandwidth with latency.

• Bandwidth is how wide the pipe is. Latency is how long one trip takes.
• Adding bandwidth does nothing for a request that is slow because of distance and round trips.
• A fat pipe does not make light travel faster. A 10 Gbps link to Singapore still has a 230 ms round trip.

Assuming the network is reliable.

• Packets drop, connections reset, DNS goes stale.
• The famous fallacies of distributed computing start with "the network is reliable" precisely because engineers keep assuming it.
• Design for retries, timeouts, and partial failure.

Treating a page load as one request.

• It is dozens. Each third-party domain adds its own DNS and TLS.
• This is why too many trackers wreck load time: five analytics scripts can mean five extra DNS plus TLS handshakes.

Mixing up public and private addressing.

• Behind your home router, devices share one public IP via NAT.
• This trips people up when they wonder how two different homes can both use 192.168.1.5.
• Those are private addresses, not reachable from the outside.

7How it shows up in interviews#

Interviewers rarely ask "explain the internet" outright. It leaks into everything else. Here is what I am actually listening for, with weak and strong answers side by side.

"Walk me through what happens when a user loads your site."

• Weak: "The request hits my load balancer, which sends it to a web server." Jumps straight to your own boxes and skips the entire journey.
• Strong: "First a DNS lookup resolves the name, maybe 40 ms on a cache miss. Then a TCP handshake, one round trip. Then TLS 1.3, one more round trip. Only then does the GET go out and the server responds. So before my code runs the user has already paid two or three round trips, which is why I care where the server sits relative to them."

"Your API is slow for users in Asia, your servers are in Virginia, why?"

• Weak: "Add more servers." More CPU in the wrong place does nothing.
• Strong: "This is physical distance. Singapore to Virginia is a 230 ms round trip, and we pay it three or four times on connection setup, so roughly 750 ms before the first byte. I would put a CDN POP in Asia so the handshakes terminate 5 ms away, reuse connections, and use TLS 1.3 to drop a round trip."

"How would the client know which server to talk to if one region fails?"

• Weak: "It retries the other region." Does not say how the client even learns the new address.
• Strong: "DNS-based routing with health checks. If Virginia fails, we pull it from the DNS answer and traffic shifts. But the TTL is the catch: a long TTL means stale answers linger and some clients stay pointed at the dead region, so I would keep the TTL around 60 seconds and accept the extra DNS traffic."

"Would you use TCP or UDP here?"

• Weak: "TCP, it's reliable." A reflex, not a decision.
• Strong: "Depends on the workload. For a live video feed I pick UDP, because head-of-line blocking means one lost packet would stall every frame behind it, and a dropped frame beats a frozen stream. For a bank transfer I pick TCP, because I need ordering and guaranteed delivery and a missing byte is unacceptable."

The pattern across all of these: interviewers reward people who reason from first principles about addressing, round trips, caching, and failure, instead of reciting box names. You do not need every TCP flag. You need to show you understand that the network has cost and can fail, and that good designs plan around both. One last tip: when you say a number, say it with a unit and a rough reason. "DNS adds maybe 20 to 100 ms on a cache miss" lands far better than "DNS is slow." Specificity signals you have actually felt this stuff in production.

Next up, try the System Design Question walkthrough on designing a URL shortener, where DNS, caching, and redirect latency all come together in one problem.