Please, and Thank You.

At the end of Zero, One, Glory, your message arrived. Bits, correctly reassembled, sitting on a server somewhere. And here is the thing that piece deliberately left hanging: a pile of correctly-ordered bits is not a webpage. It's not a padlock icon your grandmother trusts without thinking about it. It's not "the cloud." It's just bits, patiently waiting to be told what to do next.

What happens next takes about a quarter of a second, involves at least three separate systems that have never met and don't trust each other by default, and ends with you looking at a page and feeling nothing, because the entire miracle is specifically engineered to feel like nothing. That invisibility is the actual achievement. Let's make it visible once.

The politest conversation on Earth

Once two computers have done the TCP handshake from Part One — the SYN, SYN-ACK, ACK ritual that just confirms both sides are listening — they still haven't said anything real. What they say next is governed by HTTP, the Hypertext Transfer Protocol, and it is, structurally, one of the most old-fashioned, formal exchanges in modern life. Your browser doesn't just grab a page. It sends a small, polite, extremely literal request that says, roughly: GET this specific document, please, over version 1.1 of our shared protocol, and here is who I am and what formats I can accept. The server, if it's willing, replies with a status line before it sends anything else — a three-digit number that is, functionally, the server clearing its throat before it hands you the goods.

You already know some of these numbers by feel, even if you've never seen them written down. 200 means here you go, everything's fine. 404 means I have genuinely never heard of that page. 301 means that moved, permanently, go over there instead — the same courteous forwarding note your mail carrier leaves. There's even an official, honest-to-RFC status code, 418, that means I am a teapot — written into an April Fools' joke protocol spec in 1998 for coffee pots that refuse to brew tea, and never removed, because enough engineers found it too good to delete. It still works on servers that bother to implement it. The internet has a sense of humor buried in its plumbing, on purpose, left there for anyone curious enough to look.

Finding the house before you knock

Before any of that request can be sent, your browser has to resolve the actual address — and Part One only sketched this. Here's the full chain. Your browser first checks its own memory: have I looked this up in the last few minutes? If not, it asks your operating system, which keeps its own small cache. If neither knows, the request goes out to a recursive resolver — usually run by your ISP or a public service like 1.1.1.1 — which then does something almost bureaucratic in its thoroughness: it asks one of the internet's 13 root server addresses (A through M — though "13" is a historical fiction; those 13 addresses are mirrored across hundreds of physical machines worldwide via a trick called anycast, so you're never actually calling all the way to one lonely building) where to find .com. The root server doesn't know your site's address. It just knows who's in charge of .com, and points there. That .com registry, in turn, doesn't know your site either — it just knows which specific server holds the authoritative answer, and points there. Only that last server actually knows the number.

Four questions, potentially four different organizations, to convert a name into an address — and the entire chain typically finishes in under 100 milliseconds, because the answers get cached at every layer and reused by millions of other requests happening at the same moment.

The part where two strangers learn to trust each other

Here's where it gets genuinely clever, and it's worth understanding because it quietly solves a problem the earliest internet didn't solve at all. Through most of the 1990s, HTTP traffic — including passwords and, yes, credit card numbers — traveled in plain text. Anyone with access to the right router, or later, anyone on the same public WiFi, could simply read it. In 2010, a security researcher named Eric Butler released a browser extension called Firesheep that made this concrete and uncomfortable: sit in a coffee shop, click a button, and calmly hijack the Facebook or Twitter sessions of everyone else on the WiFi, because their login cookies were sailing across the air unencrypted. It wasn't subtle, and it wasn't hard. That's the failure HTTPS — the padlock icon — exists to close.

The trick behind it, public-key cryptography, sounds impossible the first time you hear it and is worth sitting with the same way Part One's "just two symbols" fact was. Imagine an open padlock that anyone in the world is allowed to copy and use to lock a box — but only one specific key, held by one specific person, can ever open a box that padlock closed. Your browser asks the server for a copy of that open padlock (its public key), locks a secret inside a box with it, and sends the box across the open internet in full view of every router along the way. It doesn't matter that everyone can see the locked box. Only the server's private key — which never leaves the server, never gets transmitted anywhere — can open it. The two sides use that exchange to agree on a shared secret, and from that point on, they switch to a faster shared-key cipher for the rest of the conversation.

Netscape shipped the first working version of this, SSL 2.0, in 1995 — a patch, not a redesign, bolted onto a web that had already been running naked for years. It took until the mid-2010s, and a coordinated push by browser makers to start flagging plain HTTP sites as "Not Secure," for encryption to become the assumed default instead of the exception. Modern TLS, the protocol's current name, has gotten fast enough that this entire handshake — server proves who it is, both sides agree on a shared secret — typically adds one extra round trip, and under some conditions, none at all.

The cloud is a building

Last piece: where is that server, actually? "The cloud" is one of the more successful pieces of marketing language in tech history, precisely because it describes nothing that exists. There is no cloud. There is a building — usually several buildings, in a handful of specific counties in Virginia, Iowa, and Oregon that host a wildly disproportionate share of the internet's American infrastructure — full of racks of ordinary computers, humming, humidity-controlled, and metered by the hour. When a company says its app "runs in the cloud," it means: we rent time on someone else's computer, in someone else's building, and we call the arrangement something weightless so nobody pictures a warehouse.

And that building is very often not the one your request actually reaches. Most large sites use a content delivery network — Cloudflare, Akamai, Amazon's CloudFront — which keeps copies of the site's content cached on servers physically scattered across a hundred-plus countries. When you request a page, you're frequently not crossing an ocean to reach the "real" server at all; you're being routed to whichever cached copy is nearest to you, sometimes a few miles away, specifically so that the light doesn't have to make the whole trip. The quarter-second you experience as instant is, in large part, the industry quietly refusing to send your request as far as it could.

Where that leaves you

So: DNS finds the house. TCP knocks and gets an answer. TLS makes sure the house is who it claims to be, using a padlock that only works one direction. HTTP asks, politely, for a specific document, and receives it, or is told plainly that it doesn't exist, or is redirected somewhere else with a note explaining why. None of the machines involved know each other, trust each other by default, or have ever spoken before this exact request — and all four of them get it right, in that order, in a quarter of a second, so routinely that "the internet is down" is treated as news.

Two symbols, a very old idea about not reserving a single path, and a padlock that only works one direction. That's the whole trick, stacked three layers deep. It has never once, in your entire life, made you wait long enough to notice it was a trick at all.

Sources and further reading

Technical background draws on RFC 2616 and RFC 9110 (HTTP semantics), RFC 2324 (the 1998 April Fools' "Hyper Text Coffee Pot Control Protocol," source of status code 418), public documentation on the DNS root server system and anycast routing, Netscape's SSL 2.0 specification (1995), and public writeups of Eric Butler's Firesheep tool (2010). Data-center and CDN detail follows public infrastructure disclosures from major cloud and CDN providers. Timing figures in the final chart are illustrative composites of typical published benchmarks, not a measurement of any specific request.