# 利刃出鞘_Tomcat 核心原理解析（二）
利刃出鞘_Tomcat 核心原理解析（二）
一、 Tomcat专题 - Tomcat架构 - HTTP工作流程
1、Http 工作原理
HTTP 协议：是浏览器与服务器之间的数据传送协议。作为应用层协议，HTTP 是基于 TCP/IP 协议来传递数据的（HTML文件、图片、查询结果等），HTTP 协议不涉及数据包（Packet）传输，主要规定了客户端和服务器之间的通信格式。
2、HTTP 协议流程图：
3、HTTP 过程：
1） 用户通过浏览器进行了一个操作，比如输入网址并回车，或者是点击链接，接着浏览
器获取了这个事件。
2） 浏览器向服务端发出TCP连接请求。
3） 服务程序接受浏览器的连接请求，并经过TCP三次握手建立连接。
4） 浏览器将请求数据打包成一个HTTP协议格式的数据包。
5） 浏览器将该数据包推入网络，数据包经过网络传输，最终达到端服务程序。
6） 服务端程序拿到这个数据包后，同样以HTTP协议格式解包，获取到客户端的意图。
7） 得知客户端意图后进行处理，比如提供静态文件或者调用服务端程序获得动态结果。
8） 服务器将响应结果（可能是HTML或者图片等）按照HTTP协议格式打包。
9） 服务器将响应数据包推入网络，数据包经过网络传输最终达到到浏览器。
10） 浏览器拿到数据包后，以HTTP协议的格式解包，然后解析数据，假设这里的数据是
HTML。
11） 浏览器将HTML文件展示在页面上。
那我们想要探究的Tomcat作为一个HTTP服务器，在这个过程中都做了些什么事情呢？主
要是接受连接、解析请求数据、处理请求和发送响应这几个步骤。
二、 Tomcat专题 - Tomcat架构 - Tomcat整体架构
1、Http服务器请求处理
浏览器发给服务端的是一个HTTP格式的请求，HTTP服务器收到这个请求后，需要调用服务端程序来处理，所谓的服务端程序就是你写的Java类，一般来说不同的请求需要由不同的 Java 类来处理。
1） 图1 ， 表示HTTP服务器直接调用具体业务类，它们是紧耦合的。
2） 图2，HTTP服务器不直接调用业务类，而是把请求交给容器来处理，容器通过Servlet接口调用业务类。因此Servlet接口和Servlet容器的出现，达到了HTTP服务器与业务类解耦的目的。而Servlet接口和Servlet容器这一整套规范叫作Servlet规范。
Tomcat 按照 Servlet 规范的要求实现了 Servlet 容器，同时它们也具有HTTP服务器的功能。作为Java程序员，如果我们要实现新的业务功能，只需要实现一个Servlet，并把它注册到Tomcat（Servlet容器）中，剩下的事情就由Tomcat帮我们处理了。
2、Servlet 容器工作流程
为了解耦，HTTP服务器不直接调用Servlet，而是把请求交给Servlet容器来处理，那
Servlet容器又是怎么工作的呢？
当客户请求某个资源时，HTTP服务器会用一个ServletRequest对象把客户的请求信息封装起来，然后调用Servlet容器的service方法，Servlet容器拿到请求后，根据请求的URL和Servlet的映射关系，找到相应的Servlet，如果Servlet还没有被加载，就用反射机制创建这个Servlet，并调用Servlet的init方法来完成初始化，接着调用Servlet的service方法来处理请求，把ServletResponse对象返回给HTTP服务器，HTTP服务器会把响应发送给
客户端。
3、Tomcat整体架构
如果要设计一个系统，首先是要了解需求，了解 Tomcat 要实现两个核心功能：
1） 处理Socket连接，负责网络字节流与Request和Response对象的转化。
2） 加载和管理Servlet，以及具体处理Request请求。
因此 Tomcat 设计了两个核心组件连接器（Connector）和容器（Container）来分别做这两件事情。连接器负责对外交流，容器负责内部处理。
三、 Tomcat专题 - Tomcat架构 - Coyote连接器架构介绍
1、连接器 - Coyote 架构介绍
-
Coyote 是 Tomcat 的连接器框架的名称 , 是Tomcat服务器提供的供客户端访问的外部接口。客户端通过 Coyote 与服务器建立连接、发送请求并接受响应 。
-
Coyote 封装了底层的网络通信（Socket 请求及响应处理），为 Catalina 容器提供了统一的接口，使 - Catalina 容器与具体的请求协议及IO操作方式完全解耦。Coyote 将 Socket 输入转换封装为 Request 对象，交由Catalina 容器进行处理，处理请求完成后, Catalina 通过Coyote 提供的 Response 对象将结果写入输出流 。
-
Coyote 作为独立的模块，只负责具体协议和 IO 的相关操作， 与 Servlet 规范实现没有直接关系，因此即便是 Request 和 Response 对象也并未实现Servlet规范对应的接口， 而
是在 Catalina 中将他们进一步封装为 ServletRequest 和 ServletResponse 。
2、 IO 模型与协议
在 Coyote 中 ， Tomcat 支持的多种 I/O 模型和应用层协议，具体包含哪些 IO 模型和应用层协议，请看下表：
1）Tomcat 支持的IO模型（自8.5/9.0 版本起，Tomcat 移除了 对 BIO 的支持）：
| IO模型 | 描述 | ||
|---|---|---|---|
| NIO | 非阻塞I/O，采用Java NIO类库实现。 | ||
| NIO2 | 异步I/O，采用JDK 7最新的NIO2类库实现。 | ||
| APR | 采用Apache可移植运行库实现，是C/C++编写的本地库。如果选择该方案，需要单独安装APR库。 | ||
2）Tomcat 支持的应用层协议 ：
| 应用层协议 | 描述 | ||
|---|---|---|---|
| HTTP/1.1 | 这是大部分Web应用采用的访问协议。 | ||
| AJP | 用于和Web服务器集成（如Apache），以实现对静态资源的优化以及集群部署，当前支持AJP/1.3。 | ||
| HTTP/2 | HTTP 2.0大幅度的提升了Web性能。下一代HTTP协议 ， 自8.5以及9.0版本之后支持。 | ||
3）协议分层 ：
| 应用层 | 传输层 | ||
|---|---|---|---|
| HTTP | NIO | ||
| AJP | NIO2 | ||
| HTTP2 | APR | ||
| Processor | Endpoint | ||
4）在 8.0 之前 ， Tomcat 默认采用的I/O方式为 BIO ， 之后改为 NIO。 无论 NIO、NIO2 还是 APR， 在性能方面均优于以往的BIO。 如果采用APR， 甚至可以达到 Apache HTTP Server 的影响性能。
5）Tomcat 为了实现支持多种I/O模型和应用层协议，一个容器可能对接多个连接器，就好比一个房间有多个门。但是单独的连接器或者容器都不能对外提供服务，需要把它们组装起来才能工作，组装后这个整体叫作Service组件。这里请你注意，Service本身没有做什么重要的事情，只是在连接器和容器外面多包了一层，把它们组装在一起。Tomcat 内可能有多个 Service，这样的设计也是出于灵活性的考虑。通过在Tomcat中配置多个 Service，可以实现通过不同的端口号来访问同一台机器上部署的不同应用。
四、 Tomcat专题 - Tomcat架构 - Coyote连接器组件
1、连接器组件：连接器中的各个组件的作用如下：
2、 EndPoint
1） EndPoint ： Coyote 通信端点，即通信监听的接口，是具体Socket接收和发送处理器，是对传输层的抽象，因此EndPoint用来实现TCP/IP协议的。
2） Tomcat 并没有 EndPoint 接口，而是提供了一个抽象类 AbstractEndpoint ，里面定义了两个内部类：Acceptor 和 SocketProcessor。Acceptor 用于监听Socket连接请求。SocketProcessor 用于处理接收到的Socket请求，它实现 Runnable 接口，在Run方法里调用协议处理组件 Processor 进行处理。为了提高处理能力，SocketProcessor 被提交到线程池来执行。而这个线程池叫作执行器（Executor)，我在后面的专栏会详细介绍 Tomcat 如何扩展原生的 Java 线程池。
3、Processor
Processor ： Coyote 协议处理接口 ，如果说 EndPoint 是用来实现 TCP/IP 协议的，那么 Processor 用来实现HTTP协议，Processor 接收来自 EndPoint 的 Socket，读取字节流解析成 Tomcat Request 和 Response对象，并通过 Adapter 将其提交到容器处理，Processor是对应用层协议的抽象。
4、 ProtocolHandler
ProtocolHandler： Coyote 协议接口， 通过Endpoint 和 Processor ， 实现针对具体协议的处理能力。Tomcat 按照协议和I/O 提供了6个实现类 ： AjpNioProtocol ， AjpAprProtocol， AjpNio2Protocol ， Http11NioProtocol ，Http11Nio2Protocol ，Http11AprProtocol。我们在配置tomcat/conf/server.xml 时 ， 至少要指定具体的 ProtocolHandler , 当然也可以指定协议名称 ， 如 ： HTTP/1.1 ，如果安装了APR，那么将使用Http11AprProtocol ， 否则使用 Http11NioProtocol 。
5、 Adapter
由于协议不同，客户端发过来的请求信息也不尽相同，Tomcat定义了自己的 Request 类来“存放”这些请求信息。ProtocolHandler 接口负责解析请求并生成 Tomcat Request 类。但是这个 Request 对象不是标准的 ServletRequest，也就意味着，不能用 Tomcat Request 作为参数来调用容器。Tomcat设计者的解决方案是引入 CoyoteAdapter，这是适配器模式的经典运用，连接器调用 CoyoteAdapter 的 Sevice 方法，传入的是 Tomcat Request 对象，CoyoteAdapter 负责将 Tomcat Request 转成 ServletRequest，再调用容器的 Service方法。
五、 Tomcat专题 - Tomcat架构 - Catalina容器结构
1、容器 - Catalina
-
Tomcat 是一个由一系列可配置的组件构成的 Web 容器，而 Catalina 是 Tomcat 的 servlet 容器。
-
Catalina 是 Servlet 容器实现，包含了之前讲到的所有的容器组件，以及后续章节涉及到的安全、会话、集群、管理等 Servlet 容器架构的各个方面。它通过松耦合的方式集成 Coyote，以完成按照请求协议进行数据读写。同时，它还包括我们的启动入口、Shell程序等。
2、Catalina 地位：Tomcat 的模块分层结构图， 如下：
Tomcat 本质上就是一款 Servlet 容器， 因此Catalina 才是 Tomcat 的核心 ， 其他模块都是为 Catalina 提供支撑的。 比如 ： 通过 Coyote 模块提供链接通信，Jasper 模块提供JSP引擎，Naming 提供 JNDI 服务，Juli 提供日志服务。
3、Catalina 结构 ：Catalina 的主要组件结构如下：
Catalina 负责管理 Server，而 Server 表示着整个服务器。Server 下面有多个服务 Service，每个服务都包含着多个连接器组件 Connector（Coyote 实现）和一个容器组件 Container。在 Tomcat 启动的时候，会初始化一个 Catalina 的实例。
4、Catalina 各个组件的职责：
| 组件 | 职责 | ||
|---|---|---|---|
| Catalina | 负责解析Tomcat的配置文件 , 以此来创建服务器Server组件，并根据命令来对其进行管理 | ||
| Server | 服务器表示整个Catalina Servlet容器以及其它组件，负责组装并启动Servlet引擎,Tomcat连接器。Server通过实现Lifecycle接口，提供了一种优雅的启动和关闭整个系统的方式 | ||
| Service | 服务是Server内部的组件，一个Server包含多个Service。它将若干个Connector组件绑定到一个Container（Engine）上 | ||
| Connector | 连接器，处理与客户端的通信，它负责接收客户请求，然后转给相关的容器处理，最后向客户返回响应结果 | ||
| Container | 容器，负责处理用户的servlet请求，并返回对象给web用户的模块 | ||
5、Container 结构
Tomcat设计了4种容器，分别是 Engine、Host、Context 和 Wrapper。这4种容器不是平行关系，而是父子关系。Tomcat 通过一种分层的架构，使得Servlet容器具有很好的灵活性。
6、各个组件的含义 ：
| 容器 | 描述 | ||
|---|---|---|---|
| Engine | 表示整个Catalina的Servlet引擎，用来管理多个虚拟站点，一个Service最多只能有一个Engine，但是一个引擎可包含多个Host | ||
| Host | 代表一个虚拟主机，或者说一个站点，可以给Tomcat配置多个虚拟主机地址，而一个虚拟主机下可包含多个Context | ||
| Context | 表示一个Web应用程序， 一个Web应用可包含多个Wrapper | ||
| Wrapper | 表示一个Servlet，Wrapper 作为容器中的最底层，不能包含子容器 | ||
7、 也可以再通过 Tomcat 的 server.xml 配置文件来加深对 Tomcat 容器的理解。Tomcat 采用了组件化的设计，它的构成组件都是可配置的，其中最外层的是 Server，其他组件按照一定的格式要求配置在这个顶层容器中。
<Server<Service><Connector/><Connector/><Engine><Host><Context></Context></Host><Engine></Service>
</Server>
8、Tomcat 是怎么管理这些容器的呢？
这些容器具有父子关系，形成一个树形结构，你可能马上就想到了设计模式中的组合模式。没错，Tomcat 就是用组合模式来管理这些容器的。具体实现方法是，所有容器组件都实现了 Container 接口，因此组合模式可以使得用户对单容器对象和组合容器对象的使用具有一致性。这里单容器对象指的是最底层的 Wrapper，组合容器对象指的是上面的 Context、Host 或 者Engine。
9、Container 接口中提供了以下方法（截图中知识一部分方法） ：
-
在上面的接口看到了getParent、SetParent、addChild和removeChild等方法。
-
Container 接口扩展了 LifeCycle 接口，LifeCycle 接口用来统一管理各组件的生命周期，后面我也用专门的篇幅去详细介绍。
上一节关联链接请点击
# 利刃出鞘_Tomcat 核心原理解析（一）