How a Server Works: From Request to Response, Step by Step

You already know what a server is at a high level: a computer that answers requests from other computers. That’s the what. This article is about the how — what genuinely happens inside that machine in the fraction of a second between a request showing up and a response heading back out. Once you can picture this loop, a lot of mysterious-sounding terms (ports, connections, requests, handlers) stop being mysterious.

We’ll walk the whole path together, slowly, using a web server as our running example because it’s the kind most people meet first. But almost everything here applies to any server. The names change; the shape stays the same.

The big picture: a loop that never ends

Strip a server down to its bones and you find a simple, repeating cycle. The program starts up, claims a spot to listen on, and then settles into a loop: wait for a request, handle it, send back a response, wait for the next one. It does this for as long as it’s running — which, on a real server, is essentially forever.

   start up
      │
      ▼
  ┌─► wait for a request   ◄── (idle, listening)
  │        │
  │        ▼
  │   read & understand it
  │        │
  │        ▼
  │   do the work
  │        │
  │        ▼
  │   send back a response
  │        │
  └────────┘   (loop forever)

That’s it. Everything else is detail filling in those boxes. The reason a server feels “always on” is that it spends most of its life sitting in the very first box — waiting — using almost no resources until something arrives. Let’s open up each step.

Step 1: the server listens on a port

Before a server can answer anyone, it has to announce where it can be reached. A machine has an address (its IP address), but a single machine can run many different servers at once — a web server, a mail server, a database server. So an address alone isn’t enough; you also need a port, which is like a numbered door on that address.

When a web server starts, it does something called binding to a port — typically port 80 for plain HTTP or 443 for HTTPS. From that moment on, it’s listening: telling the operating system, “anything that arrives at this address on this port, hand it to me.”

        one machine (IP 203.0.113.10)
   ┌──────────────────────────────────────┐
   │  port 443 → web server   (listening)  │
   │  port 25  → mail server  (listening)  │
   │  port 5432→ database     (listening)  │
   └──────────────────────────────────────┘

Think of the IP address as a building’s street address and the port as a specific office number inside it. A letter needs both to reach the right desk. Until a request arrives at the door it’s watching, the server just waits — patient, idle, using barely any of the computer’s power.

Step 2: a client connects

Somewhere out on the network, a client — your browser, a phone app, another server — decides it wants something. It reaches across the internet to that exact address-and-port and asks to open a connection.

For most web traffic this connection is built on TCP, a protocol whose whole job is to create a reliable two-way channel between two machines. Before any real data flows, the two sides perform a quick back-and-forth to agree they’re both there and ready — often called a handshake. Once that’s done, there’s an open pipe between the client and the server, and data can travel in both directions through it.

   CLIENT                              SERVER
      │                                   │
      │  "can we open a connection?"      │
      │ ────────────────────────────────► │
      │                                   │
      │  "yes, ready"                     │
      │ ◄──────────────────────────────── │
      │                                   │
      │  ═══ open connection established ══│

The server doesn’t handle this alone — the operating system does much of the low-level work and then hands the ready-made connection up to the server program. From the server’s point of view, it was waiting, and now a client is on the line. Time to listen to what they actually want.

Step 3: the request arrives

Now the client sends its request — a structured message that says exactly what it’s after. For a web server, this is an HTTP request, and it’s surprisingly readable. Here’s roughly what your browser sends when you open a page:

GET /about HTTP/1.1
Host: blog.acy-partner.com
User-Agent: Mozilla/5.0 ...
Accept: text/html

Let’s decode that, because every piece is doing a job:

• GET is the method — the kind of action wanted. GET means “give me something.” Other common ones are POST (here’s some data to save), PUT, and DELETE.
• /about is the path — which specific thing on this server is being asked for.
• HTTP/1.1 is the protocol version being spoken.
• The lines below are headers — extra context: which site (Host), what kind of client (User-Agent), what formats it can accept, and so on.

The server reads this message and now knows three crucial things: what action (GET), on what resource (/about), and with what extra context (the headers). That’s enough to decide what to do next.

Step 4: the server handles the request

This is the heart of it — the part that actually differs from server to server. Handling the request means figuring out the right response. How that happens depends entirely on what kind of resource was asked for, and this single fork is the difference between two whole categories of web content.

If the client asked for a static file — an image, a stylesheet, an already-written HTML page — the work is light. The server finds that file on its disk and gets ready to send it back, more or less as-is. Fast and simple.

If the client asked for something dynamic — a page that has to be built fresh, like your personalized dashboard or search results — the server has real work to do. It runs program code, and that code might:

• read or write data in a database (look up a user, fetch a list of articles),
• apply business rules (is this person allowed to see this?),
• and assemble a brand-new response on the spot, often as HTML or JSON.

   request for /about
          │
          ▼
   ┌─────────────────────┐
   │   is it static?     │
   └─────────┬───────────┘
       yes   │   no
      ┌──────┘   └──────────┐
      ▼                     ▼
  read a file        run program code
  from disk          (maybe query a DB,
                      check rules, build
                      the page on the fly)
      └──────────┬──────────┘
                 ▼
          response is ready

Either way, the goal is the same: end up with something to send back. The static path just gets there faster because the answer already exists; the dynamic path produces a custom answer for this exact request.

Step 5: the response goes back

With an answer in hand, the server packages it as a response and sends it back down the same open connection. An HTTP response mirrors the request’s shape: a status line, some headers, then the actual content.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024

<!doctype html>
<html> ... the page ... </html>

The first line carries a status code, a tiny number with a big meaning. You’ve seen these even if you didn’t know their names:

• 200 OK — success, here’s what you asked for.
• 404 Not Found — the server understood you, but there’s nothing at that path.
• 500 Internal Server Error — the server tried to handle it and something broke on its end.
• 301/302 — a redirect; what you want now lives somewhere else.

After the status line come the response headers (what type of content this is, how long it is, caching hints) and then the body — the HTML, the image bytes, the JSON, whatever was requested. The client receives all this, reads the status, and acts on the content. For a browser, that means painting the page on your screen.

Step 6: back to waiting (and doing it all at once)

Once the response is sent, that single exchange is done. The server returns to the top of its loop, ready for the next request. But here’s the question that trips people up: if a server is stuck in a loop handling one request at a time, how does it serve thousands of people at once?

The answer is concurrency — handling many requests in overlapping time, not strictly one-then-the-next. A real server doesn’t freeze while one slow request finishes; it juggles many in flight at the same moment. There are a few common ways to pull this off:

• Multiple workers — the server runs several copies of its handler (as separate processes or threads), so several requests are worked on in parallel.
• An event loop — a single worker that, instead of blocking while it waits on a database or disk, sets that request aside and picks up another, weaving them together.
• Both at once — many real systems combine the two: several workers, each juggling many requests.

   incoming requests
   ┌──┐ ┌──┐ ┌──┐ ┌──┐
   │R1│ │R2│ │R3│ │R4│
   └─┬┘ └─┬┘ └─┬┘ └─┬┘
     ▼    ▼    ▼    ▼
   ┌────────────────────┐
   │  the server juggles │  ← all "in flight" together,
   │  them concurrently  │     none blocking the others
   └────────────────────┘

You don’t need to master concurrency to understand servers — just to know that the simple loop we drew at the top is, in reality, running many times over in parallel. That’s what lets a single machine feel instant to thousands of visitors at the same time.

Putting the whole journey together

Let’s replay the entire trip in one picture, the way it really flows when you load a page:

  1. server is listening on port 443
  2. your browser opens a connection
  3. browser sends:  GET /about
  4. server handles it (static file OR run code + DB)
  5. server sends:    200 OK + the page
  6. browser shows the page; server waits for the next

Six steps, start to finish, usually in well under a second. Multiply that by every click, every image, every API call your apps make, and you have the constant hum of activity that keeps the web alive. The machine you’re reading this on just did exactly this dance, several times, to put these words on your screen.

Wrapping up

Here’s the whole thing in one place:

• A server runs a never-ending loop: listen, accept, handle, respond, repeat.
• It first binds to a port and listens — an address plus a port number is the “door” clients knock on.
• A client opens a connection (usually over TCP) and sends a request stating the method (GET, POST…), the path, and headers.
• The server handles the request — serving a static file directly, or running code and maybe a database query to build a dynamic response.
• It sends back a response with a status code (200, 404, 500…), headers, and a body, then returns to waiting.
• Real servers do all this concurrently, juggling many requests at once so the machine feels instant to everyone.

If you want to anchor this against the bigger idea first, it’s worth revisiting what a server actually is — this article is essentially that definition shown in slow motion. From here, the natural next questions are about where this all happens: the difference between running a server on your own machine versus out in the world, and how addresses and ports really work.