How the Web Works: What Happens When You Load a Page

You type an address, press enter, and a fraction of a second later a full page appears, complete with images, colours, and buttons that respond to your touch. It feels instant, like flicking a light switch. But underneath that switch is a surprisingly tidy sequence of steps, a short conversation between your device and a computer that might be on the other side of the planet. The whole thing usually finishes before you have taken your finger off the enter key.

Almost all modern security is web security in some form, so it genuinely pays to have a clear mental picture of what happens when you open a web page. The reassuring part is that the picture is simple once someone slows it down for you. And once you can see the steps laid out, an enormous amount of security suddenly has a place to live, because nearly every web attack is just one of these ordinary steps being nudged out of shape.

Clients and servers

The web runs on one wonderfully simple relationship. A client asks for something, and a server provides it. That is the heartbeat of the whole system, repeated billions of times a second across the world.

• Your browser is the client. Its job is to request pages and display them to you. Chrome, Safari, Firefox, and Edge are all clients. So is the app on your phone that quietly fetches data in the background.
• A server is a computer, sitting in a data centre somewhere, that holds the website and answers requests for it. It waits patiently, and when a request arrives, it works out what was asked for and sends back an answer.

Everything else in this article is simply the conversation between these two roles. Keep that in mind and none of the following steps will feel strange, because they are all just the client asking and the server answering in a little more detail.

The journey of one page load

Type an address, press enter, and here is the sequence that unfolds, usually in well under a second:

1. DNS lookup:    turn the name (holyghost.sh) into an IP address.
2. Connection:    the browser opens a TCP connection to that address.
3. TLS handshake: for https, set up encryption so the conversation is private.
4. HTTP request:  the browser asks: "GET me the page at this path."
5. Server works:  it finds or builds the page, maybe querying a database.
6. HTTP response: the server sends back the page, usually as HTML.
7. Rendering:     the browser draws the page and requests the extra bits
                  it references: CSS for styling, JavaScript, images.

Let us walk through those steps in plain language, because each one hides a small story.

Step one is the name lookup. You typed a human friendly name like holyghost.sh, but computers connect using numbers called IP addresses. So the very first thing the browser does is ask a lookup system to translate the name into an address. This is such an important step that it has its own primer worth reading: what is DNS.

Step two opens the line. Now that the browser has an address, it opens a connection to it using TCP, the protocol that makes sure data arrives reliably and in order. If any of the vocabulary here feels shaky, networking basics covers addresses, ports, and protocols from the ground up.

Step three secures the conversation. For any modern site using HTTPS, the browser and server perform a TLS handshake, a quick exchange that sets up encryption so nobody watching the path in between can read or tamper with what follows. This is the step that turns an open conversation into a private one, and it has its own explainer in how HTTPS works.

Step four is the actual request. The browser now sends an HTTP request, which is essentially a short, structured note that says what it wants. Something like "please GET me the page at this address."

Step five is the server doing its work. The server reads the request, works out what was asked for, and produces an answer. For a simple site this might just mean grabbing a file. For a complicated one it might mean running code and asking a database for your account details, your order history, or the latest posts.

Step six sends the answer back. The server replies with an HTTP response containing the page, usually written in HTML, the language that describes a web page's structure.

Step seven is rendering. The browser reads the HTML and draws the page. Along the way it notices references to extra files, such as CSS for styling, JavaScript for interactivity, and images, and it fires off further requests to fetch each of those too. A single page you see is often the result of dozens of small requests working together.

Requests and responses

The language of this whole conversation is HTTP, which stands for HyperText Transfer Protocol. Every exchange is a matched pair: a request going out and a response coming back. If you remember only one thing about how the web talks, make it that pairing.

A request always carries a method, a single word that says what you are trying to do. The two you will meet most often are:

• GET: fetch something, such as a page, an image, or a file. GET is for reading. It should not change anything on the server.
• POST: send data to the server, such as submitting a form, logging in, or posting a comment. POST is for actions that create or change something.

There are others, such as PUT and DELETE, but GET and POST cover the vast majority of what you will see day to day.

A response comes back carrying a status code, a three digit number that summarises how the request went. You have almost certainly bumped into some of these:

• 200 means success. The request worked and here is what you asked for.
• 301 and 302 are redirects, the server's way of saying "what you want is over here now, go and ask for it there instead."
• 404 means not found. The server understood the request but has nothing at that address.
• 500 means the server hit an error while trying to build the response. The problem is on the server's side, not yours.

A rough rule of thumb helps here: codes in the 200s mean success, the 300s mean redirection, the 400s mean the client asked for something wrong or was not allowed, and the 500s mean the server itself broke.

Why this matters for security

Here is the payoff for learning all of this. Almost every web attack is not some exotic new trick but an abuse of the normal request and response flow you just met. Understand the flow, and the attacks become variations on a theme rather than a wall of jargon.

• If the server trusts data from the request too much and mixes it straight into the page, you get injection flaws like cross site scripting, where an attacker's text is treated as code and runs in other people's browsers.
• If the server can be tricked into making its own outbound requests on an attacker's behalf, you get server side request forgery, where the trusted back end is turned into a confused messenger.
• If the connection is not encrypted, anyone sitting on the path between client and server can read or quietly change what passes by, which is exactly why the TLS handshake in step three matters so much.

Every one of these threats makes far more sense once you can picture the request and the response underneath it. You are no longer memorising scary names. You are spotting where a normal step got bent.

The takeaway

Loading a page is a short, orderly conversation: look up the name, open a connection, secure the channel, send an HTTP request, receive a response, and render it into the page you see. The client asks and the server answers, in a language of methods and status codes, spread across a front end you can see and a back end you cannot. Hold that single picture in your head and web security stops being abstract, because almost every attack you will ever read about is just this ordinary flow being bent out of shape. If any piece felt hazy, networking basics, what is DNS, and how HTTPS works fill in the corners.