top of page

How the Internet Actually Works

  • Contributor
  • Nov 2, 2025
  • 5 min read

You type a URL into your browser. A page appears. Between those two moments, a dozen systems coordinate across continents in under a second. Most explanations either oversimplify this into meaninglessness or drown you in protocol specs.

Here is what actually happens, step by step.

Step 1: You Type a URL

When you type https://example.com/about into your browser's address bar and hit Enter, you have just specified three things:

  • The protocol: https — how your browser should communicate

  • The domain: example.com — which server to talk to

  • The path: /about — what you want from that server

Your browser cannot do anything with example.com directly. Computers do not communicate using names. They use numbers — IP addresses like 93.184.216.34. So the first thing your browser needs is a translation.

Step 2: DNS — Translating Names to Addresses

The Domain Name System (DNS) is the internet's address book. Its only job is converting human-readable domain names into IP addresses.

Here is how the lookup works:

  1. Browser cache: Your browser checks if it already knows the IP address for example.com from a recent visit.

  2. Operating system cache: If not, it asks your OS, which keeps its own cache.

  3. Router cache: Still nothing? The request goes to your router.

  4. ISP's DNS resolver: Your Internet Service Provider maintains DNS servers specifically for this. Most lookups end here.

  5. Recursive resolution: If the ISP does not have it cached, it starts asking the hierarchy — root nameservers, then .com nameservers, then the authoritative nameserver for example.com specifically.

The entire process typically takes 20-120 milliseconds. Once resolved, the result gets cached at multiple levels so subsequent requests skip most of these steps.

Think of it like mailing a letter. You write "123 Main St, Denver, CO" on the envelope. The postal system figures out the routing — which sorting facility, which truck, which carrier. DNS is that routing layer for the internet.

Step 3: TCP — Establishing a Connection

Now your browser has an IP address. Before it can request anything, it needs to establish a reliable connection. This uses TCP (Transmission Control Protocol), and it works through a process called the three-way handshake:

  1. SYN: Your browser sends a synchronization request to the server. "I want to talk."

  2. SYN-ACK: The server responds. "Acknowledged. I am ready."

  3. ACK: Your browser confirms. "Great. Let us begin."

This handshake ensures both sides are ready and that packets will be delivered in order. It is the equivalent of a phone call — you dial, the other side picks up, you confirm you can hear each other, then you start talking.

For HTTPS connections (which should be all connections in 2026), there is an additional step: the TLS handshake. This negotiates encryption so that nobody between your browser and the server can read the data in transit. This adds one or two more round trips, though modern protocols like TLS 1.3 have reduced this significantly.

Step 4: HTTP — The Request

With a connection established, your browser sends an HTTP request. This is a structured text message that looks roughly like this:

GET /about HTTP/2
Host: example.com
Accept: text/html
User-Agent: Mozilla/5.0 ...

The key parts:

  • Method: GET means "send me this resource." Other methods include POST (submit data), PUT (update data), and DELETE (remove data).

  • Path: /about — the specific resource requested.

  • Headers: Metadata about the request — what your browser can accept, who it is, whether it has cookies.

HTTP is a stateless protocol. Every request is independent. The server does not inherently remember your previous request. Cookies, sessions, and tokens exist specifically to work around this.

Step 5: The Server — Processing the Request

The server receives your request and decides what to do with it. "Server" is not mystical — it is a computer running software that listens for incoming connections and responds to them.

For a simple static page, the server just finds the right HTML file and sends it back. For a dynamic application, the server might:

  1. Check if you are authenticated

  2. Query a database

  3. Run application logic

  4. Generate HTML on the fly

  5. Return the result

The server sends back an HTTP response:

HTTP/2 200 OK
Content-Type: text/html
Content-Length: 4523

<!DOCTYPE html>
<html>
...

That 200 is a status code. You have seen others: 404 means the resource was not found, 500 means the server had an internal error, 301 means the resource permanently moved somewhere else.

Step 6: Rendering — What You Actually See

Your browser receives the HTML and begins rendering the page. This is not instantaneous — it is a pipeline:

  1. Parse HTML: The browser reads the HTML document top to bottom, building a DOM (Document Object Model) — a tree structure representing every element on the page.

  2. Fetch additional resources: The HTML references CSS stylesheets, JavaScript files, images, and fonts. Each one triggers a new HTTP request back to the server (or to different servers entirely, like a CDN).

  3. Parse CSS: Stylesheets are parsed and matched to DOM elements. This determines how everything looks — colors, layout, typography.

  4. Execute JavaScript: JS can modify the DOM, handle user interactions, and make additional network requests. It is the layer that makes pages interactive.

  5. Layout and paint: The browser calculates the exact position and size of every element, then draws pixels to the screen.

Three technologies, three jobs:

  • HTML: Structure and content. The skeleton.

  • CSS: Presentation and layout. The appearance.

  • JavaScript: Behavior and interactivity. The muscle.

The Client-Server Model

Everything described above follows the client-server model. Your browser is the client — it initiates requests. The web server is the server — it waits for requests and responds to them.

This is a fundamental pattern, not just a web thing. Email works this way. Mobile apps work this way. When you search for a flight on an airline app, the app (client) sends a request to the airline's servers, which query their database and send results back.

The important distinction: the client and server are just roles. Any computer can be either. When you run a local development server on your laptop, your laptop is simultaneously the client (your browser) and the server (the dev server process).

Try It Yourself

You do not need to take any of this on faith. Open your browser's developer tools right now:

  1. Open DevTools: Press F12 or Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (Mac).

  2. Go to the Network tab.

  3. Navigate to any website.

  4. Watch the requests appear in real time.

Each row is one HTTP request. Click on any request and you will see:

  • Headers: The exact HTTP request and response headers

  • Timing: How long DNS lookup, connection, and transfer each took

  • Response: The actual data the server returned

Filter by type — Doc, CSS, JS, Img — to see how many separate requests a single page load requires. A typical modern page makes 50-200 requests. Some make far more.

This is not abstract theory. It is happening right in front of you, on every page load, measurably.

Takeaway

The internet is not magic. It is a stack of systems, each solving one specific problem: DNS resolves names, TCP ensures reliable delivery, HTTP structures the conversation, and the browser turns the response into something visual.

Every concept that follows in web development — APIs, databases, authentication, caching, deployment — is built on top of this same foundation. If you understand the request-response cycle described here, you have the mental model to understand everything else.

Next in the learning path: How Web Apps Work — what happens on the server side when dynamic applications enter the picture.

bottom of page