Comet技术详解:基于HTTP长连接的Web端实时通信技术

前言

貌似的话,Web端即时通讯技术因受限于浏览器的宏图范围,从来以来实现起来并不易于,主流的Web端即时通讯方案大概有4种:传统Ajax短轮询、Comet技术、WebSocket技术、SSE(Server-sent
伊夫nts)。

有关这4种技术情势的利弊,请参见《Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE》。本文将特别讲解Comet技术。(本文同步公布于:http://www.52im.net/thread-334-1-1.html

上学互换


即时报道支出交换群:215891622 [推荐]


更多即时通讯技术资料:http://www.52im.net/forum.php?mod=collection&op=all

概述

正文将介绍如何在现有的技巧基础上选拔适合的方案开发一个“服务器推”(Comet技术)的使用,最优的方案或者在于应用需求的自己。相对于传统的
Web 应用, 开发 Comet 应用拥有自然的挑衅性。

在WebSocket技术没有完全解决浏览器兼容问题前,“服务器推”(Comet技术)存在大面积的使用需求,需求促进技术的开拓进取,Comet
技术在Web端即时通讯的方案里几乎不可或缺。

“服务器推”(Comet技术)的施用范围

传统形式的 Web
系统以客户端发出请求、服务器端响应的艺术工作。这种模式并不可能满足众多切实可行应用的需求,譬如:

1] 监控体系:后台硬件热插拔、LED、温度、电压发生变化;

2] 即时通信系统:其它用户登录、发送信息;

3] 即时报价系统:后台数据库内容暴发变化。

这么些应用都亟需服务器能实时地将更新的音讯传递到客户端,而无须客户端发出请求。“服务器推”技术在现实应用中有部分缓解方案,本文将这多少个解决方案分为两类:一类需要在浏览器端安装插件,基于套接口传送信息,或是使用
RMI、CORBA 进行长距离调用;而另一类则不用浏览器安装其他插件、基于 HTTP
长连接。

将“服务器推”应用在 Web
程序中,首先考虑的是何许在效益有限的浏览器端接收、处理音信:

1]
客户端如何接受、处理信息,是否需要运用套接口或是使用远程调用。客户端表现给用户的是
HTML 页面仍然 Java applet 或 Flash
窗口。假使使用套接口和远程调用,怎么和 JavaScript 结合修改 HTML
的显得。

2] 客户与服务器端通信的信息格式,拔取怎么样的失误处理机制。

3] 客户端是否需要协理不同档次的浏览器如 IE、Firefox,是否需要同时匡助Windows 和 Linux 平台。

来看看更传统的基于客户端套接口的“服务器推”技术

Ajax,1)Flash XMLSocket

倘若 Web 应用的用户接受应用只有在安装了 Flash 播放器才能正常运行,
那么使用 Flash 的 XMLSocket 也是一个使得的方案。

这种方案实现的功底是:

1] Flash 提供了 XMLSocket 类。

2] JavaScript 和 Flash 的紧密结合:在 JavaScript 可以直接调用 Flash
程序提供的接口。

切实落实形式:在 HTML 页面中内放置一个采取了 XMLSocket 类的 Flash
程序。JavaScript 通过调用此 Flash
程序提供的套接口接口与服务器端的套接口举行通信。JavaScript
在吸收服务器端以 XML 格式传送的信息后可以很容易地控制 HTML
页面的情节显示。

至于咋样去构建充当了 JavaScript 与 Flash XMLSocket 桥梁的 Flash
程序,以及咋样在 JavaScript 里调用 Flash 提供的接口,咱们得以参照
AFLAX(Asynchronous Flash and XML)项目提供的 Socket Demo 以及
SocketJS(请参见 参考资源)。

Javascript 与 Flash 的紧密结合,极大提升了客户端的处理能力。从 Flash
播放器 V7.0.19 起头,已经撤回了 XMLSocket 的端口必须超出 1023
的限量。Linux 平台也支撑 Flash XMLSocket 方案。但此方案的通病在于:

1] 客户端必须安装 Flash 播放器;

2] 因为 XMLSocket 没有 HTTP 隧道功用,XMLSocket
类不可以自行通过防火墙;

3]
因为是拔取套接口,需要安装一个通信端口,防火墙、代理服务器也恐怕对非
HTTP 通道端口举行界定。

而是这种方案在一部分网络聊天室,网络互动游戏中已收获大面积采纳。

2)Java Applet 套接口

在客户端应用 Java Applet,通过 java.net.Socket 或
java.net.DatagramSocket 或 java.net.MulticastSocket
建立与劳动器端的套接口连接,从而实现“服务器推”。

这种方案最大的阙如在于 Java applet 在接受服务器端重临的信息后,不可以通过
JavaScript 去立异 HTML 页面的内容。

基于 HTTP 长连接的“服务器推”技术:Comet技术

1)Comet 简介

浏览器作为 Web
应用的前台,自身的拍卖效用比较简单。浏览器的向上需要客户端升级软件,同时由于客户端浏览器软件的多样性,在某种意义上,也潜移默化了浏览器新技巧的放大。在
Web
应用中,浏览器的重要办事是发送请求、解析服务器重返的音信以不同的品格显示。AJAX
是浏览器技术进步的果实,通过在浏览器端发送异步请求,进步了单用户操作的响应性。但
Web
本质上是一个多用户的系列,对其他用户来说,可以认为服务器是此外一个用户。现有
AJAX 技术的开拓进取并不可能缓解在一个多用户的 Web
应用中,将履新的信息实时传送给客户端,从而用户可能在“过时”的音信下开展操作。而
AJAX 的行使又使后台数据更新更加频繁成为可能。

图 1. 传统的 Web 应用模型与基于 AJAX 的模子之相比较:

“服务器推”是一种很已经存在的技艺,在此之前在促成上重中之重是通过客户端的套接口,或是服务器端的远程调用。因为浏览器技术的升华相比缓慢,没有为“服务器推”的贯彻提供很好的支撑,在纯浏览器的施用中很难有一个到家的方案去实现“服务器推”并用以生意程序。近来几年,因为
AJAX 技术的普及,以及把 IFrame 嵌在“htmlfile“的 ActiveX 组件中得以解决
IE 的加载显示问题,一些受欢迎的应用如 meebo,gmail+gtalk
在贯彻中应用了那个新技巧;同时“服务器推”在切实应用中确确实实存在不少急需。因为这一个原因,基于纯浏览器的“服务器推”技术起始面临较多关注,亚历克斯(Alex)(Alex)罗素(Russell)(Dojo Toolkit 的类型 Lead)称这种依照 HTTP
长连接、无须在浏览器端安装插件的“服务器推”技术为“Comet”。近来一度面世了一些早熟的
Comet 应用以及各样开源框架;一些 Web 服务器如 Jetty
也在为支撑大气涌出的长连接举行了许多更上一层楼。关于 Comet
技术最新的上进景观请参考关于Comet 的
wiki
?cm_mc_uid=72410021035714633836363&cm_mc_sid_50200000=1464236784)。

下面将介绍三种 Comet 应用的贯彻模型。

2)Comet技术实现模型1:基于 AJAX 的长轮询(long-polling)形式

如 图 1 所示,AJAX 的产出使得 JavaScript 可以调用 XMLHttpRequest
对象发出 HTTP 请求,JavaScript 响应处理函数遵照服务器重返的信息对 HTML
页面的显示举行更新。使用 AJAX 实现“服务器推”与观念的 AJAX
应用不同之处在于:

服务器端会阻塞请求直到有多少传递或超时才重临。

客户端 JavaScript
响应处理函数会在处理完服务器再次来到的信息后,再度发出请求,重新建立连接。

当客户端处理接收的数额、重新建立连接时,服务器端可能有新的多寡到达;这个消息会被劳务器端保存直到客户端重新树立连接,客户端会五回把当前服务器端所有的音讯取回。

图 2. 基于长轮询的服务器推模型:

一些利用及示例如 “Meebo”, “Pushlet Chat”
都选取了这种长轮询的点子。相对于“轮询”(poll),这种长轮询形式也足以称之为“拉”(pull)。因为这种方案基于
AJAX,具有以下部分独到之处:请求异步发出;无须设置插件;IE、Mozilla FireFox都辅助 AJAX。

在这种长轮询情势下,客户端是在 XMLHttpRequest 的 readystate 为
4(即数据传输截至)时调用回调函数,举办新闻处理。当 readystate 为 4
时,数据传输停止,连接已经倒闭。Mozilla Firefox 提供了对 Streaming AJAX
的支撑, 即 readystate 为 3
时(数据仍在传输中),客户端可以读取数据,从而无须关闭连接,就能读取处理服务器端再次来到的音讯。IE
在 readystate 为 3 时,不可以读取服务器再次回到的数量,近期 IE 不扶助基于
Streaming AJAX。

3)Comet技术实现模型2:基于 Iframe 及 htmlfile
的流(streaming)形式

上节波及的 AJAX 方案是在 JavaScript 里处理 XMLHttpRequest
从服务器取回的数额,然后 Javascript 可以很便宜的去决定 HTML
页面的显示。同样的笔触用在 iframe 方案的客户端,iframe
服务器端并不回来直接体现在页面的数量,而是回到对客户端 Javascript
函数的调用,如“js_func(“data from server
”)”。服务器端将重回的数量作为客户端 JavaScript
函数的参数传递;客户端浏览器的 Javascript 引擎在收到服务器重回的
JavaScript 调用时就会去实践代码。

从 图 3
可以见到,每一趟数据传送不会倒闭连接,连接只会在通信出现谬误时,或是连接重建时关闭(一些防火墙常被安装为丢弃过长的连日,
服务器端可以设置一个超时时间,
超时后通告客户端重新创立连接,并关闭原来的总是)。

使用 iframe 请求一个长连接有一个很强烈的不足之处:IE、Morzilla Firefox
下端的速度栏都会来得加载没有完结,而且 IE
上方的图标会不停的转动,表示加载正在开展。Google的天分们运用一个誉为“htmlfile”的 ActiveX 解决了在 IE
中的加载呈现问题,并将这种情势用到了 gmail+gtalk 产品中。Alex(Alex) 罗素(Russell) 在
“What else is burried down in the depth’s of Google’s amazing
JavaScript?”作品中介绍了这种办法。Zeitoun 网站提供的
comet-iframe.tar.gz,封装了一个基于 iframe 和 htmlfile 的 JavaScript
comet 对象,辅助 IE、Mozilla Firefox 浏览器,可以作为参照。

行使 Comet 模型开发协调的应用

地点介绍了两种基于 HTTP
长连接的“服务器推”架构,更多描述了客户端处理长连接的技艺。对于一个实际上的施用而言,系统的平稳和总体性是可怜紧要的。将
HTTP 长连接用于实际利用,很多细节需要考虑。

1)不要在一如既往客户端同时利用超越五个的 HTTP 长连接

俺们采纳 IE 下载文件时会有这般的经验,从同一个 Web
服务器下载文件,最六只可以有四个文本同时被下载。第七个公文的下载会被封堵,直到前边下载的公文下载完毕。那是因为
HTTP 1.1 规范中规定,客户端不应有与劳务器端建立领先多少个的 HTTP 连接,
新的连续会被封堵。而 IE 在促成中严峻遵照了这种规定。

HTTP 1.1 对五个长连接的范围,会对运用了长连接的 Web
应用带来如下现象:在客户端假设打开领先几个的 IE
窗口去访问同一个施用了长连接的 Web 服务器,第三个 IE 窗口的 HTTP
请求被前四个窗口的长连接阻塞。

于是在付出长连接的行使时, 必须小心在采用了六个 frame
的页面中,不要为各类 frame 的页面都建立一个 HTTP
长连接,这样会堵塞此外的 HTTP 请求,在筹划上考虑让三个 frame
的换代共用一个长连接。

2)服务器端的性能和可增加性

貌似 Web 服务器会为每个连接成立一个线程,假若在大型的经贸使用中采用Comet,服务器端需要维护大量产出的长连接。在这种使用背景下,服务器端需要考虑负载均衡和集群技术;或是在劳务器端为长连接作一些改革。

动用和技艺的上扬总是带来新的急需,从而助长新技巧的开拓进取。HTTP 1.1 与 1.0
规范有一个很大的例外:1.0 规范下服务器在拍卖完每个 Get/Post
请求后会关闭套接口连接; 而 1.1
规范下服务器会保持那些连续,在处理几个请求的间隔时间里,那些连续处于空闲状态。
Java 1.4 引入了支撑异步 IO 的 java.nio
包。当连接处于空闲时,为这一个连续分配的线程资源会返还到线程池,可以供新的连日使用;当原来处于空闲的连年的客户发生新的呼吁,会从线程池里分配一个线程资源处理那么些请求。
这种技术在一连处于空闲的机率较高、并发连接数目很多的情景下对于降低服务器的资源负载非凡实惠。

只是 AJAX 的施用使请求的面世变得频繁,而 Comet
则会长时间占据一个连连,上述的服务器模型在新的拔取背景下会变得非凡低效,线程池里区区的线程数甚至可能会堵塞新的总是。Jetty
6 Web 服务器针对 AJAX、Comet
应用的特征举办了成百上千改进的精益求精,请参考作品“AJAX,Comet and Jetty”。

3)控制音讯与数量消息应用不同的 HTTP 连接

选择长连接时,存在一个很常见的现象:客户端网页需要关闭,而服务器端还处于读取数据的杜绝意况,客户端需要及时通报服务器端关闭数据连接。服务器在接受关闭请求后先是要从读取数据的阻塞状态唤醒,然后释放为这多少个客户端分配的资源,再关闭连接。

故而在筹划上,我们需要使客户端的主宰请求和多少请求使用不同的 HTTP
连接,才能使控制请求不会被卡住。

在贯彻上,即使是按照 iframe 流情势的长连接,客户端页面需要使用两个iframe,一个是控制帧,用于往服务器端发送控制请求,控制请求能很快收到响应,不会被堵塞;一个是呈现帧,用于往服务器端发送长连接请求。即便是基于
AJAX 的长轮询形式,客户端可以异步地暴发一个 XMLHttpRequest
请求,布告服务器端关闭数据连接。

4)在客户和服务器之间保持“心跳”新闻

在浏览器与服务器之间维持一个长连接会为通信带来一些不明确:因为数量传输是随便的,客户端不亮堂什么时候服务器才有多少传送。服务器端需要确保当客户端不再工作时,释放为这么些客户端分配的资源,制止内存泄漏。因而需要一种机制使双方知情我们都在常规运作。在贯彻上:

服务器端在堵塞读时会设置一个限期,超时后阻塞读调用会回去,同时发放客户端从未新数据到达的心跳信息。此时一经客户端已经关闭,服务器往通道写多少会出现非凡,服务器端就会登时放出为这些客户端分配的资源。

如若客户端应用的是遵照 AJAX
的长轮询格局;服务器端重临数据、关闭连接后,经过某个时限没有收受客户端的再一次呼吁,会觉得客户端不可以健康工作,会释放为那么些客户端分配、维护的资源。

当服务器处理音讯现身万分意况,需要发送错误音信通告客户端,同时释放资源、关闭连接。

Comet开源工程推荐

Pushlet:

Pushlet 是一个开源的 Comet
框架,在统筹上有很多值得借鉴的地点,对于开发轻量级的 Comet
应用很有参考价值。使用了观看者模型。浏览器端提供了依照 AJAX 和 iframe 的
JavaScript 库,服务器端使用 Java
Servlet。地址是:http://www.pushlets.com/?cm\_mc\_uid=72410021035714633836363&cm\_mc\_sid\_50200000=1464236784

iComet:

iComet 是一个利用 C++ 语言开发的支撑百万并发连接的 comet/push 服务器,
匡助百万级并发连接, 内存占用少, 性能优越. 可用来移动 App 的 Push
Server(新闻推送服务器), 或者用于 Web Push(Web 服务器推). 用于 Web Push
时, 帮助的浏览器和操作系统平台包括: Safari(iOS, Mac),
Firefox/Chrome(Windows, Mac),
IE6+。详细请参见:http://www.52im.net/thread-330-1-1.html

铺天盖地著作

�Web端即时通讯新手入门:

新手入门:详解Web端即时通讯技术的法则

�Web端即时通讯技术盘点请参见:

Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE

关于Ajax短轮询:

找这地点的材料没什么意义,除非忽悠客户,否则请考虑任何3种方案即可。

有关Comet技术�的事无巨细介绍请参见:

Comet技术详解:基于HTTP长连接的Web端实时通信技术

WEB端即时通讯:HTTP长连接、长轮询(long
polling)详解

WEB端即时通讯:不用WebSocket也一律能搞定音信的即时性

开源Comet服务器iComet:辅助百万产出的Web端即时通讯�方案

有关WebSocket的事无巨细介绍请参见:

WebSocket详解(一):起始认识WebSocket技术

WebSocket详解(二):技术原理、代码演示和行使案例

WebSocket详解(三):深刻WebSocket通信协议细节

Socket.IO介绍:匡助WebSocket、用于WEB端的即时通讯的框架

socket.io和websocket
之间是怎么关系?有咋样界别?

关于SSE的详尽介绍著作请参见:

SSE技术详解:一种崭新的HTML5服务器推送事件技术

更多WEB端即时通讯作品请见:

http://www.52im.net/forum.php?mod=collection&action=view&ctid=15

(本文同步发表于:http://www.52im.net/thread-334-1-1.html

作者:Jack
Jiang
(点击作者姓名进入Github)

出处:http://www.52im.net/space-uid-1.html

交流:�欢迎参与即时通讯开发交换群215891622

讨论:http://www.52im.net/

Jack Jiang同时是【原创Java
Swing外观工程BeautyEye】
【轻量级移动端即时通讯框架MobileIMSDK】的撰稿人,可前往下载互换。

相关文章