Tomcat基于Coyote的连接器源码分析

不论Tomcat的容器设计得如何精妙，本质上Tomcat就是个HTTP服务器，需要从socket中获得HTTP数据流；另一方面，容器只能处理封装好的org.apache.coyote.Request，从socket到Request之间需要有个转换过程。因此，连接socket和容器之间的重任就交给了Coyote

Coyote简介

Coyote是Tomcat的Connector框架的名字，简单说就是Coyote来处理底层的socket，并将HTTP请求、响应等字节流层面的东西，包装成Request和Response两个类（这两个类是tomcat定义的，而非servlet中的ServletRequest和ServletResponse），供容器使用；同时，为了能让我们编写的servlet能够得到ServletRequest，Tomcat使用了Facade模式，将比较底层、低级的Request包装成为ServletRequest（这一过程通常发生在Wrapper容器一级），这也是为很多人津津乐道的tomcat对设计模式的一个巧妙的运用，具体过程将会在以后讨论。

所以，coyote本质上是为tomcat的容器提供了对底层socket连接数据的封装，以Request类的形式，让容器能够访问到底层的数据。

而关于连接池、线程池等直接和socket打交道的事情，tomcat交给了org.apache.tomcat.util.net包的类去完成，这里介绍其中几个核心类

org.apache.coyote

这个包里面的主要是coyote框架的接口

Adapter

“适配器”在这里的意思，是指“凡是使用Coyote连接器的容器，都要实现这个接口，以便从Coyote连接器接收请求和响应数据”，当然这里的请求和响应是org.apache.coyote.Request和Response

ProtocolHandler

每个ProtocolHandler，代表着对一种协议的支持，比如tomcat默认支持的协议有http1.1和ajp。根据支持的协议，ProtocolHandler里面通常包含了一个实现对应协议的Handler接口的处理类，用于接收socket对象，再交给对应协议的Processor类（然而这个Processor类没有实现Processor接口，而是实现了ActionHook接口），最后由Processor类交给实现了Adapter接口的容器（准确的说是该容器的Pipeline的第一个Valve）

Processor

这个接口已经废弃了，通常Tomcat的Processor实现类实现的接口是ActionHook。你会看到许多名为“XXXProcessor”的类，但其实他们实现的接口却是ActionHook

ActionHook

本接口代替了Processor接口，成为所有Processor实现类的标准接口。其方法只有一个：public void action( ActionCode actionCode, Object param); 
ActionCode是一个静态类，说白了是一堆常量（估计以后会改成enum），即对应不同的ActionCode，ActionHook要作出不同的动作，至于param是用于传递一些信息的，通常会把调用者“this”传递进去

InputBuffer和OutputBuffer

两个接口都只有一个方法，分别是doread和dowrite，就是把数据从ByteChunk参数读出或者写入ByteChunk。然而“数据”从何而来、怎样写进ByteChunk，还得看不同的类实现

Request和Response

Request这个类可谓tomcat的一大核心，几乎所有Connector和容器都要用到它

Request类实现了对底层http字节流的封装，因为http本质上是从网络过来的一串字节流，并且从逻辑上根据http协议，分成了头和体，其中头部又有很多字段（包括MIME字段）。而Request的作用就是把这些字节封装成对应的字段，并且达到处理效率的最优

因此，Request里面大部分方法是字段的get方法（set方法不多，因为大部分字段是不可改变的），此外还有提供给容器使用的方法，如recycle、inputbuffer等等。但最关键的是，Request是如何提高处理效率的

对于底层的、和字节流打交道的DO（data object），性能瓶颈在于对内存的使用上（因为字节都是放在一块块的内存中），如果能有效的使用内存，就能有效地提高DO的性能。

如果让我们来实现这个Request类，估计大部分人第一反应就是用String来表示每个http头字段，然而String的效率之低下是绝对无法胜任服务器的性能要求的。Request的注释告诉我们，它的大部分字段是“GC free”的，即很少、甚至不会被垃圾回收。杜绝了java中最大的一个性能瓶颈，Request自然性能得到大幅提升。

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

当然，Tomcat的程序员也是人也喜欢偷懒，谁都不乐意直接操纵字节数组，那样出错的风险也大。因此，tomcat的org.apache.tomcat.util包定义了许多底层的工具类，用于操作和维护字节数组。Request的字段们的类型为MessageBytes就是其中的一种

而关于Response，原理和Request类似，但是Response简单了很多，最明显的是里面的字段不像Request那样为效率绞尽脑汁，而是直接用了String，也许是Response对整体效率影响不大，亦或者当前版本的tomcat还未对其进行改造。

Coyote框架总结

在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请求的大部分字段在我们编程时都用不到），就不作转换。这样又进一步挖掘出更多的性能潜力，其思想和“延迟加载”的设计模式如出一辙。