Tomcat最底层应用的是Java规范的SocketServer和Socket承受和解决申请，然而Socket承受到的数据是网络运输层的TCP或UDP协定的数据，须要转为Http或者其它应用层协定的数据。Tomcat中就是通过连接器Connector来治理Socket连贯、解析Scoket申请为Request并封装响应数据为Response对象。新版本的Tomcat容器应用的连接器是Coyote框架，本文会具体介绍Connector的Coyote框架原理。本文很多内容参考了这篇博客

什么是Coyote

Coyote是Tomcat链接器框架的名称，是Tomcat服务器提供的供客户端拜访的内部接口。客户端通过Coyote与服务器建设链接、发送申请并且接管响应。

Coyote封装了底层的网络通信（Socket申请以及响应解决），为Catalina容器提供了对立的接口，是Catalina容器与具体的申请协定以及 I/O形式解耦。Coyote将Socket输出转换为Request对象，交由Catalina容器进行解决，解决申请实现之后，Catalina通过Coyote提供的Response对象将后果写入输入流。

Coyote作为独立的模块，只负责具体协定和I/O的解决，与Servlet标准实现没有间接关系，因而即使是Request和Response对象也并未实现Servlet标准对应的接口，而是在Catalina中将他们进一步封装为ServletRequest何ServletResponse。

Coyote反对的协定

Coyote框架反对以下三种应用层协定：

  1. HTTP/1.1协定：这是绝大多数Web利用采纳的拜访协定，次要用于Tomcat独自运行（不予Web服务器集成）的状况。
  2. AJP协定：用于和Web服务器（如Apache HTTP Server）集成，以实现针对动态资源的优化以及集群部署，以后反对AJP/1.3。
  3. HTTP/2.0协定：下一代HTTP协定，自Tomcat8.5以及9.0版本开始反对，截止目前，支流的最新版本均已反对HTTP/2.0。

针对HTTP和AJP协定，Coyote又依照 I/O形式别离提供了不同的抉择计划（自8.5/9.0版本起，Tomcat已出了对BIO的反对）。

  1. NIO：采纳Java NIO类库实现。
  2. NIO2：采纳JDK 7最新的NIO2类库实现。
  3. APR：采纳APR（Apache可移植运行库）实现

在8.0之前，Tomcat默认采纳的I/O形式为BIO，之后采纳NIO。无论NIO、NIO2还是APR，在性能方面均优于以往的BIO。如果采纳APR，甚至能够达到靠近于 Apache HTTP Server的响应性能。

在Coyote中，HTTP/2.0的解决形式与HTTP/1.1和AJP不同，采纳一种降级协定的形式实现，这也是有HTTP/2.0的传输计划决定的。

能够采纳一种简略的分层视图来形容Tomcat对协定以及 I/O形式的反对，如下图所示：

Connector的外围概念

在Connector中有如下几个外围概念：

  • Endpoint：Coyote通信端点，即通信监听的接口，是具体的Socker接管解决类，是对传输层的形象。Tomcat并没有Endpoint接口，而是提供了一个抽象类AvstractEndpoint。依据I/O形式的不同，提供了NioEndpoint（NIO）、AprEndpoint（APR）以及Nio2Endpoint（NIO2）三个实现。
  • Processor：Coyote协定解决接口，负责结构Request和Response对象，并且通过Adapter将其提交到Catalina容器解决，是对应用层的形象。Processor是单线程的，Tomcat在同一次链接中复用Processor。Tomcat依照协定的不同提供了3个实现类：Http11Processor（HTTP/1.1）、AjpProcessor（AJP）、StreamProcessor（HTTP/2.0）。除此之外，他还提供了两个用于解决外部解决的实现：UpgradeProcessorInternal和UpgradeProcessorExternal，前者用于解决外部反对的降级协定（如HTTP/2.0和WebSocket），后者用于解决内部扩大的降级协定反对。
  • UpgradeProtocol：Tomcat采纳UpgradeProtocol接口示意HTTP降级协定，以后只提供了一个实现（Http2Protocol）用于解决HTTP/2.0.他依据申请创立一个用于降级解决的令牌UpgradeToken，该令牌中蕴含了具体的HTTP降级处理器HttpUpgradeHandler，HTTP/2.0的处理器实现为Http2UpgradeHandler。Tomcat中的WebSocket也是通过UpgradeToken机制实现的。

Connector申请解决流程

Connector解决申请的流程如上所示，咱们一步步剖析一下流程的内容：

  1. 当Connector启动时，会同时启动其持有的Endpoint实例。Endpoint并容许多个线程（有属性acceptorThreadCount确定），每个线程容许一个AbstractEndpoint.Acceptor实例。在AbstractEndpoint.Acceptor实例中监听端口通信（I/O形式不同，具体的解决形式也不同），而且只有Endpoint处于运行状态，始终循环监听。
  2. 当监听到申请时，Acceptor将Socker封装为SocketWrapper实例（此时并未读取数据），并交由一个SocketProcessor对象解决（此过程也由线程池异步解决）。此局部依据I/O形式的不同解决会有所不同，如NIO采纳轮询的形式检测SelectionKey是否就绪。如果就绪，则获取一个无效的SocketProcessor对象并且提交线程池解决。
  3. SocketProcessor是一个线程池Worker实例，每一个I/O形式均有本人的实现。他首先判断Socket的状态（如实现SSL握手），而后提交到ConnectionHandler解决。

  4. ConnectionHandler是AbstractProtocol的一个外部类，次要用于链接抉择一个适合的Processor实现以进行申请解决。

    • 晋升性能，他针对每个无效的了解都会缓存器Processor对象。不仅如此，以后链接敞开时，其Processor对象还会被开释到一个回收队列（降级协定不会回收），这样后续链接能够重置并且反复利用，以缩小对象结构。
    • 在解决申请时，他首先会从缓存中获取以后链接的Processor对象。如果不存在，则尝试依据协商协定结构Processor（如HTTP/2.0申请）。如果不存在协商协定（如HTTP/1.1申请），则从回收队列中获取一个已开释的Processor对象应用。如果回收队列中没有可用的对象，那么由具体的协定创立一个Processor应用（同时注册到缓存）。
  5. 协定降级时，ConnectionHandler会从以后Processor失去一个UpgradeToken对象（如果没有，则默认为HTTP/2），并结构一个降级Processor实例（如果是Tomcat反对的协定则会是UpgradeProcessorInternal，否则是UpgradeProcessorExternal）替换以后的Processor，并将以后的Processor开释回收。替换后，该链接的后续解决将由降级Process实现。
  6. 通过UpgradeToken中HttpUpgradehandler对象的init()办法进行初始化，以便筹备开始启用新协定。

我是御狐神，欢送大家关注我的微信公众号:wzm2zsd

本文最先公布至微信公众号，版权所有，禁止转载！