图解Spring：HTTP请求的处理流程与机制【2】

2. HTTP 请求在 Web 容器中的处理流程

Web 容器以进程的方式在计算机上运行，我们知道进程是系统资源分配的最小单元，线程是系统任务执行的最小单元。从这个角度看，Web 容器就像是邮包收件人所居住的楼宇或小区，HTTP 这套物流快递体系只能将邮包投递到楼宇前台或者小区物业等处，而楼宇前台或小区物业并不属于物流快递体系，就像 Web 容器并不属于计算机网络基础设施一样。之所以这样分工，原因是网络路由信息由域名服务器 DNS、路由器等设备掌握，Web 容器内部体系结构信息只有它自己知道。从 Web 容器接收到 HTTP 请求，到将其投送至特定的应用，这期间还会经历一个复杂的过程，了解这个过程对于日常开发和问题分析都会有所帮助。接下来，老兵哥我将陪着你一起来剖析这个过程。

创新互联建站是专业的二道网站建设公司，二道接单;提供成都做网站、网站建设、外贸营销网站建设,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行二道网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!

JAVA 语言领域的 Web 容器类型非常多，包括 Tomcat、Jetty、Resin、Websphere、Weblogic、JBoss、Glassfish、GonAS 等，其中 Tomcat 是由 Apache Software Foundation 维护的开源 Web 容器。Tomcat 市场占用率接近 60%，截止目前是最受欢迎的 Web 容器，如下图所示横跨 Web 服务器和 Java 应用服务器。

我们就以 Tomcat 为例来看看 Web 容器的内部结构，作为符合 JAVA Servlet 标准规范的容器，Tomcat 是一款基于组件的 Java Web 应用服务器，核心组件都是灵活可配的。Tomcat 最外层是 Catalina Servlet 容器，其他组件是按照特定格式要求配置在这个顶层容器当中，配置文件就是安装目录下的：/conf/server.xml。通过这份配置文件，我们就可以了解 Tomcat 的体系结构，示例文件如下所示（快速浏览一遍，后面详细剖析）：

2.1 Tomcat 核心组件简介

如果经常使用配置 Tomcat，那么你对上述配置文件一定非常熟悉。为了方便大家理解，结合本文的主题，我们把上述这份配置文件中的关键节点提取出来，然后再逐一分析介绍：

上述结构中包含了 Tomcat 的核心组件：Server 组件在最顶层，代表整个 Tomcat 容器。一个 Server 组件中可以包含一个或多个 Service 组件。Service 在 Connector 和 Engine 外面包了一层，把它们组装在一起对外提供服务。一个 Service 可以包含多个 Connector，但是只能包含一个 Engine。不同 Connector 负责接收不同端口上相应协议的请求，而 Engine 负责处理请求。Engine 包含一个或多个 Host，Host 包含一个或多个 Context，Engine、Host、Context 都属于容器组件，一个 Host 组件代表一个虚拟主机，一个 Context 组件代表在隶属 Host 上运行的一个 Web 应用。

2.1.1 顶层类组件 Server

它是整个配置文件的唯一根元素，代表整个 Tomcat 容器，内部可以包含多个 Service。Server 主要职责就是管理多个 Service，对外提供给客户端访问，同时维护所有 Service 的生命周期，包括初始化服务、结束服务、定位客户端要访问的 Service 等等。所有 Tomcat 组件的生命周期都是通过 Lifecycle 接口来控制的，组件只要继承这个接口并实现其中的方法就可以统一被父组件控制了，这样层层递进 Server 组件就可以控制所有组件的生命周期了，而控制 Server 就是通过启动和关停 Tomcat。在前面配置示例中，Server 的配置如下所示：

其中，属性 shutdown 指定关闭 Server 的指令。属性 port 指定 Server 接收 shutdown 指令的端口号，设置为“-1”可以禁掉该端口。

2.1.2 顶层类组件 Service

Service 主要职责就是将 Engine 与 Connector 装配在一起对外提供服务，一个 Service 可以包含多个 Connector，但只能包含一个 Engine，其中 Connector 负责从客户端接收请求，Engine 负责处理 Connector 接收进来的请求。如前面配置示例中，Service 的配置如下所示：

我们可以通过属性 name 为 Service 指定名称，不同的 Service 负责监管其下属 Connector 所绑定的端口。

2.1.3 连接器组件 Connector

Tomcat 的工作模式可以分为下面两类：

• 作为 Web 服务器：请求是直接来自于客户端 HTTP 请求（或浏览器）。
• 作为 Java Web 应用服务器：请求来自于前置 Web 服务器，通常包括：Apache、IIS、Nginx 等。Tomcat 主要优势是作为 JSP/Servlet 容器，在处理静态资源方面效率偏低。因此，它通常要跟 Apache、IIS、Nginx 等 Web 服务器集成使用。AJP 协议主要负责 Tomcat 和集成 Web 服务器的交互连接。
  
  每个 Service 可以有一个或多个 Connector，不同工作模式下，Tomcat 需要为各种类型的请求分别定义相应的 Connector，这样才能正确接收客户端对应协议的请求。定义 Connector 可以使用多种属性，某些属性只适用于某种特定的 Connector 类型。一般说来，常见的 Connector 有 4 种类型：HTTP、SSL、AJP、Proxy。
  
  作为通信接口，Connector 为其所属特定的 Service 接收外部客户端请求，以及回送应答至外部客户端。具体职责包括创建 Request、Response 对象用于跟外部客户端交换数据，并将 Request 交给配套的 Engine 来处理。通过修改 Connector 的属性取值，我们可以控制 Service 所监听的网络协议及端口号，具体示例如下：

• 配置一，客户端可以通过 8080 端口号使用 HTTP 协议访问 Tomcat。
• 配置二，客户端可以通过 8009 端口使用 AJP 协议访问 Tomcat。AJP 协议主要用于跟其他的 HTTP 服务器连接协作。当 Tomcat 与其他 HTTP 服务器集成时，我们就要用到这个连接器。
• 配置三，客户端可以通过 8443 端口号使用 HTTPS 协议访问 Tomcat。

连接器的定义可以配置的属性非常多，下面是常用属性的说明：

• address：指定连接器监听的地址，默认为所有地址，即：0.0.0.0。
• maxThreads：支持最大的并发连接数，默认为：200。
• port：监听端口，默认为：0。
• protocol：连接器使用的协议，默认为：HTTP/1.1，定义 AJP 协议时通常为：AJP/1.3。
• redirectPort：在强制要求 HTTPS 的情况下，如果请求时 HTTP，则将会被重定向至 8443 端口。
• connectionTimeout：连接的超时时间，单位为毫秒，默认为 60000，即 1 分钟；
• enableLookups：是否通过 request.getRemoteHost() 进行 DNS 查询以获取客户端的主机名。
• acceptCount：设置等待队列的最大长度。通常，在 Tomcat 所有处理线程均处于繁忙状态时，新请求将被放置于等待队列中。

2.1.4 容器类组件 Engine

Engine 内部可以包含多个 Host，它是 Service 组件中负责请求处理的组件。它从一个或多个 Connector 中接收请求并处理，并将处理结果封装成应答交给 Connector，最终回传给外部客户端。在前文配置文件示例中，Engine 的配置如下所示：

其中，属性 name 用于日志和错误信息，其取值在整个 Server 中保证唯一。属性 defaultHost 指定了默认的Host 名称，当 HTTP 请求所指定的 Host 名称不存在时，一律使用 defaultHost 指定的 Host 来处理。因此，defaultHost 的值，必须与 Engine 中的某个 Host 组件的属性 name 取值匹配。

2.1.5 容器类组件 Host

Host 代表一个虚拟主机，它对应计算机网络上的一个实体，即某个在 DNS 服务器上注册过的域名或者 IP 地址，例如：www.abc.com 或 201.187.10.21。Host 内部可以包含多个 Context，每个 Context 表示一个 Web 应用。Host 负责安装、展开、启动和结束每个 Web 应用。

客户端在填写收件人地址时会通过主机名来标识它希望访问的服务器，Tomcat 将从 HTTP 请求头的 Host 字段提取主机名，然后再匹配对应的虚拟主机。如果没有找到匹配的，HTTP 请求将被发送至默认主机 defaultHost。因此，默认主机不需要是在 DNS 服务器上注册的网络名，例如：localhost。在前面配置示例中，Host 的配置如下所示：

其中，属性 name 指定虚拟主机的名称。属性 appBase 指定 Web 应用所在的目录，默认值是 webapps，这是一个相对路径，标识 Tomcat 安装根目录下的 webapps 文件夹。属性 unpackWARs 指定是否将 Web 应用的 WAR 文件解压。如果取值为 true，Tomcat 将以解压后的文件结构运行该 Web 应用；如果为 false，Tomcat 将直接使用 WAR 文件运行 Web 应用。属性 autoDeploy 指定是否自动部署 Web 应用。

2.1.6 容器类组件 Context

Context 代表在特定虚拟主机上运行的一个 Web 应用，负责处理某个特定 Web 应用的所有请求。每个 Web 应用要么基于 WAR 文件，要么基于 WAR 文件解压后对应的文件目录。在前文配置文件示例中，我们没有看到 Context 的配置，这是因为 Host 开启了自动部署，Web 应用没有在配置文件中配置静态部署，而是由 Tomcat 通过特定的规则自动部署，Context 组件也将被自动创建。Context 通过属性 path 来唯一标识自身。考虑到 Web 应用自动部署与本文主题关系不大，老兵哥我就不再展开，如果你对此内容感兴趣，可以找资料做扩展阅读。

2.1.7 内嵌类元素

除了前面介绍的核心组件外，Tomcat 还提供了 Listener、GlobalNamingResources、Realm、Valve 等组件，这些组件都是嵌入到核心组件当中来使用，我们将它们归为内嵌组件，考虑到不涉及主题就不再赘述。

2.2 Tomcat 处理 HTTP 请求的流程

在前面各个章节介绍的各种核心组件基础上，我们一起来看看，当 HTTP 请求被投递到 Tomcat 所在主机之后，Tomcat 是如何将 HTTP 请求派发给特定的 Web 应用来处理的：

• 根据协议类型和端口号选定 Service 和 Engine：Service 下属的 Connector 组件负责监听接收特定协议和特定端口的请求。因此，当 Tomcat 启动时，Service 组件就开始监听特定的端口，如前文配置文件示例，Catalina 这个 Service 监听了 HTTP 协议 8080 端口和 AJP 协议的 8009 端口。当 HTTP 请求抵达主机网卡的特定端口之后，Tomcat 就会根据协议类型和端口号选定处理请求的 Service，随即 Engine 也就确定了。通过在 Server 中配置多个 Service，可以实现通过不同端口访问同一主机上的不同应用。
• 根据域名或 IP 地址选定 Host：待 Service 被选定之后，Tomcat 将在 Service 中寻找与 HTTP 请求头中指定的域名或 IP 地址匹配的 Host 来处理该请求。如果没有匹配成功，则采用 Engine 中配置的默认虚拟主机 defaultHost 来处理该请求。
• 根据 URI 选定 Context：URI 中的 context-path 指定了 HTTP 请求将要访问的 Web 应用。当请求抵达时，Tomcat 将根据 Context 的属性 path 取值与 URI 中的 context-path 的匹配程度来选择 Web 应用处理相应请求，例如：Web 应用 spring-demo 的 path 属性是”/spring-demo”，那么请求“/spring-demo/user/register”将交由 spring-demo 来处理。
  
  最终，我们还是继续用向下文这个地址发送 HTTP 请求为例，将整个处理流程串一遍：

http://201.187.10.21:8080/spring-demo/user/register

1. 客户端（或浏览器）发送请求至主机（201.187.10.21）的端口 8080，被在该端口上监听的 Coyote HTTP/1.1 Connector 所接收。
2. Connector 将该请求交给它所在 Service 的 Engine 来负责处理，并等待 Engine 的回应。
3. Engine 获得请求之后从报文头中提取主机名称（201.187.10.21），在所有虚拟主机 Host 当中寻找匹配。
4. 在未匹配到同名虚拟主机的情况下，Engine 将该请求交给名为 localhost 的默认虚拟主机 Host 处理。
5. Host 获得请求之后将根据 URI（/spring-demo/user/register）中的 context-path 的取值“/spring-demo” 去匹配它所拥有的所有 Context，将请求交给代表应用 spring-demo 的 Context 来处理。
6. Context 构建 HttpServletRequest、HttpServletResponse 对象，将其作为参数调用应用 spring-demo，由应用完成业务逻辑执行、结果数据存储等过程，等待应答数据。
7. Context 接收到应用返回的 HttpServletResponse 对象之后将其返回给 Host。
8. Host 将 HttpServletResponse 对象返回给 Engine。
9. Engine 将 HttpServletResponse 对象返回 Connector。
10. Connector 将 HttpServletResponse 对象返回给客户端（或浏览器）。

2.3 Tomcat 体系结构演进的趋势剖析

从上述体系结构剖析来看，Tomcat 这款 Java Web 应用服务器的功能还是非常强大的，它可以在一个实例进程当中同时支持多种协议，同时支持多个虚拟主机，每个虚拟主机下还支持部署多款应用，具备强大的扩展性和灵活性。为什么它具备这样一种体系结构呢？这其实跟 Tomcat 诞生时的基础架构相匹配的，当时服务器是以小型机或 PC 服务器为主，缺乏现在容器这种切分资源的虚拟技术，进程是系统资源分配的最小单元。为了更加充分地利用每台计算机上的资源，我们通常要在同一台计算机上部署多款应用，但是在一台计算机上运行多个 Tomcat 实例所带来的复杂度是非常高的，不如在同一个 Tomcat 实例中部署多款 Web 应用，这样在配置运维等管理上面更加便利。

在这种架构下，Tomcat 处理 HTTP 请求就需要经过上述复杂的过程，这也再次印证老兵哥我坚信的一个观点：不存在绝对好或坏的架构，匹配当时业务场景的架构就是好架构！随着互联网业务的发展和云计算的兴起，为了更好地管理大规模应用集群，我们需要借助容器等虚拟化技术将大颗粒资源分割成更小的、标准的单元，每个容器中只安装一个 Web 容器，每个 Web 容器中只部署一个应用，在标装化下我们就可以采用云计算的自动化操作。

按照这个趋势发展下去，Web 容器的架构用不着这么复杂了，其价值也会不断弱化。以前，Tomcat 都是需要单独安装的，应用是后续再部署到 Tomcat 当中的。但目前在 Spring Boot 的开发模式下，Tomcat 是以 Starter 方式作为内嵌 Web 容器，它已经不再需要独立安装部署了。在越来越标装化的趋势下，Tomcat 基本上采用默认配置，用户基本上不用太关注它了。剖析了解它的原因，就是老兵哥我在开题中所说的：知其然，知其所以然。

这个演进过程就像住宅样式的变迁，古代城市人口密度没有这么大，每家每户都是独门独院的平房。随着近代人口不断涌入城市，早前住宅的空间利用率太低，无法支撑快速增长的居住需求，这时候高层楼房就应运而生了，每栋楼房都有多个楼层，每个楼层分割成多套房子，每套房子居住一户家庭，Tomcat 的体系结构就类似这种高层楼房。但现代城市的人口还在不断增长，早前的高层楼房也无法满足居住需求了，不够标准化，缺乏物业管理，周边配套不全，空间利用率还有待于提高，在这种情况下楼盘小区诞生了，标准化得到了提升，也配套了物业管理，这就类似云计算。

本文主要价值是帮助大家梳理出端到端的全流程框架，也就是我们常说的全局视角或者上帝视角。有了这个框架之后，我们可以根据自己的需要按图索骥找相关节点的资料来研究学习，不至于陷入细节找不到方向。当然，考虑到我们每个人的工作学习情况不同，平时遇到的问题也不同，本文内容无法覆盖所有人遇到的问题，欢迎大家留言提问，也欢迎关注我的博客或公号“IT老兵哥”交流互动，我会尽力尽快解答大家提出的问题，谢谢！

本系列其他文章索引如下：

• 图解 Spring：HTTP 请求的处理流程与机制【1】
• 图解 Spring：HTTP 请求的处理流程与机制【3】
• 图解 Spring：HTTP 请求的处理流程与机制【4】
• 图解 Spring：HTTP 请求的处理流程与机制【5】