IXHONG 阅读(212) 评论(0)

转自http://blog.csdn.net/wangchengsi/article/details/2973012

 

不论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还未对其进行改造