What is the difference between application server and web server?

Most of the times these terms Web Server and Application server are used interchangeably.

Following are some of the key differences in features of Web Server and Application Server:

• Web Server is designed to serve HTTP Content. App Server can also serve HTTP Content but is not limited to just HTTP. It can be provided other protocol support such as RMI/RPC
• Web Server is mostly designed to serve static content, though most Web Servers have plugins to support scripting languages like Perl, PHP, ASP, JSP etc. through which these servers can generate dynamic HTTP content.
• Most of the application servers have Web Server as integral part of them, that means App Server can do whatever Web Server is capable of. Additionally App Server have components and features to support Application level services such as Connection Pooling, Object Pooling, Transaction Support, Messaging services etc.
• As web servers are well suited for static content and app servers for dynamic content, most of the production environments have web server acting as reverse proxy to app server. That means while servicing a page request, static contents (such as images/Static HTML) are served by web server that interprets the request. Using some kind of filtering technique (mostly extension of requested resource) web server identifies dynamic content request and transparently forwards to app server

Example of such configuration is Apache Tomcat HTTP Server and Oracle (formerly BEA) WebLogic Server. Apache Tomcat HTTP Server is Web Server and Oracle WebLogic is Application Server.

In some cases the servers are tightly integrated such as IIS and .NET Runtime. IIS is web server. When equipped with .NET runtime environment, IIS is capable of providing application services.

Both terms are very generic, one containing the other one and vice versa in some cases.

• Web server: serves content to the web using http protocol.

• Application server: hosts and exposes business logic and processes.

I think that the main point is that the web server exposes everything through the http protocol, while the application server is not restricted to it.

That said, in many scenarios you will find that the web server is being used to create the front-end of the application server, that is, it exposes a set of web pages that allow the user to interact with the business rules found into the application server.

As Rutesh and jmservera pointed out, the distinction is a fuzzy one. Historically, they were different, but through the 90's these two previously distinct categories blended features and effectively merged. At this point is is probably best to imagine that the "App Server" product category is a strict superset of the "web server" category.

Some history. In early days of the Mosaic browser and hyperlinked content, there evolved this thing called a "web server" that served web page content and images over HTTP. Most of the content was static, and the HTTP 1.0 protocol was just a way to ship files around. Quickly the "web server" category evolved to include CGI capability - effectively launching a process on each web request to generate dynamic content. HTTP also matured and the products became more sophisticated, with caching, security, and management features. As the technology matured, we got company-specific Java-based server-side technology from Kiva and NetDynamics, which eventually all merged into JSP. Microsoft added ASP, I think in 1996, to Windows NT 4.0. The static web server had learned some new tricks, so that it was an effective "app server" for many scenarios.

In a parallel category, the app server had evolved and existed for a long time. companies delivered products for Unix like Tuxedo, TopEnd, Encina that were philosophically derived from Mainframe application management and monitoring environments like IMS and CICS. Microsoft's offering was Microsoft Transaction Server (MTS), which later evolved into COM+. Most of these products specified "closed" product-specific communications protocols to interconnect "fat" clients to servers. (For Encina, the comms protocol was DCE RPC; for MTS it was DCOM; etc.) In 1995/96, these traditional app server products began to embed basic HTTP communication capability, at first via gateways. And the lines began to blur.

Web servers got more and more mature with respect to handling higher loads, more concurrency, and better features. App servers delivered more and more HTTP-based communication capability.

At this point the line between "app server" and "web server" is a fuzzy one. But people continue to use the terms differently, as a matter of emphasis. When someone says "web server" you often think HTTP-centric, web UI, oriented apps. When someone says "App server" you may think "heavier loads, enterprise features, transactions and queuing, multi-channel communication (HTTP + more). But often it is the same product that serves both sets of workload requirements.

• WebSphere, IBM's "app server" has its own bundled web server.
• WebLogic, another traditional app server, likewise.
• Windows, which is Microsoft's App Server (in addition to being its File&Print Server, Media Server, etc.), bundles IIS.

In short,
The web server is a server that serves static web pages to users via HTTP requests.
The application server is a server that hosts the business logic for a system.
It often hosts both long-running/batch processes and/or interop services not meant for human consumption (REST/JSON services, SOAP, RPC, etc).

An application server is typically designed and deployed to facilitate longer running processes that will also be more resource intensive.

A web server is used for short bursts that are not resource intensive, generally. This is mostly to facilitate serving up web based traffic.

A web server runs the HTTP protocol to serve web pages. An application server can (but doesn't always) run on a web server to execute program logic, the results of which can then be delivered by the web server. That's one example of a web server/application server scenario.

A good example in the Microsoft world is the Internet Information Server / SharePoint Server relationship. IIS is a web server; SharePoint is an application server. SharePoint sits "on top" of IIS, executes specific logic, and serves the results via IIS.

In the Java world, there's a similar scenario with Apache and Tomcat, for example.

An application server is a machine (an executable process running on some machine, actually) that "listens" (on any channel, using any protocol), for requests from clients for whatever service it provides, and then does something based on those requests. (may or may not involve a respose to the client)

A Web server is process running on a machine that "listens" specifically on TCP/IP Channel using one of the "internet" protocols, (http, https, ftp, etc..) and does whatever it does based on those incoming requests... Generally, (as origianly defined), it fetched/generated and returned an html web page to the client, either fetched from a static html file on the server, or constructed dynamically based on parameters in the incoming client request.

Basic understanding :

In client server architecture

Server :> Which serves the requests.

Client :> Which consumes service.

Web server & Application server are both software applications which act as servers to their clients.

They got their names based on their place of utilization.

Web server :> serve web content
           :> Like Html components
           :> Like Javascript components
           :> Other web components like images,resource files
           :> Supports mainly web protocols like http,https.
           :> Supports web Request & Response formats.

Usage --

      we require low processing rates,

      regular processing practices involves.

Eg: All flat servers generally available ready-made which serves only web based content.

Application server :> Serve application content/component data(Business data).
                   :> These are special kind which are custom written 
                      designed/engineered for specific
                      purpose.some times fully unique in 
                      their way and stands out of the crowd. 

                   :> As these serves different types of data/response contents
                   :> So we can utilize these services for mobile client,web 
                      clients,intranet clients. 
                   :> Usually application servers are services offered on different 
                      protocols.    
                   :> Supports different Request& Response formats.

Usage --

      we require multi point processing,

      specialized processing techniques involves like for AI.

Eg: Google maps servers, Google search servers,Google docs servers,Microsoft 365 servers,Microsoft computer vision servers for AI.

We can assume them as tiers/Hierarchies in 4-tier/n-tier architecture.

 So they can provide 
                    load balancing,
                    multiple security levels,
                    multiple active points,
                    even they can provide different request processing environments.

Please follow this link for standard architecture analogies:

https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658120(v%3dpandp.10)

IMO, it's mostly about separating concerns.

From a purely technical point of view, you can do everything (web content + business logic) in a single web server. If you'd do that, then the information would be embedded inside requested the HTML content. What would be the impact?

For example, imagine you have 2 different apps which renders entirely different HTML content on the browser. If you would separate the business logic into an app-server than you could provide different web-servers looking up the same data in the app-server via scripts. However, If you wouldn't separate the logic and keep it in the web-server, whenever you change your business model, you would end up changing it in every single web-server you have which would take more time, be less reliable and error-prone.

Application server and web server both are used to host web application. Web Server is deal with web container on the other hand Application Server is deal with web container as well as EJB (Enterprise JavaBean) container or COM+ container for Microsoft dot Net.

Web Server is designed to serve HTTP static Content like HTML, images etc. and for the dynamic content have plugins to support scripting languages like Perl, PHP, ASP, JSP etc and it is limited to HTTP protocol. Below servers can generate dynamic HTTP content.

Web Server's Programming Environment:

IIS : ASP (.NET)

Apache Tomcat: Servlet

Jetty: Servlet

Apache: Php, CGI

Application Server can do whatever Web Server is capable and listens using any protocol as well as App Server have components and features to support Application level services such as Connection Pooling, Object Pooling, Transaction Support, Messaging services etc.

Application Server's Programming Environment:

MTS: COM+

WAS: EJB

JBoss: EJB

WebLogic Application Server: EJB

• web server: for every URL, it returns a file. That's all it does. The file is static content, meaning, it is stored somewhere in the server, before you make your request. Most popular web servers are apache http and nginx.
• application server: for every URL, it runs some code, written in some language, generates a response, and returns it. The response doesn't exist in advance, it is generated for your particular request, that is, it is dynamic content. Application servers are different for each language. Some popular examples are tomcat/jetty for java, uwsgi/gunicorn for python.

Almost every page you visit uses both. The static content (eg, images, videos) is served by the web server, and the rest (the parts that are different between you and other users) are generated by the application server.

IBM makes a really nice comparison between the two:

By strict definition, a web server is a common subset of an application server.

A web server delivers static web content—e.g., HTML pages, files, images, video—primarily in response to hypertext transfer protocol (HTTP) requests from a web browser.

An application server typically can deliver web content too, but its primary job is to enable interaction between end-user clients and server-side application code—the code representing what is often called business logic—to generate and deliver dynamic content, such as transaction results, decision support, or real-time analytics. The client for an application server can be the application’s own end-user UI, a web browser, or a mobile app, and the client-server interaction can occur via any number of communication protocols.

In practice, however, the line between web servers and application servers has become fuzzier, particularly as the web browser has emerged as the application client of choice and as user expectations of web applications and web application performance have grown.

Most web servers support plug-ins for scripting languages (e.g., ASP, JSP, PHP, Perl) that enable the web server to generate dynamic content based on server-side logic. And an increasing number of application servers not only incorporate web server capabilities, but use HTTP as their primary protocol and support other protocols (e.g., CGI and CGI variants) for interfacing with web servers. They also allow web applications to leverage services like reverse proxy, clustering, redundancy, and load balancing—services that improve performance and reliability and allow developers to focus less on infrastructure and more on coding.

To make matters more confusing, many web servers and some application servers are referred to, or refer to themselves, as web application servers.

The bottom line is that today’s most popular web servers and application servers are hybrids of both. Most of the increasingly rich applications you use today feature a combination of static web content and dynamic application content, delivered via a combination of web server and application server technologies.

Drawing my conclusion from posts of awesome SO evangelists above, I conclude that both are software that resides on actual metal servers(physical servers). Both work hand in hand to get service to the end-user. Then, depending on the setup, we can choose what to call it, which means how to describe it depends on the actual setup in use. If they both reside on the same bare metal(physical server), we call it web and application server...simple! If on separate machines, obviously, we have two distinct bare metals(physical servers) at our hands. Then we can label these servers according to their function: one web server and the other application server.