tomcat架构分析(connector BIO 实现)

出处：http://gearever.iteye.com

在tomcat架构分析(概览)中已经介绍过，connector组件是service容器中的一部分。它主要是接收，解析http请求，然后调用本service下的相关servlet。由于tomcat从架构上采用的是一个分层结构，因此根据解析过的http请求，定位到相应的servlet也是一个相对比较复杂的过程。 
 
整个connector实现了从接收socket到调用servlet的全部过程。先来看一下connector的功能逻辑；

• 接收socket
• 从socket获取数据包，并解析成HttpServletRequest对象
• 从engine容器开始走调用流程，经过各层valve，最后调用servlet完成业务逻辑
• 返回response，关闭socket

可以看出，整个connector组件是tomcat运行主干，之前介绍的各个模块都是tomcat启动时，静态创建好的，通过connector将这些模块串了起来。 
通常在实际运行中，特别是对于一些互联网应用而言，网络吞吐一直是整个服务的瓶颈所在，因此，connector的运行效率在一定程度上影响了tomcat的整体性能。相对来说，tomcat在处理静态页面方面一直有一些瓶颈，因此通常的服务架构都是前端类似nginx的web服务器，后端挂上tomcat作为应用服务器(当然还有些其他原因，例如负载均衡等)。Tomcat在connector的优化上做了一些特殊的处理，这些都是可选的，通过部署，配置方便完成，例如APR（Apache Portable Runtime），BIO，NIO等。 
目前connector支持的协议是HTTP和AJP。AJP是Apache与其他服务器之间的通信协议。通常在集群环境中，例如前端web服务器和后端应用服务器或servlet容器，使用AJP会比HTTP有更好的性能，这里引述apache官网上的一段话“ If integration with the native webserver is needed for any reason, an AJP connector will provide faster performance than proxied HTTP. AJP clustering is the most efficient from the Tomcat perspective. It is otherwise functionally equivalent to HTTP clustering.” 
本篇主要是针对HTTP协议的connector进行阐述。先来看一下connector的配置，在server.xml里；

熟悉的80端口不必说了。“protocol”这里是指这个connector支持的协议。针对HTTP协议而言，这个属性可以配置的值有：

• HTTP/1.1
• org.apache.coyote.http11.Http11Protocol –BIO实现
• org.apache.coyote.http11.Http11NioProtocol –NIO实现
• 定制的接口

配置“HTTP/1.1”和“org.apache.coyote.http11.Http11Protocol”的效果是一样的，因此connector的HTTP协议实现缺省是支持BIO的。无论是BIO还是NIO都是实现一个org.apache.coyote.ProtocolHandler接口，因此如果需要定制化，也必须实现这个接口。 
本篇就来看看缺省状态下HTTP connector的架构及其消息流。 
 
可以看见connector中三大块

• Http11Protocol
• Mapper
• CoyoteAdapter

Http11Protocol 
类全路径org.apache.coyote.http11.Http11Protocol，这是支持http的BIO实现。 Http11Protocol包含了JIoEndpoint对象及Http11ConnectionHandler对象。 
Http11ConnectionHandler对象维护了一个Http11Processor对象池，Http11Processor对象会调用CoyoteAdapter完成http request的解析和分派。 
JIoEndpoint维护了两个线程池，Acceptor及Worker。Acceptor是接收socket，然后从Worker线程池中找出空闲的线程处理socket，如果worker线程池没有空闲线程，则Acceptor将阻塞。Worker是典型的线程池实现。Worker线程拿到socket后，就从Http11Processor对象池中获取Http11Processor对象，进一步处理。除了这个比较基础的Worker线程池，也可以通过基于java concurrent 系列的java.util.concurrent.ThreadPoolExecutor线程池实现，不过需要在server.xml中配置相应的节点，即在connector同级别配置<Executor>，配置完后，使用ThreadPoolExecutor与Worker在实现上没有什么大的区别，就不赘述了。

图中的箭头代表了消息流。 
Mapper 
类全路径org.apache.tomcat.util.http.mapper.Mapper，此对象维护了一个从Host到Wrapper的各级容器的快照。它主要是为了，当http request被解析后，能够将http request绑定到相应的servlet进行业务处理。前面的文章中已经说明，在加载各层容器时，会将它们注册到JMX中。 
 
所以当connector组件启动的时候，会从JMX中查询出各层容器，然后再创建这个Mapper对象中的快照。 
CoyoteAdapter 
全路径org.apache.catalina.connector.CoyoteAdapter，此对象负责将http request解析成HttpServletRequest对象，之后绑定相应的容器，然后从engine开始逐层调用valve直至该servlet。在session管理中，已经说明，根据request中的jsessionid绑定服务器端的相应session。这个jsessionid按照优先级或是从request url中获取，或是从cookie中获取，然后再session池中找到相应匹配的session对象，然后将其封装到HttpServletRequest对象。所有这些都是在CoyoteAdapter中完成的。看一下将request解析为HttpServletRequest对象后，开始调用servlet的代码；

connector的容器就是StandardEngine，代码的可读性很强，获取StandardEngine的pipeline，然后从第一个valve开始调用逻辑，相应的过程请参照tomcat架构分析(valve机制)。