由于 Web 服务器非常适合静态内容，而应用程序服务器非常适合动态内容，因此大多数生产环境都具有 Web服务器充当应用程序服务器的反向代理。这意味着在服务页面请求时，静态内容（例如图像/静态 HTML）由解释请求的 Web 服务器提供。使用某种过滤技术（主要是请求资源的扩展）Web 服务器识别动态内容请求并透明地转发到应用程序服务器
此类配置的示例是 Apache Tomcat HTTP Server 和 Oracle（以前称为 BEA）WebLogic Server。 Apache Tomcat HTTP Server 是 Web 服务器，Oracle WebLogic 是应用程序服务器。
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.
应用程序服务器这个术语有时会与网络服务器混合使用。虽然 Web 服务器主要处理 HTTP 协议，但应用程序服务器处理多种不同的协议，包括但不限于 HTTP。
Web服务器的主要工作是显示网站内容，应用服务器负责逻辑，即用户与显示内容之间的交互。应用程序服务器与 Web 服务器协同工作，其中一个服务器显示，另一个服务器交互。
服务器与其客户端之间来回传输的信息不限于简单的显示标记，还包括两者之间的交互。
在大多数情况下，服务器通过组件 API 创建此交互，例如J2EE（Java 2 平台）、EJB ( Enterprise JavaBean）和其他不同的应用软件模型。
示例：
最好的要了解应用程序服务器与 Web 服务器一起使用的场景与没有应用程序服务器的场景之间的区别，可以通过在线商店来了解。
场景 1：不使用应用程序服务器的 Web 服务器应用程序服务器
您有一个只有 Web 服务器而没有应用程序服务器的在线商店。该网站将提供一个显示屏，您可以从中选择产品。当您提交查询时，站点会执行查找并将 HTML 结果返回给其客户端。 Web 服务器将您的查询直接发送到数据库服务器（请耐心等待，我将在下一篇文章中解释这一点）并等待响应。收到后，Web 服务器会将响应制定为 HTML 文件并将其发送到您的 Web 浏览器。每次运行查询时，服务器和数据库服务器之间都会发生这种来回通信。
场景 2：带有应用程序服务器的 Web 服务器
如果您要运行的查询之前已经完成，并且此后没有数据发生更改，则服务器将生成结果，而无需必须将请求发送到数据库服务器。这允许实时查询，第二个客户端可以访问相同的信息并接收实时、可靠的信息，而无需向数据库服务器发送另一个重复的查询。服务器基本上充当数据库服务器和 Web 服务器之间的中间人。这允许在第一种情况下提取的信息可重用，因为该信息嵌入在特定的“定制”HTML 页面中，所以这不是可重用的过程。第二个客户端将不得不再次请求信息并接收另一个包含所请求信息的 HTML 嵌入页面 - 效率极低。更不用说这种类型的服务器非常灵活，因为它能够管理自己的资源，包括安全性、事务处理、消息传递和资源池。
This is a detailed answer with some scenarios to clearly understand the difference and similarity, and how both can work in conjunction.
Application Server is a term that sometimes is mixed with a web server. While a web server handles mainly HTTP protocols, the application server deals with several different protocols, including, but not limited, to HTTP.
The Web server's main job is to display the site content and the application server is in charge of the logic, the interaction between the user and the displayed content. The application server is working in conjunction with the web server, where one displays and the other one interacts.
The information traveling back and forth between the server and its client is not restricted to simple display markup, but to interaction between the two.
In most cases, the server creates this interaction through a component API, such as J2EE (Java 2 Platform), EJB (Enterprise JavaBean) and other different application software models.
An example:
The best way to understand the difference between the scenarios where an application server works with the web server versus a scenario where there isn't an application server is through an online store.
Scenario 1: Web server without an application server
you have an online store with only a web server and no application server. The site will provide a display where you can choose a product from. When you submit a query, the site performs a lookup and returns an HTML result back to its client. The web server sends your query directly to the database server (be patient, I will explain this one in our next nugget) and waits for a response. Once received, the web server formulates the response into an HTML file and sends it to your web browser. This back and forth communication between the server and database server happens every time a query is run.
Scenario 2: Web server with an application server
if the query you want to run has already been done previously and no data has changed since then, the server will generate the results without having to send the request to the database server. This allows a real-time query where a second client can access the same info and receive real time, reliable information without sending another duplicate query to the database server. The server basically acts as an intermediate between the database server and the web server. This allows the information pulled to be reusable while in the first scenario, since this info is embedded in a particular and "customized" HTML page, this is not a reusable process. A second client will have to request the info again and receive another HTML embedded page with the info requested -highly inefficient. Not to mention that this type of server is very flexible due to its ability to manage its own resources, including security, transaction processing, messaging and resource pooling.
To support such a variety of complex tasks this server must have a built in redundancy, great processing power and high amount of RAM to handle all the data it's pulling in real time.
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.
请注意，您实际上可以使用应用程序服务器的代码构建 Web 服务器。在开发过程中的某些情况下，您不希望计算机上运行大量不同的服务器，这是在某些情况下完成的。
Web server
Run python -m 'SimpleHTTPServer' and go to http://localhost:8080. What you see is a web server at its workings. The server simply serves files over HTTP stored on your computer. The key point is that all this is done on top of the HTTP protocol. There also exist FTP servers for example which do exactly the same thing (serving stored files) but on top of a different protocol.
Application server
Say we have a tiny application like below (snippet from Flask).
@app.route('/')
def homepage():
return '<html>My homepage</html>'
@app.route('/about')
def about():
return '<html>My name is John</html>'
The small example program maps the URL / to the function homepage() and the /about to the function about().
To run this code we need an application server (e.g. Gunicorn) - a program or module that can listen for requests from a client and using our code, return something dynamically. In the example we simply return some very bad HTML.
What's the business logic all the other people talk about? Well, since a URL maps to somewhere specifically in our codebase, we are hypothetically showing some logic about how our program works.
Recapping
web server - serves files stored somewhere (most commonly .css, .html, .js). Common web servers are Apache, Nginx or even Python's SimpleHTTPServer.
application server - serves files generated on the fly. Essentially most web servers have some sort of plugins or even come with built-in functionality to do that. There exist also strict application servers like Gunicorn (Python), Unicorn (Ruby), uWSGI (Python), etc.
Notice that you can actually build a web server with the code of the application server. This is done in some cases during development where you do not want to have a gazillion of different servers running on your computer.
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.
关键的区别在于应用程序服务器支持一些分布式组件技术，提供远程调用和分布式事务等功能，如EJB Java世界中的或微软平台上的COM+。 Http 服务器通常支持一些更简单的编程环境，通常是脚本，例如 Microsoft 或基于 Servlet 的 ASP (.NET)，包括 JSP 和许多其他 Java 或 PHP 的环境，以及 Apache 的 CGI。
其他功能，如负载平衡、集群、会话故障转移、连接池等，以前属于应用程序服务器领域，现在也可以直接或通过某些第三方产品在 Web 服务器上使用。
最后，值得注意的是，像 Spring Framework 这样的“轻量级容器”进一步扭曲了情况，这些容器通常以更简单的方式补充应用程序服务器的用途，并且不需要应用程序服务器基础设施。而且由于应用程序的分布方面正在从分布式组件转向服务范式和 SOA 架构，因此留给传统应用程序服务器的空间越来越少。
As many have said before, web servers handle HTTP petitions, while application servers handle petitions for distributed components.
So, maybe the easiest way to understand the difference is to compare the two products in regards to programming environment they offer.
Web Server -> Programming Environment
IIS : ASP (.NET)
Tomcat : Servlet
Jetty : Servlet
Apache : Php, CGI
Application Servers -> Programming Environment
MTS : COM+
WAS : EJB
JBoss : EJB
WebLogic Application Server : EJB
The crucial difference is that application servers support some distributed component technology, providing features like remote invocation and distributed transactions, like EJB in Java world or COM+ on Microsoft platform. Http server often support some more simple programming environments, often scripting, like ASP (.NET) in case of Microsoft or Servlet--based, including JSP and many other in case of Java or PHP and CGI in case of Apache.
Other capabilities like load-balancing, clustering, session-failover, connection pooling etc. that used to be in the realm of application servers, are becoming available on web servers as well directly or through some third party products.
Finally, it is worth noting that the picture is further distorted with "lightweight containers" like Spring Framework, that often supplement the purpose of application servers in more simple manner and without the application server infrastructure. And since distribution aspect in applications is moving from distributed component towards service paradigm and SOA architecture, there is less and less space left for traditional application servers.
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).
Web 服务器和应用程序服务器之间的主要区别在于，Web 服务器旨在提供静态页面（例如 HTML 和 CSS），而应用程序服务器负责通过执行服务器端代码（例如 JSP、Servlet 或 EJB）来生成动态内容。
我应该使用哪一个？
一旦了解了 Web 和应用程序服务器以及 Web 容器之间的区别，就很容易弄清楚何时使用它们。
如果您提供静态网页，则需要像 Apache HTTPD 这样的 Web 服务器。如果您有一个仅包含 JSP 和 Servlet 的 Java 应用程序来生成动态内容，那么您需要像 Tomcat 或 Jetty 这样的 Web 容器。然而，如果您有使用 EJB、分布式事务、消息传递和其他奇特功能的 Java EE 应用程序，那么您需要一个成熟的应用程序服务器，例如 JBoss、WebSphere 或 Oracle 的 WebLogic。
Web容器是Web服务器的一部分，Web服务器是应用程序服务器的一部分。
Web Server由Web容器组成，而Application Server由Web容器和EJB容器组成。
The main difference between Web server and application server is that web server is meant to serve static pages e.g. HTML and CSS, while Application Server is responsible for generating dynamic content by executing server side code e.g. JSP, Servlet or EJB.
Which one should i use?
Once you know the difference between web and application server and web containers, it's easy to figure out when to use them.
You need a web server like Apache HTTPD if you are serving static web pages. If you have a Java application with just JSP and Servlet to generate dynamic content then you need web containers like Tomcat or Jetty. While, if you have Java EE application using EJB, distributed transaction, messaging and other fancy features than you need a full fledged application server like JBoss, WebSphere or Oracle's WebLogic.
Web container is a part of Web Server and the Web Server is a part of Application Server.
Web Server is composed of web container, while Application Server is composed of web container as well as EJB container.
Web 服务器专门处理 HTTP/HTTPS 请求。它使用 HTTP/HTTPS 协议向 Web 提供内容。
应用服务器通过任意数量的协议（可能包括 HTTP）为应用程序提供业务逻辑。应用程序可以使用此逻辑，就像调用对象的方法一样。在大多数情况下，服务器通过组件 API 公开此业务逻辑，例如 Java EE（Java 平台企业版）应用程序服务器上的 EJB（企业 JavaBean）组件模型。
要点是，Web 服务器通过 http 协议公开所有内容，而应用程序服务器不限于此。
因此，应用程序服务器提供比 Web 服务器更多的服务，通常包括：（
专有或非专有）API
负载平衡、故障转移...
对象生命周期管理
状态管理（会话）
资源管理（例如到数据库的连接池）
大多数的应用程序服务器将 Web 服务器作为其不可分割的一部分，这意味着应用程序服务器可以执行 Web 服务器能够执行的任何操作。此外，应用程序服务器还具有支持应用程序级服务的组件和功能，例如连接池、对象池、事务支持、消息服务等。
应用程序服务器可以（但并不总是）在 Web 服务器上运行以执行程序逻辑、结果然后可以由网络服务器传送。这是 Web 服务器/应用程序服务器场景的一个示例。
Microsoft 世界中的一个很好的例子是 Internet Information Server / SharePoint Server 关系。 IIS 是一个网络服务器； SharePoint 是一个应用程序服务器。 SharePoint 位于 IIS“之上”，执行特定逻辑，并通过 IIS 提供结果。
例如，在 Java 世界中，Apache 和 Tomcat 也存在类似的情况。
由于 Web 服务器非常适合静态内容，而应用程序服务器非常适合动态内容，因此大多数生产环境都将 Web 服务器充当应用程序服务器的反向代理。这意味着在服务页面请求时，静态内容（例如图像/静态 html）由解释请求的 Web 服务器提供。使用某种过滤技术（主要是请求资源的扩展）Web 服务器识别动态内容请求并透明地转发到应用程序服务器。
此类配置的示例是 Apache HTTP Server 和 BEA WebLogic Server。 Apache HTTP Server 是 Web 服务器，BEA WebLogic 是应用程序服务器。
在某些情况下，服务器紧密集成，例如 IIS 和 .NET Runtime。 IIS 是网络服务器。当配备.NET运行环境时IIS能够提供应用程序服务
Web Server Programming Environment
Apache PHP, CGI
IIS (Internet Information Server) ASP (.NET)
Tomcat Servlet
Jetty Servlet
Application Server Programming Environment
WAS (IBM's WebSphere Application Server) EJB
WebLogic Application Server (Oracle's) EJB
JBoss AS EJB
MTS COM+
A Web server exclusively handles HTTP/HTTPS requests. It serves content to the web using HTTP/HTTPS protocol.
An application server serves business logic to application programs through any number of protocols, possibly including HTTP. The application program can use this logic just as it would call a method on an object. In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on Java EE (Java Platform, Enterprise Edition) application servers.
The main point is that the web server exposes everything through the http protocol, while the application server is not restricted to it.
An application server thus offers much more services than an web server which typically include:
A (proprietary or not) API
Load balancing, fail over...
Object life cycle management
State management (session)
Resource management (e.g. connection pools to database)
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.
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.
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 service a page request, static contents such as images/Static html is 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 HTTP Server and BEA WebLogic Server. Apache HTTP Server is Web Server and BEA 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
Web Server Programming Environment
Apache PHP, CGI
IIS (Internet Information Server) ASP (.NET)
Tomcat Servlet
Jetty Servlet
Application Server Programming Environment
WAS (IBM's WebSphere Application Server) EJB
WebLogic Application Server (Oracle's) EJB
JBoss AS EJB
MTS COM+
应用程序服务器向客户端公开业务逻辑。这意味着应用程序服务器包含一组执行业务逻辑的方法（但不完全如此，甚至可以是允许许多人在其上运行软件的联网计算机）。所以它只会输出想要的结果，而不是 HTML 内容。 （类似于方法调用）。所以它并不是严格基于 HTTP 的。
但 Web 服务器将 HTML 内容传递给 Web 浏览器（严格基于 HTTP）。 Web 服务器只能处理静态 Web 资源，但服务器端脚本的出现使得 Web 服务器也可以处理动态内容。 Web 服务器接收请求并将其定向到相关脚本（PHP、JSP、CGI 脚本等）以创建要发送到客户端的 HTML 内容。一旦接收到内容，Web 服务器就会将 HTML 页面发送到客户端。
然而，现在这两种服务器一起使用。
Web 服务器接收请求，然后调用脚本来创建 HTML 内容。然后，脚本将再次调用应用服务器LOGIC（例如检索交易详细信息）来填充HTML内容。
The border between these two are getting ever so thinner.
Application servers expose business logic to clients. That means application servers comprise of a set of methods (not exclusively though, can even be a networked computer allowing many to run software on it) to perform business logic. So it will simply output the desired results, not HTML content. (similar to a method call). So it is not strictly HTTP based.
But web servers pass HTML content to web browsers (Strictly HTTP based). Web servers were capable of handling only the static web resources, but the emergence of server side scripting allowed web servers to handle dynamic contents as well. Where a web server takes in the request and directs it to relevant scripts (PHP, JSP, CGI scripts, etc.) to CREATE HTML content to be sent to the client. Once the content is received, web server will send the HTML page to the client.
However, nowadays both these servers are used together.
Where web server takes the request and then calls a script to create the HTML content. Then, the script will again call an application server LOGIC (e.g. Retrieve transaction details) to fill the HTML content.
So both the servers are used effectively.
Therefore ....
We can safely say that nowadays, in most of the cases, web servers are used as a subset of application servers. BUT theoretically it is NOT the case.
I have read many articles about this topic and found this article quite handy.
用 Java 术语来说，还有一个：Web 容器（或更严格地说，Servlet 容器）。比如说，它位于 Web 服务器和应用程序服务器之间。
Java 术语中的 Web 容器是一个应用程序服务器，它基本上仅实现 Java EE 的 JSP/Servlet 部分，缺少 Java EE 的几个核心部分，例如 EJB 支持。 Apache Tomcat 就是一个例子。
In Java terms, there's one more: web container (or more strictly, servlet container). It's, say, in between web server and application server.
A web container in Java terms is an application server that basically only implements the JSP/Servlet part of Java EE and lacks several core parts of Java EE, such as EJB support. An example is Apache Tomcat.
Web 服务器运行 HTTP 协议来提供网页服务。应用程序服务器可以（但并不总是）在 Web 服务器上运行以执行程序逻辑，然后由 Web 服务器传递结果。这是 Web 服务器/应用程序服务器场景的一个示例。
Microsoft 世界中的一个很好的例子是 Internet Information Server / SharePoint Server 关系。 IIS 是一个网络服务器； SharePoint 是一个应用程序服务器。 SharePoint 位于 IIS“之上”，执行特定逻辑，并通过 IIS 提供结果。
例如，在 Java 世界中，Apache 和 Tomcat 也存在类似的情况。
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.
Web 服务器是在使用“互联网”协议之一（http、https、ftp 等）专门“侦听”TCP/IP 通道的计算机上运行的进程。 ）并根据这些传入请求执行它所做的任何操作...通常（按照最初的定义），它获取/生成并向客户端返回一个 html 网页，或者从服务器上的静态 html 文件获取，或者动态构建基于传入客户端请求中的参数。
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.
首先，Web 服务器通过 HTTP 协议提供 Web 内容（HTML 和静态内容）。另一方面，应用程序服务器是一个容器，您可以在其上构建业务逻辑和流程，并通过各种协议（包括 n 层架构中的 HTTP）向客户端应用程序公开业务逻辑和流程。
因此，应用程序服务器提供比 Web 服务器更多的服务，通常包括：（
专有或非专有）API
对象生命周期管理、
状态管理（会话）、
资源管理（例如到数据库的连接池）、
负载平衡、故障转移。 ..
AFAIK，ATG Dynamo 是 90 年代末最早的应用服务器之一（根据上面的定义）。 2000 年初，一些专有应用程序服务器占据了统治地位，例如 ColdFusion (CFML AS)、< a href="http://www.broadvision.com/" rel="noreferrer">BroadVision（服务器端 JavaScript AS）等。但没有一个真正在 Java 应用服务器时代幸存下来。
On a first hand, a web server serves web content (HTML and static content) over the HTTP protocol. On the other hand, an application server is a container upon which you can build and expose business logic and processes to client applications through various protocols including HTTP in a n-tier architecture.
An application server thus offers much more services than an web server which typically include:
A (proprietary or not) API
Object life cycle management,
State management (session),
Resource management (e.g. connection pools to database),
Load balancing, fail over...
AFAIK, ATG Dynamo was one of the very first application server in late 90's (according to the definition above). In early 2000, it was the reign of some proprietary application servers like ColdFusion (CFML AS), BroadVision (Server-side JavaScript AS), etc. But none really survived the Java application server era.
实际上Apache是一个Web服务器，而Tomcat是一个应用程序服务器。当 HTTP 请求到达 Web 服务器时。然后静态内容通过网络服务器发送回浏览器。是否有逻辑需要完成，然后将该请求发送到应用程序服务器。处理逻辑后，将响应发送到 Web 服务器并发送到客户端。
Actually Apache is a web server and Tomcat is an application server. When as HTTP request comes to web server. Then static contents send back to browser by web server. Is there and logic do to done, then that request send to the application server. after processing the logic then response send to web server and send to the client.
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.
用法--
我们要求低处理率，
常规处理实践涉及。
例如：所有平面服务器通常都是现成的，仅提供网络服务
基于内容。
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.
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:
您将看到 Tomcat（Web 容器/服务器）只是应用程序服务器库中的另一个工具。如果您愿意，您也可以在 Web 服务器中获取 JPA 和其他技术，但应用程序服务器只是为了您的方便而打包所有这些东西。要完全归类为应用程序服务器，您本质上需要遵守某些标准规定的工具列表。
All of the above is just over-complicating something very simple. An application server contains a web server, an application server just has a couple more additions/extensions to it than standard web servers. If you look at TomEE as an example:
You will see that Tomcat (Web container/server) is just another tool in the app servers arsenal. You can get JPA and the other tech in the web server as well if you want, but the application servers just package all of these things for your convenience. To be fully classified as an app server you essentially need to comply with a list of tools set forth by some standard.
There is not necessarily a clear dividing line. Nowadays, many programs combine elements of both - serving http requests (web server) and handling business logic (app server)
从纯粹的技术角度来看，您可以在单个 Web 服务器中完成所有操作（Web 内容 + 业务逻辑）。如果您这样做，那么该信息将嵌入到请求的 HTML 内容中。会有什么影响？
例如，假设您有 2 个不同的应用程序，它们在浏览器上呈现完全不同的 HTML 内容。如果您将业务逻辑分离到应用程序服务器中，那么您可以提供不同的 Web 服务器通过脚本在应用程序服务器中查找相同的数据。然而，如果您不分离逻辑并将其保留在 Web 服务器中，那么每当您更改业务模型时，您最终都会在您拥有的每个 Web 服务器中更改它，这将花费更多时间，可靠性更低，并且容易出错。
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.
应用程序服务器可以执行 Web 服务器的任何功能，并使用任何协议进行侦听以及应用程序服务器具有支持应用程序级服务的组件和功能，例如连接池、对象池、事务支持、消息服务等。
应用程序服务器的编程环境：
MTS：COM+
WAS：EJB
JBoss：EJB
WebLogic 应用程序服务器：EJB
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.
While there may be overlaps between the two (some web servers may even be used as application servers) the biggest difference IMHO is in the processing model and the session management:
In Web server processing model, the focus is on handling requests; the notion of "session" is pretty much virtual. That is to say that "session" is simulated by transferring the representation of state between client and server (hence REST) and/or serializing it to an external persistent storage (SQL Server, Memcached etc).
In Application server the session is usually more explicit and often takes form of an object living in memory of the application server for the entire duration of the "session".
A web server is a computer system that processes requests via HTTP, the basic network protocol used to distribute information on the World Wide Web. The term can refer to the entire system, or specifically to the software that accepts and supervises the HTTP requests.
An application server runs behind a web Server (e.g. Apache or Microsoft Internet Information Services (IIS)) and (almost always) in front of an SQL database (e.g. PostgreSQL, MySQL, or Oracle).
Web applications are computer code which run atop application servers and are written in the language(s) the application server supports and call the runtime libraries and components the application server offers.
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.
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.
从上面精彩的 SO 布道者的帖子中得出结论，我得出的结论是，两者都是驻留在实际金属服务器（物理服务器）上的软件。两者携手合作，为最终用户提供服务。然后，根据设置，我们可以选择如何称呼它，这意味着如何描述它取决于实际使用的设置。如果它们都驻留在同一个裸机（物理服务器）上，我们将其称为 Web 和应用程序服务器...简单！如果在不同的机器上，显然，我们手上有两个不同的裸机（物理服务器）。然后我们可以根据这些服务器的功能来标记它们：一个是 Web 服务器，另一个是应用程序服务器。
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.
这取决于具体的架构。某些应用程序服务器可能本机使用 Web 协议（XML/RPC/SOAP over HTTP），因此技术差异很小。通常，Web 服务器是面向用户的，通过 HTTP/HTTPS 提供各种内容，而应用程序服务器不是面向用户的，并且可能使用非标准或不可路由的协议。当然，对于 RIA/AJAX，差异可能会进一步变得模糊，只向提供特定远程访问服务的客户端提供非 HTML 内容 (JSON/XML)。
It depends on the specific architecture. Some application servers may use web protocols natively (XML/RPC/SOAP over HTTP), so there is little technical difference. Typically a web server is user-facing, serving a variety of content over HTTP/HTTPS, while an application server is not user-facing and may use non-standard or non-routable protocols. Of course with RIA/AJAX, the difference could be further clouded, serving only non-HTML content (JSON/XML) to clients pumping particular remote access services.
发布评论
评论（28）
大多数时候，这些术语“Web 服务器”和“应用程序服务器”可以互换使用。
以下是 Web 服务器和应用程序服务器功能上的一些主要区别：
此类配置的示例是 Apache Tomcat HTTP Server 和 Oracle（以前称为 BEA）WebLogic Server。 Apache Tomcat HTTP Server 是 Web 服务器，Oracle WebLogic 是应用程序服务器。
在某些情况下，服务器紧密集成，例如 IIS 和 .NET Runtime。 IIS 是网络服务器。当IIS配备.NET运行环境时，就可以提供应用程序服务。
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:
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.
这是一个详细的答案，其中包含一些场景，可以清楚地理解差异和相似之处，以及两者如何结合使用。
应用程序服务器这个术语有时会与网络服务器混合使用。虽然 Web 服务器主要处理 HTTP 协议，但应用程序服务器处理多种不同的协议，包括但不限于 HTTP。
Web服务器的主要工作是显示网站内容，应用服务器负责逻辑，即用户与显示内容之间的交互。应用程序服务器与 Web 服务器协同工作，其中一个服务器显示，另一个服务器交互。
服务器与其客户端之间来回传输的信息不限于简单的显示标记，还包括两者之间的交互。
在大多数情况下，服务器通过组件 API 创建此交互，例如J2EE（Java 2 平台）、EJB ( Enterprise JavaBean）和其他不同的应用软件模型。
示例：
最好的要了解应用程序服务器与 Web 服务器一起使用的场景与没有应用程序服务器的场景之间的区别，可以通过在线商店来了解。
场景 1：不使用应用程序服务器的 Web 服务器应用程序服务器
您有一个只有 Web 服务器而没有应用程序服务器的在线商店。该网站将提供一个显示屏，您可以从中选择产品。当您提交查询时，站点会执行查找并将 HTML 结果返回给其客户端。 Web 服务器将您的查询直接发送到数据库服务器（请耐心等待，我将在下一篇文章中解释这一点）并等待响应。收到后，Web 服务器会将响应制定为 HTML 文件并将其发送到您的 Web 浏览器。每次运行查询时，服务器和数据库服务器之间都会发生这种来回通信。
场景 2：带有应用程序服务器的 Web 服务器
如果您要运行的查询之前已经完成，并且此后没有数据发生更改，则服务器将生成结果，而无需必须将请求发送到数据库服务器。这允许实时查询，第二个客户端可以访问相同的信息并接收实时、可靠的信息，而无需向数据库服务器发送另一个重复的查询。服务器基本上充当数据库服务器和 Web 服务器之间的中间人。这允许在第一种情况下提取的信息可重用，因为该信息嵌入在特定的“定制”HTML 页面中，所以这不是可重用的过程。第二个客户端将不得不再次请求信息并接收另一个包含所请求信息的 HTML 嵌入页面 - 效率极低。更不用说这种类型的服务器非常灵活，因为它能够管理自己的资源，包括安全性、事务处理、消息传递和资源池。
为了支持如此多种复杂的任务，该服务器必须具有内置冗余、强大的处理能力和大量 RAM，以处理实时提取的所有数据。
This is a detailed answer with some scenarios to clearly understand the difference and similarity, and how both can work in conjunction.
Application Server is a term that sometimes is mixed with a web server. While a web server handles mainly HTTP protocols, the application server deals with several different protocols, including, but not limited, to HTTP.
The Web server's main job is to display the site content and the application server is in charge of the logic, the interaction between the user and the displayed content. The application server is working in conjunction with the web server, where one displays and the other one interacts.
The information traveling back and forth between the server and its client is not restricted to simple display markup, but to interaction between the two.
In most cases, the server creates this interaction through a component API, such as J2EE (Java 2 Platform), EJB (Enterprise JavaBean) and other different application software models.
An example:
The best way to understand the difference between the scenarios where an application server works with the web server versus a scenario where there isn't an application server is through an online store.
Scenario 1: Web server without an application server
you have an online store with only a web server and no application server. The site will provide a display where you can choose a product from. When you submit a query, the site performs a lookup and returns an HTML result back to its client. The web server sends your query directly to the database server (be patient, I will explain this one in our next nugget) and waits for a response. Once received, the web server formulates the response into an HTML file and sends it to your web browser. This back and forth communication between the server and database server happens every time a query is run.
Scenario 2: Web server with an application server
if the query you want to run has already been done previously and no data has changed since then, the server will generate the results without having to send the request to the database server. This allows a real-time query where a second client can access the same info and receive real time, reliable information without sending another duplicate query to the database server. The server basically acts as an intermediate between the database server and the web server. This allows the information pulled to be reusable while in the first scenario, since this info is embedded in a particular and "customized" HTML page, this is not a reusable process. A second client will have to request the info again and receive another HTML embedded page with the info requested -highly inefficient. Not to mention that this type of server is very flexible due to its ability to manage its own resources, including security, transaction processing, messaging and resource pooling.
To support such a variety of complex tasks this server must have a built in redundancy, great processing power and high amount of RAM to handle all the data it's pulling in real time.
这两个术语都非常通用，一个包含另一个，在某些情况下反之亦然。
Web 服务器：使用 http 协议向 Web 提供内容。
应用程序服务器：托管并公开业务逻辑和流程。
我认为主要的一点是Web服务器通过http协议公开一切，而应用程序服务器不限于此。
也就是说，在很多场景中，您会发现Web服务器被用来创建应用程序服务器的前端，也就是说，它公开了一组网页，允许用户与应用程序中发现的业务规则进行交互。应用服务器。
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.
Web 服务器
运行
python -m 'SimpleHTTPServer'并转到 http://localhost ：8080。您所看到的是正在运行的 Web 服务器。服务器仅通过 HTTP 提供存储在您计算机上的文件。关键是这一切都是在 HTTP 协议之上完成的。例如，还存在 FTP 服务器，它们执行完全相同的操作（提供存储的文件），但基于不同的协议。应用程序服务器
假设我们有一个像下面这样的小型应用程序（来自 Flask 的片段）。
这个小示例程序将 URL
/映射到函数homepage()，将/about映射到函数about().要运行此代码，我们需要一个应用程序服务器（例如 Gunicorn） - 一个可以侦听来自客户端的请求并使用我们的代码动态返回某些内容的程序或模块。在示例中，我们只是返回一些非常糟糕的 HTML。
其他人谈论的业务逻辑是什么？好吧，由于 URL 映射到我们的代码库中特定的某个位置，因此我们假设显示一些有关我们的程序如何工作的逻辑。
回顾
网络服务器 - 提供存储在某处的文件（最常见的是 .css、.html、.js）。常见的Web服务器有Apache、Nginx甚至Python的SimpleHTTPServer。
应用程序服务器 - 提供动态生成的文件。本质上，大多数网络服务器都有某种插件，甚至带有内置功能来做到这一点。还存在严格的应用程序服务器，例如 Gunicorn (Python)、Unicorn (Ruby)、uWSGI (Python) 等。
请注意，您实际上可以使用应用程序服务器的代码构建 Web 服务器。在开发过程中的某些情况下，您不希望计算机上运行大量不同的服务器，这是在某些情况下完成的。
Web server
Run
python -m 'SimpleHTTPServer'and go to http://localhost:8080. What you see is a web server at its workings. The server simply serves files over HTTP stored on your computer. The key point is that all this is done on top of the HTTP protocol. There also exist FTP servers for example which do exactly the same thing (serving stored files) but on top of a different protocol.Application server
Say we have a tiny application like below (snippet from Flask).
The small example program maps the URL
/to the functionhomepage()and the/aboutto the functionabout().To run this code we need an application server (e.g. Gunicorn) - a program or module that can listen for requests from a client and using our code, return something dynamically. In the example we simply return some very bad HTML.
What's the business logic all the other people talk about? Well, since a URL maps to somewhere specifically in our codebase, we are hypothetically showing some logic about how our program works.
Recapping
web server - serves files stored somewhere (most commonly .css, .html, .js). Common web servers are Apache, Nginx or even Python's SimpleHTTPServer.
application server - serves files generated on the fly. Essentially most web servers have some sort of plugins or even come with built-in functionality to do that. There exist also strict application servers like Gunicorn (Python), Unicorn (Ruby), uWSGI (Python), etc.
Notice that you can actually build a web server with the code of the application server. This is done in some cases during development where you do not want to have a gazillion of different servers running on your computer.
正如 Rutesh 和 jmservera 指出的那样，这种区别是模糊的。从历史上看，它们是不同的，但到了 90 年代，这两个先前截然不同的类别融合了特征并有效地融合了。此时可能最好想象“应用程序服务器”产品类别是“Web 服务器”类别的严格超集。
一些历史。在 Mosaic 浏览器和超链接内容的早期，出现了一种称为“Web 服务器”的东西，它通过 HTTP 提供网页内容和图像。大多数内容都是静态的，HTTP 1.0 协议只是一种传送文件的方式。 “Web 服务器”类别很快发展到包括 CGI 功能 - 有效地在每个 Web 请求上启动一个进程以生成动态内容。 HTTP 也日趋成熟，产品也变得更加复杂，具有缓存、安全和管理功能。随着技术的成熟，我们从 Kiva 和 NetDynamics 获得了公司特定的基于 Java 的服务器端技术，最终全部合并到 JSP 中。我想是在 1996 年，Microsoft 将 ASP 添加到了 Windows NT 4.0 中。静态 Web 服务器学到了一些新技巧，因此它是许多场景下有效的“应用程序服务器”。
在并行类别中，应用程序服务器已经发展并存在了很长时间。公司为 Unix 提供了 Tuxedo、TopEnd、Encina 等产品，这些产品在原理上源自大型机应用程序管理和监控环境（如 IMS 和 CICS）。 Microsoft 的产品是 Microsoft Transaction Server (MTS)，后来演变为 COM+。这些产品中的大多数都指定了“封闭”的产品特定通信协议，以将“胖”客户端与服务器互连。 （对于Encina，通信协议是DCE RPC；对于MTS，是DCOM；等等）在1995/96年，这些传统的应用服务器产品开始嵌入基本的HTTP通信功能，首先是通过网关。界限开始变得模糊。
Web 服务器在处理更高的负载、更多的并发性和更好的功能方面变得越来越成熟。应用程序服务器提供了越来越多的基于 HTTP 的通信功能。
此时，“应用程序服务器”和“Web 服务器”之间的界限是模糊的。但出于强调的目的，人们继续以不同的方式使用这些术语。当有人说“Web 服务器”时，您通常会想到以 HTTP 为中心、Web UI 的应用程序。当有人说“应用程序服务器”时，您可能会想到“更重的负载、企业功能、事务和排队、多通道通信（HTTP + 更多）。但通常是同一个产品满足两组工作负载需求。WebSphere
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.
正如许多人之前所说，Web 服务器处理 HTTP 请求，而应用程序服务器处理分布式组件的请求。
因此，也许理解差异的最简单方法是比较这两种产品提供的编程环境。
网络服务器->编程环境
IIS : ASP (.NET)
Tomcat : Servlet
Jetty : Servlet
Apache : Php, CGI
应用服务器 ->编程环境
MTS : COM+
WAS : EJB
JBoss : EJB
WebLogic 应用程序服务器 : EJB
关键的区别在于应用程序服务器支持一些分布式组件技术，提供远程调用和分布式事务等功能，如EJB Java世界中的或微软平台上的COM+。 Http 服务器通常支持一些更简单的编程环境，通常是脚本，例如 Microsoft 或基于 Servlet 的 ASP (.NET)，包括 JSP 和许多其他 Java 或 PHP 的环境，以及 Apache 的 CGI。
其他功能，如负载平衡、集群、会话故障转移、连接池等，以前属于应用程序服务器领域，现在也可以直接或通过某些第三方产品在 Web 服务器上使用。
最后，值得注意的是，像 Spring Framework 这样的“轻量级容器”进一步扭曲了情况，这些容器通常以更简单的方式补充应用程序服务器的用途，并且不需要应用程序服务器基础设施。而且由于应用程序的分布方面正在从分布式组件转向服务范式和 SOA 架构，因此留给传统应用程序服务器的空间越来越少。
As many have said before, web servers handle HTTP petitions, while application servers handle petitions for distributed components.
So, maybe the easiest way to understand the difference is to compare the two products in regards to programming environment they offer.
Web Server -> Programming Environment
IIS : ASP (.NET)
Tomcat : Servlet
Jetty : Servlet
Apache : Php, CGI
Application Servers -> Programming Environment
MTS : COM+
WAS : EJB
JBoss : EJB
WebLogic Application Server : EJB
The crucial difference is that application servers support some distributed component technology, providing features like remote invocation and distributed transactions, like EJB in Java world or COM+ on Microsoft platform. Http server often support some more simple programming environments, often scripting, like ASP (.NET) in case of Microsoft or Servlet--based, including JSP and many other in case of Java or PHP and CGI in case of Apache.
Other capabilities like load-balancing, clustering, session-failover, connection pooling etc. that used to be in the realm of application servers, are becoming available on web servers as well directly or through some third party products.
Finally, it is worth noting that the picture is further distorted with "lightweight containers" like Spring Framework, that often supplement the purpose of application servers in more simple manner and without the application server infrastructure. And since distribution aspect in applications is moving from distributed component towards service paradigm and SOA architecture, there is less and less space left for traditional application servers.
简而言之，
网络服务器是通过以下方式向用户提供静态网页的服务器HTTP 请求。
应用程序服务器是托管系统业务逻辑的服务器。
它通常托管长时间运行/批处理进程和/或不适合人类使用的互操作服务（REST/JSON 服务、SOAP、RPC 等）。
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).
Web 服务器和应用程序服务器之间的主要区别在于，Web 服务器旨在提供静态页面（例如 HTML 和 CSS），而应用程序服务器负责通过执行服务器端代码（例如 JSP、Servlet 或 EJB）来生成动态内容。
我应该使用哪一个？
一旦了解了 Web 和应用程序服务器以及 Web 容器之间的区别，就很容易弄清楚何时使用它们。
如果您提供静态网页，则需要像 Apache HTTPD 这样的
Web 服务器。如果您有一个仅包含 JSP 和 Servlet 的 Java 应用程序来生成动态内容，那么您需要像 Tomcat 或 Jetty 这样的Web 容器。然而，如果您有使用 EJB、分布式事务、消息传递和其他奇特功能的 Java EE 应用程序，那么您需要一个成熟的应用程序服务器，例如 JBoss、WebSphere 或 Oracle 的 WebLogic。Web容器是Web服务器的一部分，Web服务器是应用程序服务器的一部分。
Web Server由Web容器组成，而Application Server由Web容器和EJB容器组成。
The main difference between Web server and application server is that web server is meant to serve static pages e.g. HTML and CSS, while Application Server is responsible for generating dynamic content by executing server side code e.g. JSP, Servlet or EJB.
Which one should i use?
Once you know the difference between web and application server and web containers, it's easy to figure out when to use them.
You need a
web serverlike Apache HTTPD if you are serving static web pages. If you have a Java application with just JSP and Servlet to generate dynamic content then you needweb containerslike Tomcat or Jetty. While, if you have Java EE application using EJB, distributed transaction, messaging and other fancy features than you need a full fledgedapplication serverlike JBoss, WebSphere or Oracle's WebLogic.Web container is a part of Web Server and the Web Server is a part of Application Server.
Web Server is composed of web container, while Application Server is composed of web container as well as EJB container.
Web 服务器专门处理 HTTP/HTTPS 请求。它使用 HTTP/HTTPS 协议向 Web 提供内容。
应用服务器通过任意数量的协议（可能包括 HTTP）为应用程序提供业务逻辑。应用程序可以使用此逻辑，就像调用对象的方法一样。在大多数情况下，服务器通过组件 API 公开此业务逻辑，例如 Java EE（Java 平台企业版）应用程序服务器上的 EJB（企业 JavaBean）组件模型。
要点是，Web 服务器通过 http 协议公开所有内容，而应用程序服务器不限于此。
因此，应用程序服务器提供比 Web 服务器更多的服务，通常包括：（
大多数的应用程序服务器将 Web 服务器作为其不可分割的一部分，这意味着应用程序服务器可以执行 Web 服务器能够执行的任何操作。此外，应用程序服务器还具有支持应用程序级服务的组件和功能，例如连接池、对象池、事务支持、消息服务等。
应用程序服务器可以（但并不总是）在 Web 服务器上运行以执行程序逻辑、结果然后可以由网络服务器传送。这是 Web 服务器/应用程序服务器场景的一个示例。
Microsoft 世界中的一个很好的例子是 Internet Information Server / SharePoint Server 关系。 IIS 是一个网络服务器； SharePoint 是一个应用程序服务器。 SharePoint 位于 IIS“之上”，执行特定逻辑，并通过 IIS 提供结果。
例如，在 Java 世界中，Apache 和 Tomcat 也存在类似的情况。
由于 Web 服务器非常适合静态内容，而应用程序服务器非常适合动态内容，因此大多数生产环境都将 Web 服务器充当应用程序服务器的反向代理。这意味着在服务页面请求时，静态内容（例如图像/静态 html）由解释请求的 Web 服务器提供。使用某种过滤技术（主要是请求资源的扩展）Web 服务器识别动态内容请求并透明地转发到应用程序服务器。
此类配置的示例是 Apache HTTP Server 和 BEA WebLogic Server。 Apache HTTP Server 是 Web 服务器，BEA WebLogic 是应用程序服务器。
在某些情况下，服务器紧密集成，例如 IIS 和 .NET Runtime。 IIS 是网络服务器。当配备.NET运行环境时IIS能够提供应用程序服务
A Web server exclusively handles HTTP/HTTPS requests. It serves content to the web using HTTP/HTTPS protocol.
An application server serves business logic to application programs through any number of protocols, possibly including HTTP. The application program can use this logic just as it would call a method on an object. In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on Java EE (Java Platform, Enterprise Edition) application servers.
The main point is that the web server exposes everything through the http protocol, while the application server is not restricted to it.
An application server thus offers much more services than an web server which typically include:
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.
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.
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 service a page request, static contents such as images/Static html is 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 HTTP Server and BEA WebLogic Server. Apache HTTP Server is Web Server and BEA 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
两者之间的界限变得越来越薄弱。
应用程序服务器向客户端公开业务逻辑。这意味着应用程序服务器包含一组执行业务逻辑的方法（但不完全如此，甚至可以是允许许多人在其上运行软件的联网计算机）。所以它只会输出想要的结果，而不是 HTML 内容。 （类似于方法调用）。所以它并不是严格基于 HTTP 的。
但 Web 服务器将 HTML 内容传递给 Web 浏览器（严格基于 HTTP）。 Web 服务器只能处理静态 Web 资源，但服务器端脚本的出现使得 Web 服务器也可以处理动态内容。 Web 服务器接收请求并将其定向到相关脚本（PHP、JSP、CGI 脚本等）以创建要发送到客户端的 HTML 内容。一旦接收到内容，Web 服务器就会将 HTML 页面发送到客户端。
然而，现在这两种服务器一起使用。
Web 服务器接收请求，然后调用脚本来创建 HTML 内容。然后，脚本将再次调用应用服务器LOGIC（例如检索交易详细信息）来填充HTML内容。
所以这两个服务器都得到了有效的利用。
所以 ....
我们可以有把握地说，如今，在大多数情况下，Web 服务器被用作应用程序服务器的子集。但理论上情况并非如此。
我读过很多关于这个主题的文章，发现 这篇文章非常方便。
The border between these two are getting ever so thinner.
Application servers expose business logic to clients. That means application servers comprise of a set of methods (not exclusively though, can even be a networked computer allowing many to run software on it) to perform business logic. So it will simply output the desired results, not HTML content. (similar to a method call). So it is not strictly HTTP based.
But web servers pass HTML content to web browsers (Strictly HTTP based). Web servers were capable of handling only the static web resources, but the emergence of server side scripting allowed web servers to handle dynamic contents as well. Where a web server takes in the request and directs it to relevant scripts (PHP, JSP, CGI scripts, etc.) to CREATE HTML content to be sent to the client. Once the content is received, web server will send the HTML page to the client.
However, nowadays both these servers are used together.
Where web server takes the request and then calls a script to create the HTML content. Then, the script will again call an application server LOGIC (e.g. Retrieve transaction details) to fill the HTML content.
So both the servers are used effectively.
Therefore ....
We can safely say that nowadays, in most of the cases, web servers are used as a subset of application servers. BUT theoretically it is NOT the case.
I have read many articles about this topic and found this article quite handy.
用 Java 术语来说，还有一个：Web 容器（或更严格地说，Servlet 容器）。比如说，它位于 Web 服务器和应用程序服务器之间。
Java 术语中的 Web 容器是一个应用程序服务器，它基本上仅实现 Java EE 的 JSP/Servlet 部分，缺少 Java EE 的几个核心部分，例如 EJB 支持。 Apache Tomcat 就是一个例子。
In Java terms, there's one more: web container (or more strictly, servlet container). It's, say, in between web server and application server.
A web container in Java terms is an application server that basically only implements the JSP/Servlet part of Java EE and lacks several core parts of Java EE, such as EJB support. An example is Apache Tomcat.
应用程序服务器的设计和部署通常是为了促进运行时间更长的进程，这些进程也将占用更多的资源。
Web 服务器通常用于非资源密集型的短突发。这主要是为了方便提供基于网络的流量。
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.
Web 服务器运行 HTTP 协议来提供网页服务。应用程序服务器可以（但并不总是）在 Web 服务器上运行以执行程序逻辑，然后由 Web 服务器传递结果。这是 Web 服务器/应用程序服务器场景的一个示例。
Microsoft 世界中的一个很好的例子是 Internet Information Server / SharePoint Server 关系。 IIS 是一个网络服务器； SharePoint 是一个应用程序服务器。 SharePoint 位于 IIS“之上”，执行特定逻辑，并通过 IIS 提供结果。
例如，在 Java 世界中，Apache 和 Tomcat 也存在类似的情况。
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.
应用程序服务器是一台机器（实际上是在某些机器上运行的可执行进程），它“侦听”（在任何通道上，使用任何协议）来自客户端对其提供的任何服务的请求，然后根据这些请求执行某些操作。 （可能涉及也可能不涉及对客户端的响应）
Web 服务器是在使用“互联网”协议之一（http、https、ftp 等）专门“侦听”TCP/IP 通道的计算机上运行的进程。 ）并根据这些传入请求执行它所做的任何操作...通常（按照最初的定义），它获取/生成并向客户端返回一个 html 网页，或者从服务器上的静态 html 文件获取，或者动态构建基于传入客户端请求中的参数。
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.
首先，Web 服务器通过 HTTP 协议提供 Web 内容（HTML 和静态内容）。另一方面，应用程序服务器是一个容器，您可以在其上构建业务逻辑和流程，并通过各种协议（包括 n 层架构中的 HTTP）向客户端应用程序公开业务逻辑和流程。
因此，应用程序服务器提供比 Web 服务器更多的服务，通常包括：（
AFAIK，ATG Dynamo 是 90 年代末最早的应用服务器之一（根据上面的定义）。 2000 年初，一些专有应用程序服务器占据了统治地位，例如 ColdFusion (CFML AS)、< a href="http://www.broadvision.com/" rel="noreferrer">BroadVision（服务器端 JavaScript AS）等。但没有一个真正在 Java 应用服务器时代幸存下来。
On a first hand, a web server serves web content (HTML and static content) over the HTTP protocol. On the other hand, an application server is a container upon which you can build and expose business logic and processes to client applications through various protocols including HTTP in a n-tier architecture.
An application server thus offers much more services than an web server which typically include:
AFAIK, ATG Dynamo was one of the very first application server in late 90's (according to the definition above). In early 2000, it was the reign of some proprietary application servers like ColdFusion (CFML AS), BroadVision (Server-side JavaScript AS), etc. But none really survived the Java application server era.
最大的区别是 Web 服务器处理 HTTP 请求，而应用程序服务器将在任意数量的协议上执行业务逻辑。
Biggest difference is a Web Server handles HTTP requests, while an Application server will execute business logic on any number of protocols.
实际上Apache是一个Web服务器，而Tomcat是一个应用程序服务器。当 HTTP 请求到达 Web 服务器时。然后静态内容通过网络服务器发送回浏览器。是否有逻辑需要完成，然后将该请求发送到应用程序服务器。处理逻辑后，将响应发送到 Web 服务器并发送到客户端。
Actually Apache is a web server and Tomcat is an application server. When as HTTP request comes to web server. Then static contents send back to browser by web server. Is there and logic do to done, then that request send to the application server. after processing the logic then response send to web server and send to the client.
基本理解：
客户端服务器架构
网络服务器和应用程序服务器都是充当客户端服务器的软件应用程序。
他们根据使用地点而得名。
我们可以将它们假设为 4 层/n 层架构中的层/层次结构。
请点击此链接了解标准体系结构类比：
https://learn.microsoft.com/en-us/previous-versions/msp-np/ee658120(v%3dpandp.10)
Basic understanding :
In client server architecture
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.
We can assume them as tiers/Hierarchies in 4-tier/n-tier architecture.
Please follow this link for standard architecture analogies:
https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ee658120(v%3dpandp.10)
以上所有内容都只是将非常简单的事情变得过于复杂。应用程序服务器包含一个 Web 服务器，应用程序服务器只是比标准 Web 服务器多了一些添加/扩展。如果您以 TomEE 为例：
您将看到 Tomcat（Web 容器/服务器）只是应用程序服务器库中的另一个工具。如果您愿意，您也可以在 Web 服务器中获取 JPA 和其他技术，但应用程序服务器只是为了您的方便而打包所有这些东西。要完全归类为应用程序服务器，您本质上需要遵守某些标准规定的工具列表。
All of the above is just over-complicating something very simple. An application server contains a web server, an application server just has a couple more additions/extensions to it than standard web servers. If you look at TomEE as an example:
You will see that Tomcat (Web container/server) is just another tool in the app servers arsenal. You can get JPA and the other tech in the web server as well if you want, but the application servers just package all of these things for your convenience. To be fully classified as an app server you essentially need to comply with a list of tools set forth by some standard.
不一定有明确的分界线。如今，许多程序结合了两者的元素 - 服务 http 请求（Web 服务器）和处理业务逻辑（应用程序服务器）
There is not necessarily a clear dividing line. Nowadays, many programs combine elements of both - serving http requests (web server) and handling business logic (app server)
IMO，这主要是关于分离关注点。
从纯粹的技术角度来看，您可以在单个 Web 服务器中完成所有操作（Web 内容 + 业务逻辑）。如果您这样做，那么该信息将嵌入到请求的 HTML 内容中。会有什么影响？
例如，假设您有 2 个不同的应用程序，它们在浏览器上呈现完全不同的 HTML 内容。如果您将业务逻辑分离到应用程序服务器中，那么您可以提供不同的 Web 服务器通过脚本在应用程序服务器中查找相同的数据。然而，如果您不分离逻辑并将其保留在 Web 服务器中，那么每当您更改业务模型时，您最终都会在您拥有的每个 Web 服务器中更改它，这将花费更多时间，可靠性更低，并且容易出错。
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.
应用程序服务器和Web服务器都用于托管Web应用程序。 Web 服务器处理 Web 容器，而应用程序服务器处理 Web 容器以及 Microsoft dot Net 的 EJB（企业 JavaBean）容器或 COM+ 容器。
Web 服务器设计用于服务 HTTP 静态内容（如 HTML、图像等），而对于动态内容，则有插件支持脚本语言（如 Perl、PHP、ASP、JSP 等），并且仅限于 HTTP 协议。下面的服务器可以生成动态 HTTP 内容。
Web 服务器的编程环境：
IIS : ASP (.NET)
Apache Tomcat: Servlet
Jetty: Servlet
Apache: Php, CGI
应用程序服务器可以执行 Web 服务器的任何功能，并使用任何协议进行侦听以及应用程序服务器具有支持应用程序级服务的组件和功能，例如连接池、对象池、事务支持、消息服务等。
应用程序服务器的编程环境：
MTS：COM+
WAS：EJB
JBoss：EJB
WebLogic 应用程序服务器：EJB
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 服务器甚至可能用作应用程序服务器），但恕我直言，最大的区别在于处理模型和会话管理：在
Web 服务器处理模型中，重点是处理请求；在 Web 服务器处理模型中，重点是处理请求。 “会话”的概念几乎是虚拟的。也就是说，“会话”是通过在客户端和服务器之间传输状态表示（因此称为 REST）和/或将其序列化到外部持久存储（SQL Server、Memcached 等）来模拟的。
在应用程序服务器中，会话通常更加明确，并且通常采用在“会话”的整个持续时间内驻留在应用程序服务器内存中的对象的形式。
While there may be overlaps between the two (some web servers may even be used as application servers) the biggest difference IMHO is in the processing model and the session management:
In Web server processing model, the focus is on handling requests; the notion of "session" is pretty much virtual. That is to say that "session" is simulated by transferring the representation of state between client and server (hence REST) and/or serializing it to an external persistent storage (SQL Server, Memcached etc).
In Application server the session is usually more explicit and often takes form of an object living in memory of the application server for the entire duration of the "session".
来自 https://en.wikipedia.org/wiki/Web_server
一个网络服务器 是一种通过 HTTP 处理请求的计算机系统，HTTP 是用于在万维网上分发信息的基本网络协议。该术语可以指整个系统，或者特指接受和监督 HTTP 请求的软件。
来自 https://en.wikipedia.org/wiki/Application_server#Application_Server_definition
应用程序服务器在Web 服务器（例如Apache 或Microsoft Internet Information Services (IIS)）后面运行，并且（几乎总是）在SQL 数据库（例如PostgreSQL、MySQL 或Oracle）前面运行。
Web 应用程序是在应用程序服务器上运行的计算机代码，以应用程序服务器支持的语言编写，并调用应用程序服务器提供的运行时库和组件。
From https://en.wikipedia.org/wiki/Web_server
A web server is a computer system that processes requests via HTTP, the basic network protocol used to distribute information on the World Wide Web. The term can refer to the entire system, or specifically to the software that accepts and supervises the HTTP requests.
From https://en.wikipedia.org/wiki/Application_server#Application_Server_definition
An application server runs behind a web Server (e.g. Apache or Microsoft Internet Information Services (IIS)) and (almost always) in front of an SQL database (e.g. PostgreSQL, MySQL, or Oracle).
Web applications are computer code which run atop application servers and are written in the language(s) the application server supports and call the runtime libraries and components the application server offers.
几乎您访问的每个页面都使用两者。静态内容（例如图像、视频）由网络服务器提供，其余内容（您与其他用户之间不同的部分）由应用程序服务器生成。
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 对两者进行了非常好的比较：
IBM makes a really nice comparison between the two:
从上面精彩的 SO 布道者的帖子中得出结论，我得出的结论是，两者都是驻留在实际金属服务器（物理服务器）上的软件。两者携手合作，为最终用户提供服务。然后，根据设置，我们可以选择如何称呼它，这意味着如何描述它取决于实际使用的设置。如果它们都驻留在同一个裸机（物理服务器）上，我们将其称为 Web 和应用程序服务器...简单！如果在不同的机器上，显然，我们手上有两个不同的裸机（物理服务器）。然后我们可以根据这些服务器的功能来标记它们：一个是 Web 服务器，另一个是应用程序服务器。
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.
这取决于具体的架构。某些应用程序服务器可能本机使用 Web 协议（XML/RPC/SOAP over HTTP），因此技术差异很小。通常，Web 服务器是面向用户的，通过 HTTP/HTTPS 提供各种内容，而应用程序服务器不是面向用户的，并且可能使用非标准或不可路由的协议。当然，对于 RIA/AJAX，差异可能会进一步变得模糊，只向提供特定远程访问服务的客户端提供非 HTML 内容 (JSON/XML)。
It depends on the specific architecture. Some application servers may use web protocols natively (XML/RPC/SOAP over HTTP), so there is little technical difference. Typically a web server is user-facing, serving a variety of content over HTTP/HTTPS, while an application server is not user-facing and may use non-standard or non-routable protocols. Of course with RIA/AJAX, the difference could be further clouded, serving only non-HTML content (JSON/XML) to clients pumping particular remote access services.