Tomcat 7源码学习笔记 -3 Http11Protocol和Http11NioProtocol

zhangxinba

Tomcat既支持阻塞式IO，也支持非阻塞式IO。

如果要使用NIO，需要修改server.xml的配置。

<Connector executor="tomcatThreadPool" port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000"
redirectPort="8443" URIEncoding="UTF-8"/>

web服务器一般有两种处理http请求的机制，阻塞和非阻塞，阻塞式因为每一个连接都产生一个线程，当线程数达到一定数量的时候，CPU用于线程切换的时间会变多，整体的性能会下降，所以线程池的数量要控制在一定的数量内，这是就需要引入非阻塞的机制，就是把连接先缓冲在一个队列中，然后再分给后台的线程池中的空闲线程慢慢处理。

Comet属于长连接，所以对于web服务器的吞吐量要求要更高，也就是要具备处理大量http请求的能力，所以必须使用Http11NioProtocal来提高吞吐量。

至于把连接缓存在队列中，依然排队等待的问题，和阻塞式处理方式比，至少客户端不会收到500 connection refused，只是感觉响应慢一些，还有因为comet属于消息推送，一般客户端的http请求是异步的，比如通过ajax在后台发起http请求，所以对于这种情况，连接缓存在等待队列中也没有关系，因为是异步的，而且用户也看不到，所以对用户的使用也没有影响。

下面看一下这两种方式的区别：

1.Http11Protocal
使用阻塞IO,服务器端使用Socket类和ServerSocket类负责请求的接入

一个请求接入线程，专门负责请求的接入accept，接入后把socket扔给后面的线程池，线程池中有具体的处理线程，负责后续的处理，一个线程对应一个请求，直到请求处理完毕并返回response，这个线程数就是web服务器能承载的最大线程数，如果线程池中没有空闲线程，那么下一个请求就无法接入，如果ServerSocket的等待队列也满了的话，客户端就会收到500 connection refused。

2.Http11NioProtocal
使用非阻塞IO，服务器端使用SocketChannel类和ServerSocketChannel类负责请求的接入

这种方式也有一个请求接入线程，专门负责请求的接入accept，但是接入后不是直接扔给后面的处理线程池，而是又多了一个或两个中间线程，这个中间线程里面有一个队列，接入后直接把SocketChannel以及对应的Selector监听信息包装成一个事件对象扔到中间线程的队列中（如果有两个中间线程，那么平均使用这两个线程，这次是线程1，下次是线程2，在下次是线程1，以此类推，所以每个中间线程会处理多个连接），这个队列可以容纳足够多的事件对象，Selector相当于对socket状态进行监视的监听器。这个中间线程不断地对这个事件队列进行循环处理，当Selector中有需要处理的事件时（比如socket read就绪，socket write就绪），再把socket转给后面的处理线程池进行后续的处理。

前面提到的中间线程可以有一个或者两个，每个里面都有一个队列，所以可以容纳足够多的socket连接。这样即使后面的线程池中没有空闲线程，一样可以对请求进行接入，然后缓存在中间线程的队列中。这样就加大了web服务器的吞吐量。comet长连接很多时也可以应付得了。

这种方式不单单是对连接进行缓存，前面提到了中间线程对Selector中的事件进行监视，直到有事件到达时才把socket转给后台线程池进行处理，这样就减少了线程池中的处理线程的等待时间，此外，对每个SocketChannel都分配了readbuffer和writebuffer,这样可以减少实际的socket流的读写次数，以减少IO等待。