How a Request Travels the Internet

The problem

It's the first night Adda is live. It runs on Ria's laptop, tucked under her desk in a Dhaka apartment, and it has exactly one user: her friend Fahim. He types adda.com into his phone, hits Enter, and a quarter of a second later the page is staring back at him. "Feels instant," he texts. "Like flipping a light switch."

But nothing about it was instant, and nothing was direct. Fahim's request was chopped into pieces, handed a numeric address, routed through a dozen machines neither of them will ever see, answered by Ria's laptop, and reassembled on his screen — all before he could blink. Ria knows that soon Adda will need to be fast for people much farther away than Fahim. To make that journey fast, she first has to see it.

A first attempt

Ria's naive mental model, the one most people carry: Fahim's phone has a wire that runs straight to her laptop, and the whole page travels down it in one gulp.

That falls apart the moment she asks three questions. Which wire? There is no dedicated cable from Fahim's phone to Adda — or to every other site on Earth. What address? "adda.com" is a name for humans; the network only moves numbers. And what if the page is 2 MB but a single network frame carries only ~1,500 bytes? A single, direct, whole-page transfer is a fiction. The real internet is a mesh of independent hops, and Fahim's data is split into thousands of small packets that each find their own way.

The insight

The internet works because nobody tries to solve the whole problem at once. It is built in layers, and each layer only worries about one job and trusts the layer below it.

• Names → numbers. DNS turns adda.com into an IP like 203.0.113.42.
• A reliable stream. TCP takes Fahim's byte stream, cuts it into packets, numbers them, and guarantees they arrive in order — retransmitting anything lost.
• Routing. IP moves each packet hop-by-hop toward Ria's laptop, no single hop knowing the full path.
• Meaning. HTTP rides on top and says what Fahim actually wants: "GET me the Adda home page."

Peel the layers and the magic disappears. What is left is a chain of small, boring, reliable steps — and every one of them is something Ria can later measure, cache, or move closer to the user.

How it works

Here is Fahim's tap, step by step:

The whole trip in one picture:

The numbers

A rough budget for Fahim loading Adda while both he and the laptop are in Dhaka:

• DNS lookup: ~20–120 ms (0 ms once his phone has it cached).
• TCP handshake: 1 round trip ≈ 5–30 ms locally, ~150 ms if the server were on another continent.
• TLS handshake: +1 round trip (TLS 1.3), so roughly another 5–30 ms.
• First byte of HTML: after the request round trip, ~50 ms more.
• Speed of light floor: light in fiber travels ~200,000 km/s, so a Dhaka ↔ London round trip (~8,000 km) can never beat ~80 ms — no amount of money buys past physics.

Notice how much of the budget is round trips, not data volume. That single distinction drives Adda's whole networking story: when Fahim's cousin in Canada complains later, it won't be because Adda's pages are big — it'll be because every round trip has to cross an ocean.

Practice

Recap

• A request is not a direct transfer — it is layers (DNS, TCP/IP, TLS, HTTP), each doing one small job.
• Data travels as packets that route hop-by-hop; TCP makes that unreliable mesh look like a clean, ordered stream.
• The cost of a page load is dominated by round trips and distance, not raw bandwidth — the fact that shapes everything Adda does next.