01 — Internet Anatomy: How the Pieces Fit Together

"The internet is a cloud" was the closest I had to a model, and a cloud explains nothing. The model that finally stuck: the internet is a stack of layers, each with one job. Once I could see the layers separately, most "the internet is broken" moments turned into a question of _which layer_, not _what on earth is going on_.

Here's the whole stack — unfolded into two sides (your browser on the left, the server on the right) so you can see who's who and how a request actually flows between them, before I walk through it one layer at a time:

The browser: the client

The top layer is the one I actually work in — the browser, the client that takes the HTML the server sent and renders it into something a human can see and click [7]. DOM, layout, paint, the rendering pipeline all live here. That pipeline is a topic of its own; the point for these notes is just that the browser is one layer of the stack, not the whole picture — and to render anything, it first has to fetch it. The next layer down is the conversation it holds to do that.

HTTP: the conversation

That conversation is HTTP — a simple, line-by-line protocol of requests and responses between browser and server [5]. A request carries a method (the verb — GET to fetch, POST to submit, PUT/PATCH/DELETE to change or remove) and a path; a response starts with a status code. Two details worth knowing: HTTP is stateless, so each request stands alone and the server remembers nothing between them — cookies and sessions are the workarounds bolted on top — and it has versions. HTTP/1.1 is the legacy one; HTTP/2 and HTTP/3 pack many requests over a single connection for real speed gains. The entire web runs on this one exchange, billions of times a second.

Since the server forgets everything between requests, the two workarounds differ by _where the state lives_:

• Cookies are stored on the client — small key–value blobs the server hands to the browser, which echoes them back on every later request. The state travels with the request, so anyone can read (and edit) it.
• Sessions are stored on the server — the real state stays there, and the browser only carries a session ID (itself a cookie). The client holds a pointer, not the data.

So a cookie is data I can actually open in the browser; a session is memory only the server can see, reachable through an ID the browser carries around. Cookies are the transport, sessions are the server-side memory.

One thing I had to straighten out: HTTPS isn't a different protocol. It's the same HTTP conversation wrapped in an encryption layer (TLS), so nobody between browser and server can read or alter it [6]. The padlock icon in the address bar just means "this conversation is encrypted." But every conversation needs two parties, and the browser is only one of them — the other end is a machine that holds the actual files a website is made of: the HTML, the CSS, the images, the JavaScript.

Hosting: where a site actually lives

The other party in every request is a server — an ordinary computer in a rack somewhere, holding the site's files [4]. "Hosting" is just renting space on one of these machines.

This is the layer that dissolved the cloud metaphor for me. _There is no cloud._ A website lives on a specific physical box, in a specific data center, run by a specific company. The monthly hosting bill is rent on a slice of that box plus its always-on connection to the network.

The common flavors are all the same layer, with one trade-off — cost versus how much of the machine I'm willing to manage myself. The real dividing line is isolation and control: who else shares my machine, and how much of it am I allowed to touch.

• Shared hosting — my site shares a box, its operating system, and its resources (RAM, CPU) with hundreds of others. I can only upload files; I can't install software or change server settings. Cheap and hands-off, but if a neighbor gets a traffic spike, my site slows down with theirs.
• VPS — the physical box is sliced by virtualization into isolated virtual machines, each with its own OS, guaranteed resources, and root access. I still share the hardware, but my slice is mine to configure, install into, and reboot — a private room in a shared building. (Shared vs VPS comes down to this: shared is renting a bed in a dorm, VPS is renting a locked apartment in the same block.)
• Dedicated — the whole physical box is mine, no neighbors at all. Maximum control and predictable performance, at maximum price and maximum responsibility.
• Serverless / edge — I stop thinking about the box entirely; the provider runs my code on machines near each user, and I pay per use. The least control over the machine, but the least to manage — no server to keep patched, and it scales on its own.

But there are millions of these boxes. How does the browser know which one to talk to? Not by number — by name. Naming is the next layer down.

Naming: domains and DNS

I can't remember 142.250.191.78. I can remember aveshina.my.id. So there's a layer whose only job is translating names into numbers. That's DNS — the Domain Name System, a distributed phonebook consulted in milliseconds before every connection [2]. "Distributed" is doing real work in that sentence: there's no single phonebook. A lookup fans out through a hierarchy — my recursive resolver (usually my ISP's, or a public one like Cloudflare's) asks a root nameserver where .id lives, which points to a TLD nameserver, which points to the authoritative nameserver for aveshina.my.id that actually holds the answer. Each level gets cached, so most lookups never make the full trip [3].

Here's that hierarchy as a step-by-step, for aveshina.my.id:

1. Browser checks its own memory first — the browser cache, then the operating system's hosts file. If the name is already cached and not expired, it's done before the network is even touched.
2. Ask the recursive resolver. If nothing's cached, the browser asks a recursive resolver — my ISP's, or a public one like Cloudflare's 1.1.1.1. The resolver does the walking on my behalf, and it has a cache too.
3. Resolver → root nameserver. The resolver starts at the top and asks a root nameserver where .id lives. The root doesn't know the IP — it only points to the TLD nameserver that handles .id.
4. Resolver → TLD nameserver. The resolver asks the .id nameserver where aveshina.my.id lives. Again, no answer — it points to the authoritative nameserver for the domain.
5. Resolver → authoritative nameserver. This is the one that actually holds the answer. It returns the IP (76.76.21.21).
6. The resolver hands the IP back to the browser and caches the result at each level, stamped with a time-to-live (TTL), so the next lookup skips most of the trip.
7. The browser connects to that IP for the rest of the conversation.

It's directly observable. On any machine with a terminal:

dig +short aveshina.my.id

76.76.21.21

Type a name, get a number, and the browser then talks to that number for the rest of the conversation. When a site won't load but my Wi-Fi is fine, this is now my first suspect.

A domain name itself has parts, and they're owned by different entities:

• aveshina — the second-level domain, the part I registered and pay for.
• .my.id — the top-level domain, run by a country registry.
• blog. — a subdomain, which I control for free because I own the parent.

That's why I never bought a separate "blog domain" — a subdomain record costs nothing. And once DNS hands back a number, the real work begins: getting the data to that number. That's the bottom layer.

The network: cables, routers, and one shared agreement

The bottom layer is plumbing — physical cables (including the undersea ones), routers, and TCP/IP, the protocol every network agreed to speak so they could hand data to each other. The word _internet_ literally means _inter-network_ [1].

Two ideas from this layer underpin everything above:

• Packets. Data doesn't travel as a stream. It's split into small, self-addressed packets that get routed independently and reassembled at the destination. A single image is dozens of packets, possibly arriving out of order.
• IP addresses. Every device gets a number — 142.250.191.78, say — that routers use to forward packets in roughly the right direction.
• ISPs. My own machine isn't on this network directly — I buy access from an Internet Service Provider, the on-ramp connecting my home network to the rest of the inter-network. Everyone reaches the internet through some ISP; that's the "last mile" of the plumbing.

The part that clicked for me: the network moves things by number. Every layer above — names, servers, HTTP, the browser — is just a convenience bolted on top of that.

How I use this

The practical payoff of the stack is diagnostic. When something breaks, I ask _which layer_:

• Site won't load, Wi-Fi fine → probably DNS.
• Works locally, fails in production → often the server, or an HTTP/CORS gate.
• Slow from the other side of the world → hosting — my box sits in one city, and packets take their time getting there. (CDNs and "edge" exist precisely to fix this.)
• Blank page, but the file arrived → browser — my code threw.

That single habit — naming the layer before reaching for a fix — is the whole reason I wrote these notes down. The internet isn't one thing, and most of debugging it is simply remembering that.

References

[1] cs.fyi, "How does the Internet work?," 2020. [Online]. Available: https://cs.fyi/guide/how-does-internet-work

[2] Cloudflare, "What is DNS?," 2024. [Online]. Available: https://www.cloudflare.com/en-gb/learning/dns/what-is-dns/

[3] "How DNS works," howdns.works. [Online]. Available: https://howdns.works/

[4] Namecheap, "What is web hosting?," 2023. [Online]. Available: https://www.namecheap.com/hosting/what-is-web-hosting-definition/

[5] Cloudflare, "What is HTTP?," 2024. [Online]. Available: https://www.cloudflare.com/en-gb/learning/ddos/glossary/hypertext-transfer-protocol-http/

[6] "How HTTPS works," howhttps.works. [Online]. Available: https://howhttps.works/

[7] Mozilla, "Populating the page: how browsers work," MDN Web Docs, 2024. [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work