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

• SNS网站用户互动消息通知(weibo/twitter)
• 门户网站实时滚动新闻(突发事件)、文字直播(体育赛事)
• 在线聊天室(在线客服)
• 实时数据展示（实时股价，实时商品价，服务器实时监控等）

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

普通的http

• 客户端使用普通的http方式向服务器端请求网页
• 客户端执行网页中的JavaScript轮询脚本，定期循环的向服务器发送请求（例如每5秒发送一次请求），获取信息
• 服务器对每次请求作出响应，并返回相应信息，就像正常的http请求一样

客户端定时请求服务器来询问是否有新的消息产生，这种情况下客户端每次请求都要建立一次http连接，服务器都要产生一个响应信息。

• 优点：实现简单，使用方便，开发成本很低，适合刚起步的小型应用或是其它方案的备用方案。
• 缺点：消息有延迟，网络通信消耗大（特别是移动网络下），服务器容易产生峰值请求。
• 实现：浏览器里用js定时请求，或是移动设备上 native app里定时发http请求。
• 实例：适于小型应用。

• 客户端使用普通的http方式向服务器端请求网页
• 客户端执行网页中的JavaScript脚本，向服务器发送数据、请求信息
• 服务器并不是立即就对客户端的请求作出响应，而是等待有效的更新
• 当信息是有效的更新时，服务器才会把数据推送给客户端
• 当客户端接收到服务器的通知时，立即会发送一个新的请求，进入到下一次的轮询

• 优点：消息到达客户端更及时；减少了http请求不停地创建、关闭成的不必要浪费。在无消息的情况下不会频繁的请求。Long-polling支持大多数当前的浏览器。
• 缺点：服务端需要保持大量连接，http连接的维护开销较大；每次产生消息后都需要重新创建连接。
• 实现：客户端只要简单的发送请求，等待响应即可。服务器端需要做两方面的工作：一是保持大量的连接(Non-Blocking I/O)；二是读取后台的消息更新（异步定时轮询或由事件触发）。是一个近实时的异步方式。
• 兼容性：
• 实例：WebQQ、Hi网页版、Facebook IM。

• 客户端使用普通的http方式向服务器端请求网页
• 客户端执行网页中的JavaScript脚本，与服务器之间建立了一个连接
• 当服务器端有有效的更新时，会发送一个事件到客户端
  • 服务器到客户端数据的实时推送，大多数内容是你需要的
  • 你需要一台可以做Event Loop的服务器
  • 不允许跨域的连接
  • 默认延时3秒，但是可以调整。
  • 除非Server-Sent Events不必在每一次响应发出后都关闭连接。
  • 支持Chrome9+、Firefox6+、Opera11+、Safari5+

• Using server-sent events
• Server-Sent Events
• Stream Updates with Server-Sent Events
• Tutorial: JSF 2 and HTML5 Server Sent Events

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

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

Comet

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

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

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