web应用从服务器主动推送消息到客户端到方式

总结帖

为什么需要服务端向客户端推送消息？

在某些应用功能中，例如定位，游戏，社交消息的推送等，用户都是被动接受u消息的，为了处理这类问题，需要服务端向客户端推送消息。

引言： 普通情况下，有客户端向服务器发送请求，获得数据后返回结果，并关闭二者之间的通信信道

服务器段主动推送的方式

1.轮询

这种方式实际上并不是服务器端主动，而是引言中提到的方式。
简单来说是客户端定时不停地向服务器端发请求，不管之前的请求是否返回结果，返回什么结果。只管自己发送请求。

• 缺点：显然，盲目检查更新导致浪费服务器资源
• 优点：实现简单，只需定时发送请求即可
• 常见：Ajax轮询、JSONP跨域轮询
• 实例：适用于小型应用

长轮询

原理类似轮询，这里的长指的是请求之间的事件间隔。当客户端想服务器端发送的是异步请求，若暂时没有结果返回，则改请求会被i服务器端挂起，直到有结果才返回给客户端，并断开连接。客户端在拿到结果后再次发送请求。如下图所示过程：

• 优点：异步请求，客户端容易实现错误处理系统和超时管理，实现方式与Ajax轮询类似。实时性较好，能支持大量用户。
• 缺点：需要服务器端有特殊的功能来临时挂起连接，当客户端发起的连接较多时，服务器端会长期保持较多连接，具有一定风险且失去来无状态高并发特点。
• 常见：基于Ajax的长轮询（long-polling）、HTTP和 JSONP方式的长轮询、XHR长轮询
• 实例：web QQ 、Hi 网页版 、 Facebook IM

长连接

在页面中潜入一个隐藏iframe，将这个iframe 的src属性设为对一个长连接对请求，服务端就能源源不断地往客户端输入数据。
基本过程如下图：

• 优点：消息能够实时到达，能支持大量用户
• 服务器长期维持长链接消耗资源，iframe不规范的用法，数据推送过程会有加载进度条显示，界面体验不好
• 常见：基于iframe的htmlfile的流（通过传输html，客户端有js负责插入信息来实时更新页面）
• 实例：Gmail聊天

Server-sent events:SSE

与长轮询类似，但是它在返回结果给客户端之后，并不关闭两者间的连接，以继续保持通信。
过程图如下所示：

优点：HTML5 标准，大多数浏览器支持，全双工实时通信
缺点：实现相对复杂，需要对ws协议专门处理，只能单项服务器端向客户端推消息。

webSocket

HTML5开始i提供的一种在单个TCP连接上进行的全双工通讯协议，浏览器与服务器只需做一个握手动作，即可形成一条快速通道（持久），使两者可以直接数据互相传送。

通过一篇文章来了解：看完让你彻底搞懂webSocket

• 优点：全双工实时通信，协议持久化
• 缺点：不兼容低版本IE