Web Server vs. Application Server: What's the Difference?

Performance

Web servers are tailored to be performant, responding to as many requests as possible in the shortest amount of time, with as little resource utilization as possible. To do this, they are designed with simplicity in mind. By default, when the web server receives a request, it will try to serve the requested file from the file system. For example, if my web server is configured to serve files from/var/www/public/html, I can request a file index.html by sending an HTTP request tomysite.com/index.html. If the file exists in/var/www/public/html, the web server will read and transmit that file to the requesting client, along with some metadata known as HTTP response headers.

In a more advanced scenario, the web server may be configured to pass the request to a program capable of handling it appropriately. For example, I may have a perl application that renders a response to a request formysite.com/cgi-bin/todaysDatethat responds with a template showing the current date and time.  

Ultimately, individual web servers are bound to IP addresses and ports, listening for requests on common ports like TCP/80 for HTTP and TCP/443 for HTTPS. They can have many unique names assigned to them, even on the same IP address and port, which is handled through a concept called virtual servers. Web servers also provide an environment where a server-side program, like PHP, perl, python, and others, can execute and send back responses.  

Configuration

Web servers are usually easy to configure. Many enterprise applications rely on web servers to directly respond to requests for static files, as opposed to dynamic files which are “proxied” to application servers. A static file is the same every time it’s requested — for example, the logo for a company’s website — and is generally a logical file on a directory on a disk attached to the web server. A dynamic response is generated every time the path is requested, like the perl example generating the date and time. The simplicity of a static request aids in the overall performance of a web server. A web server is designed to respond to a request rapidly, with little overhead. 

When developers deploy web servers with application servers, they often keep the functionality of the web server and the application server separate. This is typically viewed as the best way to increase performance, as the web server fulfills the roll of rapidly responding to HTTP/S requests and the app server can be left to do what app server does best: generate dynamic content.  

While a web server mainly deals with sending static files to a web browser, the application server generates responses according to business logic that is dynamic, and can change depending on the parameters of the request from a web browser client. 

As application server workloads are more complicated than web server workloads, they are usually configured to have more CPU, memory, and disk resources compared to web servers. Application servers often require load balancing, which helps to distribute requests to across multiple servers, distributing the entire applications current load and maximizing availability. Web servers are often placed in front of application servers to provide this load balancing functionality. 

Application server functionality often includes features not found in web servers such as messaging, security, connection pooling to databases, support for transactions, batch processing, scheduled tasks, and job queues. Application servers can employ scalability strategies, like load balancing, and fault-tolerance techniques, like shared sessions, to enable high availability. These functionalities are often enabled by web servers, but require the application server to be configured to take advantage of the features (such as load balancing) that the web server, configured as a web proxy, provides. This allows application servers to handle increasing numbers of users simultaneously and sustain performance when traffic grows.