A web server is software that accepts HTTP and HTTPS requests from clients such as browsers, mobile apps and API consumers and returns responses: static files, pages generated by an application, redirects or error messages. Among web servers, the best-known implementations are Nginx, Apache HTTP Server, Microsoft IIS, LiteSpeed and Caddy, and in the wider subject of servers the term also loosely refers to the machine that runs such software.
The web server is the front door of almost every website and web application. It terminates TLS encryption, maps URLs to resources, enforces access rules, compresses and caches content and hands dynamic requests to application code through interfaces such as FastCGI, PHP-FPM or a reverse proxy connection.
How a web server handles a request
Every request follows the same basic request-response cycle. The server listens on a TCP port, usually 80 for HTTP and 443 for HTTPS, accepts the connection, negotiates TLS if required, parses the HTTP request line and headers and decides how to answer based on its configuration.
- Accept and decrypt: the server accepts the connection and completes the TLS handshake.
- Select the site: the Host header or SNI name selects the matching virtual host.
- Map the URL: rewrite rules and location blocks decide whether the path is a file, a script or a proxied backend.
- Apply rules: authentication, access control, rate limits and headers are evaluated.
- Produce the response: the server reads a file, calls an application or forwards the request.
- Send and log: the response is compressed if allowed, sent to the client and recorded in the access log.
Modern servers support HTTP/1.1, HTTP/2 and increasingly HTTP/3 over QUIC. HTTP/2 and HTTP/3 multiplex many requests over one connection, which reduces the number of connections a server must manage and improves page load times.
Static content, dynamic content and application interfaces
A web server delivers static content directly from disk or memory with very little work, which is why a single server can handle thousands of such requests per second. Dynamic content requires application code, and the web server must pass the request to a separate runtime and relay its answer.
The table below compares the main ways a web server connects to application code.
| Interface | How it works | Typical use |
|---|---|---|
| Embedded module | Interpreter runs inside the server process | Apache with mod_php, legacy setups |
| FastCGI | Persistent worker pool over a socket | PHP-FPM behind Nginx or Apache |
| Reverse proxy over HTTP | Requests forwarded to an app server | Node.js, Gunicorn, Apache Tomcat |
| uWSGI protocol | Binary protocol to Python workers | Python applications with uWSGI |
| CGI | New process for every request | Rare today, too slow for production |
Separating the web server from the application runtime lets each part scale and restart independently. The web server absorbs slow clients, buffers uploads and serves static assets, while the application workers spend their time only on business logic.
Process models and popular web server software
The internal concurrency model determines how a web server behaves under load. Older designs dedicate a process or thread to each connection, while event-driven servers handle thousands of connections in a few worker processes using non-blocking input and output.
| Server | Concurrency model | Notable strengths |
|---|---|---|
| Nginx | Event-driven workers | Static files, reverse proxy, low memory |
| Apache HTTP Server | Prefork, worker or event MPM | Modules, .htaccess, flexible configuration |
| LiteSpeed Web Server | Event-driven | Apache compatibility, built-in page cache |
| Caddy | Event-driven, written in Go | Automatic HTTPS certificates |
| Microsoft IIS | Kernel-mode HTTP stack | Windows and .NET integration |
The difference matters most with many idle keep-alive connections. A thread-per-connection server spends memory on each waiting client, whereas an event-driven server keeps memory use nearly flat as connection counts grow.
Web server compared with related components
The term web server overlaps with several neighboring components, and many products play more than one role. The distinction lies in what the component does with a request, not in the product name.
| Component | Primary job | Relationship to a web server |
|---|---|---|
| Web server | Answers HTTP requests | Serves files and fronts applications |
| Application server | Runs business logic | Sits behind the web server |
| Reverse proxy | Forwards requests to backends | A role most web servers can take |
| Load balancer | Spreads traffic across servers | Often placed in front of web servers |
| CDN edge server | Caches content near users | A distributed web server and cache |
In a typical stack, Nginx terminates TLS and serves assets, then proxies application requests to PHP-FPM, Gunicorn or a Java container. The same Nginx binary may act as web server, reverse proxy and load balancer at once.
Configuration, security and common mistakes
Most web server incidents come from configuration rather than software defects. A hardened server keeps its software patched, exposes only the needed ports, uses modern TLS settings and limits what it reveals about itself.
- Directory listing left enabled, exposing backups and configuration files.
- Weak TLS settings, such as allowing TLS 1.0 or outdated cipher suites.
- Missing security headers such as Strict-Transport-Security and Content-Security-Policy.
- Overly broad rewrite rules that create redirect loops or expose internal paths.
- Undersized worker or connection limits, causing queued requests and timeouts under load.
- Running application code as the server user, so one compromised script can modify the whole site.
Performance tuning focuses on keep-alive timeouts, worker counts, compression and caching headers. Measuring with access logs and load tests is more reliable than copying settings from another server, because the right values depend on memory, traffic shape and the application behind it.
Stripped to the essentials
When you type an address into your browser, your computer sends a request across the internet asking for a page. The web server is the program on the other end that answers. It is a bit like a reception desk: it reads each request, finds the right document or asks a colleague in the back office to prepare one, and hands the result back.
Simple things, such as images and style files, it fetches itself in an instant. More complex things, such as your shopping cart, it passes to the application and then delivers the answer. Every website you visit depends on one.
Where it is applied
An online bookstore runs its shop on a PHP application. During a seasonal sale, pages slow to several seconds and the server runs out of memory. Investigation shows Apache in prefork mode with mod_php, so every connection, even one downloading a small image, holds a full PHP interpreter in memory.
The team places Nginx in front as the web server, lets it serve all images, scripts and style files directly and passes only PHP requests to a PHP-FPM pool of 40 workers. It also enables HTTP/2, Brotli compression and long cache lifetimes for versioned assets. Memory use falls by more than half, and the sale traffic is handled with page responses well under one second.