本文引证自“ 豆米博客”的《JS实时通讯三把斧》系列文章，有优化和改动。

　　有关Web端即时通讯技能的文章我已整理过许多篇，阅读过的读者或许都很了解，前期的Web端即时通讯计划，受限于Web客户端的技能约束，想完成真实的“即时”通讯，难度相当大。

　　传统的Web端即时通讯技能从短轮询到长连询，再到Comet技能，在如此原始的HTML标准之下，为了完成所谓的“即时”通讯，技能上可谓费尽心机，极尽所能。

　　自从HTML5标准发布之后，WebSocket这类技能横空出世，完成Web端即时通讯技能的便利性大大提早，以往想都不敢想的真实全双工实时通讯，如此早已成为或许。

　　本文将专门介绍WebSocket、socket.io、SSE这几种现代的Web端即时通讯技能，从适用场景到技能原理，浅显又不失深度的文字，特别适宜对Web端即时通讯技能有必定了解，且想深化学习WebSocket等现代Web端“实时”通讯技能，却又不想花时刻去深读单调的IETF技能手册的读者。

　　“豆米”：现居杭州，酷爱前端，酷爱互联网，豆米是“洋芋(马铃薯-豆)”和“米喳(米)”的简称。

　　《网页端IM通讯技能快速入门：短轮询、长轮询、SSE、WebSocket》

　　《理论联系实践：从零了解WebSocket的通讯原理、协议格局、安全性》

　　在这里不计划详细介绍整个WebSocket协议的内容，依据我自己曾经协议的学习思路，我挑要点运用问答办法来介绍该协议，这样读起来就不那么单调。

　　运用层，WebSocket协议是一个独立的依据TCP的协议。 它与HTTP仅有的联系是它的握手是由HTTP服务器解释为一个Upgrade恳求。

　　默许状况下，WebSocket协议运用端口80用于惯例的WebSocket衔接、端口443用于WebSocket衔接的在传输层安全（TLS）RFC2818之上的地道化口。

　　1）Upgrade：`upgrade`是HTTP1.1中用于界说转化协议的`header`域。它标明，假如服务器支撑的话，客户端期望运用现有的「网络层」现已树立好的这个「衔接（此处是 TCP 衔接）」，切换到别的一个「运用层」（此处是 WebSocket）协议；

　　3）Sec-WebSocket-Key：用来发送给服务器运用（服务器会运用此字段组装成另一个key值放在握手回来信息里发送客户端）；

　　5）Sec-WebSocket-Version：标识了客户端支撑的WS协议的版别列表，假如服务器不支撑这个版别，有必要回应自己支撑的版别；

　　6）Origin：作安全运用，避免跨站进犯，浏览器一般会运用这个来标识原始域；

　　至于为什么需求这么一个进程，能够参阅《理论联系实践：从零了解WebSocket的通讯原理、协议格局、安全性》一文。

　　1）避免服务端收到不合法的websocket衔接（比方http客户端不小心恳求衔接websocket服务，此刻服务端能够直接回绝衔接）；

　　2）保证服务端了解websocket衔接。由于ws握手阶段选用的是http协议，因此或许ws衔接是被一个http服务器处理并回来的，此刻客户端能够经过Sec-WebSocket-Key来保证服务端知道ws协议。（并非百分百稳妥，比方总是存在那么些无聊的http服务器，光处理Sec-WebSocket-Key，但并没有完成ws协议。。。）；

　　4）能够避免反向署理（不了解ws协议）回来过错的数据。比方反向署理前后收到两次ws衔接的晋级恳求，反向署理把第一次恳求的回来给cache住，然后第2次恳求到来时直接把cache住的恳求给回来（无意义的回来）；

　　5）Sec-WebSocket-Key首要意图并不是保证数据的安全性，由于Sec-WebSocket-Key、Sec-WebSocket-Accept的转化核算公式是揭露的，而且十分简略，最首要的作用是防备一些常见的意外状况（非故意的）。

　　着重：Sec-WebSocket-Key/Sec-WebSocket-Accept的换算，只能带来根本的保证，但衔接是否安全、数据是否安全、客户端/服务端是否合法的 ws客户端、ws服务端，其实并没有实践性的保证。

　　1）FIN： 1bit，用来标明这是一个音讯的最终的音讯片断，当然第一个音讯片断也或许是最终的一个音讯片断；

　　2）RSV1，RSV2，RSV3： 别离都是1位，假如两边之间没有约好自界说协议，那么这几位的值都有必要为0,不然有必要断掉WebSocket衔接。在ws中就用到了RSV1来标明是否音讯压缩了的；

　　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)位，负载数据为扩展数据及运用数据长度之和；

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

　　相同的为什么需求掩码操作，也能够参阅之前的那篇文章：《理论联系实践：从零了解WebSocket的通讯原理、协议格局、安全性》，完好的我就不列举了。

　　WebSocket协议中，数据掩码的作用是增强协议的安全性。但数据掩码并不是为了维护数据自身，由于算法自身是揭露的，运算也不杂乱。除了加密通道自身，好像没有太多有用的维护通讯安全的办法。

　　那么为什么还要引进掩码核算呢，除了添加核算机器的运算量外好像并没有太多的收益（这也是不少同学疑问的点）。

　　答案仍是两个字： 安全。但并不是为了避免数据泄密，而是为了避免前期版别的协议中存在的署理缓存污染进犯（proxy cache poisoning attacks）等问题。

　　介绍完上一节WebSocket协议，咱们把视野转移到现代Web端即时通讯技能的第二个利器：socket.io。

　　在了解socket.io之前，咱们先聊聊传统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进行封装，然后让长衔接满意一切的场景，不过当然得合作运用对应的客户端代码。

　　经过前面章节，读者们都知道了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层完成了一个心跳机制，这样答应客户端和服务器知道什么时分其间的一方不能呼应。该功用是经过设置在服务端和客户端的定时器完成的，在衔接握手的时分，服务器会主动奉告客户端心跳的间隔时刻以及超时时刻；

　　6）支撑复用：为了在运用程序中将创立的关注点阻隔开来，Socket.io答应你创立多个namespace，这些namespace具有独自的通讯通道，但将同享相同的底层衔接；

　　7）支撑Room：在每一个namespace下，你能够界说恣意数量的通道，咱们称之为房间，你能够参加或许脱离房间，乃至播送音讯到指定的房间。

　　当时engine.io协议的版别是3，咱们依据上图来大致介绍一下engine.io协议。

　　3）t=xxxxx: 代码中运用yeast依据时刻戳生成一个仅有的字符串；

　　4）sid=xxxx: 客户端和服务器树立衔接之后获取到的session id，客户端拿到之后有必要在每次恳求中追加这个字段。

　　2）b64: 假如客户端不支撑XHR，那么客户端应该设置b64=1传给服务器，奉告服务器一切的二进制数据应该以base64编码后再发送。

　　3）2(ping): 由客户端发送的ping包，服务端有必要回应一个包含相同数据的pong包；

　　5）4(message): 实践音讯，在客户端和服务端都能够监听message事情获取音讯内容；

　　6）5(upgrade): 在engine.io切换transport之前，它会用来测验服务端和客户端是否在该transport上通讯。假如测验成功，客户端会发送一个upgrade包去让服务器改写它的缓存并切换到新的transport；

　　7）6(noop): 首要用来强制一个轮询循环当收到一个WebSocket衔接的时分。

　　1）假如当只要发送string而且不支撑XHR的时分，其编码格局是：:[:[...]]；

　　2）当不支撑XHR2而且发送二进制数据,可是运用base64编码字符串的时分，其编码格局是：:b[...]；

　　4）假如发送的内容混杂着UTF-8的字符和二进制数据，字符串的每个字符被写成一个字符编码，用1个字节标明。

　　然后服务端会奉告客户端去测验晋级到websocket，而且奉告对应的sid。

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

　　接着第二部分数据是message包类型，而且数据是0，所以是40，长度为2字节，所以是2:40，最终就拼成方才咱们看到的成果。

　　协议界说了transport晋级到websocket需求阅历一个有必要的进程。

　　WebSocket的测验开端于发送probe，假如服务器也呼应probe的话，客户端就有必要发送一个upgrade包。

　　为了保证不会丢包，只要在当时transport的一切buffer被改写而且transport被以为paused的时分才能够发送upgrade包。服务端收到upgrade包的时分，服务端有必要假定这是一个新的通道并发送一切已存的缓存到这个通道上

　　许多人或许猎奇，有了WebSocket这种实时通讯，为什么还需求SSE呢？

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

　　比方：在股票行情、新闻推送的这种只需求服务器发送音讯给客户端场景中，运用SSE或许愈加适宜。

　　别的：SSE是运用HTTP传输的，这意味着咱们不需求一个特别的协议或许额定的完成就能够运用。而WebSocket要求全双工衔接和一个新的WebSocket服务器去处理。加上SSE在规划的时分就有一些WebSocket没有的特性，比方主动重衔接、event IDs、以及发送随机事情的才能，所以各有各的专长，咱们需求依据实践运用场景，去挑选不同的运用计划。

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

　　SSE有必要编码成utf-8的格局，音讯的每个字段运用\n来做切割，而且需求下面4个标准界说好的字段。

　　4）Retry： 奉告浏览器在一切的衔接丢掉之后从头敞开新的衔接等候的时刻，在主动从头衔接的进程中，之前收到的最终一个事情流ID会被发送到服务端。

　　SSE的通讯进程比较简略，底层的一些完成都被浏览器给封装好了，包含数据的处理。

　　在开端推送信息流之前，服务器还会发送一个客户端会疏忽掉的包，这个详细原因不清楚：

　　2）由于是清晰指定用于传输UTF-8数据的，所以关于传输二进制流是低效率的，即便你转为base64的话，反而添加带宽的负载，因小失大。

　　[14]理论联系实践：从零了解WebSocket的通讯原理、协议格局、安全性

　　[17]网页端IM通讯技能快速入门：短轮询、长轮询、SSE、WebSocket

上一篇：通信网络通信网络专题全面介绍 - OFweek光通讯网 下一篇：关于通讯技能的进程介绍与6G要害技能开展