--- title: "01 — Internet Anatomy: How the Pieces Fit Together" uid: internet-anatomy tags: ["dns", "networking", "internet", "hosting", "roadmap:frontend", "fundamentals"] excerpt: "The internet is a stack of layers, each with one job. See the layers separately and most 'the internet is broken' moments become a question of which layer, not what on earth is going on." date: 2026-08-11T16:15:32+0000 source: https://www.aveshina.my.id/en/blog/internet-anatomy --- "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: ```figure YOU — your machine the client side shared plumbing consulted by both sides SERVER — a rented box where the site lives Browser renders what comes back DNS name → number Server app holds the site files HTTP request / response lines HTTP answers in the same format ① what's the IP? ② here's the IP Cables, routers & TCP/IP — packets routed by IP ③ request ▸ GET / ④ ◂ response · HTML ``` ## 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: ```figure blog. aveshina .my.id subdomain second-level domain top-level domain free — I control it the part I registered managed by a registry ``` - 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](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/](https://www.cloudflare.com/en-gb/learning/dns/what-is-dns/) [3] "How DNS works," howdns.works. [Online]. Available: [https://howdns.works/](https://howdns.works/) [4] Namecheap, "What is web hosting?," 2023. [Online]. Available: [https://www.namecheap.com/hosting/what-is-web-hosting-definition/](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/](https://www.cloudflare.com/en-gb/learning/ddos/glossary/hypertext-transfer-protocol-http/) [6] "How HTTPS works," howhttps.works. [Online]. Available: [https://howhttps.works/](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](https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work) ```quiz Q: What translates a domain name into an IP address? - DNS - HTTP - TCP correct: 0 explain: DNS — the Domain Name System — is the distributed phonebook that resolves names to numbers. Q: How does data actually travel across the network? - As one continuous stream - As small, independently routed packets correct: 1 explain: Data is split into packets that may take different routes and arrive out of order, then get reassembled at the destination. Q: HTTP is ______ — each request stands alone and the server remembers nothing between them. - stateless - stateful correct: 0 explain: HTTP is stateless. Cookies and sessions are the workarounds bolted on top to fake persistence. Q: In the DNS lookup chain, which server actually holds the answer for your specific domain? - The recursive resolver - The root nameserver - The authoritative nameserver correct: 2 explain: The resolver, root, and TLD servers only point the way — the authoritative nameserver for the domain is the one with the real answer. Q: "There is no cloud." A website actually lives on… - a specific physical server in a data center - a distributed global cloud with no physical location correct: 0 explain: Hosting is renting a slice of a specific machine plus its always-on connection to the network below. ```