Comet：基于 HTTP 长连接的 Server PUSH

服务器推实现的相关资料

文章分类:Web前端

有个不错的文章《Comet：基于 HTTP 长连接的“服务器推”技术》。文章提到Comet现实应用的需求：

监控系统：后台硬件热插拔、LED、温度、电压发生变化；

即时通信系统：其它用户登录、发送信息；

即时报价系统：后台数据库内容发生变化；

也提到多种技术实现服务器推送。

我现在比较同意这个，介绍了选择要注意的事项，比如服务器对long-polling的支持。现在主要关心：

如果数据推送频率不高，并发压力不大，可以用基于 AJAX 的长轮询（long-polling）方式，实现比较简单。nginx有个Module可以支持long-polling，可能以后还支持Streaming。long-polling每次返回数据后是要再次请求。

如果数据变化快，想以推送为主，可以用基于 Iframe 及 htmlfile 的流（streaming）方式。这里有比较不错的介绍，里边还介绍了APE等一些服务器实现，要根据具体情况来选择。比如APE是C实现的，我是用java的，对我来说它不容易扩展（基本javascript的扩展性能可靠性能实现的功能要测试，对于实在想走80端口，这个是我目前找到的功能全，而且官方说支持100K+并发，但是目前资料少，说明用的人不多啊）。APE1.0主要还是long-polling，流方式使用XHRStreaming在IE上不行；相比而言streamHub流是使用写<script>标签实现的，可以跨浏览器。那些不开源的不要说了，python也不熟悉，Jetty 6 和 Tomcat 6已经支持Comet，一般情况可以满足，并发太大了也要做选择，有人用netty自己实现，支持10万以上。想自己写服务器看这个用xsocket实现了。

引用
2010.5补充：以前对长连接和http persistent connection没有太清晰的概念，在脑子里老是把请求和tcp连接混在一块想。long-polling方式在firebug里能看到一个请求及数据返回响应，然后再请求，但都是同一tcp连接（支持http1.1的服务器）。像streamHub那样用流方式的，我们看到一个返回响应数据不断涨，可通过其它请求，改变这一响应数据内容。以前错误的认为：这样一个响应才是同一连接，long-polling会重新建立tcp连接。

出于性能或其它原因，有些应用比较适合用socket。B/S结构客户端可以用flash，以后HTML5，也是不错的选择。看这里文章中提到：

引用
自己实现的server通常存在性能及可扩展性的问题，因此实现全部功能需要投入大量的开发精力。Hemlock通过flash长连到XMPP Server上。由于XMPP Server(如openfire, ejabberd等)本身就支持多服务器，因此使用默认的版本就可以支持上十万的并发，如果稍加优化，同时支持上百万用户也不会有太大问题。

openfire开源的，基于mina实现 （喜欢java代码的也可以看看red5或者http://code.google.com/p/gfs-server/）

再加几个基于netty的开源项目： http://openr66.free.fr/GoldenGateFTP.html http://code.google.com/p/jmemcache-daemon/ http://kevwil.github.com/aspen/ http://code.google.com/p/sensei-search/

(看到过的资料单机2*4core 16GB实现近50万在线连接，每秒处理近10万请求，c实现，内核，网卡等都经过优化；看过java最高的就是Using Netty we have comet running on 100.000+ open connections - this uses some GB of memory and 20% of CPU on a quad core server.一个四核服务器10万以上连接）