认识 Tomcat 连接器组件 Coyote

Coyote

Coyote 是Tomcat 中连接器的组件名称 , 是对外的接⼝。客户端通过Coyote与服务器建⽴连接、发送请
求并接受响应 。
（1）Coyote 封装了底层的⽹络通信（Socket 请求及响应处理）
（2）Coyote 使Catalina 容器（容器组件）与具体的请求协议及IO操作⽅式完全解耦
（3）Coyote 将Socket 输⼊转换封装为 Request 对象，进⼀步封装后交由Catalina 容器进⾏处理，处
理请求完成后, Catalina 通过Coyote 提供的Response 对象将结果写⼊输出流
（4）Coyote 负责的是具体协议（应⽤层）和IO（传输层）相关内容

Tomcat Coyote ⽀持的 IO模型与协议
Tomcat⽀持多种应⽤层协议和I/O模型，如下：

在 8.0 之前 ，Tomcat 默认采⽤的I/O⽅式为 BIO，之后改为 NIO。 ⽆论 NIO、NIO2 还是 APR， 在性
能⽅⾯均优于以往的BIO。 如果采⽤APR， 甚⾄可以达到 Apache HTTP Server 的影响性能。

Coyote 组件及作⽤

EndPoint

EndPoint 是 Coyote 通信端点，即通信监听的接⼝，是具体Socket接收和发送处理器，是对传输层的抽象，因此EndPoint⽤来实现TCP/IP协议的

Processor

Processor 是Coyote 协议处理接⼝ ，如果说EndPoint是⽤来实现TCP/IP协议的，那么Processor⽤来实现HTTP协议，Processor接收来⾃EndPoint的Socket，读取字节流解析成Tomcat Request和Response对象，并通过Adapter将其提交到容器处理，Processor是对应⽤层协议的抽象

ProtocolHandler

Coyote 协议接⼝， 通过Endpoint 和 Processor ， 实现针对具体协议的处理能⼒。Tomcat 按照协议和I/O 提供了6个实现类 ： AjpNioProtocol ，AjpAprProtocol， AjpNio2Protocol ， Http11NioProtocol ，
Http11Nio2Protocol ，Http11AprProtocol

Adapter

由于协议不同，客户端发过来的请求信息也不尽相同，Tomcat定义了⾃⼰的Request类来封装这些请求信息。ProtocolHandler接⼝负责解析请求并⽣成Tomcat Request类。但是这个Request对象不是标准的ServletRequest，不能⽤Tomcat Request作为参数来调⽤容器。Tomcat设计者的解决⽅案是引⼊CoyoteAdapter，这是适配器模式的经典运⽤，连接器调⽤CoyoteAdapter的Sevice⽅法，传⼊的是Tomcat Request对象，CoyoteAdapter负责将Tomcat Request转成ServletRequest，再调⽤容器

实现分析

在Coyote框架中，最吸引我的有三个地方：recycle机制，ByteChunk和MessageBytes。

1）由于Java自动内存回收机制效率不高，有很多问题，所以Coyote中通过recycle机制的使用，及时进行参数初始化和内存释放。以Request为例，Recycle函数中主要进行了三个方面的事情：自身参数的初始化，自身创建的资源的释放和调用类中使用的引用对象的recycle函数。通过递归地进行recycle，一方面及时并且全面地释放了不再需要的资源，另一方面及时对相关参数进行初始化，提高下一次类访问的执行速度。

2）对于底层的、和字节流打交道的DO（data object），性能瓶颈在于对内存的使用上（因为字节都是放在一块块的内存中），如果能有效的使用内存，就能有效地提高DO的性能。ByteChunk和MessageBytes都是Tomcat为了提高处理效率封装出来的对字节流和字节数组进行优化的类，在执行效率上比java的string和byte数组要高。这两个类都都在org.apache.tomcat.util.buf包中。

3）由于ByteChunk和MessageBytes的使用，Request中字段的一些耗时操作都会延迟到用户代码一级。也就是说，tomcat内部在使用Request时，都会尽量保证它的字段处于原始的字节状态，直到用户代码（servlet代码层）需要时才进行转换，如果用不到（其实http请求的大部分字段在我们编程时都用不到），就不作转换。这样又进一步挖掘出更多的性能潜力，其思想和“延迟加载”的设计模式如出一辙。