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

1. 前言

Web端即时通讯技术因受限于浏览器的统筹范围,一向以来实现起来并不容易,主流的Web端即时通讯方案大致有4种:传统Ajax短轮询、Comet技术、WebSocket技术、SSE(Server-sent
伊芙(Eve)nts)。本文将简单介绍这4种技术的原理,并指出个另外异同点、优缺点等。

2. 学习互换


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


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

3. 概述

1996年IETF  HTTP工作组发表了HTTP协议的1.0版本
,到近期广流年用的本子1.1,HTTP协议经历了17
年的前行。这种分布式、无状态、基于TCP的伸手/响应式、在互联网流行的前天拿到广泛应用的商事,绝对于互联网的迅猛发展,它犹如提升地很慢。互联网从兴起到前些天,经历了门户网站盛行的web1.0时日,而后随着ajax技术的面世,发展为web应用盛行的web2.0一代,近日又朝着web3.0的主旋律迈进。反观http协议,从版本1.0提高到1.1,除了默认长连接之外就是缓存处理、带宽优化和安全性等方面的不痛不痒的立异。它一贯保留着无状态、请求/响应情势,似乎一向没意识到那应当享有变更。

好在HTML5的一世已经来到,为Web端即时通讯的贯彻带来了WebSocket和SSE(Server-sent
伊芙(Eve)nts)二种技术方案。

4. Ajax短轮询:脚本发送的http请求

价值观的web应用要想与服务器交互,必须付出一个表单(form),服务器收到并处理传来的表单,然后回来全新的页面,因为前后六个页面的多少大部分都是同等的,这多少个进程传输了无数冗余的数量、浪费了带宽。于是Ajax技术便出现。

Ajax是Asynchronous JavaScript and XML的简称,由Jesse 詹姆士 Garrett
首先提议。这种技能开创性地同意浏览器脚本(JS)发送http请求。Outlook Web
Access小组于98年采取,并很快变成IE4.0的一部分,可是这些技术平昔很小众,直到二零零五年底,google在他的goole
groups、gmail等交互式应用中广泛利用此种技术,才使得Ajax飞速被我们所收受。

Ajax的产出使客户端与劳务器端传输数据少了不少,也快了成百上千,也满意了以增长用户体验为特点的web2.0一时
初期发展的内需,然而逐渐地也爆出了他的害处。比如不可以满意即时通信等富交互式应用的实时更新数据的渴求。这种浏览器端的小技巧到底依然按照http协议,http协议要求的伸手/响应的形式也是无力回天改观的,除非http协议本身具有变动。

5. Comet:一种hack技术

以即时通信为代表的web应用程序对数码的Low
Latency要求,传统的依照轮询的措施已经力不从心满意,而且也会带来欠好的用户体验。于是一种基于http长连接的“服务器推”技术便被hack出来。这种技术被命名为Comet),那多少个术语由Dojo
Toolkit 的系列老董亚历克斯(Alex)(Alex) 罗素在博文Comet: Low Latency Data for the
Browser
第一次指出,并沿用下来。

实际上,服务器推很已经存在了,在经典的client/server模型中有广阔应用,只是浏览器太懒了,并从未对这种技术提供很好的支撑。不过Ajax的出现使这种技能在浏览器上贯彻成为可能,
google的gmail和gtalk的咬合首先应用了这种技能。随着有些关键问题的解决(比如
IE
的加载展现问题),很快那种技能拿到了认可,如今已经有成百上千早熟的开源Comet框架。

以下是压倒元白的Ajax和Comet数据传输格局的相比较,区别简单明了。典型的Ajax通信格局也是http协议的经典使用形式,要想取得数据,必须首首发送请求。在Low
Latency要求比较高的web应用中,只可以扩张服务器请求的频率。Comet则不同,客户端与劳动器端保持一个长连接,只有客户端需要的多少更新时,服务器才主动将数据推送给客户端。

Comet的贯彻紧要有二种形式,基于Ajax的长轮询(long-polling)格局和按照Iframe 及 htmlfile 的流(http streaming)形式。

有关Comet技术的事无巨细介绍散文请参见:《Comet技术详解:基于HTTP长连接的Web端实时通信技术》、《WEB端即时通讯:HTTP长连接、长轮询(long
polling)详解
》、《WEB端即时通讯:不用WebSocket也如出一辙能搞定信息的即时性》、《开源Comet服务器iComet:辅助百万冒出的Web端即时通讯方案》。

5.1 基于Ajax的长轮询(long-polling)模式

浏览器发出XMLHttpRequest
请求,服务器端接收到请求后,会卡住请求直到有数量或者逾期才重回,浏览器JS在处理请求重返信息(超时或有效数据)后重新发出请求,重新确立连接。在此期间服务器端可能早就有新的数据到达,服务器会拔取把数据保存,直到再也成立连接,浏览器会把所有数据五回性取回。

5.2 基于 Iframe 及 htmlfile 的流(http streaming)方式

Iframe是html标记,那多少个符号的src属性会维持对点名服务器的长连接请求,服务器端则可以不停地赶回数据,绝对于第一种办法,那种形式跟传统的服务器推则更类似。

在率先种模式中,浏览器在接收多少后会直接调用JS回调函数,然则这种办法该如何响应数据吧?可以透过在回去数据中嵌入JS脚本的主意,如“”,服务器端将再次回到的多寡作为回调函数的参数,浏览器在吸收数额后就会履行那段JS脚本。

可是那种方法有一个眼看的不足之处:IE、Morzilla Firefox
下端的快慢栏都会彰显加载没有做到,而且 IE
上方的图标会不停的旋转,表示加载正在拓展。Google的禀赋们采纳一个叫作“htmlfile”的
ActiveX 解决了在 IE 中的加载显示问题,并将这种艺术应用到了 gmail+gtalk
产品中。

6. Websocket:将来的化解方案1

假使说Ajax的产出是互联网发展的肯定,那么Comet技术的面世则更多表透露一种无奈,仅仅看做一种hack技术,因为尚未更好的缓解方案。Comet解决的题材应该由什么人来解决才是有理的吗?浏览器,html标准,依旧http标准?主角应该是什么人呢?本质上讲,这提到到数量传输形式,http协议应首当其冲,是时候改变一下以此懒惰的商议的乞请/响应情势了。

W3C给出了答案,在新一代html标准html5中提供了一种浏览器和服务器间开展全双工通讯的网络技术Websocket。从Websocket草案得知,Websocket是一个全新的、独立的合计,基于TCP协议,与http协议兼容、却不会融入http协议,仅仅看做html5的一局部。于是乎脚本又被给予了另一种力量:发起websocket请求。这种情势大家应有很熟识,因为Ajax就是如此做的,所例外的是,Ajax发起的是http请求而已。

与http协议不同的央求/响应情势不同,Websocket在创设连接在此之前有一个Handshake(Opening
Handshake)过程,在闭馆连接前也有一个Handshake(Closing
Handshake)过程,建立连接之后,双方即可双向通信。

关于WebSocket的详细介,请参见即时通讯网有关WebSocket的千家万户作品:《WebSocket详解(一):初阶认识WebSocket技术》、《WebSocket详解(二):技术原理、代码演示和选拔案例》、《WebSocket详解(三):深刻WebSocket通信协议细节》。

从浏览器援助角度来看,WebSocket已经近在眼前,但仍有一段较长的路要走,特别是在中国那多少个IE6、7、8依然流行的国度,旧版本浏览器的消散需要很长一段时间,在一点一滴实现浏览器全兼容前,Comet技术或者照样是最好的解决方案。不过,当前也已存在有的相比成熟的卷入方案来缓解那种兼容性限制,比如:开源的Socket.io,详见《Socket.IO介绍:帮助WebSocket、用于WEB端的即时通讯的框架》。

7. SSE:未来的缓解方案2

SSE(Server-Sent
Event,服务端推送事件)是一种允许服务端向客户端推送新数据的HTML5技术。与由客户端每隔几秒从服务端轮询拉取新数据相比较,这是一种更优的解决方案。

与WebSocket相比,它也能从服务端向客户端推送数据。这什么样控制你是用SSE如故WebSocket呢?概括来说,WebSocket能做的,SSE也能做,反之亦然,但在成功某些任务方面,它们各有千秋。

WebSocket是一种更加复杂的服务端实现技术,但它是实在的双向传输技术,既能从服务端向客户端推送数据,也能从客户端向服务端推送数据。

WebSocket和SSE的浏览器帮助率差不多,大多数主流桌面浏览器两者都补助。在Android
4.3以及更早的版本中,系统默认浏览器两者都不扶助,Firefox和Chrome则一心匡助;Android
4.4中,系统默认浏览器两者都帮助;Safari从5.0始发援助SSE(iOS系统从4.0起初),但截止6.0才正确地支撑WebSocket(6.0事先的Safari所实现的WebSocket协议存在安全题材,所以有的主流浏览器已经禁用了依照这么些协议的实现)。

与WebSocket相比,SSE有部分眼看的优势。个人觉得它最大的优势就是福利:不需要添加其余新组件,用别样你不乏先例的后端语言和框架就能持续选用。你不要为新建虚拟机、弄一个新的IP或新的端口号而麻烦,就像在现有网站中新增一个页面这样简单。我欢喜把这称之为既存基础设备优势。

SSE的第二个优势是服务端的简单。相对而言,WebSocket则很复杂,不借助于扶助类库基本搞不定(我试过,令人痛苦)。

因为SSE能在现有的HTTP/HTTPS协议上运行,所以它能直接运行于现有的代理服务器和验证技术。而对WebSocket而言,代理服务器需要做一些支付(或其他干活)才能支撑,在写这本书时,很多服务器还尚未(固然这种情形会改良)。SSE还有一个优势:它是一种文本协议,脚本调试分外容易。事实上,在本书中,大家会在开发和测试时用curl,甚至直接在命令行中运行后端脚本。

不过,这就引出了WebSocket相较SSE的一个隐秘优势:WebSocket是二进制协议,而SSE是文本协议(经常选用UTF-8编码)。当然,我们能够透过SSE连接传输二进制数据:在SSE中,只有两个拥有优秀意义的字符,它们是CR和LF,而对它们举行转码并不难。但用SSE传输二进制数据时数据会变大,若是急需从服务端到客户端传输大量的二进制数据,最好仍然用WebSocket。

WebSocket相较SSE最大的优势在于它是双向沟通的,这意味向服务端发送数据就像从服务端接收数据一样简单。用SSE时,一般通过一个独立的Ajax请求从客户端向服务端传送数据。相对于WebSocket,这样使用Ajax会扩展支出,但也就多一点点而已。如此一来,问题就变成了“何时需要关怀这个出入?”假设急需以1次/秒如故更快的效用向服务端传输数据,这应该用WebSocket。0.2次/秒到1次/秒的效率是一个青色地带,用WebSocket和用SSE差异不大;但假如您愿意重负载,这就有必不可少确定基准点。频率低于0.2次/秒左右时,两者反差不大。

从服务端向客户端传输数据的特性怎样?就算是文本数据而非二进制数据(如前文所提到的),SSE和WebSocket没怎么区别。它们都用TCP/IP套接字,都是轻量级协议。延迟、带宽、服务器负荷等都不曾分别,除非……呃?除非什么?

当你在享受SSE的既存基础设备优势,并在客户端和服务端脚本之间设了一个网络服务器,区别就显现出来了。一个SSE连接不仅使用一个套接字,还会占有一个Apache线程或进程,就算用PHP,它会为这多少个连续专门创制一个PHP新实例。Apache和PHP会使用大量的内存,这会限打败务器所能襄助的互动连接数。所以,要成功效SSE在数码传输性能上和WebSocket完全一致,需要写一个友好的后端服务器,当然,那么些在任何情况下都会用自己的服务器并应用Node.js的人,会觉得这有咋样奇妙的。

说一下WebSocket在旧版本浏览器上的匹配。当前,大约超越2/3的浏览器襄助这么些新技巧,移动端浏览器的协助率会低一些。依惯例,每当需要双向套接字时,就会用到Flash,并且WebSocket的向后万分日常是用Flash来做,这早已至极复杂了,假使浏览器上尚无Flash,意况更糟。概括来说,WebSocket难兼容,SSE易包容。有关SSE的专项介绍作品请参见:《SSE技术详解:一种全新的HTML5服务器推送事件技术》。

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

8. 多级资料

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

新手入门贴:详解Web端即时通讯技术的原理

关于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

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

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

交流:迎接插手即时通讯开发互换群 215891622

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

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

相关文章