JS实时通信三把斧系列之二: socket.io

刺骨的言语ヽ痛彻心扉 2021-06-26 16:06 941阅读 0赞

介绍完上一篇文章`websocket`,我们把视线转移到第二个RTC利器：`socket.io`。估计有童鞋就会问，`websocket`和`socket.io`有啥区别啊？

在了解`socket.io`之前，我们先聊聊`websocket`(长连接)的实现背景。

## 1、长连接的实现背景 ##

在现实产品中，并不是所有的客户端都支持长连接的，或者换句话说，在`websocket`协议出来之前，是有两种方式去实现`websocket`类似的功能的。

1.  `Flash`： 使用Flash是一种简单的方法。不过很明显的缺点就是Flash并不会安装在所有客户端上，比如iPhone/iPad。
2.  `AJAX Long-Polling`:AJAX长轮询已经被用来模拟`websocket`有一段时间了。这是一种有效的技术，但并没有对消息发送进行优化。虽然我不会把`AJAX`长轮询当做一种`hack`技术，但它确实不是一个最优方法

那么如果单纯地使用`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的实际应用是怎样的，需要注意些什么？

如果有童鞋对上述问题已经清楚，想必就没有往下读的必要了。

## 2、`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下，你可以定义任意数量的通道，我们称之为"房间"，你可以加入或者离开房间，甚至广播消息到指定的房间。

**Note**

> `Socket.IO`不是`websocket`的实现，虽然 `Socket.IO`确实在可能的情况下会去使用`Websocket`作为一个`transport`，但是它添加了很多元数据到每一个报文中：报文的类型以及namespace和ack Id。这也是为什么`websocket`客户端不能够成功连接上 [Socket.IO][] 服务器，同样一个 [Socket.IO][] 客户端也连接不上Websocket服务器的原因。

## 3、`engine.io`协议的介绍 ##

完整的`engine.io`协议的握手过程如下图：  
![在这里插入图片描述][20190811214555176.png]  
当前`engine.io`协议的版本是3，我们根据上图来大致介绍`engine.io`协议

### 3.1、协议请求字段 ###

我们看到的是请求的`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`了

### 3.2、数据包编码要求 ###

`engine.io`协议的数据包编码有自己的一套格式，在协议介绍上`engine.io-protocol`,定义了两种编码类型：

1.  packet
2.  payload

#### 3.2.1、`packet` ####

一个编码过的`packet`是下面这种格式：

<packet type 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连接的时候

#### 3.2.2、`payload` ####

那`payload`也有对应的格式要求：

1.  如果当只有发送`string`并且不支持`XHR`的时候，其编码格式是：`<length1>:<packet1>[<length2>:<packet2>[...]]`
2.  当不支持`XHR2`并且发送二进制数据,但是使用`base64`编码字符串的时候，其编码格式是：`<length of base64 representation of the data + 1 (for packet type)>:b<packet1 type><packet1 data in b64>[...]`
3.  当支持XHR2的时候，所有的数据都被编码成二进制，格式是：`<0 for string data, 1 for binary data><Any number of numbers between 0 and 9><The number 255><packet1 (first type, then data)>[...]`
4.  如果发送的内容混杂着UTF-8的字符和二进制数据，字符串的每个字符被写成一个字符编码，用1个字节表示。

**TIPS: `payload`的编码要求不适用于`websocket`的通信**

针对上面的编码要求，我们随便举个例子，之前在第一条polling请求的时候，服务端编码发送了这个数据：

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

根据上面的知识，我们知道第一次服务端会发送一个`open`的数据包，所以组装出来的`packet`是：

然后服务端会告知客户端去尝试升级到`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，最后就拼成刚才大家看到的结果。

Tips

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

### 3.3、升级协议的必备过程 ###

协议定义了`transport`升级到`websocket`需要经历一个必须的过程，如下图：  
![在这里插入图片描述][20190812222349440.png]`websocket`的测试开始于发送`probe`，如果服务器也响应`probe`的话，客户端就必须发送一个`upgrade`包。

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

在`Chrome`上的效果如下：  
![在这里插入图片描述][20190812222633736.png]

## 4、`engine.io`的代码实现 ##

熟悉了`engine.io`协议之后，我们看看代码是怎么实现主流程的。

客户端的`engine.io`的主要实现流程我们在上面文字介绍了，结合代码`engine.io`,画了这么一个客户端流程图：  
![在这里插入图片描述][20190812222859448.png]服务端的代码和客户端非常相似，其实现流程图如下：  
![在这里插入图片描述][20190812223024129.png]

## 5、`socket.io`的应用以及坑 ##

### 5.1、搭配`nginx`使用 ###

在实际应用中，`socket.io`服务器都会部署在`nginx`后面，所以我们需要配置`nginx`几个配置：

1.  需要添加下面两行配置：
    
        proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection "Upgrade";

如果有多个实例启动的话，需要保证某个ip连接到某个实例之后，一直保持和该实例的连接，而不是被负载均衡随机分配实例，还需要配置下面一行：

upstream { 
      ip_hash; // 主要这行，该行还必须在ip:port之前，否则会有警告出现
      ip:port;
      ip:port;
      ....
    }

二者有任何一个没有配置，客户端都会出现下图中类似的错误：  
![在这里插入图片描述][20190812223704436.png]

### 5.2、`io.use`中间件的诡异行为 ###

在实际应用中发现如下注释的行为，请参考demo代码io.js

// socket.io这边有个很奇怪的，如果我使用io.use的话，那么只有连接根ns的客户端才会收到这个错误的packet
    // 而不会让某个ns的客户端收到，但是这个中间件的函数却是监听所有的socket的。
    
    io.use((socket, next) => { 
      console.log('middleware has triggered.......')
      // if (socket.request.headers.cookie) return next();
      next(new Error('Authentication error'));
    })

现象： 在页面中点击**连接到根ns，测试服务端的根中间件的问题**按钮是会收到错误消息，但是点击其他ns却不会收到错误消息。

虽然每个ns下是有提供了ns的中间件，但是我们更希望有一个普遍的中间件去使用，但是很明显socket.io目前是没有这样实现的。关于这个问题如果也影响了大家的实现的话，这个只能改动源码，具体改哪里，童鞋们自行去思考吧。

### 5.3、根`ns` ###

另外需要注意的是，使用`socket.io`的话，是有默认的`namespace(/)`，所以无论客户端连接的`ns`是哪一个，都会先进入根`ns`的，并且会记录下这个客户端的。换句话说，如果你有2个客户端连接`ns1`，3个客户端连接`ns2`的话，那么在/下就会有5个客户端，并且在根`ns`下监听`connection`事件也是会进入的。

[socket.io]: https://github.com/socketio/socket.io
[Socket.IO]: http://Socket.IO
[20190811214555176.png]: /images/20210626/ea0dabeaf18b4177ac7f4e3a3b0c68d0.png
[20190812222349440.png]: /images/20210626/5d331f54bfaf4033a7c3558794c2b5bd.png
[20190812222633736.png]: /images/20210626/01bf48adeb9848f1a9fb49dc554109d9.png
[20190812222859448.png]: /images/20210626/b8119f37f9864b06b7eda6b0155a92da.png
[20190812223024129.png]: /images/20210626/04c50171a9994e848b6b74e70763fa9f.png
[20190812223704436.png]: /images/20210626/2d1274f44ad24a918e9454ffeb5c8d17.png