本文来自“糊糊糊糊糊了”的分享，原题《实时音讯推送整顿》，有优化和改变。
1、写在后面
对 Web 端即时通讯技术相熟的开发者来说，咱们回顾网页端 IM 的底层通信技术，从短轮询、长轮询，到起初的 SSE 以及 WebSocket，应用门槛越来越低（晚期的长轮询 Comet 这类技术理论属于 hack 伎俩，应用门槛并不低），技术手段越来越先进，网页端即时通讯技术的体验也因而越来越好。
但上周在编辑《IM 扫码登录技术专题》系列文章第 3 篇的时候突然想到，之前的这些所谓的网页端即时通讯“老技术”绝对于当红的 WebSocket，并非毫无用武之地。就拿 IM 里的扫码登录性能来说，用短轮询技术就十分适合，齐全没必要大炮打蚊子上 WebSocket。
所以，很多时候没必要自觉谋求新技术，绝对利用场景来说适宜的才是最好的。对于即时通讯网的 im 和音讯推送这类即时通讯技术开发者来说，把握 WebSocket 诚然很重要，但理解短轮询、长轮询等这些所谓的 Web 端即时通讯“老技术”依然大有裨益，这也正是整顿分享本文的重要起因。
学习交换：
即时通讯 / 推送技术开发交换 5 群：215477170 [举荐]
挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
开源 IM 框架源码：https://github.com/JackJiang2…
（本文同步公布于：http://www.52im.net/thread-35…
2、举荐浏览
[1] 新手入门贴：史上最全 Web 端即时通讯技术原理详解
[2] 详解 Web 端通信形式的演进：从 Ajax、JSONP 到 SSE、Websocket
[3] Web 端即时通讯技术盘点：短轮询、Comet、Websocket、SSE
3、注释引言
对于 IM/ 音讯推送这类即时通讯零碎而言，零碎的要害就是“实时通信”能力。
从外表意思上来看，“实时通信”指的是：
1）客户端能随时被动发送数据给服务端；
2）当客户端关注的内容在产生扭转时，服务器可能实时地告诉客户端。
类比于传统的 C / S 申请模型，“实时通信”时客户端不须要主观地发送申请去获取本人关怀的内容，而是由服务器端进行“推送”。
留神：下面的“推送”二字打了引号，实际上现有的几种技术实现形式中，并不是服务器端真正被动地推送，而是通过肯定的伎俩营造了一种“实时通信”的假象。
就目前现有的几种技术而言，次要有以下几类：
1）客户端轮询：传统意义上的短轮询（Short Polling）；
2）服务器端轮询：长轮询（Long Polling）；
3）单向服务器推送：Server-Sent Events（SSE）；
4）全双工通信：WebSocket。
以下注释将针对这几种技术计划，为你一一解惑。
4、本文配套 Demo 和代码
为了帮忙读者更好的了解本文内容，笔者专门写了一个较完整的 Demo，Demo 会以一个繁难聊天室的例子来别离通过上述的四种技术形式实现（代码存在些许 bug，次要是为了做演示用，别介意）。
残缺 Demo 源码打包下载：
（请从同步链接附件中下载：http://www.52im.net/thread-35…
Demo 的运行成果（动图）：
有趣味能够自行下载钻研学习。
5、了解短轮询（Short Polling）
短轮询的实现原理：
1）客户端向服务器端发送一个申请，服务器返回数据，而后客户端依据服务器端返回的数据进行解决；
2）客户端持续向服务器端发送申请，持续反复以上的步骤，如果不想给服务器端太大的压力，个别状况下会设置一个申请的工夫距离。
逻辑如下图所示：
应用短轮询的长处：根底不须要额定的开发成本，申请数据，解析数据，作出响应，仅此而已，而后一直反复。
毛病也不言而喻：
1）一直的发送和敞开申请，对服务器的压力会比拟大，因为自身开启 Http 连贯就是一件比拟耗资源的事件；
2）轮询的工夫距离不好管制。如果要求的实时性比拟高，显然应用短轮询会有显著的短板，如果设置 interval 的距离过长，会导致音讯提早，而如果太短，会对服务器产生压力。
短轮询客户的代码实现（片段节选）：
var ShortPollingNotification = {
datasInterval: null,
subscribe: function() {
this.datasInterval = setInterval(function() {Request.getDatas().then(function(res) {window.ChatroomDOM.renderData(res);
});
}, TIMEOUT);
return this.unsubscribe;
},
unsubscribe: function() {
this.datasInterval && clearInterval(this.datasInterval);
}
}
PS：残缺代码，请见本文“4、本文配套 Demo 和代码”一节。
对应本文配套 Demo 的运行成果如下（动图）：
上面是对应的申请，留神左下角的申请数量始终在变动：
在上图中，每隔 1s 就会发送一个申请，看起来成果还不错，然而如果将 timeout 的值设置成 5s，成果将大打折扣。如下图所示。
将 timeout 值设置成 5s 时的 Demo 运行成果（动图）：
6、了解长轮询(Long Polling)
6.1 基本原理
长轮询的基本原理：
1）客户端发送一个申请，服务器会 hold 住这个申请；
2）直到监听的内容有扭转，才会返回数据，断开连接（或者在肯定的工夫内，申请还得不到返回，就会因为超时主动断开连接）；
3）客户端持续发送申请，反复以上步骤。
逻辑如下图所示：
长轮询是基于短轮询上的改良版本：次要是缩小了客户端发动 Http 连贯的开销，改成了在服务器端被动地去判断所关怀的内容是否变动。
所以其实轮询的实质并没有多大变动，变动的点在于：
1）对于内容变动的轮询由客户端改成了服务器端（客户端会在连贯中断之后，会再次发送申请，比照短轮询来说，大大减少了发动连贯的次数）；
2）客户端只会在数据扭转时去作相应的扭转，比照短轮询来说，并不是全盘接管。
6.2 代码实现
长轮询客户的代码实现（片段节选）：
// 客户端
var LongPollingNotification = {
// ....
subscribe: function() {
var that = this;
// 设置超时工夫
Request.getV2Datas(this.getKey(),{timeout: 10000}).then(function(res) {
var data = res.data;
window.ChatroomDOM.renderData(res);
// 胜利获取数据后会再次发送申请
that.subscribe();}).catch(function(error) {
// timeout 之后也会再次发送申请
that.subscribe();});
return this.unsubscribe;
}
// ....
}
笔者采纳的是 express，默认不反对 hold 住申请，因而用了一个 express-longpoll 的库来实现。
上面是一个原生不必库的实现（这里只是介绍原理），整体的思路是：如果服务器端反对 hold 住申请的话，那么在肯定的工夫内会自轮询，而后期间通过比拟 key 值，判断是否返回新数据。
以下是具体思路：
1）客户端第一次会带一个空的 key 值，这次会立刻返回，获取新内容，服务器端将计算出的 contentKey 返回给客户端；
2）而后客户端发送第二次申请，带上第一次返回的 contentKey 作为 key 值，而后进行下一轮的比拟；
3）如果两次的 key 值雷同，就会 hold 申请，进行外部轮询，如果期间有新内容或者客户端 timeout，就会断开连接；
4）反复以上步骤。
代码如下：
// 服务器端
router.get(‘/v2/datas’, function(req, res) {
const key = _.get(req.query, ‘key’, ”);
let contentKey = chatRoom.getContentKey();
while(key === contentKey) {
sleep.sleep(5);
contentKey = chatRoom.getContentKey();
}
const connectors = chatRoom.getConnectors();
const messages = chatRoom.getMessages();
res.json({
code: 200,
data: {connectors: connectors, messages: messages, key: contentKey},
});
});
以下是用 express-longpoll 的实现片段：
// mini-chatroom/public/javascripts/server/longPolling.js
function pushDataToClient(key, longpoll) {
var contentKey = chatRoom.getContentKey();
if(key !== contentKey) {
var connectors = chatRoom.getConnectors();
var messages = chatRoom.getMessages();
long poll.publish(
'/v2/datas',
{
code: 200,
data: {connectors: connectors, messages: messages, key: contentKey},
}
);
}
}
long poll.create(“/v2/datas”, function(req, res, next) {
key = _.get(req.query, ‘key’, ”);
pushDataToClient(key, longpoll);
next();
});
intervalId = setInterval(function() {
pushDataToClient(key, longpoll);
}, LONG_POLLING_TIMEOUT);
PS：残缺代码，请见本文“4、本文配套 Demo 和代码”一节。
为了不便演示，我将客户端发动申请的 timeout 改成了 4s，留神察看上面的截图：
能够看到，断开连接的两种形式，要么是超时，要么是申请有数据返回。
6.3 基于 iframe 的长轮询模式
这是长轮询技术的另一个种实现计划。
该计划的具体的原理为：
1）在页面中嵌入一个 iframe，地址指向轮询的服务器地址，而后在父页面中搁置一个执行函数，比方 execute(data)；
2）当服务器有内容扭转时，会向 iframe 发送一个脚本 <script>parent.execute(JSON.stringify(data))</script>；
3）通过发送的脚本，被动执行父页面中的办法，达到推送的成果。
因不篇幅起因，在此不作深刻介绍，有趣味的同学能够详读《新手入门贴：史上最全 Web 端即时通讯技术原理详解》一文中的“3.3.2 基于 iframe 的数据流”一节。
7、什么是 Server-Sent Events（SSE）
7.1 根本介绍
从纯技术的角度讲：上两节介绍的短轮询和长轮询技术，服务器端是无奈被动给客户端推送音讯的，都是客户端被动去申请服务器端获取最新的数据。
本节要介绍的 SSE 是一种能够被动从服务端推送音讯的技术。
SSE 的实质其实就是一个 HTTP 的长连贯，只不过它给客户端发送的不是一次性的数据包，而是一个 stream 流，格局为 text/event-stream。所以客户端不会敞开连贯，会始终等着服务器发过来的新的数据流，视频播放就是这样的例子。
简略来说，SSE 就是：
1）SSE 应用 HTTP 协定，现有的服务器软件都反对。WebSocket 是一个独立协定。
2）SSE 属于轻量级，应用简略；WebSocket 协定绝对简单。
3）SSE 默认反对断线重连，WebSocket 须要本人实现。
4）SSE 个别只用来传送文本，二进制数据须要编码后传送，WebSocket 默认反对传送二进制数据。
5）SSE 反对自定义发送的音讯类型。
SSE 的技术原理如下图所示：
SSE 根本的应用办法，能够参看 SSE 的 API 文档，地址是：https://developer.mozilla.org/en … _server-sent_events。
目前除了 IE 以及低版本的浏览器不反对，绝大多数的古代浏览器都反对 SSE：
（上图来自：https://caniuse.com/?search=S…
7.2 代码实现
// 客户端
var SSENotification = {
source: null,
subscribe: function() {
if('EventSource'inwindow) {this.source = newEventSource('/sse');
this.source.addEventListener('message', function(res) {
const d = res.data;
window.ChatroomDOM.renderData(JSON.parse(d));
});
}
return this.unsubscribe;
},
unsubscribe: function() {
this.source && this.source.close();
}
}
// 服务器端
router.get(‘/sse’, function(req, res) {
const connectors = chatRoom.getConnectors();
const messages = chatRoom.getMessages();
const response = {code: 200, data: { connectors: connectors, messages: messages} };
res.writeHead(200, {
"Content-Type":"text/event-stream",
"Cache-Control":"no-cache",
"Connection":"keep-alive",
"Access-Control-Allow-Origin": '*',
});
res.write(“retry: 10000\n”);
res.write(“data: “+ JSON.stringify(response) + “\n\n”);
var unsubscribe = Event.subscribe(function() {
const connectors = chatRoom.getConnectors();
const messages = chatRoom.getMessages();
const response = {code: 200, data: { connectors: connectors, messages: messages} };
res.write("data:"+ JSON.stringify(response) + "\n\n");
});
req.connection.addListener(“close”, function() {
unsubscribe();
}, false);
});
上面是控制台的状况，留神察看响应类型：
详情中留神查看申请类型，以及 EventStream 音讯类型：
PS：无关 SSE 更详尽的材料就不在这里开展了，有趣味的同学能够详读《SSE 技术详解：一种全新的 HTML5 服务器推送事件技术》、《应用 WebSocket 和 SSE 技术实现 Web 端音讯推送》。
8、什么是 WebSocket
8.1 根本介绍
PS：本大节内容援用自《Web 端即时通讯实际干货：如何让 WebSocket 断网重连更疾速？》一文的“3、疾速理解 WebSocket”。
WebSocket 诞生于 2008 年，在 2011 年成为国际标准，当初所有的浏览器都已反对（详见《老手疾速入门：WebSocket 扼要教程》）。它是一种全新的应用层协定，是专门为 web 客户端和服务端设计的真正的全双工通信协议，能够类比 HTTP 协定来理解 websocket 协定。
（图片援用自《WebSocket 详解（四）：刨根问底 HTTP 与 WebSocket 的关系(上篇)》）
它们的不同点：
1）HTTP 的协定标识符是 http，WebSocket 的是 ws；
2）HTTP 申请只能由客户端发动，服务器无奈被动向客户端推送音讯，而 WebSocket 能够；
3）HTTP 申请有同源限度，不同源之间通信须要跨域，而 WebSocket 没有同源限度。
它们的相同点：
1）都是应用层的通信协议；
2）默认端口一样，都是 80 或 443；
3）都能够用于浏览器和服务器间的通信；
4）都基于 TCP 协定。
两者和 TCP 的关系图：
（图片援用自《老手疾速入门：WebSocket 扼要教程》）
无关 Http 和 WebSocket 的关系，能够详读：
《WebSocket 详解（四）：刨根问底 HTTP 与 WebSocket 的关系(上篇)》
《WebSocket 详解（五）：刨根问底 HTTP 与 WebSocket 的关系(下篇)》
无关 WebSocket 和 Socket 的关系，能够详读：《WebSocket 详解（六）：刨根问底 WebSocket 与 Socket 的关系》.
8.2 技术特色
WebSocket 技术特色总结下就是：
1）可双向通信，设计的目标次要是为了缩小传统轮询时 http 连贯数量的开销；
2）建设在 TCP 协定之上，握手阶段采纳 HTTP 协定，因而握手时不容易屏蔽，能通过各种 HTTP 代理服务器；
3）与 HTTP 兼容性良好，同样能够应用 80 和 443 端口；
4）没有同源限度，客户端能够与任意服务器通信；
5）能够发送文本，也能够发送二进制数据；
6）协定标识符是 ws（如果加密，则为 wss），服务器网址就是 URL.
WebSocket 的技术原理如下图所示：
对于 WebSocket API 方面的常识，这里不再作解说，能够本人查阅：https://developer.mozilla.org…
8.3 浏览器兼容性
WebSocket 兼容性良好，根本反对所有古代浏览器。
（上图来自：https://caniuse.com/mdn-api_w…
8.4 代码实现
笔者这里采纳的是 socket.io，是基于 WebSocket 的封装，提供了客户端以及服务器端的反对。
// 客户端
var WebsocketNotification = {
// …
subscribe: function(args) {
var connector = args[1];
this.socket = io();
this.socket.emit('register', connector);
this.socket.on('register done', function() {window.ChatroomDOM.renderAfterRegister();
});
this.socket.on('data', function(res) {window.ChatroomDOM.renderData(res);
});
this.socket.on('disconnect', function() {window.ChatroomDOM.renderAfterLogout();
});
}
// …
}
// 服务器端
var io = socketIo(httpServer);
io.on(‘connection’, (socket) => {
socket.on(‘register’, function(connector) {
chatRoom.onConnect(connector);
io.emit('register done');
var data = chatRoom.getDatas();
io.emit('data', { data});
});
socket.on(‘chat’, function(message) {
chatRoom.receive(message);
var data = chatRoom.getDatas();
io.emit('data', { data});
});
});
PS：残缺代码，请见本文“4、本文配套 Demo 和代码”一节。
响应格局如下：
8.5 深刻学习
随着 HTML5 的普及率越来越高，WebSocket 的利用也越来越遍及，对于 WebSocket 的学习材料网上很容易找到，限于篇幅本文就不深刻开展这个话题。
如果想进一步深刻学习 WebSocket 的方方面面，以下文章值得一读：
《老手疾速入门：WebSocket 扼要教程》
《WebSocket 详解（一）：初步意识 WebSocket 技术》
《WebSocket 详解（二）：技术原理、代码演示和利用案例》
《WebSocket 详解（三）：深刻 WebSocket 通信协议细节》
《WebSocket 详解（四）：刨根问底 HTTP 与 WebSocket 的关系(上篇)》
《WebSocket 详解（五）：刨根问底 HTTP 与 WebSocket 的关系(下篇)》
《WebSocket 详解（六）：刨根问底 WebSocket 与 Socket 的关系》
《实践联系实际：从零了解 WebSocket 的通信原理、协定格局、安全性》
《微信小程序中如何应用 WebSocket 实现长连贯(含残缺源码)》
《八问 WebSocket 协定：为你疾速解答 WebSocket 热门疑难》
《Web 端即时通讯实际干货：如何让你的 WebSocket 断网重连更疾速？》
《WebSocket 从入门到精通，半小时就够！》
《WebSocket 硬核入门：200 行代码，教你徒手撸一个 WebSocket 服务器》
《长连贯网关技术专题(四)：爱奇艺 WebSocket 实时推送网关技术实际》
9、本文小结
短轮询、长轮询实现老本绝对比较简单，实用于一些实时性要求不高的音讯推送，在实时性要求高的场景下，会存在提早以及会给服务器带来更大的压力。
SSE 只能是服务器端推送音讯，因而对于不须要双向通信的我的项目比拟实用。
WebSocket 目前而言实现老本绝对较低，适宜于双工通信，对于多人在线，要求实时性较高的我的项目比拟实用。
本文已同步公布于“即时通讯技术圈”公众号。
▲ 本文在公众号上的链接是：点此进入。同步公布链接是：http://www.52im.net/thread-35…