关于即时通讯:搞懂现代Web端即时通讯技术一文就够WebSocketsocketioSSE

本文援用自“ 豆米博客”的《JS实时通信三把斧》系列文章，有优化和改变。

1、引言

无关Web端即时通讯技术的文章我已整顿过很多篇，浏览过的读者可能都很相熟，晚期的Web端即时通讯计划，受限于Web客户端的技术限度，想实现真正的“即时”通信，难度相当大。

传统的Web端即时通讯技术从短轮询到长连询，再到Comet技术，在如此原始的HTML规范之下，为了实现所谓的“即时”通信，技术上堪称搜索枯肠，极尽所能。

自从HTML5规范公布之后，WebSocket这类技术横空出世，实现Web端即时通讯技术的便利性大大提前，以往想都不敢想的真正全双工实时通信，如此早已成为可能。

本文将专门介绍WebSocket、socket.io、SSE这几种古代的Web端即时通讯技术，从实用场景到技术原理，艰深又不失深度的文字，特地适宜对Web端即时通讯技术有肯定理解，且想深刻学习WebSocket等古代Web端“实时”通信技术，却又不想花工夫去深读干燥的IETF技术手册的读者。

学习交换：

• 即时通讯/推送技术开发交换5群：215477170 [举荐]
• 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》
• 开源IM框架源码：https://github.com/JackJiang2...

（本文同步公布于：http://www.52im.net/thread-36...）

2、本文作者

“豆米”：现居杭州，酷爱前端，酷爱互联网，豆米是“洋芋(土豆-豆)”和“米喳(米)”的简称。
作者博客：https://blog.5udou.cn/
作者Github：https://github.com/linxiaowu66/

3、常识准备

如果你对Web端即时通讯技术的前世今生未曾理解，倡议先读以下文章：

《新手入门贴：史上最全Web端即时通讯技术原理详解》
《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《详解Web端通信形式的演进：从Ajax、JSONP 到 SSE、Websocket》
《网页端IM通信技术疾速入门：短轮询、长轮询、SSE、WebSocket》

如果你对本文将要介绍的技术已有理解，倡议进行专项学习，以便深刻把握：

《Comet技术详解：基于HTTP长连贯的Web端实时通信技术》
《SSE技术详解：一种全新的HTML5服务器推送事件技术》
《WebSocket详解（三）：深刻WebSocket通信协议细节》
《实践联系实际：从零了解WebSocket的通信原理、协定格局、安全性》
《WebSocket从入门到精通，半小时就够！》

4、WebSocket

在这里不打算具体介绍整个WebSocket协定的内容，依据我自己以前协定的学习思路，我挑重点应用问答形式来介绍该协定，这样读起来就不那么干燥。

4.1 根本状况
协定运行在OSI的哪层？

应用层，WebSocket协定是一个独立的基于TCP的协定。 它与HTTP惟一的关系是它的握手是由HTTP服务器解释为一个Upgrade申请。

协定运行的规范端口号是多少？

默认状况下，WebSocket协定应用端口80用于惯例的WebSocket连贯、端口443用于WebSocket连贯的在传输层平安（TLS）RFC2818之上的隧道化口。

4.2 协定是如何工作的?
协定的工作流程能够参考下图：

其中帧的一些重要字段须要解释一下：

1）Upgrade：upgrade是HTTP1.1中用于定义转换协定的header域。它示意，如果服务器反对的话，客户端心愿应用现有的「网络层」曾经建设好的这个「连贯（此处是 TCP 连贯）」，切换到另外一个「应用层」（此处是 WebSocket）协定；
2）Connection：Upgrade固定字段。Connection还有其余字段，能够本人给本人科普一下；
3）Sec-WebSocket-Key：用来发送给服务器应用（服务器会应用此字段组装成另一个key值放在握手返回信息里发送客户端）；
4）Sec-WebSocket-Protocol：标识了客户端反对的子协定的列表；
5）Sec-WebSocket-Version：标识了客户端反对的WS协定的版本列表，如果服务器不反对这个版本，必须回应本人反对的版本；
6）Origin：作平安应用，避免跨站攻打，浏览器个别会应用这个来标识原始域；
7）Sec-WebSocket-Accept：服务器响应，蕴含Sec-WebSocket-Key 的签名值，证实它反对申请的协定版本。

对于Sec-WebSocket-Key和Sec-WebSocket-Accept的计算是这样的：

所有兼容RFC 6455 的WebSocket 服务器都应用雷同的算法计算客户端挑战的答案：将Sec-WebSocket-Key 的内容与规范定义的惟一GUID字符(258EAFA5-E914-47DA-95CA-C5AB0DC85B11)串拼接起来，计算出SHA1散列值，后果是一个base-64编码的字符串，把这个字符串发给客户端即可。

用代码就是实现如下：

const key = crypto.createHash('sha1')      .update(req.headers['sec-websocket-key'] + constants.GUID, 'binary')      .digest('base64')

至于为什么须要这么一个步骤，能够参考《实践联系实际：从零了解WebSocket的通信原理、协定格局、安全性》一文。

援用如下：

Sec-WebSocket-Key/Sec-WebSocket-Accept在次要作用在于提供根底的防护，缩小歹意连贯、意外连贯。

作用大抵归纳如下：

1）防止服务端收到非法的websocket连贯（比方http客户端不小心申请连贯websocket服务，此时服务端能够间接回绝连贯）；
2）确保服务端了解websocket连贯。因为ws握手阶段采纳的是http协定，因而可能ws连贯是被一个http服务器解决并返回的，此时客户端能够通过Sec-WebSocket-Key来确保服务端意识ws协定。（并非百分百保险，比方总是存在那么些无聊的http服务器，光解决Sec-WebSocket-Key，但并没有实现ws协定。。。）；
3）用浏览器里发动ajax申请，设置header时，Sec-WebSocket-Key以及其余相干的header是被禁止的。这样能够防止客户端发送ajax申请时，意外申请协定降级（websocket upgrade）；
4）能够避免反向代理（不了解ws协定）返回谬误的数据。比方反向代理前后收到两次ws连贯的降级申请，反向代理把第一次申请的返回给cache住，而后第二次申请到来时间接把cache住的申请给返回（无意义的返回）；
5）Sec-WebSocket-Key次要目标并不是确保数据的安全性，因为Sec-WebSocket-Key、Sec-WebSocket-Accept的转换计算公式是公开的，而且非常简单，最次要的作用是预防一些常见的意外状况（非故意的）。

强调：Sec-WebSocket-Key/Sec-WebSocket-Accept 的换算，只能带来根本的保障，但连贯是否平安、数据是否平安、客户端/服务端是否非法的 ws客户端、ws服务端，其实并没有实际性的保障。

4.3 协定传输的帧格局是什么?
帧格局定义的格局如下：

各个字段的解释如下：

1）FIN： 1bit，用来表明这是一个音讯的最初的音讯片断，当然第一个音讯片断也可能是最初的一个音讯片断；
2）RSV1，RSV2，RSV3： 别离都是1位，如果单方之间没有约定自定义协定，那么这几位的值都必须为0,否则必须断掉WebSocket连贯。在ws中就用到了RSV1来示意是否消息压缩了的；
3）opcode：4 bit，示意被传输帧的类型：

• %x0 示意间断音讯片断；
• %x1 示意文本音讯片断；
• %x2 表未二进制音讯片断；
• %x3-7 为未来的非管制音讯片断保留的操作码；
• %x8 示意连贯敞开；
• %x9 示意心跳查看的ping；
• %xA 示意心跳查看的pong；
• %xB-F 为未来的管制音讯片断的保留操作码。
  4）Mask： 1 bit。定义传输的数据是否有加掩码,如果设置为1,掩码键必须放在masking-key区域，客户端发送给服务端的所有音讯，此位都是1；
  5）Payload length：传输数据的长度，以字节的模式示意：7位、7+16位、或者7+64位。如果这个值以字节示意是0-125这个范畴，那这个值就示意传输数据的长度；如果这个值是126，则随后的两个字节示意的是一个16进制无符号数，用来示意传输数据的长度；如果这个值是127,则随后的是8个字节示意的一个64位无合乎数，这个数用来示意传输数据的长度。多字节长度的数量是以网络字节的程序示意。负载数据的长度为扩大数据及利用数据之和，扩大数据的长度可能为0,因此此时负载数据的长度就为利用数据的长度；
  6）Masking-key：0或4个字节，客户端发送给服务端的数据，都是通过内嵌的一个32位值作为掩码的；掩码键只有在掩码位设置为1的时候存在；
  7）Extension data： x位，如果客户端与服务端之间没有非凡约定，那么扩大数据的长度始终为0，任何的扩大都必须指定扩大数据的长度，或者长度的计算形式，以及在握手时如何确定正确的握手形式。如果存在扩大数据，则扩大数据就会包含在负载数据的长度之内；
  8）Application data： y位，任意的利用数据，放在扩大数据之后，利用数据的长度=负载数据的长度-扩大数据的长度；
  9）Payload data： (x+y)位，负载数据为扩大数据及利用数据长度之和；

更多细节请参考RFC6455-数据帧，这里不作赘述。

针对下面的各个字段的介绍，有一个Mask的须要说一下。

掩码键（Masking-key）是由客户端筛选进去的32位的随机数。掩码操作不会影响数据载荷的长度。

掩码、反掩码操作都采纳如下算法。

首先，假如：

1）original-octet-i：为原始数据的第i字节；
2）transformed-octet-i：为转换后的数据的第i字节；
3）j：为i mod 4的后果；
4）masking-key-octet-j：为mask key第j字节。

算法形容为： original-octet-i 与 masking-key-octet-j 异或后，失去 transformed-octet-i。

即： j = i MOD 4 transformed-octet-i = original-octet-i XOR masking-key-octet-j

用代码实现：

const mask = (source, mask, output, offset, length) => {  for(vari = 0; i < length; i++) {    output[offset + i] = source[i ] ^ mask[i & 3];  }};

解掩码是反过来的操作：

const unmask = (buffer, mask) => {  // Required until [url=https://github.com/nodejs/node/issues/9006]https://github.com/nodejs/node/issues/9006[/url] is resolved.  const length = buffer.length;  for(vari = 0; i < length; i++) {    buffer[i ] ^= mask[i & 3];  }};

同样的为什么须要掩码操作，也能够参考之前的那篇文章：《实践联系实际：从零了解WebSocket的通信原理、协定格局、安全性》，残缺的我就不列举了。

须要留神的重点，我援用一下：

WebSocket协定中，数据掩码的作用是加强协定的安全性。但数据掩码并不是为了爱护数据自身，因为算法自身是公开的，运算也不简单。除了加密通道自身，仿佛没有太多无效的爱护通信安全的方法。

那么为什么还要引入掩码计算呢，除了减少计算机器的运算量外仿佛并没有太多的收益（这也是不少同学纳闷的点）。

答案还是两个字： 平安。但并不是为了避免数据泄密，而是为了避免晚期版本的协定中存在的代理缓存净化攻打（proxy cache poisoning attacks）等问题。

5、socket.io

5.1 本节引言

介绍完上一节WebSocket协定，咱们把眼帘转移到古代Web端即时通讯技术的第二个利器：socket.io。

预计有读者就会问，WebSocket和socket.io有啥区别啊？

在理解socket.io之前，咱们先聊聊传统Web端即时通讯“长连贯”技术的实现背景。

5.2 传统Web长连贯的技术实现背景
在事实的Web端产品中，并不是所有的Web客户端都反对长连贯的，或者换句话说，在WebSocket协定进去之前，是三种形式去实现WebSocket相似的性能的。

这三种形式是：

1）Flash：应用Flash是一种简略的办法。不过很显著的毛病就是Flash并不会装置在所有客户端上，比方iPhone/iPad。
2）Long-Polling：也就是众所周之的“长轮询”，在过来，这是一种无效的技术，但并没有对音讯发送进行优化。尽管我不会把AJAX长轮询当做一种hack技术，但它的确不是一个最优办法；
3）Comet：在过来，这被称为Web端的“服务器推”技术，绝对于传统的 Web 利用， 开发 Comet 利用具备肯定的挑战性，具体请见《Comet技术详解：基于HTTP长连贯的Web端实时通信技术》。

那么如果单纯地应用WebSocket的话，那些不反对的客户端怎么办呢？难道间接放弃掉？

当然不是。Guillermo Rauch大神写了socket.io这个库，对WebSocket进行封装，从而让长连贯满足所有的场景，不过当然得配合应用对应的客户端代码。

socket.io将会应用个性检测的形式来决定以websocket/ajax长轮询/flash等形式建设连贯。

那么socket.io是如何做到这些的呢？

咱们带着以下几个问题去学习：

1）socket.io到底有什么新个性？
2）socket.io是怎么实现个性检测的？
3）socket.io有哪些坑呢？
4）socket.io的理论利用是怎么的，须要留神些什么？

如果有童鞋对上述问题曾经分明，想必就没有往下读的必要了。

5.3 socket.io的介绍
通过后面章节，读者们都晓得了WebSocket的性能，那么socket.io绝对于WebSocket，在此基础上封装了一些什么新货色呢？

socket.io其实是有一套封装了websocket的协定，叫做engine.io协定，在此协定上实现了一套底层双向通信的引擎Engine.io。

而socket.io则是建设在engine.io上的一个应用层框架而已。所以咱们钻研的重点便是engine.io协定。

在socket.io的README中提到了其实现的一些新个性（答复了问题一）：

1）可靠性：连贯仍然能够建设即便应用环境存在： 代理或者负载均衡器 集体防火墙或者反病毒软件；
2）反对主动连贯： 除非特地指定，否则一个断开的客户端会始终重连服务器直到服务器复原可用状态；
3）断开连接检测：在Engine.io层实现了一个心跳机制，这样容许客户端和服务器晓得什么时候其中的一方不能响应。该性能是通过设置在服务端和客户端的定时器实现的，在连贯握手的时候，服务器会被动告知客户端心跳的间隔时间以及超时工夫；
4）二进制的反对：任何序列化的数据结构都能够用来发送；
5）跨浏览器的反对：该库甚至反对到IE8；
6）反对复用：为了在应用程序中将创立的关注点隔离开来，Socket.io容许你创立多个namespace，这些namespace领有独自的通信通道，但将共享雷同的底层连贯；
7）反对Room：在每一个namespace下，你能够定义任意数量的通道，咱们称之为"房间"，你能够退出或者来到房间，甚至播送音讯到指定的房间。

留神：Socket.IO不是WebSocket的实现，尽管 Socket.IO的确在可能的状况下会去应用WebSocket作为一个transport，然而它增加了很多元数据到每一个报文中：报文的类型以及namespace和ack Id。这也是为什么规范WebSocket客户端不可能胜利连贯上 Socket.IO 服务器，同样一个 Socket.IO 客户端也连贯不上规范WebSocket服务器的起因。

5.4 engine.io协定介绍
残缺的engine.io协定的握手过程如下图：

以后engine.io协定的版本是3，咱们依据上图来大抵介绍一下engine.io协定。

5.4.1）engine.io协定申请字段：

咱们看到的是申请的url和WebSocket不大一样，解释一下：

1）EIO=3: 示意的是应用的是Engine.io协定版本3；
2）transport=polling/websocket: 示意应用的长连贯形式是轮询还是WebSocket；
3）t=xxxxx: 代码中应用yeast依据工夫戳生成一个惟一的字符串；
4）sid=xxxx: 客户端和服务器建设连贯之后获取到的session id，客户端拿到之后必须在每次申请中追加这个字段。

除了上述的3个字段，协定还形容了上面几个字段：

1）j: 如果transport是polling，然而要求有一个JSONP的响应，那么j就应该设置为JSONP响应的索引值；
2）b64: 如果客户端不反对XHR，那么客户端应该设置b64=1传给服务器，告知服务器所有的二进制数据应该以base64编码后再发送。

另外engine.io默认的path是 /engine.io，socket.io在初始化的时候设置为了 /socket.io，所以大家看到的path就都是 /socket.io 了：

function Server(srv, opts){  if(!(this instanceof Server)) return new Server(srv, opts);  if('object'== typeof srv && srv instanceof Object && !srv.listen) {    opts = srv;    srv = null;  }  opts = opts || {};  this.nsps = {};  this.parentNsps = new Map();  this.path(opts.path || '/socket.io');

5.4.2）数据包编码要求：

engine.io协定的数据包编码有本人的一套格局，在协定介绍上engine.io-protocol，定义了两种编码类型： packet和payload。

一个编码过的packet是上面这种格局：
<packettype id>[<data>]

而后协定定义了上面几种packet type(采纳数字进行标识)：

1）0(open): 当开始一个新的transport的时候，服务端会发送该类型的packet；
2）1(close): 申请敞开这个transport然而不要本人敞开敞开连贯；
3）2(ping): 由客户端发送的ping包，服务端必须回应一个蕴含雷同数据的pong包；
4）3(pong): 响应ping包，服务端发送；
5）4(message): 理论音讯，在客户端和服务端都能够监听message事件获取音讯内容；
6）5(upgrade): 在engine.io切换transport之前，它会用来测试服务端和客户端是否在该transport上通信。如果测试胜利，客户端会发送一个upgrade包去让服务器刷新它的缓存并切换到新的transport；
7）6(noop): 次要用来强制一个轮询循环当收到一个WebSocket连贯的时候。

那payload也有对应的格局要求：

1）如果当只有发送string并且不反对XHR的时候，其编码格局是：:[:[...]]；
2）当不反对XHR2并且发送二进制数据,然而应用base64编码字符串的时候，其编码格局是：:b[...]；
3）当反对XHR2的时候，所有的数据都被编码成二进制，格局是：<0 for string data, 1 for binary data>[...]；
4）如果发送的内容混杂着UTF-8的字符和二进制数据，字符串的每个字符被写成一个字符编码，用1个字节示意。

留神：payload的编码要求不适用于WebSocket的通信。

针对下面的编码要求，咱们轻易举个例子.

之前在第一条polling申请的时候，服务端编码发送了这个数据：

97:0{"sid":"Peed250dk55pprwgAAAA","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":60000}2:40

依据下面的常识，咱们晓得第一次服务端会发送一个open的数据包。

所以组装进去的packet是：
0

而后服务端会告知客户端去尝试降级到websocket，并且告知对应的sid。

于是整合后便是：

0{"sid":"Peed250dk55pprwgAAAA","upgrades":"websocket","pingInterval":25000,"pingTimeout":60000}

接着依据payload的编码格局，因为是string，且长度是97个字节。

所以是：

97:0{"sid":"Peed250dk55pprwgAAAA","upgrades":"websocket","pingInterval":25000,"pingTimeout":60000}

接着第二局部数据是message包类型，并且数据是0，所以是40，长度为2字节，所以是2:40，最初就拼成方才大家看到的后果。

留神：

ping/pong的间隔时间是服务端告知客户端的："pingInterval":25000,"pingTimeout":60000，也就是说心跳工夫默认是25秒，并且期待pong响应的工夫默认是60s。

5.5 降级协定的必备过程
协定定义了transport降级到websocket须要经验一个必须的过程。

如下图：

WebSocket的测试开始于发送probe，如果服务器也响应probe的话，客户端就必须发送一个upgrade包。

为了确保不会丢包，只有在以后transport的所有buffer被刷新并且transport被认为paused的时候才能够发送upgrade包。服务端收到upgrade包的时候，服务端必须假如这是一个新的通道并发送所有已存的缓存到这个通道上

在Chrome上的成果如下：

5.6 engine.io的代码实现
相熟了engine.io协定之后，咱们看看代码是怎么实现主流程的。

客户端的engine.io的次要实现流程咱们在下面文字介绍了。

联合代码engine.io，画了这么一个客户端流程图：

服务端的代码和客户端十分类似，其实现流程图如下：

6、SSE

6.1 本节引言

本文前两节剖析了WebSocket和socket.io，当初咱们来看看SSE。

很多人兴许好奇，有了WebSocket这种实时通信，为什么还须要SSE呢？

答案其实很简略：那就是SSE其实是单向通信，而WebSocket是双向通信。

比方：在股票行情、新闻推送的这种只须要服务器发送音讯给客户端场景中，应用SSE可能更加适合。

另外：SSE是应用HTTP传输的，这意味着咱们不须要一个非凡的协定或者额定的实现就能够应用。而WebSocket要求全双工连贯和一个新的WebSocket服务器去解决。加上SSE在设计的时候就有一些WebSocket没有的个性，比方主动重连贯、event IDs、以及发送随机事件的能力，所以各有各的专长，咱们须要依据理论利用场景，去抉择不同的利用计划。

6.2 SSE介绍
SSE的简略模型是：一个客户端去从服务器端订阅一条“流”，之后服务端能够发送音讯给客户端直到服务端或者客户端敞开该“流”，所以SSE全称叫“server-sent-event”。

相比以前的轮询，SSE能够为B2C带来更高的效率。

有一张图片画出了二者的区别：

6.3 SSE数据帧的格局
SSE必须编码成utf-8的格局，音讯的每个字段应用"\n"来做宰割，并且须要上面4个标准定义好的字段。

这4个字段是：

1）Event: 事件类型；
2）Data: 发送的数据；
3）ID: 每一条事件流的ID；
4）Retry： 告知浏览器在所有的连贯失落之后从新开启新的连贯期待的工夫，在主动从新连贯的过程中，之前收到的最初一个事件流ID会被发送到服务端。

下图是通过wireshark抓包失去的数据包的原始格局：

6.4 SSE通信过程
SSE的通信过程比较简单，底层的一些实现都被浏览器给封装好了，包含数据的解决。

大抵流程如下：

在浏览器中截图如下：

携带的数据是JSON格局的，浏览器都帮你整合成为一个Object：

在wireshark中，其通信流程如下。

发送申请：

失去响应：

在开始推送信息流之前，服务器还会发送一个客户端会疏忽掉的包，这个具体起因不分明：

断开连接后的重传：

6.5 SSE的简略应用示例
浏览器端的应用：
const es = new EventSource('/sse')

服务端的应用：

const sseStream = new SseStream(req)sseStream.pipe(res)sseStream.write({  id: sendCount,  event: 'server-time',  retry: 20000, // 通知客户端,如果断开连接后,20秒后再重试连贯  data: {ts: newDate().toTimeString(), count: sendCount++}})

更多API应用和demo介绍别离参考：SSE API、demo代码。

6.6 兼容性及毛病
兼容性：

▲ 上图来自 https://caniuse.com/?search=S...

毛病：

1）因为是服务器 -> 客户端的，所以它不能解决客户端申请流；
2）因为是明确指定用于传输UTF-8数据的，所以对于传输二进制流是低效率的，即便你转为base64的话，反而减少带宽的负载，得失相当。

7、参考资料

[1] WebSocket API文档
[2] SSE API文档
[3] 新手入门贴：史上最全Web端即时通讯技术原理详解
[4] Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE
[5] SSE技术详解：一种全新的HTML5服务器推送事件技术
[6] Comet技术详解：基于HTTP长连贯的Web端实时通信技术
[7] 老手疾速入门：WebSocket扼要教程
[8] WebSocket详解（三）：深刻WebSocket通信协议细节
[9] WebSocket详解（四）：刨根问底HTTP与WebSocket的关系(上篇)
[10] WebSocket详解（五）：刨根问底HTTP与WebSocket的关系(下篇)
[11] 应用WebSocket和SSE技术实现Web端音讯推送
[12] 详解Web端通信形式的演进：从Ajax、JSONP 到 SSE、Websocket
[13] MobileIMSDK-Web的网络层框架为何应用的是Socket.io而不是Netty？
[14] 实践联系实际：从零了解WebSocket的通信原理、协定格局、安全性
[15] WebSocket从入门到精通，半小时就够！
[16] WebSocket硬核入门：200行代码，教你徒手撸一个WebSocket服务器
[17] 网页端IM通信技术疾速入门：短轮询、长轮询、SSE、WebSocket

本文已同步公布于“即时通讯技术圈”公众号。
同步公布链接是：http://www.52im.net/thread-36...