Tomcat连接器Connector源码解读架构概览，如何设计？为什么这样设计？

Posted 2021-09-23 徐同学呀

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Tomcat连接器Connector源码解读架构概览，如何设计？为什么这样设计？相关的知识，希望对你有一定的参考价值。

首发CSDN：徐同学呀，原创不易，转载请注明源链接。我是徐同学，用心输出高质量文章，希望对你有所帮助。
本篇基于Tomcat10.0.6。

文章目录

一、前言

Tomcat是一个非常优秀的开源项目，深深被它匠心独具的架构理念所折服。技术的思维是互通的，哪有那么多的高深莫测，都是对现实世界的抽象。

Tomcat作为Web应用服务器，接收请求和处理请求是它的两个核心功能。接收请求这步需要考虑适配多种网络协议，主流的是HTTP协议，还有WebSocket协议、AJP协议等；处理请求就是找到对应的Servlet，执行业务代码。

为了解耦和扩展性，Tomcat 设计了两个核心组件来做这两件事情：

连接器（Connector）负责对外交流，建立Socket连接，读取并解析网络字节流，生成Request和Response对象并转发给容器。
容器（Container）负责内部处理，加载和管理Servlet，通过Response对象的输出流写入响应结果。

二、Connector基本结构

具体来看看Connector有哪些功能：

监听网络端口。
接受网络连接请求。
读取网络请求字节流。
根据具体应用层协议（HTTP/AJP）解析字节流，生成统一的 Request和 Response对象。（需要注意，Connector为了兼容多种协议，没有耦合Servlet标准，所以这里生成的Request和 Response对象没有实现HttpServletRequest和HttpServletResponse接口）。
将Request和 Response对象转换为HttpServletRequest和HttpServletResponse对象。
将HttpServletRequest和HttpServletResponse对象转发给Container。

总结就是做了三件事：

网络通信。
应用层协议解析和封装。
Request和Response对象转换和传递。

对应Connector中的三个组件就是：Endpoint、Processor、Adapter，其中 Endpoint和 Processor放在一起抽象成了 ProtocolHandler协议组件。

三、ProtocolHandler

ProtocolHandler负责传输层网络连接和应用层协议解析，由两个核心部件 Endpoint和 Processor具体做这两件事。

从实现类来看，Tomcat的连接器主要支持两种协议：HTTP/1.1协议和AJP协议，实则还支持HTTP/2.0协议，HTTP/2.0的处理与HTTP/1.1和AJP不同，采用一种升级协议的方式实现。

HTTP/1.1协议：大家最熟悉的协议了，绝大多数web应用采用的访问协议，Tomcat既是Servlet容器又是HTTP服务器，单独运行就可以对外提供服务，但是一般会搭配nginxweb服务器做反向代理和负载均衡。
HTTP/2.0协议：自Tomcat8.5开始支持，相较于HTTP/1.1采用二进制传输数据而非文本格式；对消息头采用HPACK压缩，提升传输效率；基于帧和流的多路复用，真正实现了基于一个连接多请求并发处理；支持服务器主动推送。
AJP/1.3协议：全名Apache JServ Protocol，是Alexei Kosut创建的定向包通信协议，采用二进制格式传输可读文本。用于集成Web服务器，以提升静态资源的访问性能，当前最新版本为1.3。目前Apache、Tomcat、Nginx、Jetty、JBoss等均已支持AJP。（名不见经传，不过多解释）

除了支持3种协议外，还分别支持3种I/O方式：NIO、NIO2、APR，Tomcat8.5之前默认还支持BIO，后来因为性能问题直接给删除了，APR也贴上了过期标签。协议和I/O方式两两组合就出现了很多实现类：Http11NioProtocol、Http11Nio2Protocol、Http11AprProtocol（已过期）、AjpNioProtocol、AjpNio2Protocol、AjpAjpProtocol（已过期）。（HTTP/2.0是在HTTP/1.1的基础上升级处理的，不在该继承体系内，APR采用Apache可移植运行库（c++编写的本地库，就是native方法）实现的，官方已标注过期不建议使用，所以不过多解释）

Tomcat采用UpgradeProtocol表示HTTP升级协议，当前只有一个实现类Http2Protocol用于处理HTTP/2.0。它根据请求创建一个用于升级处理的令牌UpgradeToken，该令牌包含了具体的HTTP升级处理器HttpUpgradeHandler（HTTP/2.0的处理器为Http2UpgradeHandler）。（Tomcat中WebSocket也是通过UpgradeToken机制实现的，其处理器为WsHttpUpgradeHandler）

1、Endpoint通信端点

Endpoint负责网络通信，监听一个端口，循环接收socket请求，读取网络字节流等。Endpoint不是接口，而是提供了一个抽象类AbstractEndpoint，又根据I/O方式提供了若干实现类：

网络通信这一层是非常抽象的，传输层协议毋庸置疑是TCP/IP，但是如何监听socket请求，读取网络字节流的方式是多样的，同步非阻塞、I/O多路复用、异步非阻塞等等：

Endpoint高度抽象出一个Acceptor来循环监听socket请求；
Tomcat是支持高并发的，但是机器的性能是有限的，为了保证Web服务器不被高流量冲垮，所以在接收请求前会有一个LimitLatch限流器（利用AQS实现）；
接收到的socket通道（SocketChannel or AsynchronousSocketChannel），会先根据I/O方式包装一下，如同步非阻塞NioChannel、异步非阻塞Nio2Channel等；
包装之后的socket通道又用一个更抽象的SocketWrapper封装，以应对不同方式的网络字节流的读取和写入;
出于高并发的设计，将抽象的SocketWrapper交由SocketProcessor任务对象处理，SocketProcessor会扔进一个线程池Executor处理；
为了进一步提高性能，每次处理请求都会把一些对象缓存起来，不重复创建，比如SocketWrapper、SocketProcessor等。

2、Processor应用层协议解析

Acceptor接收到请求封装成一个SocketProcessor扔进线程池Executor后，会调用Processor从操作系统底层读取、过滤字节流，对应用层协议（HTTP/AJP）进行解析封装，生成org.apache.coyote.Request和org.apache.coyote.Response对象。不同的协议有不同的Processor，HTTP/1.1对应Http11Processor，AJP对应AjpProcessor，HTTP/1.2对应StreamProcessor，UpgradeProcessorInternal 和 UpgradeProcessorExternal用于协议升级：

（1）ConnectionHandler创建合适的Processor

SocketProcessor并不是直接调用的Processor，而是通过org.apache.coyote.AbstractProtocol.ConnectionHandler#process找到一个合适的Processor进行请求处理：

根据不同协议创建Http11Processor or AjpProcessor；
根据协议升级是内部升级（HTTP/2.0）还是外部升级创建UpgradeProcessorInternal or UpgradeProcessorExternal。

（2）协议升级

如果是正常的协议，如HTTP/1.1、AJP/1.3，则Processor#process处理完请求后会直接调用Adapter#service，将请求转发给Container。

如果是协议升级（除Websocket），首先通过HTTP/1.1进行协议升级：

服务器接收到带有特殊请求头（Upgrade）的HTPP/1.1连接，因此仍会先交给Http11Processor进行处理；
根据请求头Upgrade对应协议名创建 UpgradeToken，并赋值给当前Processor；
返回SocketState.UPGRADING，再由ConnectionHandler进行协议升级；
ConnectionHandler会从当前Processor获取UpgradeToken对象（如果没有，则默认为HTTP/2.0），并构建一个升级的Processer（若为Tomcat可以处理的协议升级（HTTP/2.0、WebSocket），则是UpgradeProcessorInternal，否则为UpgradeProcessorExternal）。
替换当前Processer，并将当前Processer释放回收；
将 UpgradeProcessor 设置给 UpgradeToken中的HttpUpgradeHandler ，并调用HttpUpgradeHandler.init进行初始化，开启升级协议的处理。
由于HTTP/2.0是多路复用协议，一个连接可以处理多个HTTP请求，所以对于Http2UpgradeHandler，会将每次请求响应交于StreamProcessor处理，再由StreamProcessor将请求提交给Container。

注意：

UpgradeProcessorInternal 和 UpgradeProcessorExternal都实现了接口WebConnection，表示一个用于升级的连接，并不处理协议升级后数据读写和解析，而是交由HttpUpgradeHandler，对于Http2UpgradeHandler再构建StreamProcessor，又将StreamProcessor包装成任务类StreamRunnable，扔进线程池Executor处理。
WebSocket也属于协议升级，和HTTP/2.0升级方案一致，但是协议升级的判断机制有所不同，WebSocket升级判断不在连接器里，而是交由Servlet容器通过当前请求的过滤器WsFilter判断，如果是WebSocket协议升级，则调用当前org.apache.catalina.connector.Request#upgrade构建UpgradeToken并传递给Http11Processor处理（调用钩子函数org.apache.coyote.AbstractProcessor#action），之后到了ConnectionHandler逻辑就跟HTTP/2.0升级差不多了。

3、配置方式

<Connector port="8080" protocol="HTTP/1.1" 
           connectionTimeout="20000" 
           executor="tomcatThreadPool" 
           redirectPort="8443">
     <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"/>
</Connector>

port是Connector监听的端口。
protocol是应用层协议名，可填参数有HTTP/1.1、org.apache.coyote.http11.Http11NioProtocol、AJP/1.3、org.apache.coyote.ajp.AjpNioProtocol，如果protocol不填，则默认为Http11NioProtocol。
connectionTimeout表示Connector接收到连接后等待超时时间，单位毫秒，默认20秒。
executor表示使用一个共享线程池，若使用私有线程池，则executor不需要指定，私有线程池可选参数有minSpareThreads=“10”、maxThreads=“200”等
redirectPort表示非SSL重定向到SSL端口，当请求是non-SSL请求，但是接收到的请求内容需要SSL传输，则重定向到SSL端口。
若为HTTP开启HTTP/2.0支持，需要配置UpgradeProtocol。

四、Adapter

Adapter接口只有一个实现类org.apache.catalina.connector.CoyoteAdapter，其主要职责如下：

将org.apache.coyote.Request和org.apache.coyote.Response转为实现了标准Servlet的org.apache.catalina.connector.Request和org.apache.catalina.connector.Response。
将请求体的serverName、URI、version传给Mapper组件做映射，匹配到合适的Host、Context、Wrapper。
将Request和Response传给Container处理，Engine通过管道Pipeline传给Host，Host再传给Context，Context再传给Wrapper，Wrapper是最终的Servlet。

五、请求处理完整流程

六、要点回顾

任重而道远啊，本篇主要从Connector的整体架构进行讲解，主要弄明白Connector是如何设计的？为什么要这样设计？

Connector作为独立模块，封装底层网络通信，使Container和具体的协议及I/O方式解耦，易扩展、高性能。这也使得架构变得抽象复杂，Connector需要应对多种协议和I/O方式的组合，高度的抽象和封装。Connector只负责接收和解析请求，具体的业务处理还需要交给Container，所以需要一个适配器作为Connector和Container连接的桥梁。

很多实现细节并没有展开，比如：