Web Servers narrated
live from the paddock.

Stage 01 pit wall + garage

What a web server is for

Lights out! The very first corner already asks the question that decides the whole race: what stays in the driver's lap, and what goes to the pit wall. The best teams win Grands Prix in the pit box, and a Red Bull stop under two seconds proves the operation around the driver matters as much as the car. Let's find out why.

Picture a team that spins up a Node.js app and lets it answer directly on port 3000, with nothing in front of it. At first it works fine, but the product grows and a string of pains show up, none of them related to business logic: serving static files starts competing for the same process running the app, renewing the HTTPS certificate means touching the code and restarting the process, spreading traffic across replicas turns into a manual call on every request, and there's no layer filtering bots before they hit the application directly. Translated to the cockpit: it's the driver who, on top of driving, would also have to run his own encrypted radio, decide the stint strategy alone, and still keep intruders out of the box. Nobody races like that.

How it works

Every one of these problems is edge infrastructure, not business logic. Solving all of them inside the application's own code mixes up responsibilities that should stay separate, and that exact set of responsibilities is what a web server like the Apache HTTP Server or Nginx takes on.

The analogy: think of your team's pit wall and garage. Without them, the driver would have to work out strategy alone, handle his own secure comms, and still watch who walks into the box. With a central operation, everything arrives at one point (the pit wall), which decides what to pass on to the driver, turns away anyone without clearance, and handles the shared chores (radio, telemetry, timing) without breaking the concentration of whoever's in the car. The web server is that pit wall for your infrastructure: the point every HTTP request passes through before it reaches (or doesn't) your application.

A modern web server typically takes on the six functions in the cards below. Worth remembering: this piece of software is a war veteran. The Apache HTTP Server first shipped in 1995, which makes it more than 30 years on track.

The six functions of a modern web server

The Server header gives away who's answering you

 # /etc/nginx/conf.d/default.conf
server {
    listen 80;                       # the port Nginx listens on
    server_name localhost;           # the domain this block serves
 
    location / {
        root /usr/share/nginx/html;  # the folder holding the static files
        index index.html;           # file served when the URL ends in "/"
    }
}

Essential commands for this stage

Hands-on

Two containers up, a curl to read the Server header, and you can already feel the pit wall answering before the driver gets in the car. No rush to set a lap time here: it's a track familiarization lap.

1. Spin up an Nginx container (docker run -d -p 8080:80 nginx:latest) and an Apache container (docker run -d -p 8081:80 httpd:latest).
2. Run curl -I http://localhost:8080 and curl -I http://localhost:8081. Notice the Server header on each: two different pieces of software answering the same job. Two different pit wall vendors doing the same work.
3. Ask for a path that doesn't exist on each one (curl -I http://localhost:8080/does-not-exist) and notice the 404 Not Found. That response came from the web server, with no application ever triggered: the pit wall turned the request away at the door, the driver never even knew it existed.

Clear as day: the pit wall exists so you can just drive. Now the track opens onto the longest straight of the circuit, the evolution of the radio protocol between car and box. Stage 02, and it's all about shaving milliseconds off the conversation.

Stage 02 the HTTP evolution straight

HTTP and its evolution, from 1.1 to QUIC/HTTP-3

Here the fight is over milliseconds in the conversation between car and pit wall, and three generations of protocol are racing on the same tarmac. Remember Mansell glued to Senna's gearbox in the closing laps of Monaco 1992, faster and unable to pass? Head-of-line blocking is exactly that: the quick one stuck behind whoever got there first.

Two scenes explain why HTTP had to evolve, framed as two communication failures between car and pit wall. Scene 1: an e-commerce page loads the main HTML plus 40 thumbnail images; even with persistent connections (keep-alive), HTTP/1.1 processes one request at a time within that connection, so the second image only starts downloading once the first has arrived in full. It's a single radio: while the engineer dumps one long transmission, every other message waits in line. Scene 2: even once scene 1 is fixed, a user on a shaky mobile network still feels the lag, because a single lost packet along the way is enough to freeze the whole page load until the retransmission arrives, even though everything else already got there. It's the car entering the Monaco tunnel: it loses one word of the radio and the whole message freezes until it repeats, even though the rest had already come through.

How it works

Before the version numbers, one structural fact about HTTP itself: it's a stateless protocol. Every request is handled completely independently, with no memory of previous requests, like an isolated radio call that carries no memory of the calls before it. That makes the protocol simpler to scale, but it requires mechanisms layered on top (cookies, sessions) to fake context between requests from the same user. On the pit wall, that context lives on the pit board and in accumulated telemetry, not in the radio call itself.

HTTP/1.1, the classic version (1997): introduced persistent connections (keep-alive), letting multiple requests and responses share the same TCP connection, which cut a lot of the overhead of opening a fresh connection for every resource. The catch is head-of-line blocking: if the first request takes a while, everything behind it, on that same connection, has to wait. Channel stays open, sure, but one transmission at a time, and the long one holds up the queue.

HTTP/2, multiplexing (2015): solves scene 1's head-of-line blocking at the application layer, multiple requests and responses travel simultaneously over the same TCP connection, with none blocking another. It's the modern telemetry of a 2026 car, dumping dozens of channels at once over the same link (tire pressure, ERS deployment, DRS mode) with no channel holding up another. It also brought resource prioritization, header compression via HPACK, and Server Push (a feature that shipped in the original spec but has since fallen out of use: the major browsers have removed or restricted support for it since 2022, because the real performance gain rarely justified the complexity of using it correctly).

HTTP/3, QUIC over UDP: HTTP/2 solved head-of-line blocking at the application layer, but scene 2's problem still lives one layer down. TCP guarantees bytes arrive in strict order, so if a packet is lost, everything that came after it waits for the retransmission, even if it belongs to a different stream than the one that stalled. HTTP/3 attacks that by swapping TCP for QUIC (Quick UDP Internet Connections), which runs over UDP: every stream is independent, and losing a packet from one stream doesn't stall the others. It's like having every telemetry channel immune to the others' noise: if the brake-temperature reading drops out for an instant in the tunnel, the GPS channel doesn't even notice. The gain is biggest on networks with packet loss or high latency, the typical case for mobile connections, in other words the car out in the far, noisy stretches of a long track like Spa.

The three generations, side by side

Asking curl itself which version got negotiated

# Let curl negotiate freely and show the version used in the response
$ curl -so /dev/null -w 'Negotiated protocol: HTTP/%{http_version}\n' https://www.cloudflare.com
Negotiated protocol: HTTP/2
 
# Force HTTP/1.1, even if the server supports newer versions
$ curl --http1.1 -so /dev/null -w 'Negotiated protocol: HTTP/%{http_version}\n' https://www.cloudflare.com
Negotiated protocol: HTTP/1.1
 
# Force HTTP/3 (needs a curl build with QUIC support)
$ curl --http3 -so /dev/null -w 'Negotiated protocol: HTTP/%{http_version}\n' https://www.cloudflare.com
Negotiated protocol: HTTP/3

Essential commands for this stage

Hands-on

Three curl commands, three protocol versions negotiated right in front of you. Clock the %{time_total} of each and feel, in your own hands, the difference every generation brought. This one's a qualifying lap.

1. Pick a domain you know supports HTTP/2 (for example, www.cloudflare.com or www.google.com) and run the three commands from the example above. Watch the %{http_version} value change with the flag used.
2. Run curl -v --http2 https://www.cloudflare.com 2>&1 | grep -i "HTTP/2" and find, buried in the verbose output, the line confirming the version negotiated during the handshake. It's the radio handshake before the first real transmission.
3. If your curl supports HTTP/3, repeat with --http3 and compare the response time with -w "%{time_total}\n" across all three variants.

You watched the radio clear its queue and the telemetry go deaf to interference. Now the circuit stretches into a technical chicane: two lookalike intermediaries doing opposite jobs. Stage 03, mind the braking zone.

Stage 03 the proxy chicane

Forward Proxy and Reverse Proxy, the web's two intermediaries

Careful with this sequence: forward proxy and reverse proxy are twins running in opposite directions. Get them mixed up here and you lose the car in the gravel. Full focus through the next few corners.

Two mirrored scenes, one on the client side and one on the server side. Think of a car that needs to talk to the world (outbound) and a box that needs to receive the world (inbound). Scene A: a company wants every outbound request from its employees to pass through a single control point, to block unwanted sites, log access for compliance, and stop each machine's internal IP from being exposed straight to the internet. Scene B: the same company runs five application servers behind a single public domain, and it makes no sense to expose each server's IP individually, repeat the TLS certificate setup on every one of them, or let each server decide on its own whether it can handle one more simultaneous connection. Two different needs, but with one piece in common: an intermediary sitting between whoever's asking and whoever's answering. The difference is which side that intermediary represents and protects.

How it works

Forward Proxy, the outbound intermediary: sits between a client (usually inside a private network) and the internet, and is explicitly configured on the client's side (in the browser, the operating system, or the application). Analogy: it's the driver's manager. The driver doesn't personally go negotiate with a sponsor or field questions from the press, he talks to his manager, who decides what goes out, negotiates on his behalf, and brings the outcome back. The sponsor on the other end has no idea the words came from the driver, all they see is the manager. The driver hired that intermediary on purpose, exactly like a client configures a forward proxy. Use cases: security and compliance (routing traffic through firewalls), content control (blocking sites), anonymity and privacy (masking the client's real IP), and caching (storing frequent responses to save bandwidth).

Reverse Proxy, the smart gatekeeper at the front door: sits at the edge of the infrastructure, receiving requests from the internet and handing them out to the application servers behind it. It's transparent to the client, who has no idea it's even there. Analogy: it's literally the pit wall from Stage 01, seen from another angle, now formalized specifically for when it exists to protect and organize what's behind it. Picture Ferrari's pit wall taking every incoming call from outside and deciding, request by request, whether it's business for Hamilton's car or Leclerc's, already armed with ready answers for the routine stuff and turning away anyone who shouldn't get near the cars. Main functions: load balancing across multiple backends, centralized SSL/TLS termination (taking that CPU load off the backends), content caching, a first line of defense against malicious traffic (blocking specific attacks like XSS usually needs extra WAF rules, not just the plain proxy), compression (Gzip/Brotli), and smart routing across different services.

Summed up in paddock slang: forward proxy is the manager speaking for the driver on the way out, reverse proxy is the pit wall taking in the world on the way in. Same kind of intermediary, opposite directions.

The two sides of the same mechanism

An Nginx reverse proxy in front of a simple backend

 # /etc/nginx/conf.d/proxy.conf
upstream backend_app {
    server 127.0.0.1:8000;         # the real application server, behind the proxy
}
 
server {
    listen 80;
    server_name localhost;
 
    location / {
        proxy_pass http://backend_app;                    # forwards the request to the backend
        proxy_set_header Host $host;                       # preserves the client's original Host
        proxy_set_header X-Real-IP $remote_addr;           # tells the backend the client's real IP
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # chain of IPs, if there's more than one proxy
    }
}

Essential commands for this stage

Hands-on

Spin up the Python backend, put Nginx in front of it, reload, and check the Server header with a curl: every step is a tire change, do it in order and the car leaves the box clean. Garage warning: this exercise edits Nginx's real config and reloads the process with nginx -s reload, so use an Nginx installed on the host (sudo apt install nginx), not the nginx:latest container from Stage 01. If you'd rather stay on Docker, see the workaround suggested at the top of the guide.

1. Spin up the Python backend (python3 -m http.server 8000, in a folder with any index.html) and configure Nginx as in the example above. Reload with nginx -s reload.
2. Run curl -I http://localhost and notice the Server: nginx header, even with the content coming from the Python process. The pit wall out front, the car behind it.
3. Temporarily remove the proxy_set_header X-Real-IP line, reload, and think through what the backend would now see: without that header, it would only see Nginx's own IP.
4. Compare with the forward proxy's curl -x command: notice that there, it's you pointing at the intermediary on purpose; in step 2, you didn't even know it existed.

Manager on the way out, pit wall on the way in: you won't mix those up again. Now comes the heaviest braking zone on the track, where Apache's garage strategy decides who survives the peak. Stage 04.

Stage 04 the MPM braking zone

Apache HTTP Server and its processing models (MPMs)

Here the track demands garage strategy: how do you scale your crew of mechanics to handle 5,000 cars wanting the box at the same time? Get this wrong and it costs you. Ask Ferrari about Abu Dhabi 2010, who threw away a championship on the wrong box call at the wrong moment.

Scenario 1: an e-commerce site running Apache with the oldest processing model takes a spike of 5,000 simultaneous connections during a sale. Since every connection gets its own, fully isolated operating-system process, the server tries to open thousands of processes, each burning tens of megabytes just to exist, before it's even processed a single request. Memory runs out, the system starts swapping to disk, and the site crashes right at the sales peak. It's a pit-stop window under a safety car: all 22 cars want the box at the same time, and if you demanded a whole separate crew for every car, there wouldn't be room or people in the pit lane for all of them. Scenario 2, the opposite: the same company depends on an old module written with no concurrency care (not thread-safe), and it has to keep working. Switching the processing model to one based on threads sharing memory would make that module corrupt data or crash the process unpredictably. It's that legacy calibration tool that only works on an isolated bench: on a shared bench, it messes up every other mechanic's work. One scenario calls for lightness to scale; the other calls for total isolation to survive. Apache resolves that tension by letting you choose the concurrency model, the MPMs (Multi-Processing Modules).

How it works

General analogy: think of the garage and how you scale the mechanics. In this stage, a connection is a car pulling in to be serviced, a process is an independent box with its own tools and its own space, and a thread is a mechanic inside that box, sharing the same toolbench.

Prefork MPM (non-threaded): an independent child process gets spun up for every connection, fully isolated from the rest. Advantages: very stable (a problem in one process doesn't touch the others), ideal for non-thread-safe modules, high compatibility with legacy software. Drawbacks: high memory use and poor scalability under heavy concurrency. Prefork commonly pairs with mod_php (PHP embedded inside Apache's own process, historically not thread-safe); the modern alternative is running PHP as a separate process via PHP-FPM, with Apache talking to it over a proxy, which lets you run a lighter MPM without losing compatibility.

Worker MPM (multithreaded): spins up multiple child processes, each running multiple threads, and each thread handles one connection. More memory-efficient than Prefork and better performing under heavy concurrency, but since threads in the same process share memory, a serious bug in one thread can corrupt the whole child process hosting it, taking down the connections that specific process was serving (the other processes and the master process stay up). It's the mechanic who knocks over the toolbench and only hurts his own box's crew; the other boxes and the team principal keep working. That's why the modules need to be thread-safe.

Event MPM (recommended for production): builds on the Worker model, but tuned for the common case of open, idle keep-alive connections: one dedicated thread can watch several connections that are just waiting, without tying up a whole working thread just to hold an idle connection open. It's the mechanic who doesn't stand rooted next to a car that's only waiting for an order; he watches several waiting cars at once and only acts when one of them actually needs him. Efficient for keep-alive, tuned for high concurrency, with native HTTP/2 support, but it demands thread-safe modules and is more complex to configure.

The three MPMs, side by side

Finding and switching the active MPM

# Shows which MPM is compiled in / active right now (trimmed output)
$ apachectl -V | grep -i mpm
Server MPM:     event
 
# On Debian/Ubuntu, a2query shows which MPM module is enabled
$ sudo a2query -M
event

Essential commands for this stage

Hands-on

Find the active MPM, switch it, and run Apache Bench before and after: the same machine stopping in 2 seconds or 4, just from how you scaled the crew. Garage warning: this exercise uses a2enmod/a2dismod and apachectl, commands that act on an Apache installed on the host (sudo apt install apache2), not on the httpd:latest container from Stage 01. Step 3 also uses ab: if it's not installed, run sudo apt install apache2-utils before you get there.

1. Run apachectl -V | grep -i mpm (or httpd -V | grep -i mpm, depending on the distro) on your Apache and note which MPM is active right now.
2. If your system is Debian/Ubuntu, switch the active MPM with a2dismod/a2enmod and confirm the switch with a2query -M.
3. Run a simple load test against the same Apache, before and after the MPM switch: ab -n 500 -c 50 http://localhost/. Compare the Requests per second and Time per request lines between the two runs. Don't expect a magic number: the point is to feel that the same machine behaves differently just because of the MPM chosen, the same feeling as a pit stop that comes out in 2 seconds or in 4 depending on how the crew was scaled.

An isolated box per car, a shared bench per crew, or a mechanic watching several waiting cars at once: you can already pick the garage layout to match the race. All that's left is the final fast corner, where Nginx shows why it was born for this era. Stage 05.

Stage 05 the event-loop fast corner

Nginx and its event-driven architecture

The final split of the lap, and this is where the grid's leanest chassis shines. Nginx follows F1 designers' golden rule: simplify first, then strip out every gram of weight that doesn't need to be there. Let's watch this car through its best corner.

Scenario: an application with lots of long-lived, mostly idle simultaneous connections (real-time chat, push notifications, keep-alive for mobile app APIs). Even with Apache's Event MPM cutting the cost of idle connections, the model is still built on reserving one thread for every connection being actively processed. Scaling to tens of thousands of simultaneous connections means scaling, in the same proportion, the number of threads and the memory they eat, until you hit the practical limit of how many threads can coexist efficiently. Imagine wanting one dedicated engineer per car to monitor tens of thousands of cars at once: no pit wall can hold that. That's the exact problem Nginx was built from scratch to solve. While Apache started life as a traditional web server and picked up concurrency models over time, Nginx was designed from day one with a modern architecture in mind, built specifically to serve static content and act as a reverse proxy under heavy concurrency.

How it works

Nginx's core difference is its asynchronous, event-driven architecture, quite unlike the dedicated thread- or process-per-connection model. Analogy: picture a race engineer at the telemetry wall, the giant board showing every car's telemetry at once. He doesn't stand there staring at a single car waiting for something to happen. He sweeps the whole board and only acts when an event fires: a tire-temperature alert on Russell's car, an undercut request from Antonelli's. One engineer can monitor the entire grid this way, because he's never blocked waiting on just one car.

On Apache, every active connection tends to hold a dedicated thread or process for as long as it lasts (even the Event MPM only reserves a thread for the request being actively processed, it just avoids spending a whole thread on connections that are merely idle). With 10,000 users connected at once, you need to sustain a meaningful fraction of 10,000 threads or processes eating memory. It would be like wanting one engineer per car for a grid of ten thousand cars.

On Nginx, non-blocking I/O: when an I/O operation is needed (reading from disk, waiting on a backend's response), the worker registers the event and moves on to another connection, instead of standing there waiting. The engineer logs "let me know when car X's data comes in" and goes straight to watching car Y. The event loop is the loop each worker process runs, handling thousands of connections with few resources, the continuous sweep of the telemetry wall. When the event is ready, the worker gets notified and picks up exactly where it left off: the alert flashes on the board, the engineer reacts on that car, and goes back to sweeping the rest.

This approach makes Nginx extremely efficient, especially for keep-alive and idle connections, exactly this stage's scenario. Practical benefits: lower memory use, higher throughput, better latency, and excellent performance as a reverse proxy and load balancer, including in front of Apache itself.

One caveat, so as not to oversell it: at a real telemetry wall, a human engineer has limited attention and genuinely loses track with too many cars. Nginx's worker doesn't get tired: it processes every event in microseconds and goes back to the loop, and the bottleneck becomes CPU and memory, not attention. The engineer image is there to explain the event loop's logic, not to claim there's a human inside making it happen.

The pieces of the event-driven engine

Few processes, thousands of connections

 # /etc/nginx/nginx.conf (main excerpt)
worker_processes auto;   # 1 worker process per available CPU core
 
events {
    worker_connections 1024;   # each worker can handle up to 1024 simultaneous connections
    use epoll;                 # Linux kernel's event notification mechanism
}

Essential commands for this stage

Hands-on

Count the processes with ps aux, throw load at it with ab, and watch: the number of engineers at the wall doesn't budge, no matter how many cars show up. Garage warning: just like in Stage 03, this exercise reads config and watches processes for an Nginx installed on the host, not the nginx:latest container from Stage 01. Step 3 uses ab again: install it with sudo apt install apache2-utils if you haven't already in Stage 04.

1. Find your Nginx's nginx.conf (nginx -t shows the path at the top of its output) and locate the worker_processes and worker_connections directives.
2. Run ps aux | grep '[n]ginx' and count how many processes show up. Compare with nproc (your machine's core count): the worker count is usually equal to or close to it. As many engineers as available cores.
3. Generate load with several simultaneous connections: ab -n 1000 -c 200 http://localhost/. While the test runs, run ps aux | grep '[n]ginx' in a second terminal. Notice: the process count doesn't change, even with hundreds of simultaneous connections hitting the server. The same engineers at the wall, whether more cars show up or not.
4. If you have access to an Apache for the same kind of test, repeat the load there and run ps aux | grep '[a]pache2\|[h]ttpd'. Depending on the configured MPM, notice the process or thread count grow along with the load, unlike what happened with Nginx. There, the garage hires mechanics as traffic picks up; here, the wall keeps running with the same crew.

A handful of processes, one event loop, and Nginx dominating the edge of anything, including Apache itself. You've crossed the whole track, from static content to the event loop. Pack up the pit board, go over the debrief at your own pace, and see you at the next race on the calendar.