应用服务器和web服务器之间的区别是什么？
当前回答
这是一个详细的答案，其中包含一些场景，以清楚地了解差异和相似性，以及两者如何协同工作。
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，以实时处理其提取的所有数据。
其他回答
IBM在这两者之间做了一个非常好的比较：
严格定义，web服务器是应用程序服务器的一个子集。web服务器主要响应来自web浏览器的超文本传输协议（HTTP）请求，提供静态web内容，例如HTML页面、文件、图像和视频。应用程序服务器通常也可以交付web内容，但其主要工作是实现最终用户客户端和服务器端应用程序代码之间的交互，这些代码表示通常称为业务逻辑的内容，以生成和交付动态内容，如交易结果、决策支持或实时分析。应用服务器的客户端可以是应用程序自己的最终用户UI、web浏览器或移动应用程序，客户端-服务器交互可以通过任意数量的通信协议进行。然而，在实践中，web服务器和应用程序服务器之间的界限变得更加模糊，特别是随着web浏览器成为应用程序客户端的选择，以及用户对web应用程序和web应用程序性能的期望值的增加。大多数web服务器支持脚本语言插件（例如，ASP、JSP、PHP、Perl），使web服务器能够基于服务器端逻辑生成动态内容。越来越多的应用服务器不仅具有web服务器功能，而且使用HTTP作为其主要协议，并支持其他协议（例如CGI和CGI变体）与web服务器进行接口。它们还允许web应用程序利用反向代理、集群、冗余和负载平衡服务等服务，从而提高性能和可靠性，并允许开发人员减少对基础设施的关注，而更多地关注编码。为了使事情更加混乱，许多web服务器和一些应用程序服务器被称为web应用程序服务器，或者称为它们自己。底线是，当今最流行的web服务器和应用程序服务器是两者的混合。您现在使用的大多数日益丰富的应用程序都是静态web内容和动态应用程序内容的组合，通过web服务器和应用程序服务器技术的组合提供。
正如Rutesh和jmservera所指出的，区别是模糊的。从历史上看，它们是不同的，但在90年代，这两个以前不同的类别混合了特征并有效地合并了。在这一点上，最好的设想是“应用服务器”产品类别是“web服务器”类别的严格超集。
一些历史。在Mosaic浏览器和超链接内容的早期，出现了一种称为“web服务器”的东西，它通过HTTP提供网页内容和图像。大部分内容都是静态的，HTTP1.0协议只是一种传送文件的方式。很快，“web服务器”类别演变为包括CGI功能——有效地对每个web请求启动一个过程以生成动态内容。HTTP也成熟了，产品变得更加复杂，具有缓存、安全性和管理功能。随着技术的成熟，我们从Kiva和NetDynamics获得了特定于公司的基于Java的服务器端技术，这些技术最终都合并到了JSP中。我认为微软在1996年将ASP添加到了Windows NT 4.0中。静态web服务器已经学会了一些新技巧，因此对于许多场景来说，它是一个有效的“应用服务器”。
在一个平行的类别中，应用服务器已经进化并存在了很长时间。公司为Unix提供了Tuxedo、TopEnd、Encina等产品，这些产品从哲学上源自IMS和CICS等大型机应用程序管理和监控环境。微软的产品是微软事务服务器（MTS），后来演变成COM+。这些产品中的大多数指定了“封闭”的特定于产品的通信协议，以将“胖”客户端与服务器互连。（对于Encina，通信协议是DCE RPC；对于MTS，它是DCOM；等等）1995/96年，这些传统的应用服务器产品开始嵌入基本的HTTP通信功能，最初是通过网关。线条开始模糊。
Web服务器在处理更高的负载、更多的并发性和更好的功能方面变得越来越成熟。应用服务器提供了越来越多的基于HTTP的通信功能。
此时，“应用服务器”和“web服务器”之间的界限是模糊的。但作为一个重点，人们继续使用不同的术语。当有人说“web服务器”时，你通常会想到以HTTP为中心、面向web UI的应用程序。当有人说“应用服务器”时，你可能会想到“更重的负载、企业功能、事务和排队、多渠道通信（HTTP+更多）。但通常是同一个产品同时满足两组工作负载要求。”。
IBM的“应用服务器”WebSphere有自己的捆绑web服务器。另一个传统的应用服务器WebLogic也是如此。Windows是微软的应用服务器（除了作为其文件和打印服务器、媒体服务器等），捆绑了IIS。
在Java术语中，还有一个：web容器（或者更严格地说，servlet容器）。例如，它位于web服务器和应用程序服务器之间。
Java术语中的web容器是一个应用服务器，它基本上只实现JavaEE的JSP/Servlet部分，并且缺少JavaEE的几个核心部分，例如EJB支持。Apache Tomcat就是一个例子。
Web服务器
运行python-m“SimpleHTTPServer”并转到http://localhost:8080.你所看到的是一个运行中的web服务器。服务器只需通过存储在计算机上的HTTP提供文件。关键点是，所有这些都是在HTTP协议之上完成的。例如，也存在FTP服务器，它们执行完全相同的操作（为存储的文件提供服务），但使用不同的协议。
应用程序服务器
假设我们有一个像下面这样的小应用程序（来自Flask的片段）。
@app.route('/')
def homepage():
return '<html>My homepage</html>'
@app.route('/about')
def about():
return '<html>My name is John</html>'
这个小示例程序将URL/映射到函数homepage（），将/about映射到函数about（）。
为了运行这段代码，我们需要一个应用服务器（例如Gunicorn）——一个程序或模块，它可以监听来自客户端的请求，并使用我们的代码动态地返回一些东西。在本例中，我们只返回一些非常糟糕的HTML。
其他人谈论的商业逻辑是什么？好吧，由于URL映射到代码库中的某个特定位置，所以我们假设显示了一些关于程序如何工作的逻辑。
重新包装
web服务器-提供存储在某处的文件（最常见的是.css、.html、.js）。常见的web服务器有Apache、Nginx甚至Python的SimpleHTTPServer。
应用服务器-提供动态生成的文件。本质上，大多数web服务器都有某种插件，甚至带有内置功能。还有严格的应用服务器，如Gunicorn（Python）、Unicorn（Ruby）、uWSGI（Python）等。
请注意，您实际上可以使用应用程序服务器的代码构建web服务器。在某些情况下，在开发过程中，您不希望在计算机上运行大量不同的服务器。
应用程序服务器是一台机器（实际上是在某台机器上运行的可执行进程），它“监听”（在任何信道上，使用任何协议）客户端对其提供的任何服务的请求，然后根据这些请求执行某些操作。（可能涉及或不涉及对客户的回应）
Web服务器是在一台机器上运行的进程，该机器使用“互联网”协议之一（http、https、ftp等）专门“侦听”TCP/IP信道，并根据这些传入的请求执行任何操作。。。通常，（按照最初的定义），它获取/生成并向客户端返回一个html网页，或者从服务器上的静态html文件获取，或者根据传入客户端请求中的参数动态构建。
