How a web request works, end to end

Key takeaways Every time you load a page, the same spine runs underneath: DNS → TCP → TLS → HTTP → response. Typing a URL and pressing Enter kicks off a precise sequence — the browser turns the name into an address, opens a connection, secures it, asks for the page, and renders the reply. This lesson traces the whole spine in one pass; the rest of the path unpacks each step in detail.

You’ve used this thousands of times without seeing it. Under the hood, a single web request is a short, ordered chain of steps, and each one has to succeed before the next can start. Learn the chain once and the whole path ahead — DNS, ports, TCP, TLS, HTTP — stops feeling like a pile of unrelated acronyms and starts looking like one journey.

The one-sentence version

Here’s the whole thing in a breath: the browser turns the name into an address, opens a connection, secures it, asks for the page, and renders the reply. Everything below is just that sentence, slowed down.

Step by step

Say you type https://example.com/about and press Enter. Roughly this happens, in order:

  1. Parse the URL. The browser breaks the address into parts: the scheme (https, which says how to talk), the host (example.com, which says who to talk to), and the path (/about, which says what to ask for). These three pieces drive every step that follows.

  2. DNS lookup. The host is a name, but the network delivers data by number, so the browser resolves example.com to an IP address through DNS — the internet’s directory. This is the first network step, and until it finishes the browser doesn’t even know where to send anything.

  3. Open a TCP connection. With an IP in hand, the browser opens a TCP connection to that address on the right port (443 for https). TCP’s short handshake sets up a reliable, ordered pipe between the two machines. The pair of (address, port) it connects to is a socket.

  4. TLS handshake. Because the scheme is https, the browser and server negotiate encryption and the browser verifies the server’s certificate before any real data flows — this is the TLS handshake. It proves you’re talking to the real example.com and scrambles everything from here on. (Plain http skips this step.)

  5. HTTP request. Now the browser actually asks for the page. It sends an HTTP request — a line like GET /about plus a set of headers describing the browser, what formats it accepts, and any cookies. This is the “please send me this” message.

  6. Server responds. The server answers with an HTTP response: a status code (200 OK, 404 Not Found, and so on), its own headers, and the body — the actual HTML, image, or data you asked for.

  7. Render or use. The browser reads the body and draws the page, fetching any extra pieces (styles, images, scripts) with more requests that repeat this same chain. If the caller is your own program rather than a browser, it simply uses the data it got back — the pattern behind web APIs and REST.

A simple diagram

A quick sketch of who talks to whom, in order:

  You type a URL
        │
        ▼
  ┌───────────┐   1. "what's the IP for example.com?"
  │  Browser  │ ─────────────────────────────▶ ┌─────┐
  │ (client)  │ ◀───────────────────────────── │ DNS │
  └───────────┘   2. "it's 93.184.x.x"          └─────┘
        │
        │  3. open TCP  ·  4. TLS handshake
        │  5. GET /about
        ▼
  ┌───────────┐                                 ┌─────────┐
  │  Browser  │ ─────────────────────────────▶  │ Server  │
  │           │ ◀───────────────────────────── │         │
  └───────────┘   6. 200 OK + page body         └─────────┘
        │
        ▼
  7. render the page

The same round trip repeats for every extra file the page needs.

Why trace it

Almost every “why won’t this connect?” is one of these exact steps failing. The name won’t resolve (DNS). The connection never opens (TCP, or a firewall on the port). The certificate is rejected (TLS). The server answers with an error status (HTTP). Because the steps run in a fixed order, the point where things break tells you where to look — you stop guessing and start checking the chain in sequence. That’s precisely the mindset behind testing connectivity later in this path.

Quick check: after you type a domain and press Enter, what's the FIRST network step?

Recap

  • A web request is a fixed chain: DNS → TCP → TLS → HTTP → response.
  • The browser parses the URL into scheme, host, and path first.
  • DNS turns the host name into an IP address — the first network step.
  • TCP opens the connection; for https, TLS encrypts it and checks the certificate.
  • The browser sends an HTTP request and gets back a status, headers, and a body, then renders it (or your code uses the data).
  • The steps run in order, so a broken connection points to the exact step that failed.

Next up: Module 2 covers how machines find each other — IP addresses & subnets