How Web Servers Work: From a URL in the Browser to a Page on Your Screen

You type an address into your browser, press Enter, and a fraction of a second later a full page is sitting in front of you. It feels instant and effortless — which is exactly why almost nobody stops to ask what happened in between. But a surprising amount of careful work runs behind that moment, and most of it happens inside a single piece of software: the web server.

In this article we’re going to slow the whole thing down and watch it frame by frame. Not the high-level “the browser talks to the server” version, but the actual sequence of steps a web server takes from the instant a request lands on its doorstep to the instant it sends a reply back. Once you can picture that loop clearly, a lot of words you’ve heard in passing — ports, requests, headers, status codes — stop being jargon and start being parts of a machine you understand.

What a web server is doing all day

Before the step-by-step, it helps to know the web server’s one job. A web server is a program that sits and waits for requests over the network, and answers them with web content — HTML pages, images, stylesheets, JSON data, whatever was asked for. That’s it. It doesn’t go looking for work; it reacts. The request comes in, the server responds, and it goes back to waiting for the next one.

That “sit and wait” behavior is the key to the whole thing. A web server is a long-running process — it starts up once and keeps running for days or weeks, always listening, always ready. This is different from a script you run once and that exits when it’s done. If the web server program stops, your site goes down, because there’s nobody left to answer the door.

The setup: listening on a port

A web server can’t answer requests it never hears, so the very first thing it does when it starts is bind to a port and begin listening. A port is a numbered doorway on the machine — think of the machine as an apartment building with one street address (its IP) and many numbered doors. Web traffic conventionally uses two of them: port 80 for plain HTTP and port 443 for encrypted HTTPS.

When the server “listens on port 443,” it’s telling the operating system: any request that arrives at this machine aimed at door 443, hand it to me. From that point on, the server is registered with the OS as the program responsible for that door, and it parks itself in a loop, waiting.

   THE MACHINE (one IP address)
   ┌─────────────────────────────────────┐
   │  port 22  → SSH                      │
   │  port 80  → web server (HTTP)        │
   │  port 443 → web server (HTTPS) ◄──── listening here
   │  port 5432 → database                │
   └─────────────────────────────────────┘

If ports and IP addresses feel fuzzy, the earlier article on IP addresses and ports walks through them properly. For now, just hold this picture: the server is a program standing at one specific door, waiting for someone to knock.

Step by step: one request, start to finish

Now the interesting part. Let’s follow a single request as it travels through the server. Imagine a visitor’s browser wants the homepage of ACY Partner Indonesia. Here’s everything that happens, in order.

1. The connection arrives

The browser has already figured out which machine to talk to (that’s the domain-name lookup, which happens before the server is even involved — see domains and DNS if you’re curious). Now it opens a network connection to that machine on port 443 and sends its request across.

The operating system receives the incoming connection and, because the web server registered itself for port 443 earlier, hands it straight over. The server’s long wait is over — it has a customer.

2. The request gets parsed

What actually arrives is just text, formatted according to the rules of HTTP. A bare-bones request looks something like this:

GET / HTTP/1.1
Host: acy-partner.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
Connection: keep-alive

The server reads this and pulls it apart into pieces it can act on:

• The method (GET) — what kind of action is wanted. GET means “give me something,” POST means “here’s some data, take it,” and there are a handful of others.
• The path (/) — which resource is being asked for. / is the homepage; /about would be the about page.
• The headers (Host, User-Agent, Accept, …) — extra context about the request: which site the browser wants, what kind of program it is, what content types it can handle.

Parsing turns a blob of text into structured information. Until this step finishes, the server doesn’t actually know what’s being asked for — afterwards, it does.

3. Decrypting (if it’s HTTPS)

If the connection came in on port 443, the request was encrypted in transit so nobody along the way could read it. Before the server can parse anything, it has to decrypt the incoming bytes using its TLS certificate, and on the way out it will encrypt the response too. This handshake-and-encrypt work is what the lock icon in your browser is quietly promising. It happens around the parsing step, transparently — the rest of the server logic works the same whether the request was encrypted or not.

4. Routing: deciding who handles this

Now the server knows the method and path, so it has to answer the central question: what should respond to this? This decision is called routing, and it’s where web servers split into two broad behaviors.

If the path points at a file that already exists — say a logo image at /images/logo.png — the server can often just find that file on disk and send it back as-is. Nothing needs to be computed; the file is the answer. This is static content.

If the path needs something to be built on the fly — a page personalized for the logged-in user, a search result, today’s order list — the server can’t just read a file. It has to hand the request off to a program that runs code, talks to a database, and assembles a fresh response. This is dynamic content.

   request for /images/logo.png   →  file exists on disk  →  send the file  (static)

   request for /dashboard         →  no ready-made file   →  run a program
                                                              that builds the
                                                              page  →  send it  (dynamic)

5. Building the response

However the content gets produced — read from disk or generated by a program — the server now has a body to send back, and it wraps it in a proper HTTP response. Like the request, the response is structured text (plus the content itself):

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 5120
Cache-Control: max-age=3600

<!DOCTYPE html>
<html> ... the actual page ... </html>

Two things deserve a second look:

• The status code (200 OK) — a three-digit number that tells the browser how it went. 200 means success. 404 means “I couldn’t find what you asked for.” 500 means “something broke on my end.” 301 means “this moved, go here instead.” You’ve seen 404 in the wild; now you know it comes straight from this step.
• The response headers (Content-Type, Content-Length, Cache-Control, …) — instructions for the browser about what’s coming. Content-Type tells it whether to render this as a web page, an image, or raw data. Cache-Control tells it how long it’s allowed to remember the answer instead of asking again.

6. Sending it back, and going quiet again

The server writes the response onto the same connection the request came in on, and it travels back across the network to the browser. The browser reads the status code, checks the headers, and renders the body — and from the visitor’s side, the page simply appears.

For the server, the job is done. Depending on the headers, it might keep the connection open for a moment in case the browser asks for more (your typical page pulls in dozens of images, scripts, and stylesheets, each its own request), or it might close it. Either way, the server returns to its loop and waits for the next knock.

   BROWSER                              WEB SERVER
      │                                     │  (listening on :443)
      │  1. opens connection, sends request │
      │ ──────────────────────────────────► │
      │                                     │  2. parse  3. decrypt
      │                                     │  4. route  5. build response
      │  6. response: 200 OK + the page     │
      │ ◄────────────────────────────────── │
      │                                     │
   renders the page                      back to waiting

That entire round trip usually finishes in well under a second. And the server isn’t doing it once — it’s running this loop for every visitor, often many at the same time, which leads us to the part that makes web servers genuinely impressive.

Handling many requests at once

A real website doesn’t get one visitor politely waiting their turn. It gets hundreds or thousands of requests arriving in overlapping bursts. If the server could only handle one at a time — finish the whole loop, then accept the next — everyone after the first person would be stuck in a queue, and the site would feel frozen.

So web servers are built for concurrency: handling many requests during the same window of time. The exact technique varies, but the broad strategies are worth recognizing:

• Many workers. The server keeps a pool of worker threads or processes, and hands each incoming request to a free worker. Twenty workers can be busy with twenty different visitors simultaneously.
• Event-driven loops. Instead of dedicating a worker to each request and letting it sit idle while waiting on a slow database or disk, the server juggles thousands of connections in a single loop, doing a little work on each one whenever it’s ready. This is why some servers handle enormous numbers of connections on modest hardware.

You don’t need to choose or configure any of this to understand the web — but knowing that the server is constantly multiplexing many conversations at once explains how a single machine can serve a busy site, and why “how many requests per second can it handle” is such a common question when people talk about server performance.

Why understanding this loop pays off

Once the request–parse–route–respond cycle is clear in your head, an enormous amount of web development stops being mysterious. When a page returns a 404, you know the routing step couldn’t match the path to anything. When you see a 500, you know the server did match a route but the code that was supposed to build the response blew up. When a developer talks about “setting a header” or “the request body,” you can place those words in the exact step where they live.

It also draws a clean line between the two halves of building for the web. Everything that happens in the browser — the layout, the clicks, the animations — is the front end. Everything we just walked through — listening on a port, parsing requests, routing, generating responses — is the server side. The web server is the hinge between them: the program standing at the door, turning every “I’d like this page” into “here it is.”

Wrapping up

Here’s the whole journey in one place:

• A web server is a long-running program whose job is to listen for requests over the network and answer them with web content.
• It starts by binding to a port (80 for HTTP, 443 for HTTPS) and waiting for connections.
• For each request it runs a loop: accept the connection → parse the request → decrypt if HTTPS → route to find what should respond → build the response → send it back, then return to waiting.
• The request carries a method, a path, and headers; the response carries a status code (200, 404, 500 …), headers, and the content itself.
• Routing decides between static content (an existing file, sent as-is) and dynamic content (built on the fly, often by a separate program).
• Real servers handle many requests at the same time through worker pools or event-driven loops, and they run as a supervised service so they stay up.

Next, it’s worth zooming in on that fork in the road we kept brushing past — the real difference between static and dynamic content, and why it shapes how every site is built and deployed.