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

2017-02-15 17:01

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

 

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