You type an address, press Enter, and a fraction of a second later a full page appears. It feels instant, almost magical. But behind that single moment, your request takes a real journey: it gets read apart, an address is looked up, a connection is opened, your message is wrapped and sent across the planet, a server does some work, and an answer comes back to be drawn on your screen.
This article walks through that journey one careful step at a time. We are not going to write any code here. The goal is simply to understand what actually happens when one request travels across the web, so that the rest of programming feels far less mysterious. Think of it as the detailed companion to a higher-level “how the web works” overview: same trip, but this time we stop at every station.
The journey at a glance
Before we slow down and inspect each step, here is the whole trip on one map. Keep this picture in mind as you read the rest of the article.
YOU (browser) THE SERVER
┌──────────┐ ┌──────────┐
│ 1 parse │ │ │
│ URL │ │ │
└────┬─────┘ └────▲─────┘
│ 2 DNS: name → IP address │
│ 3 TCP: open a connection │
│ 4 TLS: secure it (only for https) │
│ 5 HTTP: send the request ───────────────────────►│ 6 process
│ │ the work
│◄─────────────────────── 7 HTTP: send response ───┤
┌────┴─────┐ └──────────┘
│ 8 render │ browser turns the response into pixels
│ page │
└──────────┘Eight steps. Each one is small and sensible on its own. Let’s take them in order.
Step 1: The URL is parsed
It all starts with the address you type, called a URL (Uniform Resource Locator). A URL looks like one solid string, but it is really several labelled parts packed together. Your browser’s first job is to pull it apart.
https://blog.acy-partner.com/en/articles?page=2#top
└─┬─┘ └────────┬────────┘└─────┬─────┘└──┬──┘└┬┘
scheme host path query frag| Part | Example | What it means |
|---|---|---|
| Scheme | https |
The rules to use. https means secure HTTP. |
| Host | blog.acy-partner.com |
The name of the machine you want to reach. |
| Path | /en/articles |
Which resource on that machine. |
| Query | ?page=2 |
Extra parameters, like “give me page 2”. |
| Fragment | #top |
A spot inside the page; the browser keeps this and never sends it to the server. |
Once the browser has these pieces, it knows two important things: which server to talk to (the host) and how to talk to it (the scheme). Everything that follows depends on this split.
Where does a missing port come from?
A full address can also include a port number, like :443. If you don’t type one, the browser fills in a default based on the scheme: 443 for https and 80 for http. A port is just the specific “door” on the server to knock on.
Step 2: DNS turns the name into an address
Computers don’t actually find each other by friendly names like blog.acy-partner.com. They use numeric addresses called IP addresses (something like 203.0.113.42). So before anything can be sent, the browser must translate the human-friendly name into that number. That translation is the job of DNS, the Domain Name System.
The easiest way to picture DNS is a giant phone book for the internet. You know the name; DNS gives you back the number. Here is roughly how the lookup unfolds:
browser ──"where is blog.acy-partner.com?"──► DNS resolver
resolver checks: top-level (.com) → domain → subdomain
browser ◄──────"it lives at 203.0.113.42"────── DNS resolverTo avoid repeating this every single time, the answer gets cached (remembered for a while) at several levels: in your browser, in your operating system, and in your network’s resolver. So the second time you visit a site that day, this step is often skipped entirely.
| DNS term | Plain meaning |
|---|---|
| Resolver | The helper that does the lookup for you. |
| Record | One entry in the phone book (e.g. an “A record” maps a name to an IP). |
| TTL | “Time To Live” — how long an answer may be cached before checking again. |
| Cache | A saved answer kept nearby so you don’t ask twice. |
By the end of this step, the browser finally holds an IP address. Now it knows exactly where on the network to send things.
Step 3: A TCP connection is opened
Knowing the address isn’t the same as having a line open. Before any web data flows, the browser establishes a reliable connection to the server using a protocol called TCP (Transmission Control Protocol). TCP’s promise is simple but valuable: data arrives complete, in order, and with nothing silently lost.
Opening a TCP connection takes a short three-message greeting, often called the three-way handshake:
browser ──────── SYN ──────────► server "Hi, can we talk?"
browser ◄────── SYN-ACK ───────── server "Yes, and hi to you."
browser ──────── ACK ──────────► server "Great, let's begin."Once those three messages have crossed, both sides agree the line is open and trustworthy. Think of it as a quick phone-call greeting before you start the real conversation: “Hello?” — “Hello, yes?” — “Okay, here’s why I called.”
Step 4: TLS secures the connection (for https)
If the scheme back in Step 1 was https instead of http, there is one more layer before any real message is sent: TLS (Transport Layer Security). TLS is what puts the “s” (secure) in https. It does two things that matter to you:
- Encryption — it scrambles everything you send so that anyone watching the wire in between sees only gibberish.
- Identity — it checks the server’s certificate, a kind of digital ID card, so you can trust you’re really talking to
blog.acy-partner.comand not an impostor.
Setting this up is its own short negotiation, the TLS handshake, where the two sides agree on how to encrypt and the browser verifies the certificate.
Why the padlock matters
The little padlock in your address bar means TLS succeeded: the connection is encrypted and the server proved its identity. Plain http skips this step entirely, so anyone on the network path could read or tamper with the data. This is why nearly every modern site uses https.
With TCP open and (for https) TLS in place, you finally have a secure, reliable pipe between your browser and the server. Now, at last, we can send the actual request.
Step 5: The HTTP request is sent
Everything so far was setup. This step is where you actually ask for something. The browser composes an HTTP request — a short, structured text message — and sends it down the connection. A simple one looks like this:
GET /en/articles HTTP/1.1
Host: blog.acy-partner.com
Accept: text/html
User-Agent: Mozilla/5.0Let’s read it line by line:
GETis the method — the kind of action you want.GETmeans “give me this resource.”/en/articlesis the path — exactly the one we split out of the URL.- The lines below are headers — extra notes about the request, like which formats you can accept and what kind of browser you are.
The method tells the server your intent. A few common ones:
| Method | What it asks for |
|---|---|
| GET | Fetch a resource (a page, an image). |
| POST | Send data to create something (submit a form). |
| PUT | Replace an existing resource. |
| DELETE | Remove a resource. |
Step 6: The request is routed across networks
Your request rarely jumps straight from your house to the server in one leap. The internet is a mesh of many smaller networks linked together, and your message hops from one to the next until it reaches its destination — much like a parcel passing through a chain of sorting depots.
Each handoff point is a router, a device whose only job is to read where a packet is headed and forward it one step closer.
you ─► home router ─► your ISP ─► internet backbone ─► server's
(Wi-Fi) (provider) (long-haul links) network ─► serverTwo ideas make this trip reliable. First, your data is broken into small packets, and each packet can take its own route — if one path is busy, packets simply go around. Second, TCP (from Step 3) checks that every packet arrives and reassembles them in the right order at the other end. So even though the journey is messy and split up, what the server receives is your clean, complete request.
This whole crossing usually takes only a few thousandths to a few hundredths of a second, even across continents.
Step 7: The server processes and replies
Your request arrives at the server. Now it’s the server’s turn to work. Depending on what you asked for, it might read a file from disk, run some program logic, fetch information from a database, or assemble a page on the spot. When it’s done, it sends back an HTTP response:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1820
<!DOCTYPE html>
<html> ... the page ... </html>The first line carries a status code, a three-digit number summarising how it went. You’ll meet these constantly once you build for the web:
| Code | Family | Meaning |
|---|---|---|
| 200 | Success | OK — here’s what you asked for. |
| 301 | Redirect | Moved permanently to a new address. |
| 404 | Client error | Not found — that resource doesn’t exist. |
| 500 | Server error | Something broke on the server’s side. |
Below the status line come the response headers (notes like the content type), then a blank line, then the body — the actual content, often HTML. That body travels back across the same kind of network hops, in packets, to your browser.
Step 8: The browser renders the page
The browser now holds the response, but a chunk of HTML text isn’t a page yet — it’s instructions. The final step is rendering: turning those instructions into the visual page you see.
Roughly, the browser:
- Parses the HTML into a structured tree of elements (headings, paragraphs, images).
- Requests more resources the page mentions — stylesheets, images, scripts, fonts. Each of these is its own request, quietly repeating much of the journey above (though the open connection and DNS cache make repeats far cheaper).
- Applies the styles to decide colours, sizes, and layout.
- Paints pixels onto the screen, and runs any scripts that make the page interactive.
HTML text ─► element tree ─► apply styles ─► layout ─► paint ─► you see it
│
└─► fetch CSS, images, JS (each = another small request)And that’s the page in front of you. A single thing you wanted — one page — quietly required a whole sequence of cooperating steps.
One page is many requests
It’s easy to assume a webpage is one request. In reality, the first request usually returns just the HTML skeleton, and that page then triggers dozens more requests for images, styles, scripts, and fonts. Each follows the same lifecycle. This is a big reason pages with many heavy resources feel slower — there’s simply more traffic to complete.
Recap: the whole trip
Let’s gather the journey back into one clear list. When you load a page over https, your request:
- Parses the URL into scheme, host, path, and the rest.
- Looks up the host with DNS, turning a name into an IP address.
- Opens a TCP connection with a three-way handshake for reliability.
- Secures it with TLS (for https): encryption plus a verified identity.
- Sends an HTTP request — a method, a path, and headers.
- Hops across networks as packets, router by router, to the server.
- Gets processed by the server, which replies with a status code and a body.
- Is rendered by the browser into the page you actually see.
None of these steps is exotic on its own. The web feels like magic only because all eight happen so smoothly and so fast that you never notice them. Now that you can name each station on the route, every other web topic — what a status code means, why https matters, why a slow page is often a many-requests problem — fits onto this same map.
A natural next step is to zoom in on the pieces you found most interesting. You might look closer at how HTTP methods and status codes work in everyday building, or at what DNS records actually contain. Wherever you go next, you now carry the full picture of the trip a single request makes across the web.
