Tomcat的连接器与容器

Posted 2020-12-07 Moonshoterr

 

 

Tomcat有两个核心功能：

1.处理 Socket 连接，负责网络字节流与 Request 和 Response 对象的转化。

2.加载和管理 Servlet，以及具体处理 Request 请求。

因此 Tomcat 设计了两个核心组件连接器（Connector）和容器（Container）来分别做 这两件事情。连接器负责对外交流，容器负责内部处理。

首先，Tomcat支持的I/O模型有：

NIO：非阻塞 I/O，采用 Java NIO 类库实现。

NIO2：异步 I/O，采用 JDK 7 最新的 NIO2 类库实现。

APR：采用 Apache 可移植运行库实现，是 C/C++ 编写的本地库。

Tomcat 支持的应用层协议有：

HTTP/1.1：这是大部分 Web 应用采用的访问协议。

AJP：用于和 Web 服务器集成（如 Apache）。

HTTP/2：HTTP 2.0 大幅度的提升了 Web 性能。

Tomcat 为了实现支持多种 I/O 模型和应用层协议，一个容器可能对接多个连接器。但是单独的连接器或者容器都不能对外提供服务，需要把它们组装起来 才能工作，组装后这个整体叫作 Service 组件。Service 本身没有做什么重 要的事情，只是在连接器和容器外面多包了一层，把它们组装在一起。Tomcat 内可能有多 个 Service，这样的设计也是出于灵活性的考虑。通过在 Tomcat 中配置多个 Service，可 以实现通过不同的端口号来访问同一台机器上部署的不同应用。

 

最顶层是 Server，这里的 Server 指的就是一个 Tomcat 实例。一个 Server 中有一个或者多个 Service，一个 Service 中有多个连接器和一个容器。连接器与容 器之间通过标准的 ServletRequest 和 ServletResponse 通信。

一.连接器

连接器对 Servlet 容器屏蔽了协议及 I/O 模型等的区别，无论是 HTTP 还是 AJP，在容器 中获取到的都是一个标准的 ServletRequest 对象。

连接器的工作流程可分为：

监听网络端口。

接受网络连接请求。

读取请求网络字节流。

根据具体应用层协议（HTTP/AJP）解析字节流，生成统一的 Tomcat Request 对象。

将 Tomcat Request 对象转成标准的 ServletRequest。

调用 Servlet 容器，得到 ServletResponse。

将 Tomcat Response 转成网络字节流。

将响应字节流写回给浏览器。

 

连接器需要完成 3 个高内聚的功能。

网络通信。

应用层协议解析。

Tomcat Request/Response 与 ServletRequest/ServletResponse 的转化。

将 ServletResponse 转成 Tomcat Response 对象。

因此 Tomcat 设计了 3 个组件来实现这 3 个功能，分别是 EndPoint、Processor 和 Adapter。

网络通信的 I/O 模型是变化的，可能是非阻塞 I/O、异步 I/O 或者 APR。应用层协议也是 变化的，可能是 HTTP、HTTPS、AJP。浏览器端发送的请求信息也是变化的。 但是整体的处理逻辑是不变的，EndPoint 负责提供字节流给 Processor，Processor 负责 提供 Tomcat Request 对象给 Adapter，Adapter 负责提供 ServletRequest 对象给容 器。

连接器用 ProtocolHandler 来处理网络连接和应用层协议，包含了 2 个 重要部件：EndPoint 和 Processor

系统也存在一些相对稳定的部分，因此 Tomcat 设计了一系列抽象基类 来封装这些稳定的部分，抽象基类 AbstractProtocol 实现了 ProtocolHandler 接口。每 一种应用层协议有自己的抽象基类，比如 AbstractAjpProtocol 和 AbstractHttp11Protocol，具体协议的实现类扩展了协议层抽象基类。

EndPoint 是通信端点，即通信监听的接口，是具体的 Socket 接收和发送处理器，是对传 输层的抽象，因此 EndPoint 是用来实现 TCP/IP 协议的。 EndPoint 是一个接口，对应的抽象实现类是 AbstractEndpoint，而 AbstractEndpoint 的具体子类，比如在 NioEndpoint 和 Nio2Endpoint 中，有两个重要的子组件： Acceptor 和 SocketProcessor。

其中 Acceptor 用于监听 Socket 连接请求。SocketProcessor 用于处理接收到的 Socket 请求，它实现 Runnable 接口，在 Run 方法里调用协议处理组件 Processor 进行处理。为 了提高处理能力，SocketProcessor 被提交到线程池来执行。而这个线程池叫作执行器 （Executor)，。

如果说 EndPoint 是用来实现 TCP/IP 协议的，那么 Processor 用来实现 HTTP 协议， Processor 接收来自 EndPoint 的 Socket，读取字节流解析成 Tomcat Request 和Response 对象，并通过 Adapter 将其提交到容器处理，Processor 是对应用层协议的抽 象。Processor 是一个接口，定义了请求的处理等方法。它的抽象实现类 AbstractProcessor 对一些协议共有的属性进行封装，没有对方法进行实现。具体的实现有 AJPProcessor、 HTTP11Processor 等，这些具体实现类实现了特定协议的解析方法和请求处理方式。

EndPoint 接收到 Socket 连接后，生成一个 SocketProcessor 任务提交 到线程池去处理，SocketProcessor 的 Run 方法会调用 Processor 组件去解析应用层协 议，Processor 通过解析生成 Request 对象后，会调用 Adapter 的 Service 方法。

我在前面说过，由于协议不同，客户端发过来的请求信息也不尽相同，Tomcat 定义了自己 的 Request 类来“存放”这些请求信息。ProtocolHandler 接口负责解析请求并生成 Tomcat Request 类。但是这个 Request 对象不是标准的 ServletRequest，也就意味着， 不能用 Tomcat Request 作为参数来调用容器。Tomcat 设计者的解决方案是引入 CoyoteAdapter，这是适配器模式的经典运用，连接器调用 CoyoteAdapter 的 Sevice 方法，传入的是 Tomcat Request 对象，CoyoteAdapter 负责将 Tomcat Request 转成 ServletRequest，再调用容器的 Service 方法。

 

 

二.容器

在 Tomcat 里，容器就是用来装载 Servlet 的。Tomcat 设计了 4 种容器，分别是 Engine、Host、Context 和 Wrapper。这 4 种容器不 是平行关系，而是父子关系。

Tomcat 通过一种分层的架构，使得 Servlet 容器具有很好的灵活性。

Context 表示一个 Web 应用程序；Wrapper 表示一个 Servlet，一个 Web 应用程序中可 能会有多个 Servlet；Host 代表的是一个虚拟主机，或者说一个站点，可以给 Tomcat 配 置多个虚拟主机地址，而一个虚拟主机下可以部署多个 Web 应用程序；Engine 表示引 擎，用来管理多个虚拟站点，一个 Service 最多只能有一个 Engine。

Tomcat 就是用组合模式来管理 这些容器的。具体实现方法是，所有容器组件都实现了 Container 接口，因此组合模式可 以使得用户对单容器对象和组合容器对象的使用具有一致性。这里单容器对象指的是最底层 的 Wrapper，组合容器对象指的是上面的 Context、Host 或者 Engine。Container 接口 定义如下：

 

 在上面的接口中有 getParent、SetParent、addChild 和 removeChild 等方法。 Container 接口还扩展了 LifeCycle 接口，LifeCycle 接口用来统一管理各组件的生命周期

。Tomcat 是用 Mapper 组件来完成确定请求是由哪个 Wrapper 容器 里的 Servlet 来处理的。

Mapper 组件的功能就是将用户请求的 URL 定位到一个 Servlet，它的工作原理是： Mapper 组件里保存了 Web 应用的配置信息，其实就是容器组件与访问路径的映射关系， 比如 Host 容器里配置的域名、Context 容器里的 Web 应用路径，以及 Wrapper 容器里 Servlet 映射的路径，这些配置信息就是一个多层次的 Map。

当一个请求到来时，Mapper 组件通过解析请求 URL 里的域名和路径，再到自己保存的 Map 里去查找，就能定位到一个 Servlet。一个请求 URL 最后只会定位到一个 Wrapper 容器，也就是一个 Servlet。

假如有一个网购系统，有面向网站管理人员的后台管理系统，还有面向终端客户的在线购物 系统。这两个系统跑在同一个 Tomcat 上，为了隔离它们的访问域名，配置了两个虚拟域 名：manage.shopping.com和user.shopping.com，网站管理人员通过 manage.shopping.com域名访问 Tomcat 去管理用户和商品，而用户管理和商品管理是 两个单独的 Web 应用。终端客户通过user.shopping.com域名去搜索商品和下订单， 搜索功能和订单管理也是两个独立的 Web 应用。 针对这样的部署，Tomcat 会创建一个 Service 组件和一个 Engine 容器组件，在 Engine 容器下创建两个 Host 子容器，在每个 Host 容器下创建两个 Context 子容器。由于一个 Web 应用通常有多个 Servlet，Tomcat 还会在每个 Context 容器里创建多个 Wrapper 子容器。每个容器都有对应的访问路径。

 

 

 假如有用户访问一个 URL，比如图中的 http://user.shopping.com:8080/order/buy，Tomcat 如何将这个 URL 定位到一 个 Servlet 呢？ 首先，根据协议和端口号选定 Service 和 Engine。我们知道 Tomcat 的每个连接器都监听不同的端口，比如 Tomcat 默认的 HTTP 连接器监 听 8080 端口、默认的 AJP 连接器监听 8009 端口。上面例子中的 URL 访问的是 8080 端 口，因此这个请求会被 HTTP 连接器接收，而一个连接器是属于一个 Service 组件的，这 样 Service 组件就确定了。我们还知道一个 Service 组件里除了有多个连接器，还有一个容 器组件，具体来说就是一个 Engine 容器，因此 Service 确定了也就意味着 Engine 也确定 了。然后，根据域名选定 Host。Service 和 Engine 确定后，Mapper 组件通过 URL 中的域名去查找相应的 Host 容器，比 如例子中的 URL 访问的域名是user.shopping.com，因此 Mapper 会找到 Host2 这个 容器。之后，根据 URL 路径找到 Context 组件。 Host 确定以后，Mapper 根据 URL 的路径来匹配相应的 Web 应用的路径，比如例子中访 问的是 /order，因此找到了 Context4 这个 Context 容器。 最后，根据 URL 路径找到 Wrapper（Servlet）。Context 确定后，Mapper 再根据 web.xml 中配置的 Servlet 映射路径来找到具体的 Wrapper 和 Servlet。

 

连接器中的Adapter 会调用容器的 Service 方法来执行 Servlet，最先拿到请求的是 Engine 容器， Engine 容器对请求做一些处理后，会把请求传给自己子容器 Host 继续处理，依次类推， 最后这个请求会传给 Wrapper 容器，Wrapper 会调用最终的 Servlet 来处理。那么这个 调用过程使用 Pipeline-Valve 管道实现。

Pipeline-Valve 是责任链模式，责任链模式是指在一个请求处理的过程中有很多处理者依 次对请求进行处理，每个处理者负责做自己相应的处理，处理完之后将再调用下一个处理者 继续处理。Valve 表示一个处理点，比如权限认证和记录日志。如果你还不太理解的话，下面是Valve 和 Pipeline 接口中的关键方法。

 

 由于 Valve 是一个处理点，因此 invoke 方法就是来处理请求的。注意到 Valve 中有 getNext 和 setNext 方法，因此一个链表将 Valve 链起来了。

 

 Pipeline 中有 addValve 方法。Pipeline 中维护了 Valve 链表，Valve 可以插入到 Pipeline 中，对请求做某些处理。我们还发现 Pipeline 中没有 invoke 方法，因为整个调 用链的触发是 Valve 来完成的，Valve 完成自己的处理后，调用 getNext.invoke() 来触发 下一个 Valve 调用。

每一个容器都有一个 Pipeline 对象，只要触发这个 Pipeline 的第一个 Valve，这个容器里 Pipeline 中的 Valve 就都会被调用到。

上级容器Engine 中 Pipeline 需要调用下层容器 Host 中的 Pipeline又该如何做到呢？

答案是Pipeline 中还有个 getBasic 方法。这个 BasicValve 处于 Valve 链表的末端，它 是 Pipeline 中必不可少的一个 Valve，负责调用下层容器的 Pipeline 里的第一个 Valve。

整个调用过程由连接器中的 Adapter 触发的，它会调用 Engine 的第一个 Valve：

 

 Wrapper 容器的最后一个 Valve 会创建一个 Filter 链，并调用 doFilter() 方法，最终会调 到 Servlet 的 service 方法。

Valve 和 Filter 它们的区别是：

Valve 是 Tomcat 的私有机制，与 Tomcat 的基础架构 /API 是紧耦合的。Servlet API 是公有的标准，所有的 Web 容器包括 Jetty 都支持 Filter 机制。

另一个重要的区别是 Valve 工作在 Web 容器级别，拦截所有应用的请求；而 Servlet Filter 工作在应用级别，只能拦截某个 Web 应用的所有请求。如果想做整个 Web 容器 的拦截器，必须通过 Valve 来实现。