Web应用程序服务器/反向代理有点像四胞胎

1.1. Web服务器概念和基本原理

1.1.1. Web 服务器的历史

1989 年，互联网之父李向他的雇主 CERN 提出了一个新项目，旨在通过使用超文本系统简化科学家之间的信息交换。 该项目产生了 Lee 在 1990 年编写的两个程序：

1994 年，-Lee 决定成立万维网联盟 (W3C)，通过标准化流程来管理所涉及的许多技术（HTTP、HTML 等）的进一步开发。

这是服务器：

Web服务器的主要功能是存储、处理并向客户端传送网页。 客户端和服务器之间的通信使用超文本传输​​协议 (HTTP) 进行。 交付的页面最常见的是 HTML 文档，除了文本内容之外，还可能包含图像、样式表和脚本。

用户代理，通常是网络浏览器或网络爬虫，通过发出HTTP请求来获取服务器资源，服务器根据请求返回资源或因某种原因返回错误消息。 资源通常是服务器辅助存储上的真实文件，但情况不一定如此，具体取决于Web服务器的实现方式。

虽然主要功能是提供内容，但 HTTP 的完整实现还包括一种从客户端接收内容的方法。 该功能用于提交Web表单，包括上传文件。 许多通用 Web 服务器还支持使用 Pages (ASP)、PHP 或其他脚本语言的服务器端脚本。 这意味着 Web 服务器的行为可以在单独的文件中编写脚本，而实际的服务器软件保持不变。 通常，此函数用于动态生成 HTML 文档（“即时”）而不是返回静态文档。 前者主要用于从数据库中检索或修改信息。 后者通常更快且更容易缓存，但无法提供动态内容。

Web 服务器不仅用于为万维网提供服务。 它们还可以嵌入到打印机、路由器、网络摄像机等设备中，并仅服务于本地网络。 然后，网络服务器可以用作监控或管理相关设备的系统的一部分。 这通常意味着无需在客户端计算机上安装其他软件，因为只需要 Web 浏览器（现在大多数操作系统都包含该浏览器）。

1.1.2. Web服务器工作原理

HTTP协议基于TCP协议，是用于用户代理和Web服务器之间通信的应用层协议。 Web 服务器通常以问答方式工作：

用户向用户代理发起资源请求。 请求内容包括但不限于：指定资源的唯一标识URI和类型（GET/POST//PUT...）

用户代理解析用户输入的URI并从中获取目标域名，然后由DNS服务器解析。 如果URI中指定了IP地址，则不需要此步骤。

如果与服务器的会话尚未建立，则首先建立TCP连接并完成HTTP协商（确定双方都能接受的处理方式，包括协议版本、是否加密、内容格式等）。

用户代理将请求内容封装成HTTP数据包并发送给服务器。

服务器收到资源请求后，按照之前协商好的方式进行解包处理。

服务器请求的资源被封装成HTTP数据包返回给用户代理。

接下来我们重点介绍一下服务器端的工作原理。

主流网络服务器

包括，IIS、Nginx，市场份额如下

比较常用的还有，Jetty，，等等。

1.2. Web应用容器概念和基本原理

1.2.1. Web应用容器的起源

Web服务器的出现标志着WWW时代的到来，世界变得更加平坦。 尝到好处的先行者不满足于在互联网上获取静态资源，于是出现了动态获取资源的CGI脚本。 后来网络的发展方向也是朝着增强Web服务器动态获取资源的能力。 以下是具有代表性的动态技术：

技术术语的特点

CGI（通用网关接口）

作为独立进程运行，可以用多种语言开发，例如 C、C++、VB 和 Perl。 它很灵活，但效率低下且维护复杂。

PHP

服务器端嵌入HTML脚本，开源，功能强大，扩展性差

联合应用程序

在服务器端嵌入HTML脚本是跨平台的，需要在部署之前进行编译。 主要缺点是编写JSP比较复杂，需要熟悉JAVA及相关技术。

ASP

服务器端嵌入HTML脚本，开发简单，功能强大。 它只能在下面运行

随后，Web服务器向企业级应用发展，快速的业务变化迫使Web开发人员面临新的挑战：如何快速编写健壮、可靠、满足业务需求的程序并顺利部署？ 解决这一挑战的有效方法是创建Web程序开发框架（包括运行环境，如解释和执行JSP、Web API）。 该框架解决了健壮性和可靠性问题，并提供了快速开发接口。 也就是说，开发者只需要专注于实现业务本身，如果有更高的需求，可以对框架进行定制和扩展。 该框架的另一个名称是 Web 应用程序容器。

1.2.2. Web应用容器的基本工作原理

一般来说，一个Web应用程序容器具有以下结构：

注：浅蓝色模块是用于实现业务程序的主要模块。

与Web服务器相比，该容器有以下新增或增强的模块：

容器分配一个线程来处理每个请求，通常使用线程池来有效地使用CPU计算资源。

一个请求对应一个上下文，它主要封装了用户请求的主要组成部分：URL、HTTP请求头以及根据请求头构建的对象，以方便编程。

一个请求对应一个上下文，主要用于向用户代理返回资源。 你可以在其中写入输出流，或者重定向它，或者返回错误代码等。

在容器中，运行的开发者设置不同的路由匹配规则，比如让.HTM返回.HTML，或者自定义.xyz返回.HTML资源。 如需更灵活的配置，可以参考JAVA MVC或ASP.NET MVC的配置方案。

通常这里的具体容器和开发语言都有自己高效的开发模式，比如JAVA、ASP.NET的Web Form、MVC等。

刚才的线程资源会在这里被回收。 对于线程的复用，除非服务器空闲，否则线程将被返回到线程池中。

可见Web容器本身就具有作为Web服务器的功能。 事实上，通常实现Web容器功能的服务器就是Web服务器。 例如，IIS 和 Jetty。

主流Web容器

包括，IIS，Jetty。

还有更多的用途等等。

1.3. Web应用服务器概念和基本原理

在Web服务器发展的同时，应用服务器也已经存在并发展了很长一段时间。 一些公司开发了（面向事务的中间件）、、等针对Unix的产品。 这些产品源自主机应用程序管理和监控环境，例如 IMS 和 CICS。 这些产品中的大多数都指定“封闭”的产品特定通信协议来互连胖客户端（“胖”）和服务器。 20世纪90年代，这些传统的应用服务器产品开始嵌入HTTP通信功能，最初使用的是网关。 没过多久，他们之间的界限就开始变得模糊。

同时，Web服务器日趋成熟，可以处理更高的负载、更多的并发量，并且具有更好的功能； 应用服务器开始添加越来越多的基于HTTP的通信功能。 所有这些都导致 Web 服务器和应用程序服务器之间的界限变得越来越窄。

如今，“应用程序服务器”和“Web 服务器”之间的界限已经变得模糊。 但人们也会区分这两个术语并使用它们来强调。

当有人说“Web 服务器”时，您通常会将其视为一个以 HTTP 为核心、以 Web UI 作为指导的应用程序。 当有人说“应用程序服务器”时，您可能会想到“高负载、企业级功能、事务和队列、多通道通信（HTTP 和更多协议）”。 但现在提供这些需求的基本上是同一个产品。

下图描述了一个典型的Web应用服务器的结构图：

从上图可以看到，Web应用服务器包含了Web容器，内置了事务、安全、集成、通信、高可用等功能来支持企业应用，大大减少了重复的工作量开发并保证业务系统的速度。 开发部署，同时也是一个Web服务器。 Web应用服务器可以选择使用大厂商的重量级产品，也可以使用像Jetty和第三方框架（等）自己搭建的Web服务器； 您可以选择使用.NET Core平台。 使用 IIS、Nginx 和 ASP.NET Core 构建。

1.4. 反向代理的概念和基本原理

1.4.1. 反向代理的基本概念

反向代理是代理服务器的一种。 它根据客户端的请求从后端服务器（如Web服务器）获取资源，然后将这些资源返回给客户端。 正向代理充当将从 获取的资源返回给关联客户端的媒介，而反向代理则不同，它用作服务器端（例如 Web 服务器）而不是客户端的代理。 客户端通过正向代理可以访问很多不同的资源，而反向代理则被很多客户端用来访问不同后端服务器上的资源，而不知道这些后端服务器的存在，而是认为所有资源都来自于此反向代理服务器。

来自互联网的请求被发送到反向代理，反向代理将请求转发到内网的服务器。

反向代理的主要功能有：

1.4.2. 反向代理的基本工作原理

反向代理服务器的组成和处理过程如下：

左侧浅黄色功能模块处理外部网络报文，右侧灰色功能模块处理内部网络报文。

常用的反向代理服务器

它们的名字您一定记得：Ngnix,IIS,Apache。

1.5. 概括

从概念上讲：Web服务器是提供WWW服务的程序； Web容器是提供给开发者的一个框架； Web应用服务器的内容要丰富得多，可以由各个厂家生产，通常遵循一定的工业标准，定制扩展功能。 ，也可以使用开源组件的轻量级组装来构建； 反向代理服务器在企业级应用中表现突出，具有解决集中式安全、负载均衡等优势。如今，​​这四个概念的界限越来越模糊。 看看这个表你就知道了：

软件名词是否是Web服务器、是否是Web容器、Web应用服务器是否可以反向代理

信息系统

是的

是的

是的

nginx

是的

是的

是的

是的

是的

是的

码头

是的

是的

是的

是的

是的

是的

是的

是的

是的

是的？