# How the Internet Actually Works > The absolute basics of networking: what happens when you open a web page - how your request travels to a server and back, how machines find each other by address and name, and how they agree on a shared language. --- # How the Internet Actually Works You use the internet every waking hour and it feels like magic - you press Enter, and a page appears from a machine that might be on the other side of the planet. Nobody ever explained what actually happened in that half-second. This guide does. By the end, the internet feels less like magic and more like a stack of small, sensible agreements between machines - agreements you can reason about. This is the very first "A" of networking. No prior knowledge assumed. We build the picture one layer at a time. ## How to read this - **Just want the big picture fast?** Read [Phase 1: The Journey of One Request](01-the-journey-of-one-request.md) - it follows a single web page from your finger on the Enter key to the page on your screen. That one story carries most of the idea. - **Want it to truly click?** Read all three in order. Each phase answers a question the last one opened up. ## The phases 1. **[The Journey of One Request](01-the-journey-of-one-request.md)** - follow what happens when you open a web page: your device, your router, your ISP, across the internet, to a server and back. Meet *packets* - the labeled chunks data travels in. 2. **[Addresses & Names](02-addresses-and-names.md)** - every machine has an *IP address* (a number), and *DNS* turns human names like `example.com` into those numbers. Why both exist. 3. **[Client, Server & Talking the Same Language](03-client-server-and-protocols.md)** - the client/server model, and how machines agree on *protocols* (HTTP to ask for pages, carried reliably by TCP). A gentle first look at the layered model - and why none of this is magic. > This guide deliberately stays at the "what is happening, and why" level. The precise mechanics of addresses, ports, and name lookups live in [IP, DNS & Ports](/guides/ip-dns-and-ports); how a web request is actually phrased lives in [HTTP Explained](/guides/http-explained); and how the layers stack up formally lives in [The TCP/IP Model](/guides/tcp-ip-model). Read this guide first - then those, when you're ready to go deeper. --- # The Journey of One Request You type a web address and press Enter. For the next half-second, something genuinely remarkable happens - and it's completely understandable once you watch it step by step. Let's follow a single request all the way out and all the way back. We won't worry yet about *how* your device knows where the page lives, or how it phrases the request - that's the next two phases. Right now, just the shape of the journey. ## The cast of characters Meet the players first. Each has one small, specific job. ```mermaid flowchart LR device[Your device
phone, laptop] -->|request| router[Home router] router -->|request| isp[Your ISP] isp -->|request| net((The open
internet)) net -->|request| server[Server
holds the page] server -.->|answer comes back the same way| device ``` - **Your device** - the phone or laptop in your hand, wanting a web page. - **Your home router** - the box everything in your home connects to over Wi-Fi or cable. It's the on-ramp from your home to the wider internet. - **Your ISP** - your Internet Service Provider (Comcast, Vodafone, your phone carrier). They run the cables and equipment connecting your neighborhood to the rest of the world. - **The internet itself** - not one thing, but a vast mesh of cables, routers, and exchange points owned by many companies, all agreeing to pass each other's traffic along. *Internet* literally means "network of networks." - **The server** - a computer, somewhere, that holds the page and is always on, always listening, waiting to hand it out to anyone who asks. ๐Ÿ“ **Terminology.** *Server* = a computer whose job is to wait for requests and respond. *Client* = the computer making the request (yours). More on this pairing in [Phase 3: Client, Server & Talking the Same Language](03-client-server-and-protocols.md). ## The journey, step by step Read it once top to bottom - it's a single continuous motion, out and back. 1. **You press Enter.** Your device builds a request - "please send me the page at this address." 2. **It goes to your router.** Your device hands the request to your home router over Wi-Fi or cable - the only thing in your home that knows how to reach the outside world. 3. **The router passes it to your ISP.** This is the moment your request leaves your home. 4. **The ISP launches it into the internet.** It forwards your request router to router - each one a signpost pointing "the thing you're looking for is roughly *that* way" - hop by hop across the world. 5. **It arrives at the server**, after some number of hops. 6. **The server answers**, and the reply makes the same kind of journey in reverse: server, internet, your ISP, your router, your device. 7. **Your browser draws the page.** You can watch some of those hops yourself. `tracert` (it's `traceroute` on macOS and Linux) asks each router along the way to identify itself: ```console C:\> tracert example.com Tracing route to example.com [93.184.216.34] over a maximum of 30 hops: 1 2 ms 1 ms 1 ms 192.168.1.1 2 12 ms 11 ms 10 ms 10.0.0.1 3 14 ms 13 ms 14 ms ae-1.bras.example-isp.net 4 22 ms 21 ms 23 ms core1.lax.example-isp.net 5 71 ms 70 ms 72 ms edge.example.com [93.184.216.34] Trace complete. ``` *What just happened:* each numbered line is one "hop." Hop 1 (`192.168.1.1`) is your own home router; hop 2 is the first machine inside your ISP; the middle hops are routers passing your traffic across the country; the last hop is the server. The millisecond numbers are roughly the round trip to each stop - notice they climb as the stops get farther away. You're literally seeing the path your requests take. โš ๏ธ **Gotcha.** Don't read that hop list as "my data always goes through exactly these machines." The internet picks routes dynamically - if a cable is cut or a router is busy, traffic quietly takes a different path. Run `tracert` twice and you may see different hops. That flexibility is a feature: it's central to how the internet survives outages. ## Packets: data travels in labeled chunks The single most important idea in this guide: when the server sends your page back, it does **not** send one continuous stream. It chops the page into small chunks called **packets**, and sends each separately. ๐Ÿ“ **Terminology.** *Packet* = a small chunk of data with a label on front, saying where it's going, where it came from, and which piece of the whole it is (piece 3 of 17, say). Think of mailing a long book to a friend, but you can only use small envelopes. You tear the book into numbered pages, put each in its own envelope with your friend's address and yours, and drop them all in the mailbox. The envelopes travel independently - different routes, out-of-order arrival - but since each is numbered, your friend stacks them back into the original book. ```text one web page travels as many packets โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ” โ”‚ โ”‚ โ”€โ”€ chopped โ”€โ”€โ–ถ โ”‚ #1 โ”‚ โ”‚ #2 โ”‚ โ”‚ #3 โ”‚ โ”‚ #4 โ”‚ ... โ”‚ ... โ”‚ into โ””โ”€โ”€โ”€โ”€โ”˜ โ””โ”€โ”€โ”€โ”€โ”˜ โ””โ”€โ”€โ”€โ”€โ”˜ โ””โ”€โ”€โ”€โ”€โ”˜ โ”‚ a whole page โ”‚ each has a label: โ”‚ โ”‚ to: YOU โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ from: SERVER piece: 3 of 17 packets may take different paths and arrive out of order, then your device reassembles them in order by their labels: #3 #1 #4 #2 โ”€โ”€โ–ถ reassembled โ”€โ”€โ–ถ #1 #2 #3 #4 โ”€โ”€โ–ถ the page ``` Why do it this way? It makes the internet more robust and more fair: - **Resilience.** If one packet gets lost (an overwhelmed router, a cable hiccup), only that tiny piece needs resending - not the whole page. Packets flow around trouble spots independently. - **Sharing.** Millions of people's packets share the same cables. Breaking data into small chunks lets the network interleave your packets with everyone else's, instead of making you wait for one giant transfer to finish. - **Independence.** No packet needs to know the whole route in advance - each just gets passed toward its destination, hop by hop, by routers reading its label. โš ๏ธ **Gotcha.** Because packets travel independently, they can arrive out of order, and occasionally one goes missing. Left unhandled, that corrupts your page - so the fix is to *expect* it: the receiving side puts packets back in order by their numbers and asks for any missing ones to be resent. That reliability layer is **TCP**, met in [Phase 3](03-client-server-and-protocols.md). For now: data moves as labeled chunks, reassembled at the end. Once "everything is packets" is in your head, a lot of everyday computer life stops being mysterious. A video call gone choppy on bad Wi-Fi? Packets arriving late or dropped. A download that resumes after a blip instead of restarting? It only needed the packets it was missing. ## Recap 1. Opening a web page sends a **request** on a journey: your device, your home router, your ISP, across the internet, to a **server** - and the answer returns the same way. 2. The **internet is a network of networks** - many companies' equipment cooperating to pass traffic along, hop by hop, choosing routes flexibly. 3. Data doesn't travel as one big stream. It's broken into **packets** - small labeled chunks that travel independently and get **reassembled** at the destination. 4. Packets make the network **resilient** (lose one, resend one) and **fair** (everyone's chunks share the cables) - at the cost of arriving out of order, which the receiving side sorts out. Next, a question the journey left open: when you typed that web address, how did your device know *which* server, out of the millions on Earth, to send the request to? That's about addresses and names. ## See it move Step through the whole journey - the DNS lookup, the request travelling out, and the response coming back: ```playground-network ``` --- # Addresses & Names Last phase we followed a request across the internet to a server. But we skipped something: when you typed `example.com`, how did your device know which of the millions of computers on Earth to send your packets to? It comes down to two ideas working together - **addresses** and **names**. ## Every machine has an address Every device that talks on the internet has an **IP address** - a number that uniquely identifies it, the way a street address identifies a building. When a packet needs to get somewhere, its label carries the destination's IP address, and routers along the way use that number to pass it in the right direction. ๐Ÿ“ **Terminology.** *IP address* = the numeric address of a machine on a network. *IP* stands for *Internet Protocol* - the agreement defining how these addresses work and how packets route using them. You've almost certainly seen one: ```text 93 . 184 . 216 . 34 โ† four numbers, separated by dots ``` That dotted-number form is the most common style. (There's a newer, longer style with letters and colons too, built because the world started running out of short ones - but the idea is identical: a number that names a machine. Both styles are covered in [IP, DNS & Ports](/guides/ip-dns-and-ports).) A common assumption is that a website "is" a name like `example.com`, and the number is some technical alias. It's the other way around at the routing level: the network only ever moves packets using **numbers**. The name is a human convenience layered on top - routers don't know or care about `example.com`; they know `93.184.216.34`. ## Names exist because numbers are awful to remember If the network runs on numbers, why type names at all? Because humans are terrible at numbers and great at words. Imagine visiting a website meant remembering `93.184.216.34` instead of `example.com` - a different long number for every site. You'd need a notebook, and it would get worse: when a company moves its site to a new machine with a new number, every memorized number would suddenly be wrong. So the internet keeps two layers on purpose: ```text what humans use what the network routes by โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”‚ example.com โ”‚ โ”€โ”€โ”€โ”€โ”€โ”€โ–ถ โ”‚ 93.184.216.34 โ”‚ โ”‚ (a name you โ”‚ translated โ”‚ (the address โ”‚ โ”‚ can recall) โ”‚ into โ”‚ packets need) โ”‚ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ ``` ๐Ÿ“ **Terminology.** *Domain name* = the human-friendly name of a site, like `example.com` or `wikipedia.org`. It's a label that *points to* an IP address, not the address itself. The benefit is real: the name stays the same forever even when the machine behind it - and its number - changes. You keep typing `example.com`; behind the scenes the company swaps servers and the name gets pointed at the new number. Names are stable; numbers can move. ## DNS: the internet's phone book Something has to translate names into numbers. That's **DNS** - the Domain Name System, the internet's phone book. You give it a name; it gives back the number, the same way you'd look up a person's name to get their phone number - and your device needs that number *before* it can send any packets. This lookup happens automatically, in the blink before a page loads, every time you visit a site by name. You never see it, but it's the very first step of Phase 1's journey: ```mermaid sequenceDiagram participant You as Your device participant DNS as DNS (phone book) participant Server You->>DNS: What's the address for example.com? DNS-->>You: 93.184.216.34 You->>Server: send packets to 93.184.216.34 Note over You,Server: the Phase 1 journey begins ``` You can do the lookup by hand. `nslookup` asks DNS the same question your browser asks: ```console C:\> nslookup example.com Server: dns.google Address: 8.8.8.8 Non-authoritative answer: Name: example.com Address: 93.184.216.34 ``` *What just happened:* you handed DNS the name `example.com` and it handed back `93.184.216.34`. The "Server" line at top is *which* phone book you asked (here, a public DNS service at `8.8.8.8`); the "Address" at bottom is the answer - the number your packets actually go to. This is the translation step that happens silently before every page load. โš ๏ธ **Gotcha.** Because the name and the number are separate, two things can break independently, and knowing which one helps a lot. If DNS can't answer, you'll see an error like "server not found" - your device never even got an address to send to. That's different from getting an address fine but the server itself being down. Same blank page, two different causes. "Is it a name problem or a machine problem?" is the first useful question, and a quick `nslookup` answers it. Half of "the internet is down" moments are actually DNS moments: a site that loads by its raw IP but not by its name; a new domain that "isn't working yet" because the phone book hasn't caught up; a company-wide outage that's really a DNS misconfiguration. These all make sense once you hold the two layers apart. Names are looked up; numbers are routed to. ## Recap 1. Every machine on the internet has an **IP address** - a number that identifies it, the way a street address identifies a building. The network routes packets using these **numbers**. 2. We use **domain names** like `example.com` because humans remember words, not numbers - and because a name can stay stable even when the machine behind it changes. 3. **DNS** is the internet's phone book: it **translates names into numbers**, automatically, right before a page loads. 4. Names and numbers can fail independently - so "is it a name problem (DNS) or a machine problem (the server)?" is a powerful first question when something won't load. We now have a request that travels (Phase 1) and a way to find the right machine to send it to (Phase 2). One question remains: once the request *arrives*, how do the two machines actually understand each other? They have to speak the same language. --- # Client, Server & Talking the Same Language We have a request that travels (Phase 1) and a way to find the right machine (Phase 2). Last piece: when your request arrives, how do the two computers actually understand each other? They've never met, may run different software on different continents - yet they cooperate flawlessly. Not magic - *agreements*. ## The client/server model Almost everything on the internet is one machine **asking** and another **answering**. The one that asks is the **client**; the one that answers is the **server**. That's the whole pattern. ```mermaid sequenceDiagram participant Client as Client (your browser) participant Server as Server (waits, listens) Client->>Server: may I have the page at /about ? Server-->>Client: here it is: ``` ๐Ÿ“ **Terminology.** *Client* = the machine that initiates a request (your phone, your browser). *Server* = the machine that waits for requests and responds. A single computer can be both at different moments - but in any one exchange, one side asks and one side answers. It's tempting to imagine two computers in a balanced back-and-forth "conversation." It's more lopsided than that: the server doesn't reach out to you - it sits doing nothing, *waiting*, and only speaks when spoken to. Your browser starts every exchange. That's why a server can quietly serve millions of clients - it's not pursuing anyone; it's a shop with the lights on, answering whoever walks in. ## Protocols: agreeing how to talk For the asking and answering to work, both sides have to agree - in exact detail - on how a request and response are shaped. That shared agreement is a **protocol**: a rulebook for a conversation - what you're allowed to say, in what order, and what it means. Both machines follow the same rulebook, so they understand each other despite sharing nothing else. ๐Ÿ“ **Terminology.** *Protocol* = an agreed set of rules for how two machines communicate. The internet is built from many protocols, each handling one part of the job. Calling a restaurant has an unwritten protocol: they say "Hello, Mario's"; you say "I'd like to order"; they say "go ahead." Both sides follow the script and it works, even between strangers - break it (order before they pick up) and it falls apart. Machines are stricter still, because they can't improvise. The two protocols you'll meet first are **HTTP** and **TCP**, doing two different jobs. ### HTTP - the language for asking for web pages HTTP is the protocol for *web* conversations. It defines how a client asks for a page and how a server answers. The request your device built in Phase 1 was an HTTP request - roughly "GET me the page at this path" - and the server's reply was an HTTP response carrying the page plus a status (like the famous `404 Not Found`). ๐Ÿ“ **Terminology.** *HTTP* = *HyperText Transfer Protocol*, the agreement browsers and servers use to request and deliver pages. The `s` in `https` means the same thing, encrypted so others can't read it in transit. You can see HTTP's reply yourself. This asks a server for a page and prints just the response's opening lines (its headers): ```console $ curl -I https://example.com HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Content-Length: 1256 Date: Fri, 19 Jun 2026 12:00:00 GMT ``` *What just happened:* your machine spoke HTTP to `example.com`, and it answered in kind. `HTTP/1.1 200 OK` is the server saying "I understood your request, and here's a successful response" - `200` is HTTP's code for success, the happy cousin of `404`. The other lines describe what's coming back (it's HTML, 1256 bytes, dated). Both machines understood each other because both follow the HTTP rulebook. The full shape of requests and responses is [HTTP Explained](/guides/http-explained). ### TCP - the agreement that delivers it reliably HTTP describes *what* to say. But the message travels as packets, which can arrive out of order or go missing (Phase 1) - something has to make sure the whole message shows up intact. That's **TCP**. TCP turns the unreliable flurry of packets into a reliable, in-order stream: it numbers them, puts them back in order at the other end, notices any missing, and asks for those to be resent. HTTP rides *on top of* TCP - HTTP writes the message, TCP guarantees delivery. ๐Ÿ“ **Terminology.** *TCP* = *Transmission Control Protocol*, the agreement that delivers data reliably and in order, hiding the messy reality of lost and out-of-order packets. ```text HTTP "GET /about" โ† what to say (the web request) โ”‚ โ–ผ handed to TCP to deliver TCP [#1][#2][#3][#4]... โ† reliable, in-order delivery numbers the packets, resends any that get lost, reassembles them in order at the far end ``` This is one example of a bigger idea: protocols are **stacked**. Each trusts the layer below to handle its job, so each stays simple. HTTP doesn't worry about lost packets - that's TCP's problem. TCP doesn't worry about which cable the packet takes - that's the layer below *it*. The full stack, the **TCP/IP model**, is laid out in [The TCP/IP Model](/guides/tcp-ip-model). For now, the shape is what matters: simple agreements, stacked, each handling one thing. โš ๏ธ **Gotcha.** TCP makes delivery *reliable*, not *instant* or *private*. "Reliable" means "complete and in order" - not fast, and plain TCP isn't encrypted (that's what the `s` in `https` adds). Don't read "reliable" as "secure" - different promises from different layers. ## So... is the internet magic? No - and that's the reassuring part. Everything in this guide is a small, sensible agreement stacked on another: - Data travels as **packets** - labeled chunks (Phase 1). - Machines are found by **IP address**, and **DNS** translates human names into those numbers (Phase 2). - One machine asks (**client**), another answers (**server**) (this phase). - They understand each other through **protocols** - **HTTP** for the web request, carried reliably by **TCP**, riding on **IP** below it. No single piece is complicated. The internet feels like magic only because so many simple agreements run at once, invisibly, in a fraction of a second. Pull any one out and look at it, as you just did, and it's understandable. **The internet is not one incomprehensible thing. It's a lot of simple agreements, stacked up** - and every one is learnable. ## Recap 1. The internet runs on the **client/server model**: one machine asks (client), another waits and answers (server). 2. A **protocol** is a shared rulebook for a conversation - it lets machines that have never met understand each other exactly. 3. **HTTP** is the protocol for asking for and delivering web pages; **TCP** is the protocol that carries it reliably, putting packets back in order and resending lost ones. 4. Protocols are **stacked** - each layer handles one job and trusts the layer below - the heart of the **TCP/IP model**. 5. The internet isn't magic. It's many **simple agreements stacked up**, each one learnable on its own. --- [โ† Guide overview](_guide.md) ยท Next up: go deeper with [IP, DNS & Ports](/guides/ip-dns-and-ports), [HTTP Explained](/guides/http-explained), and [The TCP/IP Model](/guides/tcp-ip-model).