正如许多人之前所说的，web服务器处理HTTP请求，而应用程序服务器处理分布式组件的请求。因此，了解差异的最简单方法是比较两种产品提供的编程环境。

Web服务器->编程环境

IIS:ASP（.NET）

Tomcat：Servlet

码头：Servlet

阿帕奇：Php，CGI

应用程序服务器->编程环境

MTS:COM公司+

是：EJB

JBoss:EJB

WebLogic应用服务器：EJB

关键区别在于，应用程序服务器支持一些分布式组件技术，提供远程调用和分布式事务等功能，如Java世界中的EJB或Microsoft平台上的COM+。Http服务器通常支持一些更简单的编程环境，通常是脚本环境，例如Microsoft的ASP（.NET）或基于Servlet的，包括JSP和Java的许多其他编程环境，或者Apache的PHP和CGI。

其他功能，如负载平衡、集群、会话故障切换、连接池等，过去属于应用服务器领域，现在也可以直接或通过一些第三方产品在web服务器上使用。

最后，值得注意的是，像Spring Framework这样的“轻量级容器”进一步扭曲了这一图景，这些容器通常以更简单的方式补充了应用服务器的用途，而没有应用服务器基础设施。而且，由于应用程序中的分布式方面正从分布式组件转向服务范式和SOA架构，留给传统应用程序服务器的空间越来越少。

虽然两者之间可能存在重叠（某些web服务器甚至可以用作应用服务器），但IMHO最大的区别在于处理模型和会话管理：

在Web服务器处理模型中，重点是处理请求；“会话”的概念几乎是虚拟的。也就是说，通过在客户端和服务器之间传输状态表示（因此是REST）和/或将其串行化到外部持久存储（SQL server、Memcached等）来模拟“会话”。

在应用程序服务器中，会话通常更加明确，并且通常在整个“会话”期间以对象的形式存在于应用程序服务器的内存中。

不一定有明确的分界线。如今，许多程序结合了服务http请求（web服务器）和处理业务逻辑（app服务器）的元素

web服务器运行HTTP协议来服务网页。应用服务器可以（但不总是）在web服务器上运行以执行程序逻辑，然后可以由web服务器交付程序逻辑的结果。这是web服务器/应用程序服务器场景的一个示例。

Microsoft世界中的一个很好的例子是Internet Information Server/SharePoint Server关系。IIS是一个web服务器；SharePoint是一个应用程序服务器。SharePoint位于IIS之上，执行特定的逻辑，并通过IIS提供结果。

例如，在Java世界中，Apache和Tomcat也有类似的场景。

这是一个详细的答案，其中包含一些场景，以清楚地了解差异和相似性，以及两者如何协同工作。

Application Server是一个有时与web服务器混合使用的术语。虽然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，以实时处理其提取的所有数据。

国际海事组织，这主要是关于分离担忧。

从纯技术角度来看，您可以在单个web服务器中完成所有操作（web内容+业务逻辑）。如果您这样做，那么信息将嵌入请求的HTML内容中。会有什么影响？

例如，假设您有两个不同的应用程序，它们在浏览器上呈现完全不同的HTML内容。如果您将业务逻辑分离为应用服务器，那么您可以提供不同的web服务器，通过脚本在应用服务器中查找相同的数据。然而，如果您不将逻辑分离并将其保存在web服务器中，那么每当您更改业务模型时，您最终都会在您拥有的每一个web服务器中更改它，这将花费更多时间、可靠性降低且容易出错。