基于WEB的实时事件通知方案

2021年1月10日   |   by tgcode

  基于 WEB 的实时事件通知方式大致有五种方案:HTTP拉取方式(pull),HTTP流,Long Polling,FlashXMLSocket方式,Java Applet。

  首先说下Comet这个词,Comet这个词是最早由Alex Russell(DojoToolkit 的项目 Lead)提出的,称基于 HTTP 长连接、无须在浏览器端安装插件的“服务器推(Push)”技术为“Comet”。

  1. HTTP拉取方式(pull)

  在这种传统的方法中,客户端以用户可定义的时间间隔去检查服务器上的最新数据。这种拉取方式的频率要足够高才能保证很高的数据精确度,但高频率可能会导致多余的检查,从而导致较高的网络流量。而另一方面,低频率则会导致错过更新的数据。理想地,拉取的时间间隔应该等于服务器状态改变的速度。常见的实现如利用 “” tag,当然利用xmlHttpRequest定时取也是一种方法。

  2. HTTP流(Push机制)

  HTTP流有两种形式:

  * Page Stream: 页面上不间断的HTTP连接响应(HTTP 1.1 Keep Alive).

  通过在 HTML 页面里嵌入一个隐蔵帧(iframe),然后将这个隐蔵帧的SRC属性设为对一个长连接的请求,服务器端就能源源不断地往客户端输入数据。

  * Service Stream: XMLHttpRequest连接中的服务器数据流。

  客户端是在 XMLHttpRequest 的 readystate 为4(即数据传输结束)时调用回调函数,进行信息处理。当 readystate 为 4 时,数据传输结束,连接已经关闭。Mozilla Firefox 提供了对 Streaming AJAX 的支持,即 readystate 为3时(数据仍在传输中),客户端可以读取数据,从而无须关闭连接,就能读取处理服务器端返回的信息。IE 在 readystate 为3时,不能读取服务器返回的数据,目前 IE 不支持基于 Streaming AJAX。

  注:使用 Page Stream(iframe) 请求一个长连接有一个很明显的不足之处:IE、Morzilla Firefox下端的进度栏都会显示加载没有完成,而且 IE 上方的图标会不停的转动,表示加载正在进行。Google 的天才们使用一个称为“htmlfile”的 ActiveX 解决了在 IE 中的加载显示问题,并将这种方法用到了 gmail+gtalk 产品中。Alex Russell 在 “Whattgcode else is burried down in the depth’s of Google’s amazing JavaScript?”文章中介绍了这种方法。Zeitoun 网站提供的comet-iframe.tar.gz,封装了一个基于 iframe 和 htmlfile 的 JavaScript comet 对象,支tgcode持IE、Mozilla Firefox 浏览器,可以作为参考。(http://alex.dojotoolkit.org/?p=538

  3. 长时间轮询(Long Polling)

  也就是所谓的异步轮询(Asynchronous Polling),这种方式是纯tgcode服务器端推送方式和客户端拉取方式的混合。它是基于BAYEUX协议(http://svn.xantus.org/shortbus/trunk/bayeux/bayeux.html) 的。这个协议遵循基于主题的发布——订阅机制。在订阅了某个频道后,客户端和服务器间的连接会保持打开状态,并保持一段事先定义好的时间(默认为45 秒)。如果服务器端没有事件发生,而发生了超时,服务器端就会请求客户端进行异步重新连接。如果有事件发生,服务器端会发送数据到客户端,然后客户端重新连接。

  a)服务器端会阻塞请求直到有数据传递或超时才返回。

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

  c)当客户端处理接收的数据、重新建立连接时,服务器端可能有新的数据到达;这些信息会被服务器端保存直到客户端重新建立连接,客户端会一次把当前服务器端所有的信息取回。

  4. Flash XMLSocket(push机制)

  这种方案实现的基础是:

  a) 安装了 Flash 播放器,Flash 提供了 XMLSocket 类(Flash 7.0.14以上版本)。
  b) 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(请参见 [http://www.aflax.org/ Asynchronous Flash and XML,提供了强大的Flash、Javascript 库和很多范例。])。

  Javascript 与 Flash 的紧密结合,极大增强了客户端的处理能力。从 Flash 播放器 V7.0.19 开始,已经取消了XMLSocket 的端口必须大于 1023 的限制。Linux 平台也支持 Flash XMLSocket 方案。但此方案的缺点在于:

  a)客户端必须安装 Flash 播放器;

  b)因为 XMLSocket 没有 HTTP 隧道功能,XMLSocket类不能自动穿过防火墙;

  c)因为是使用Socket接口,需要设置一个通信端口,防火墙、代理服务器也可能对非 HTTP 通道端口进行限制;

  d)必须使用XML格式作为消息格式,数据冗余增大。

  此方案在一些网络聊天室,网络互动游戏中得到广泛使用。

  5. Java Applet(Push机制)

  类似于Flash XMLSocket方式。目前已经很少使用,原因极可能是因在手机等移动终端缺少支持。

  总结和建议:

  如果我们想要高数据一致性和高网络性能,我们就应该选择推送方式。但是,推送会带来一些扩展性问题;服务器应用程序CPU使用率是拉取方式的7倍。根据TUD(http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2007-016.pdf)的测试结果,服务器性能会在350-500个用户时趋于饱和。对于更大数量的用户,服务器端需要维护大量并发的长连接。在这种应用背景下,服务器端需要考虑负载均衡和集群技术;或是在服务器端为长连接作一些改进。

  使用拉取方式,要想达到完整的数据一致性以及很高的网络性能是很困难的。如果拉取的时间间隔大于数据更新的时间间隔,就会发生一些数据的遗失。而如果小于数据更新的时间间隔,网络性能就会受到影响。拉取方式只有在拉取时间间隔等同于数据更新时间间隔时,才会恰到好处。但是,为了达到那样的目标,我们就需要提前知道准确的数据更新时间间隔。然而,数据更新的时间间隔很少是静态不变并可以预知的。这使得拉取方式只有在数据是根据某种特定模式发布的情况才有用。

  控制信息与数据信息使用不同的 HTTP 连接

  使用长连接时,存在一个很常见的场景:客户端网页需要关闭,而服务器端还处在读取数据的堵塞状态,客户端需要及时通知服务器端关闭数据连接。服务器在收到关闭请求后首先要从读取数据的阻塞状态唤醒,然后释放为这个客户端分配的资源,再关闭连接。所以在设计上,我们需要使客户端的控制请求和数据请求使用不同的 HTTP 连接,才能使控制请求不会被阻塞。

  在实现上,如果是基于 iframe 流方式的长连接,客户端页面需要使用两个iframe,一个是控制帧,用于往服务器端发送控制请求,控制请求能很快收到响应,不会被堵塞;一个是显示帧,用于往服务器端发送长连接请求。如果是基于 AJAX 的长轮询方式,客户端可以异步地发出一个 XMLHttpRequest 请求,通知服务器端关闭数据连接。

  在客户和服务器之间保持“心跳”信息

  在浏览器与服务器之间维持一个长连接会为通信带来一些不确定性:因为数据传输是随机的,客户端不知道何时服务器才有数据传送。服务器端需要确保当客户端不再工作时,释放为这个客户端分配的资源,防止内存泄漏。因此需要一种机制使双方知道大家都在正常运行。在实现上:

  a)服务器端在阻塞读时会设置一个时限,超时后阻塞读调用会返回,同时发给客户端没有新数据到达的心跳信息。此时如果客户端已经关闭,服务器往通道写数据会出现异常,服务器端就会及时释放为这个客户端分配的资源。

  b)如果客户端使用的是基于 AJAX 的长轮询方式;服务器端返回数据、关闭连接后,经过某个时限没有收到客户端的再次请求,会认为客户端不能正常工作,会释放为这个客户端分配、维护的资源。

  c)当服务器处理信息出现异常情况,需要发送错误信息通知客户端,同时释放资源、关闭连接。

相关推荐: 前后端分离了,然后呢?

  前言   前后端分离已经是业界所共识的一种开发/部署模式了。所谓的前后端分离,并不是传统行业中的按部门划分,一部分人纯做前端(HTML/CSS/JavaScript/Flex),另一部分人纯做后端,因为这种方式是不工作的:比如很多团队采取了后端的模板技术(…