Comet中使用HTTP11NioProtocal的问题

0 0

Comet中使用HTTP11NioProtocal的问题20

最近在研究Comet，已经实现了几种Comet模型，但是基本上所有的说明上都写着要用到Http11NioProtocal,因为Comet要用到长连接或者一直不停的发送连接，而Nio模式能更多的支持连接数。Comet要实现CometProcessor接口，用的是事件驱动模型。
问题：比如设置最大连接数150，如果不使用NIO模式，那么第151个请求不能被处理。如果使用NIO模式，第151个请求能处理吗？如果处理的话是怎么处理的？这跟Comet的事件有什么关系？在event函数中，事件到达怎么处理（比如第151个请求来了，能收到这个事件吗）？

问题补充：Http11NIOProtocal到底有什么好处？我知道它可以支持很多连接，但是它接受了这么多连接如果处理不了，不是也得有很多连接等着吗？

2012年10月26日 10:08

jinshengwuyuan
6
0 0 3

1个答案按时间排序按投票排序

0 0

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类和Server把SocketChannel类负责请求的接入

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

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

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