When one tool absorbs several responsibilities, the labels web server, web application server (WAS), and reverse proxy get blurry.

The three labels split by the problem each solves, not by tool name. Serving static content, generating dynamic content, and mediating traffic are different problems. Depending on which responsibility a tool takes on, the same name can fall under different labels.

Web Server

A web server receives HTTP requests and returns responses. Its core job is sending static files — HTML, CSS, JavaScript, images — straight from disk.

Apache HTTP Server, nginx, and lighttpd are the common examples. They read files from the OS file system and put them into HTTP response bodies. They also handle protocol-level optimizations: HTTP caching, gzip compression, range requests.

Request handling models differ across tools. Apache’s prefork MPM spawns a process per request. nginx uses an event-driven asynchronous model. Under high concurrency the event-driven approach is more memory-efficient, but for simple static responses the gap narrows.

A web server itself does not generate dynamic content. PHP pages — or any response computed per request — get routed to a separate handler.

Web Application Server

A WAS produces dynamic content. It runs business logic on each request, pulls data from a database, and assembles a response. Unlike static file delivery, the result can change with every call.

In the Java world, Tomcat, Jetty, and WebLogic are the typical WAS choices. Python’s Gunicorn with a WSGI app and Node.js’s Express take on the same responsibility. The runtime differs, but the flow — request → business logic → response — is shared.

A WAS can also accept HTTP requests directly. Tomcat ships with an HTTP connector and listens on port 8080 by default. In production it usually sits behind a web server or reverse proxy. Static file delivery goes to whichever side handles it faster, while the WAS focuses on dynamic work.

Session management, transactions, connection pooling — the business-logic infrastructure also lives in the WAS. None of that belongs to a web server.

Reverse Proxy

A reverse proxy stands between clients and backends and mediates requests. The client sends to the reverse proxy as if it were the backend, and the reverse proxy forwards the request to an appropriate backend and returns the response.

The mediation itself matters less than the features that attach to it: load balancing, SSL/TLS termination, caching, authentication and authorization, request rewriting. When several backends sit behind the same reverse proxy, the client sees one address and the reverse proxy decides where each request goes.

nginx and HAProxy are the common examples. nginx doubles as a web server, while HAProxy focuses on reverse-proxy and load-balancing duties.

A reverse proxy does not generate dynamic content and does not own static file delivery. It mediates the traffic flow and controls the flow itself.

nginx + Tomcat in Practice

In production the three responsibilities sometimes collapse into one tool and sometimes split across many. nginx covers both web server and reverse proxy duties, so you do not need to run them as separate processes. Putting nginx in front of a WAS (Tomcat, Spring Boot, etc.) is the most common arrangement.

flowchart LR
    Client[Client] --> Nginx[nginx
reverse proxy + static content]
    Nginx -->|static files| Disk[(disk)]
    Nginx -->|dynamic requests| Tomcat[Tomcat
WAS]
    Tomcat --> DB[(database)]

Here nginx serves HTML, CSS, JavaScript, and images while also mediating traffic — SSL termination, load balancing. Tomcat runs Java servlets and business logic. The three responsibilities divide across two tools.

How far the split goes depends on scale. Low-traffic setups can run Tomcat alone with no nginx in front. Higher-traffic setups separate web server and reverse proxy, or put an L4 load balancer in front of the reverse proxy.

Closing

Three tools can sit in the same place yet solve different problems. Which tool owns serving static content, which owns dynamic generation, and which owns traffic mediation depends on the deployment. Mapping the responsibilities first makes the placement easier to settle.

References