【转载】Tomcat连接器：Coyote框架

sm702

　　不论Tomcat的容器设计得如何精妙，本质上Tomcat就是个http服务器，需要从socket中获得HTTP数据流；另一方面，容器只能处理封装好的org.apache.coyote.Request （这个类的具体用途下面会讲到），从socket到Request之间需要有个转换过程。因此，连接socket和容器之间的重任就交给了Coyote
　　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包的类去完成，这里暂且不表
　　http://www.webweavertech.com/costin/archives/000421.html
这个网页很好的描述了coyote的作用和设计思想，并介绍了其中几个影响性能的核心类
　　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和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还未对其进行改造
　　
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wangchengsi/archive/2008/09/24/2973012.aspx