Web Server Fundamentals

A web server is the software that answers HTTP requests. A client — usually a browser, but also crawlers, API clients, and other servers — sends a request for a resource identified by a URL. The web server decides what to do with that request: serve a file from disk, generate content by handing the request to an application, redirect the client elsewhere, or return an error. The term is also used for the machine running that software, but the meaningful boundary is the software: the same hardware can run many web server instances, and the same web server can serve many sites.

The useful mental model is a URL-to-response engine with a rulebook. The rulebook is the server's configuration. Every request arrives carrying a method, a path, headers, and optionally a body. The server matches the request against its rules, produces an HTTP response — a status code, headers, and a body — and closes or reuses the connection. Everything else a web server does (TLS, virtual hosting, compression, caching, proxying) is a specialization of that loop.

Why web servers exist

The earliest web servers did one job: map a URL to a file on disk and send the bytes back. That model still works for static content — HTML, images, CSS, JavaScript — and a file-serving web server is still the right tool for static sites, single-page applications, and asset delivery.

Three pressures pushed web servers beyond plain file serving:

• Dynamic content — pages whose content depends on the request (a logged-in user's profile, search results, a shopping cart). The server hands the request to an application process that builds the response, often pulling data from a database. The web server sits in front of that application and relays the request and response.
• Scale and security — a single application process cannot hold thousands of concurrent connections, terminate TLS efficiently, and shield itself from the public internet at the same time. A web server in front absorbs the connection and TLS work, then forwards plain HTTP to the backend.
• Many sites on one host — HTTP/1.1 added the Host header so one web server listening on one address and port can serve many sites, selecting among them by the requested host name. This is virtual hosting, and it is why one web server instance fronts a whole platform instead of one site.

These pressures produced the two shapes you meet everywhere today: the static web server (file server plus TLS) and the dynamic web server (static server plus an application server and a database behind it). A web server is not a single product; it is a role.

The request/response loop

Regardless of which server software you run, the processing loop is the same:

1. accept a TCP connection on a listening address and port
2. (optionally) perform a TLS handshake over that connection
3. read an HTTP request: method, target, headers, optional body
4. match the request against configured rules (virtual host, path, method)
5. produce a response: serve a file, proxy to a backend, redirect, or error
6. write an HTTP response: status code, headers, body
7. close the connection, or keep it open and reuse it for the next request

The transport is TCP (or, for HTTP/3, QUIC over UDP). HTTP itself does not require a connection-based transport; it requires only that messages arrive reliably and in order. TCP provides that, so HTTP/1.x and HTTP/2 run over TCP. HTTP/3 runs over QUIC, which builds reliability and stream multiplexing on top of UDP instead.