Web Server
A web server is software, and by extension the machine running it, that listens for HTTP and HTTPS requests from clients such as browsers and returns responses: files stored on disk, pages assembled by a program, or data from an API. It is the receiving end of the web's request-and-response conversation, the thing that makes a domain name lead to actual content.
The simplest job is serving static content: map the requested path to a file, read it, and send it with the right headers. Images, stylesheets, scripts and prebuilt HTML pages need no computation, so a server can answer them extremely quickly, cache them, and compress them; content delivery networks exist largely to replicate such files near users. The first web servers worked this way. Tim Berners-Lee's CERN httpd came from the original Web project, and NCSA's httpd, from the same group that built the Mosaic browser, spread quickly in the early 1990s and became the starting point for the Apache project.
Dynamic content means the response is computed per request, so the web server must hand work to program code. The earliest mechanism was CGI, the Common Gateway Interface, which launched a separate program for each request, passing it the request details and returning its output; it was simple but costly. Later designs keep long-running application processes instead: the web server forwards requests over a protocol such as FastCGI, or to an application server running Python, Java, PHP, Ruby, Node.js or Go code, which queries databases, applies business logic and renders the page or JSON. Modern machine-learning services follow the same shape, with a web layer accepting requests and passing inputs to a model-serving process.
Apache and nginx are the two best-known web servers, and their designs reflect different eras. The Apache HTTP Server, first released in 1995 as a set of patches to NCSA httpd, became the most widely used server of the late 1990s and 2000s, with a modular architecture and per-directory configuration files. nginx, written by Igor Sysoev and first released publicly in 2004, was built to address the C10k problem, named by Dan Kegel around 1999: how to handle ten thousand concurrent connections. Instead of dedicating a process or thread to each connection, nginx uses an event-driven design where a few workers multiplex thousands of sockets. Other servers include Microsoft's IIS, Caddy, which automates HTTPS certificates, and the built-in servers of programming frameworks.
In production the web server rarely stands alone; it is one stage in a chain. A reverse proxy sits in front of application servers to terminate TLS, balance load, compress responses, enforce rate limits and absorb slow clients. Load balancers distribute traffic across many machines, and caches, firewalls and content delivery networks sit around the edges. Cloud platforms hide much of this behind managed services, and serverless products invoke a function per request, but under the abstraction a process is still listening on a port and speaking HTTP.
Several mistakes recur. "Web server" means both the software and the computer, and context decides which is meant, so one machine can run many server programs and one site can span thousands of machines. Development servers bundled with frameworks, which are convenient for testing, are not hardened or fast enough for production, and exposing one to the Internet is a classic error. Misconfiguration causes most real incidents: serving a directory listing, leaving a backup file or secret in the document root, running as an all-powerful user, or forgetting to redirect HTTP to HTTPS. And a web server is not a database or a website: it delivers a site's content but does not itself decide what the content means.
Read a web server as the listening end of HTTP: a program on an open port that turns each request into a response by reading a file or delegating to application code, and that, in practice, is the front door guarding everything behind it.