WEB服务器、应用服务器和HTTP服务器有什么区别？ IIS、 、 、 分别属于什么类型的服务器？ 这些问题我困惑了很久，今天终于整理出来：
Web服务器的基本功能是提供Web信息浏览服务。 它只需要支持HTTP协议、HTML文档格式和URL。 与客户端的网络浏览器配合使用。 因为Web服务器支持的主要协议是HTTP，通常HTTP服务器和WEB服务器是平等的（笔者没有验证是否有Web服务器支持HTTP以外的协议），这是同一个东西。
应用服务器（简称应用服务器），我们首先看一下微软对它的定义：“我们将应用服务器定义为“作为执行共享业务应用程序的服务器的底层系统软件。”就像文件服务器提供许多用户拥有 Like 文件，应用程序服务器使应用程序（通常是客户端创建的应用程序）能够由多个用户同时使用。”
通俗地说，Web服务器交付()页面以便浏览器可以浏览它，但应用服务器提供客户端应用程序可以调用的方法()。 更准确地说，你可以说：Web服务器专门处理HTTP请求（），但应用程序服务器通过许多协议向应用程序提供（）业务逻辑（）。
以Web服务器为例，Web服务器主要处理静态页面处理，作为解释执行/JSP的容器，而应用服务器则运行业务逻辑，主要是EJB、JNDI等，还包括事务处理、数据库连接等功能。 因此，在企业级应用中，应用服务器提供的功能比WEB服务器要强大得多。
按照这个定义，IIS、IIS、IIS都可以属于Web服务器，并且都属于应用服务器。
：在Web服务器中，纯Web服务器，通常与. 它对 HTML 页面具有强大的解释能力，但无法解释页面中嵌入的服务器端脚本代码（JSP/）。
：早期的是嵌入式JSP/解释引擎+相当于IIS+ASP。 后来的就不再嵌入了，进程独立运行。 而且它已经是一个独立的JSP容器，业务逻辑层代码和界面交互层代码可以分离。 因此，有人称其为轻量级应用服务器。
IIS：微软早期的IIS是一个纯粹的Web服务器。 后来，它嵌入了ASP引擎，可以解释服务器端代码。 这时，它可以兼作应用服务器。 当然，它根本无法与J2EE应用服务器相比，但从功能和原理上来说，它勉强可以称为应用服务器。 准确的说，它是一个带有一点应用服务器功能的Web服务器。
总结一下：它是一个纯粹的Web服务器，并且由于IIS具有解释和执行服务器端代码的能力，因此可以称为轻量级应用服务器或具有服务器功能的Web服务器。 ，因为它可以提供强大的J2EE功能，所以毫无疑问是一个绝对的应用服务器。 对于中间的，可以和纯Web服务器一起使用，也可以和应用服务器一起部署，作为应用服务器的辅助：
1.与应用服务器
到目前为止，它被认为是/的执行者，也称为容器。 然而，这还不是全部，它还提供了JNDI和JNDI的实现机制。 尽管如此，它仍然不完全是一个应用程序服务器，因为它不提供大部分支持。
有趣的是，当今许多应用程序服务器经常将它们用作容器。 这使得开发人员只需添加一行确认即可将确认嵌入到他们的应用程序中。 不幸的是，许多商业应用程序服务器不遵守此规则。
对于开发人员来说，如果他们希望使用 JSP、JNDI 和 JMX 技术来生成应用程序，那么选择是一个很好的解决方案； 但如果他们希望支持其他人，那么就寻找应用程序服务器或将其用作应用程序服务器的辅助。 ，将是一个很好的解决方案； 第三种方法是找到独立的实现，然后将它们与 . 虽然整合会带来相关问题，但这种方式是最有效的。 。
2.通过Web服务器
它提供了一个支持并运行JSP的容器。 JSP可以根据实时需求生成动态网页内容。 对于Web服务器来说，如果只支持静态网页，那么对动态网页的支持就无能为力； 它不仅可以服务动态网页，还可以提供对静态网页的支持。 虽然它的速度不如普通的Web服务器，功能也不如Web服务器丰富，但它正在逐渐扩展以支持静态内容。 大多数Web服务器都是用C等低级语言编写的，利用了相应平台的特性，因此用纯Java编写的执行速度无法与它们相比。
一般来说，大型网站都是与JSP结合在一起的，负责接受客户端的所有HTTP请求，然后将JSP请求转发给JSP处理。 处理完成后，将响应传回，最后将响应返回给客户端。
并且为了提高性能，一台可以连接多台，实现负载均衡。
WEB服务器和应用服务器更详细的区别可以参考下面的文章：
通俗地说，Web服务器交付()页面以便浏览器可以浏览它，但应用服务器提供客户端应用程序可以调用的方法()。 更准确地说，你可以说：Web服务器专门处理HTTP请求（），但应用程序服务器通过许多协议向应用程序提供（）业务逻辑（）。
我们来详细看看：
网络服务器（）
Web 服务器可以 parse() HTTP 协议。 当Web服务器收到一个HTTP请求（）时，它会返回一个HTTP响应（），比如发回一个HTML页面。 为了处理请求（），Web服务器可以对静态页面或图像进行响应（），执行页面跳转（），或者将动态响应（）的生成委托给一些其他程序，例如CGI脚本、JSP() 脚本、ASP() 脚本、服务器端 (-side) 或其他一些服务器端 (-side) 技术。 不管它们（译者注：脚本）的目的如何，这些服务器端（-side）程序通常都会生成一个浏览器可以查看的 HTML 响应（）。
要知道，Web服务器的代理模型（）非常简单。 当一个 () 被发送到 Web 服务器时，它只是将 () 传递给一个能够很好地处理 () 的程序（译者注：服务器端脚本）。 Web服务器仅提供一个环境，在该环境中可以执行服务器端（端）程序并返回响应（由程序生成），而不会超出功能范围。 服务器端（-side）程序通常具有事务处理（g）、数据库连接（）、消息传递（）等功能。
虽然Web服务器不支持事务处理或数据库连接池，但是可以通过配置（）各种策略（）来实现容错（）和可扩展性（），例如负载均衡（）、缓冲（）。 集群功能（—）经常被误认为是应用服务器独有的功能。
应用服务器()
根据我们的定义，作为一个应用服务器，它通过各种协议（包括HTTP）将业务逻辑暴露给（）客户端应用程序。 Web 服务器主要负责将 HTML 发送到浏览器进行浏览，而应用程序服务器则提供对业务逻辑的访问以供客户端应用程序使用。 应用程序使用此业务逻辑就像调用对象的方法（或过程语言中的函数）一样。
应用服务器客户端（包含图形用户界面（GUI））可以在PC、Web服务器甚至另一个应用服务器上运行。 在应用程序服务器及其客户端之间来回传输的信息不仅仅是简单的显示标签。 相反，该信息是程序逻辑（）。 正是因为这个逻辑采用了数据和方法调用的形式，而不是静态的 HTML，所以客户端可以随心所欲地使用这个暴露的业务逻辑。
大多数情况下，应用服务器通过组件的应用程序编程接口（API）公开业务逻辑（向客户端应用程序），例如基于J2EE（）应用服务器的EJB（）组件。 模型。 此外，应用服务器还可以管理自己的资源，例如看门（gate-）包括安全（）、事务（g）、资源池（）和消息传递（）。 就像 Web 服务器一样，应用程序服务器也配置有各种可扩展性 ( ) 和容错 ( ) 技术。
一个例子
例如，想象一个提供实时定价（real-）和可用性（）信息的在线商店（网站）。 该网站很可能会提供一个表格供您选择产品。 当您提交查询时，网站将执行搜索（）并将结果嵌入 HTML 页面并返回。 网站可以通过多种方式实现此功能。 我将描述一个没有应用程序服务器的场景和一个有应用程序服务器的场景。 观察这两种场景之间的差异将有助于您了解应用程序服务器的功能。
场景 1：没有应用程序服务器的 Web 服务器
在这种情况下，Web 服务器独立提供在线商店的功能。 Web服务器获取你的()，然后将其发送给可以处理()的服务器端(-side)程序。 该程序从数据库或文本文件（译者注：指没有特殊格式的非二进制文件，如XML文件等）中查找定价信息。 一旦找到，服务器端（-side）程序将结果信息表示成（）HTML形式，最后网络服务器将其发送到您的网络浏览器。
简而言之，Web 服务器通过 HTML 页面响应（）来简单地处理 HTTP 请求（）。
场景 2：Web 服务器与应用程序服务器
场景2与场景1相同之处在于Web服务器仍然将()的生成委托给脚本（译者注：服务器端（-side）程序）。 但是，您可以将用于查找定价的业务逻辑放在应用程序服务器上。 由于这一更改，此脚本只是调用应用程序服务器的查找服务 ()，而不是已经知道如何查找数据，然后将其表达为响应 ()。 此时，当脚本生成()时，就可以使用服务的返回结果了。
在此场景中，应用程序服务器提供 () 用于查询产品定价信息的业务逻辑。 （服务器的）此功能不指定有关显示的详细信息以及客户端如何使用此信息，而是客户端和应用程序服务器只是来回发送数据。 当客户端调用应用服务器的查找服务()时，该服务只是进行查找并将结果返回给客户端。
通过分离生成 (-)HTML 作为响应的代码，定价（查找）逻辑在整个应用程序中的可重用性更高。 其他客户端，比如收银机，也可以调用同一个()来充当店员为顾客结账。 相反，场景 1 中的定价查找服务不可重用，因为信息嵌入在 HTML 页面中。
综上所述，在场景 2 模型中，Web 服务器通过响应 HTML 页面来处理 HTTP 请求 ()，而应用服务器通过处理定价和有效性 () 请求 () 来提供应用程序逻辑。
警告（）
现在，应用程序服务器和 Web 服务器之间的界限已经变得模糊。 通过将 XML 负载 () 传递给服务器，Web 服务器现在可以使用与以前的应用程序服务器相同的功能来处理数据和响应 ()。
另外，现在大多数应用服务器还包含Web服务器，这意味着Web服务器可以被视为应用服务器的子集（）。 虽然应用服务器包含了Web服务器功能，但是开发人员很少部署具有该功能的应用服务器（译者注：该功能既指应用服务器功能又指Web服务器功能）。 相反，他们通常独立配置 Web 服务器，并在必要时与应用程序服务器一起配置。 这种功能分离有助于提高性能（简单的 Web 请求（）而不影响应用服务器）、单独的配置（专用 Web 服务器、集群（）等），并为最佳产品的选择留下了空间。
通过：
