How Does the Internet Actually Work?

The journey of a web request, from your browser to a server and back.

I remember the first time a senior engineer told me to “just check the network tab” while we were debugging a broken API call. I opened DevTools, stared at a wall of coloured rows, and quietly closed it again. I had absolutely no idea what I was looking at.

The internet was this vast, magical thing that somehow worked. I typed a URL, a page appeared. I never asked questions.

That changed the day I had to build something that actually relied on it. Requests were failing and I didn’t know why. Headers were wrong and I didn’t know what they were. A CORS error appeared on screen and I didn’t understand what was being blocked, or who was blocking it, or why it even had a name that sounded like a 90s band.

This is the article I wish had existed back then.

Let’s start with what actually happens when you press Enter

Type https://www.google.com into your browser and press Enter. Simple action. But what follows involves at least five distinct systems, multiple protocols, and a round trip that can cross thousands of miles of physical infrastructure in under a second.

Let’s walk through every single step, in order.

Step 1: Finding Google’s address (DNS)

You typed google.com. But computers don't talk in names. They talk in numbers called IP addresses, something like 142.250.187.46. Before anything else can happen, your browser needs to translate that human-readable name into a machine-readable address.

This is the job of DNS, which stands for Domain Name System.

Think of DNS exactly like the contacts app on your phone. You search “Mum” and your phone finds the actual number +44 7700 900123. You never had to remember the number. DNS does the same thing for websites.

Here is the chain of lookups that happens:

1. Your browser checks its own cache first. “Have I visited this before? Do I already know the IP?”
2. If not, it asks your operating system, which checks its own cache.
3. If still nothing, your OS asks a DNS resolver. This is usually run by your internet provider, or a public one like Google (8.8.8.8) or Cloudflare (1.1.1.1).
4. The resolver then works through a hierarchy. It asks a root nameserver, which points to a .com nameserver, which points to Google's own nameserver, which finally hands back the actual IP address.

All of that typically takes under 20 milliseconds.

Try it yourself

Open your terminal and run this:

nslookup google.com

You should see something like:

Server:   8.8.8.8
Address:  8.8.8.8#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.187.46

That address at the bottom is what your browser actually uses to connect. You just watched DNS work in real time.

Want to see how many hops it takes to reach Google from your machine? Try this:

traceroute google.com

On Windows it is tracert google.com. You will see every router your request passes through, with the time each hop takes in milliseconds. It is one of those moments where the physical reality of the internet suddenly becomes visible.

Step 2: Knocking on the door (TCP handshake)

Your browser now knows where Google lives. But it still needs to check that the other side is ready to talk before sending anything.

This is done through TCP, the Transmission Control Protocol. Before a single byte of your actual request is sent, your browser and the server perform a three-step exchange:

1. SYN — your browser sends a signal: “I want to connect.”
2. SYN-ACK — the server replies: “Got it. I’m ready.”
3. ACK — your browser confirms: “Great. Let’s go.”

This is the TCP three-way handshake. It exists to make sure both sides are present and ready before real data starts flowing. It is a courtesy knock rather than just blasting data into the void and hoping something receives it.

For HTTPS connections, which is almost every website now, there is an additional step called the TLS handshake. This is where encryption gets set up. Both sides agree on how to scramble the data, exchange certificates to prove who they are, and create a shared secret key. After this, everything sent between your browser and the server is encrypted. Your internet provider can see you visited Google, but cannot read what you searched for.

A simple analogy that actually helps

Imagine you are calling someone on the phone.

You dial and it rings (SYN). They pick up and say “Hello?” (SYN-ACK). You say “Hi, it’s me” (ACK).

Now you both know the line is working and you are actually talking to the right person. Only then do you start the real conversation. TCP does exactly this, just in about 1 millisecond instead of a few seconds.

Step 3: Asking for the page (the HTTP request)

The handshake is done. Your browser sends an HTTP request. It looks like this:

GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
Accept-Language: en-GB

Let’s break this down line by line.

GET is the method. It tells the server what you want to do. GET means "please give me something." There are other methods too:

• POST means "I am sending you data, please process it" (like submitting a login form)
• PUT means "I am sending you data to replace something that already exists"
• DELETE means "please remove this"
• PATCH means "I want to update just part of something"

/ is the path, meaning the specific page you are requesting. For the homepage it is just a slash. For a blog post it might be /blog/how-the-internet-works.

The lines below are called headers. They are metadata, information about the request itself. Who is asking, what format they can understand, what language they prefer. Think of headers like the envelope around a letter. The actual letter is the request body, but the envelope tells the post office and the recipient important things about what is inside.

Try it yourself

You can send a raw HTTP request right from your terminal using a tool called curl:

curl -v https://www.google.com 2>&1 | head -50

The -v flag means verbose. You will see the actual headers being sent and received, the TLS handshake happening, the status code, everything. It is messy but it is real, and reading it becomes second nature quickly.

Try changing the URL to a page you know doesn’t exist:

curl -v https://www.google.com/thispagedoesnotexist 2>&1 | head -30

Watch the status code change from 200 to 404. You are now reading HTTP responses like a developer.

Step 4: What the server does with your request

Google’s server receives your request and figures out what to send back.

For a simple personal website, this might mean reading a static HTML file from disk and returning it directly. For something like Google, there is a lot happening behind the scenes: checking who you are, personalising results, searching an index of billions of pages. But the fundamental mechanic is the same regardless. The server receives the request, does some work, and sends back a response.

The response also has a structure:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 14234

<!DOCTYPE html>
<html>
...

The first line is the status code. 200 OK means everything worked perfectly. You will see other codes constantly as a developer:

• 301 means this page has permanently moved to a new address
• 404 means the server could not find what you asked for
• 500 means something went wrong on the server's side
• 401 means you need to be logged in
• 403 means you are logged in but you do not have permission

Status codes are one of the first things you will learn to love. They are how the server communicates clearly about what happened, in a way that every HTTP client in the world understands the same way.

Try it yourself

Run these two commands and compare the results:

curl -o /dev/null -s -w "%{http_code}\n" https://google.com
curl -o /dev/null -s -w "%{http_code}\n" https://google.com/thispagedoesnotexist

The first gives you 200. The second gives you 404. You just spoke HTTP directly to one of the largest servers in the world and read the reply.

Step 5: Turning bytes into a webpage (browser rendering)

The response arrives. Your browser now has raw HTML, which is just a text file full of tags. But a webpage is rarely just HTML. It also references CSS files for styling, JavaScript files for behaviour, images and fonts. Your browser has to fetch all of those too, which triggers a whole cascade of additional requests.

Here is roughly what happens inside the browser after the HTML arrives:

1. Parse the HTML and build a DOM (Document Object Model), a tree structure representing every element on the page
2. Parse the CSS and build a CSSOM (CSS Object Model)
3. Combine both into a Render Tree, which is the actual visual layout of the page
4. Paint pixels to the screen
5. Execute JavaScript, which may modify the DOM and cause parts of the page to re-render

This whole process, from your first keystroke to pixels appearing on screen, typically takes between 200 milliseconds and 2 seconds, depending on your connection, the server speed, and how complex the page is.

See it in action

Open Chrome or Firefox, go to any website, and press F12 to open DevTools. Click the "Network" tab, then refresh the page.

You will see every single request the page makes, in the order they were made, with the timing for each one. Click on the very first request, usually the HTML document itself. You will see:

• The request headers your browser sent
• The response headers the server replied with
• The status code
• How long the whole thing took

That wall of information that confused me years ago now tells a complete story. Each row is one of the steps we just walked through.

The infrastructure underneath all of this

Everything above is the logical journey. The physical reality is something else.

Your data does not travel in one clean hop from your laptop to Google’s server. It travels in packets, which are small chunks of data usually around 1500 bytes each. Those packets travel through a chain of routers. Each router reads the destination IP address and forwards the packet to the next stop in the chain, like passing a note through a classroom one desk at a time.

Along the way, those packets might pass through your home router, your internet provider’s network, regional exchange points where different networks connect to each other, undersea fibre optic cables crossing entire oceans, and data centres that could be physically located in Ireland, Virginia or Singapore.

Here is the part that genuinely surprised me when I first learned it. Those packets do not all take the same route. They can split up, travel different paths, and get reassembled at the destination. TCP handles the reassembly, making sure everything arrives in the right order and requesting retransmission of anything that gets lost along the way.

The whole network has no central control and no single point of authority. It routes around failure by design. That was intentional from the beginning. The internet was originally built to survive partial destruction and keep routing data no matter what.

Why this actually matters for your work as a developer

Understanding this flow is not trivia. It affects real decisions you will make regularly.

Performance. Every network round trip costs time. Reducing the number of requests a page makes, using CDNs to move assets closer to your users, and caching DNS results all have measurable impact on how fast your product feels.

Debugging. When something breaks, you now have a mental model to work backwards from. Is it a DNS failure? A TCP timeout? A 500 from the server? A CORS block? Each one points to a different layer of the stack, and knowing which layer to look at saves enormous amounts of time.

Security. HTTP is plain text. Anyone on the same network can read it. HTTPS is encrypted, which is why you must never send passwords or sensitive data over plain HTTP. Understanding that DNS queries can also be intercepted explains why DNS-over-HTTPS has become increasingly common.

APIs. Every time your frontend calls a backend, it is doing exactly this: an HTTP request over a TCP connection to an IP address found through DNS. The same rules apply whether you are loading google.com or fetching data from your own server.

The big picture

The internet is not magic. It is a stack of agreed-upon protocols, each one built on top of the last, each one solving one specific problem.

DNS answers: how do humans refer to machines? TCP answers: how do we guarantee reliable delivery? TLS answers: how do we keep the conversation private? HTTP answers: how do applications request and exchange data?

Each layer does its job and trusts the others to do theirs. That separation of concerns is genuinely elegant engineering, and it is a pattern you will encounter over and over as you build things.

Next time you open the Network tab and see that wall of requests, you will know the story behind every single row.

Next in this series: What is a web server? Nginx, Apache, Node, demystified with a real story.

I publish twice a week, walking through computer engineering from the ground up. Follow along if you want to build a proper mental model of how the software you work with actually works.