最近在公司内部架设了一个在线文字聊天室,自己之前对行业中比较流行的聊天室技术也做了一些研究。以下是部分调研结果,并对其中几种主要的技术做一个简单的分析。
在线文字聊天室技术目前主要有poll(轮询)、long-polling(长轮询)、Forever Iframe、Flash Socket等几种。
1. “轮询”(poll)方式
客户端向服务器循环地刷新、发送http请求.
缺点是应用将浪费大量的时间来对事件完成情况的查询,因此它直接对应用的回应能力造成了破坏。另外,一些网络带宽也被浪费掉了。优点是服务器端并发度比较高。
2. Socket连接方式
基于客户端套接口的“服务器推”技术,服务器端记录下来参加到每个聊天室的client ip。当有新消息时,通过socket连接把消息发送到每一个客户端。
优点是传输高效,节省带宽。
3. 基于 Forever Iframe 及 htmlfile 的流方式(streaming)
iframe 是很早就存在的一种 HTML 标记, 通过在 HTML 页面里嵌入一个隐蔵帧,然后将这个隐蔵帧的 SRC 属性设为对一个长连接的请求,服务器端就能源源不断地往客户端输入数据。 每次数据传送不会关闭连接,连接只会在通信出现错误时,或是连接重建时关闭(一些防火墙常被设置为丢弃过长的连接, 服务器端可以设置一个超时时间, 超时后通知客户端重新建立连接,并关闭原来的连接)。
4. 基于 AJAX 的长轮询(long-polling)方式.
一些应用及示例如 “Meebo”, “Pushlet Chat” 都采用了这种长轮询的方式。相对于“轮询”(poll),这种长轮询方式也可以称为“拉”(pull)。因为这种方案基于 AJAX,具有以下一些优点:请求异步发出;无须安装插件;IE、Mozilla FireFox都支持 AJAX。
基于Forever Iframe和基于 AJAX 的长轮询的实现都可以统称为Comet技术。但是Comet技术有以下缺点:
缺点之一: 由于长时间占用服务器链接,服务器端并发度受到限制。
缺点之二: 防火墙和HTTP代理在浏览器和Web Server之间能够造成进一步的网络问题。防火墙常常被配置为丢弃超长时间的连接,需要重建周期性的“push”连接。
缺点之三: HTTP1.1规范造成了进一步的限制。HTTP1.1规范的8.1.4章节说明:“一个单独用户的client不应该对同一Server或者代理服务器维护两个以上的连接”,大多数常见的浏览器(包括IE和Firefox)都作了类似的限制。
5。目前有不少成熟的 Comet 应用以及各种开源框架。下面是Comet 相关资源,没有链接,读者可以在search engine上找到。
Virgil‘s One™
SmartClient?
Lightstreamer
Fjax
Pjax
Server-Sent Events
COMETd
Ajax for IBM WebSphere Platform
orbit
Meteor
Tomcat6X
Jetty