对轮询的总结，注意是Web端即时通讯技术

Web端即时通讯技术因受限于浏览器的设计限制，一直以来实现起来并不容易，下面是对目前常用的轮询的方式进行汇总：

几种方式

• 短轮询（ajax短轮询）
  客户端，每隔一段时间，请求服务端获取数据。
  • 好处：实现最为简单
  • 缺点：实时性不高、频繁请求对服务端有很大压力
• 长轮询（Comet: 一种hack技术）
  服务端收到客户端的请求后，hold住一段时间，有变化提前返回，否则到达指定时间再返回。
  这里做一个补充：Comet在浏览器端有两种实现方式，一种就是这里的长轮询，还有一种是基于 Iframe 及 htmlfile 的流（http streaming）方式。
  • 好处：能大量减少请求次数，减少服务端压缩，基本上能做到及时响应。
• 长连接
  服务器推送事件（Server-sent Events），简称SSE，是 HTML 5 规范中的一个组成部分，可以用来从服务端实时推送数据到浏览器端。相对于与之类似的 COMET 和 WebSocket 技术来说，服务器推送事件的使用更简单，对服务器端的改动也比较小。对于某些类型的应用来说，服务器推送事件是最佳的选择。是 WebSocket 的一种轻量代替方案，使用 HTTP 协议，SSE 是单向通道，只能服务器向客户端发送消息。
• Websocket
  在新一代html标准html5中提供了一种浏览器和服务器间进行全双工通讯的网络技术Websocket，它是一个全新的、独立的协议，基于TCP协议，与http协议兼容、却不会融入http协议，仅仅作为html5的一部分。可以实现客户端和服务端的全双工通信，服务端和客户端可以自由相互传输数据，不存在请求和响应的区别。

对比

早期，为了浏览器的兼容性，最常见的方法就是短轮询。但因为开销大，更新也不太及时，接着便出现了长轮询的方式。

「选择长轮询还是常规短轮询？」这是每次都需要评估的命题，长轮询是不是总比常规轮询占有优势？我们可以从带宽占用的角度分析，如果一个程序数据更新太过频繁，假设每秒 2 次更新，如果使用长轮询的话每分钟要发送 120 次 HTTP 请求。如果使用常规轮询，每 5 秒发送一次请求的话， 一分钟才 20 次，从这里看，常规轮询更占有优势，当然这种场景下SSE也是一个不错的方案。

长轮询和 SSE 最关键的区别在于，每一次数据更新都需要一次 HTTP 请求。和 WebSocket 还有 SSE 一样，长轮询也会 占用一个 socket。在数据更新效率上和 SSE 差不多，一有数据更新就能检测到。加上所有浏览器都支持，是一个不错的 SSE 替代方案。简单来讲SSE就是一次请求，可以接收后端多次数据 ；长轮询，一次请求，一次返回，需要客户端轮询方式获取数据。

SSE和WebSocket的对比

与WebSocket相比，SSE有一些显著的优势。

• 个人认为它最大的优势就是便利：
  不需要添加任何新组件，用任何你习惯的后端语言和框架就能继续使用。
• SSE的第二个优势是服务端的简洁。
  相对而言，WebSocket则很复杂，不借助辅助类库基本搞不定。
• SSE它是一种文本协议，脚本调试非常容易。
  WebSocket是二进制协议，而SSE是文本协议（通常使用UTF-8编码）

因为SSE能在现有的HTTP/HTTPS协议上运作，所以它能直接运行于现有的代理服务器和认证技术。而对WebSocket而言，代理服务器需要做一些开发（或其他工作）才能支持。

WebSocket相较SSE最大的优势在于它是双向交流的，这意味向服务端发送数据就像从服务端接收数据一样简单。用SSE时，一般通过一个独立的Ajax请求从客户端向服务端传送数据。相对于WebSocket，这样使用Ajax会增加开销，但也就多一点点而已。如此一来，问题就变成了“什么时候需要关心这个差异？”如果需要以1次/秒或者更快的频率向服务端传输数据，那应该用WebSocket。0.2次/秒到1次/秒的频率是一个灰色地带，用WebSocket和用SSE差别不大；但如果你期望高的负载，那就有必要确定基准点。频率低于0.2次/秒左右时，两者差别不大。

注意

实际的过程中，进行选型的时候，还需要考虑一些特殊因素或者做一些别的准备，比如websoket，通过nginx，必须在nginx加上特殊配置，而且还有超时问题，必须在超时时间内进行心跳维持。比如SSE，必须考虑重连，因为真实情况下，会通过类似nginx的软件，这些连接都会设置一个超时时间。

参考的文章
http://www.52im.net/thread-336-1-1.html
https://blog.csdn.net/lovexiaotaozi/article/details/102775350