Web应用中实时消息技术总结

46 sec read

在互联网应用中,很多时候我们需要在客户端和服务端之间进行实时的消息交互,比如下面这些常见的应用场景:
  • SNS网站用户互动消息通知(weibo/twitter)
  • 门户网站实时滚动新闻(突发事件)、文字直播(体育赛事)
  • 在线聊天室(在线客服)
  • 实时数据展示(实时股价,实时商品价,服务器实时监控等)

接下来就来看看web开发中常见的实时消息的实现技术方案,每种方案都各有优缺点,在不同的应用场景下有不同的选择

普通的http

  • 客户端从服务器端请求网页
  • 服务器作出相应的反应
  • 服务器返回相应到客户端
http
AJAX Polling
  • 客户端使用普通的http方式向服务器端请求网页
  • 客户端执行网页中的JavaScript轮询脚本,定期循环的向服务器发送请求(例如每5秒发送一次请求),获取信息
  • 服务器对每次请求作出响应,并返回相应信息,就像正常的http请求一样
polling
客户端定时请求服务器来询问是否有新的消息产生,这种情况下客户端每次请求都要建立一次http连接,服务器都要产生一个响应信息。
  • 优点:实现简单,使用方便,开发成本很低,适合刚起步的小型应用或是其它方案的备用方案。
  • 缺点:消息有延迟,网络通信消耗大(特别是移动网络下),服务器容易产生峰值请求。
  • 实现:浏览器里用js定时请求,或是移动设备上nativeapp里定时发http请求。
  • 实例:适于小型应用。
AJAX Long-Polling
  • 客户端使用普通的http方式向服务器端请求网页
  • 客户端执行网页中的JavaScript脚本,向服务器发送数据、请求信息
  • 服务器并不是立即就对客户端的请求作出响应,而是等待有效的更新
  • 当信息是有效的更新时,服务器才会把数据推送给客户端
  • 当客户端接收到服务器的通知时,立即会发送一个新的请求,进入到下一次的轮询
long-polling
跟上面的polling模式相比:
  • 优点:消息到达客户端更及时;减少了http请求不停地创建、关闭成的不必要浪费。在无消息的情况下不会频繁的请求。Long-polling支持大多数当前的浏览器。
  • 缺点:服务端需要保持大量连接,http连接的维护开销较大;每次产生消息后都需要重新创建连接。
  • 实现:客户端只要简单的发送请求,等待响应即可。服务器端需要做两方面的工作:一是保持大量的连接(Non-Blocking I/O);二是读取后台的消息更新(异步定时轮询或由事件触发)。是一个近实时的异步方式。
  • 兼容性:
  • 实例:WebQQ、Hi网页版、Facebook IM。
基于流的模式(http streaming)
在这种情况下,客户端与服务器端保持一个持久的连接,服务器端有新消息产生时通过这个持久连接不断地返回给客户端。这种模式与上面的long polling差不多,差别就是只需要创建一次连接就可以了。另外,要注意http header中需要设置Connection: keep-alive和Transfer-Encoding: chunked这两个属性。跟上面longpolling模式相比:
  • 优点:消息可以实时到达客户端;客户端与服务端之间只需要建立一次连接。
  • 缺点:服务器端也要维持大量连接,开销很大。
  • 实现:客户端一般有两种方式:一是隐藏iframe的src指向服务器端url,不断地进行dom渲染;二是使用ajax里的XMLHttpRequest对象来实现。对于服务端来说,和longpolling一,要保持大量连接和处理后台的消息更新。
HTML5 Server Sent Events (SSE) / EventSource:
  • 客户端使用普通的http方式向服务器端请求网页
  • 客户端执行网页中的JavaScript脚本,与服务器之间建立了一个连接
  • 当服务器端有有效的更新时,会发送一个事件到客户端
    • 服务器到客户端数据的实时推送,大多数内容是你需要的
    • 你需要一台可以做Event Loop的服务器
    • 不允许跨域的连接
    • 默认延时3秒,但是可以调整。
    • 除非Server-Sent Events不必在每一次响应发出后都关闭连接。
    • 支持Chrome9+、Firefox6+、Opera11+、Safari5+
sse
如果你觉得这些还不够,想要了解更多,可以参考下面的文件和手册
HTML5 Websockets
  • 客户端使用普通的http方式向服务器端请求网页
  • 客户端执行网页中的JavaScript脚本,与服务器之间建立了一个连接
  • 服务器和客户端之间,可以双向的发送有效数据到对方
    • 服务器可以实时的发送数据到客户端,同时客户端也可以实时的发送数据到服务器
    • 你需要一台可以做Event Loop的服务器
    • 使用 WebSockets 允许跨域的建立连接
    • 它同样支持第三方的websocket主机服务器,例如Pusher或者其它。这样你只需要关心客户端的实现 ,降低了开发难度。
websocket
WebSocket是HTML5开始提供的一种浏览器与服务器间进行全双工通讯的网络技术,浏览器和服务器只需要要做一个握手的动作,然后,浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相送。
  • 优点:实时通讯,双向交互,节省服务器资源和带宽。真正的实时。
  • 缺点:浏览器支持不足。
  • 实现:客户端需要html5来实现,服务器端一般的web服务器都有支持。
目前WebSocket协议仍在开发中,目前Chrome和Safri浏览器默认支持WebSocket,而Firefox和Opera出于安全考虑,默认关闭了WebSocket,IE则不支持(包括9),目前WebSocket协议最新的为“76号草案”。有兴趣可以看以下资料 http://dev.w3.org/html5/websockets/
如果你觉得这些还不够,想要了解更多,可以参考下面的文件和手册
Flash Socket
在页面中内嵌入一个使用了Socket类的 Flash 程序JavaScript通过调用此Flash程序提供的Socket接口与服务器端的Socket接口进行通信,JavaScript在收到服务器端传送的信息后控制页面的显示。
  • 优点:实现真正的即时通信,而不是伪即时。
  • 缺点:客户端必须安装Flash插件;非HTTP协议,无法自动穿越防火墙。
  • 实例:网络互动游戏。
WebRTC

WebRTC是一种点对点类型的传输方式,它支持多种传输协议,如:UDP、TCP甚至是抽象层的协议。设计它时同时考虑到了允许使用可靠和不可靠的两种方式传输数据。这种技术一般应用在传输数据量较大的内容,比如音、视频等流媒体的传输。

参考资料:https://developer.mozilla.org/zh-CN/docs/Web/API/WebRTC_API

Comet

Comet是一种用于web的推送技术,能使服务器实时地将更新的信息传送到客户端,而无须客户端发出请求,目前有两种实现方式,长轮询和iframe流。
  • Event Loop是一个程序结构,用于等待和发送消息和事件。
  • 长轮询是在打开一条连接以后保持,等待服务器推送来数据再关闭的方式。
  • iframe流方式是在页面中插入一个隐藏的iframe,利用其src属性在服务器和客户端之间创建一条长链接,服务器向iframe传输数据(通常是HTML,内有负责插入信息的javascript),来实时更新页面。iframe流方式的优点是浏览器兼容好,Google公司在一些产品中使用了iframe流,如Google Talk。
如果你想了解更多,可以参考维基百科或者IBM
  • 优点:消息即时到达,不发无用请求。
  • 缺点:服务器维护一个长连接会增加开销。
  • 实例:Gmail聊天
在我们实际的应用中,各种方案应该怎么选择?
polling轮询机制很简单,使用方便,都是http短连接,在应用架构上跟普通接口api一致,非常适合小型应用和刚起步的应用,可以节省很多开发成本。
当用户量上升到一定程度后(比如日活跃百万级),产品做得越来越受欢迎了,我们对消息到达的及时性也就有更高的要求了,而且这种轮询机制对服务器压力也是一种考验,这时候我们就可以考虑long polling或http streaming的方式了,这两种方式其实在服务端实现上差不多,主要是保持大量长连接和异步(或事件触发)获取消息。
在保持连接方面,在java的nio出现后,为我们提供了便利,主流的应用服务器像tomcat和jetty都有支持,但是,工作在jvm上的服务器保持大量socket连接时gc是个很严重的问题。可以借助nginx的push模块来实现保持连接以及消息实时推送。

这两个模块工作在nginx上,可以维持大量的http连接,实现了pub/sub协议来支持消息发送,基本流程是下图这的,发送者(publisher)把消息推送到nginx服务器上,然后push模块负责把消息发送给订阅者(client):借助nginx的这个push模块,我们可以省去大量的工作,应用程序只需要关注业务逻辑(也就是publisher做的事),简化了应用架构,同时nginx的高性能也有不错的表现。

当我们的产品发展到千万级的日活跃时,我们可能就要考虑更好的方案了,比如上面的提到的WebSocket,但是为浏览器兼容的问题,这个方案并不是主流的解决方案。一般这种情况下,我们就要考虑基于tcp的socket长连接模式了,通过某种消息推送协议(xmpp/mqtt/自定议协议等)来实现客户端和服务器端的实时交互。

其他相关资料:http://socket.io/

打赏作者
微信支付标点符 wechat qrcode
支付宝标点符 alipay qrcode

C语言学习:size_t

在学习C语言的时候,遇到了一个新的数据类型size_t,截止目前也没有完全理清这个类似的具体场景及出现的原因。
44 sec read

C语言学习:main()函数的正确写法

C语言虽然是一门古老的语言,但是其标准一直在完善,所以很多以前支持的语法在到当前已经不能在使用了。 C语言的版
41 sec read

Scipy数学函数的Scala实现

最近在推进项目的时候,遇到需要将线下的Python代码转化成线上的集群代码,由于机器代码环境是Scala,所以
4 min read

发表评论

电子邮件地址不会被公开。 必填项已用*标注