How the Internet Works: DNS, HTTP, Servers, Browsers

Typing a URL kicks off a journey you can actually follow

You type an address, hit enter, a page appears. It feels instant and opaque, and because it's opaque, "the internet" stays a vague cloud in your head — which makes everything built on it (websites, APIs, security, why things break) vague too. But the journey from enter to page is a definite sequence of steps, each one understandable, and following it once turns the cloud into plumbing you can reason about.

The core idea to hold onto: the internet is just computers sending messages to other computers. Your device (the client) asks another computer (the server) for something; the server sends it back. Everything else — DNS, HTTP, IP addresses — is the machinery that makes "ask that specific computer for that specific thing, reliably, across the world" actually work. Let's trace one request.

What you'll have at the end

• The client–server model that underpins everything online
• What DNS, IP, HTTP and a server each do, in the order they happen
• A step-by-step trace you could explain to someone else

The one big idea: client and server

Almost everything you do online is this: a client (your browser, your app) sends a request to a server (a computer, somewhere, that's always on and waiting to answer), and the server sends back a response.

• A server is not a special mystical box — it's just a computer whose job is to wait for requests and answer them. "The website" lives on a server; when you visit, your browser asks that server for the page.
• Your browser is a client — a program whose job is to make requests and display what comes back.

Hold that shape (ask → answer) and the rest is detail about how the ask finds its way there.

You typed a name like example.com. But computers don't route by names; they route by IP addresses — numeric addresses like 93.184.216.34 that identify a specific machine on the network (like a phone number for a computer). So the first job is translating the human name into the machine number.

That's DNS (the Domain Name System) — the internet's phonebook. Your device asks a DNS server, "what's the IP address for example.com?", and gets back the number. (The answer gets cached for a while, so it's not looked up every single time.) Names exist purely for humans; DNS quietly converts them to the numbers the network actually uses.

Now your device has the server's IP address and sends its request there. Two ideas make this work across the whole planet:

• Packets. Your request (and the response) is broken into small chunks called packets, each labelled with where it's going and where it's from. They travel independently and get reassembled at the other end. Breaking messages into packets is what lets a shared network carry everyone's traffic at once.
• Routers. The packets hop across many routers — signpost machines that each pass a packet one step closer to its destination, like a parcel moving through sorting centres. No single wire connects you to the server; the packets are relayed, hop by hop, to the right IP.

A protocol called TCP oversees this: it makes sure all the packets arrive, in order, and re-sends any that got lost — turning an unreliable hop-by-hop network into a reliable "the whole message got there" channel.

Now that there's a connection to the server, your browser makes its actual request in a language both sides speak: HTTP (HyperText Transfer Protocol). An HTTP request basically says "GET me the page at this path." The server reads it, finds (or builds) what was asked for, and sends an HTTP response back containing the content.

You'll meet status codes in the response — a number saying how it went:

• 200 — OK, here it is.
• 404 — not found (that page doesn't exist).
• 500 — the server hit an error.
• 301/302 — moved, go here instead.

These are worth knowing because they're exactly what you see when something breaks, and they tell you whose problem it is (your URL vs the server).

HTTPS is HTTP with encryption: the S means the conversation is scrambled so anyone in between can't read or tamper with it (the padlock in the address bar). It's why you never send a password over plain HTTP — more in TC-11.

The server's response is usually HTML — the page's structure and text (TC-09) — often with CSS (how it looks) and JavaScript (behaviour) alongside. Your browser:

1. Reads the HTML and builds the page structure.
2. Fetches the extra pieces it references — CSS, images, scripts, fonts — each of which is another request to a server (a single page can be dozens of requests).
3. Applies the CSS (layout, colours) and runs the JavaScript (interactivity).
4. Paints the finished page on your screen.

All of that — the DNS lookup, the packets across the world, the requests and responses, the rendering — usually in a fraction of a second.

The whole trace

1. Type example.com → enter
2. DNS: "what's the IP for example.com?" → 93.184.216.34   (the phonebook)
3. Connect to that IP; request split into packets, relayed
   by routers, reliability handled by TCP
4. HTTP: browser sends "GET /"; server replies 200 + HTML
   (HTTPS = that conversation encrypted)
5. Browser reads HTML, makes more requests for CSS/JS/images,
   applies styles, runs scripts
6. Page painted on screen

That's the internet, once. Every site you visit is this loop, repeated.

What this means for you

• The internet is computers messaging computers: a client asks, a server answers. Hold that shape.
• DNS is the phonebook — turns names (example.com) into IP numbers the network routes by.
• Your message travels as packets, relayed hop-by-hop by routers; TCP makes it reliable.
• HTTP is the request/response language; status codes (200/404/500) tell you what happened and whose fault it is. HTTPS = encrypted (the padlock).
• The browser assembles the page from HTML/CSS/JS — often dozens of requests — and paints it.

Exercise (30 min, verifiable output)

1. Open your browser's developer tools (F12 / right-click → Inspect) and go to the Network tab.
2. Load a website and watch the requests appear — note how many there are for one page, and the status codes (look for a 200; try a made-up path on the site to see a 404).
3. Find one request's details: the URL, the status, whether it was HTTPS.
4. Write the full trace in your own words, from typing the URL to the page appearing, naming DNS, IP/packets, HTTP, and rendering.
5. Explain in one line each: what a server is, what DNS does, and what 404 means.

✅ Finish check: the Network tab observed for one real page (request count + a 200 and a 404 seen), and the URL-to-page trace written in your own words naming DNS, IP/packets, HTTP and rendering.

Summary card

• Client asks, server answers — the shape of everything online. A server is just a computer that waits and replies.
• DNS = phonebook: name → IP address (the number the network routes by).
• Messages travel as packets, relayed by routers; TCP makes delivery reliable.
• HTTP = the ask/answer language; status codes (200 OK, 404 not found, 500 server error) say what happened. HTTPS = encrypted.
• The browser builds the page from HTML/CSS/JS via many requests, then paints it — all in a fraction of a second.

Sources

1. Kurose, J. & Ross, K. — Computer Networking: A Top-Down Approach, 2000
2. Tanenbaum, A. — Computer Networks, 1981
3. MDN Web Docs — Learn: How the web works (reference)

Next lesson: TC-03 — The Terminal: Your First 20 Commands (L1) Related: TC-01 What a Computer Actually Does · TC-07 What an API Is · TC-11 Security Basics · DT-12 How the Algorithm Knows You Path: Ship Your First Thing — 2/7