websocket使用指南

前言

最近在一个项目中，需要使用到websocket，之前对websocket不是很了解，于是就花了一点时间来熟悉websocket。

在浏览器与服务器通信间，传统的 HTTP 请求在某些场景下并不理想，比如实时聊天、实时性的小游戏等等，

其面临主要两个缺点：

1. 无法做到消息的「实时性」；
2. 服务端无法主动推送信息；

其基于 HTTP 的主要解决方案有：

1. 基于 ajax 的轮询：客户端定时或者动态相隔短时间内不断向服务端请求接口，询问服务端是否有新信息；其缺点也很明显：多余的空请求（浪费资源）、数据获取有延时；

2. Long Poll：其采用的是阻塞性的方案，客户端向服务端发起 ajax 请求，服务端挂起该请求不返回数据直到有新的数据，客户端接收到数据之后再次执行 Long Poll；该方案中每个请求都挂起了服务器资源，在大量连接的场景下是不可接受的；

可以看到，基于 HTTP 协议的方案都包含一个本质缺陷 —— 「被动性」，服务端无法下推消息，仅能由客户端发起请求不断询问是否有新的消息，同时对于客户端与服务端都存在性能消耗。

WebSocket 是 HTML5 开始提供的一种浏览器与服务器间进行全双工通讯的网络技术。 WebSocket 通信协议于2011年被IETF定为标准RFC 6455，WebSocketAPI 被 W3C 定为标准。 在 WebSocket API 中，浏览器和服务器只需要要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。

WebSocket 是 HTML5 中提出的新的网络协议标准，其包含几个特点：

1. 建立于 TCP 协议之上的应用层；
2. 一旦建立连接（直到断开或者出错），服务端与客户端握手后则一直保持连接状态，是持久化连接；
3. 服务端可通过实时通道主动下发消息；
4. 数据接收的「实时性（相对）」与「时序性」；

实践

在浏览器中使用 Websocket 非常简单，在支持 Websocket 的浏览器中提供了原生的 WebSocekt 对象，其中对于消息的接收与数据帧处理在浏览器中已经封装好了。

以下将用一个简单的例子解释如何使用 WebSocekt；

浏览器中提供了原生类 WebSocket ，使用 new 关键字实例化它：

WebSocket WebSocket(String url,optional String | [] protocols);

接收两个参数：

1. url 表示需要连接的地址，比如：ws://localhost:8080；
2. protocols 可选参数，可以是一个字符串或者一个数组，用来表示子协议，这样做可以让一个服务器实现多种 WebSocket 子协议；

实例化对象提供两个方法：

1. send 接收一个 String|ArrayBuffer|Blob 数据，作为数据发送到服务端；
2. close 接收一个（可选）的 code（关闭状态号，默认为 1000） 与一个（可选）的字符串（表示断开原因），客户端主动断开连接；

连接状态：

1. WebSocket 类提供了一些常量表示连接状态：

2. WebSocket.CONNECTING 0 连接还没开启；

3. WebSocket.OPEN 1 连接已开启并准备好进行通信；

4. WebSocket.CLOSING 3 连接正在关闭的过程中；

5. WebSocket.CLOSED 4 连接已经关闭，或者连接无法建立；

6. WebSocket 的实例对象中提供了 readyState 属性来判断当前状态；

实例化对象中可以监听到以下事件：

1. open 连接打开的回调事件，这时 readyState 变为 OPEN；
2. message 收到消息的回调事件，同时回调函数接收到一个 MessageEvent 数据；
3. close 连接关闭的回调事件，这时 readyState 变为 CLOSED；
4. error 建立与连接过程发生错误的回调事件；

代码实现

const ws = new WebSocket('ws://localhost:8080');

let sendTimmer = null;
let sendCount = 0;

ws.onopen = function () {
  console.log('@open');

  sendCount++;
  ws.send('Hello Server!' + sendCount);

  sendTimmer = setInterval(function () {
    sendCount++;
    ws.send('Hi Server!' + sendCount);

    if (sendCount === 10) {
      ws.close();
    }
  }, 2000);
};

ws.onmessage = function (e) {
  console.log('@message');
  console.log(e.data);
};

ws.onclose = function () {
  console.log('@close');
  sendTimmer && clearInterval(sendTimmer);
};

ws.onerror = function () {
  console.log('@error');
};

控制台可以看到

@open
@message
Hello Client
@message
received: Hello Server!1(From Server)
@message
received: Hi Server!2(From Server)
@message
received: Hi Server!3(From Server)
@message
received: Hi Server!4(From Server)
@message
received: Hi Server!5(From Server)
@message
received: Hi Server!6(From Server)
@message
received: Hi Server!7(From Server)
@message
received: Hi Server!8(From Server)
@message
received: Hi Server!9(From Server)
@close

首先触发 open 事件，之后每次发送数据服务端都会回复数据，因此触发了 message 事件，当发送 10 次之后浏览器主动断开连接，因此触发 close 事件；这里最后一次发送之后未收到服务端回复也是因为客户端立即断开了连接；

当然，更具体的数据交互可以从 network 看到；

事件与数据

对 WebSocket 实例监听事件有两种方式，这里以 message 事件为例：

1. 对 onmessage 属性直接赋值，正如以上： ws.onmessage = function () {};
2. 使用 addEventListener 监听事件，如： ws.addEventListener('message', function () {})；

在 message 回调函数中得到 MessageEvent 类型参数 e ，我们需要的数据可以通过 e.data 获取；

需要注意的一点是：不论服务端与客户端，其接受到的数据都是序列化后的字符串（当然也有 ArrayBuffer|Blob 类型数据），很多时候我们需要解析处理数据，比如 JSON.parse(e.data)；

连接稳定性

由于网络环境复杂，某些情况会出现断开连接或者连接出错，需要我们在 close 或者 error 事件中监听非正常断开并重连；

由于一些原因在 error 时浏览器并不会响应回调事件，因此稳妥的做法还需要在 open 之后开启一个定时任务去判断当前的连接状态 readyState ，在出现异常情况下尝试重连；

心跳

websocket规范定义了心跳机制，一方可以通过发送ping（opcode 0x9）消息给另一方，另一方收到ping后应该尽可能快的返回pong（0xA）。

心跳机制是用于检测连接的对方在线状态，因此如果没有心跳，那么无法判断一方还在连接状态中，一些网络层比如 nginx 或者浏览器层会主动断开连接，

在 JavaScript 中，WebSocket 并没有开放 ping/pong 的 API ，虽然浏览器自带了心跳处理，然而不同厂商的实现也不尽相同，因此需要在我们开发时候与服务端约定好一个自实现的心跳机制；

比如浏览器中，检测到 open 事件后，启动一个定时任务，每次发送数据 0x9 给服务端，而服务端返回 0xA 作为响应；

实践下来，心跳的定时任务一般是相隔 15-20 秒发送一次。

网络协议

前文说到，Websocket 是建立与 TCP 之上，那么其与 HTTP 协议有和关系呢？

Websocket 连接分为建连阶段与连接阶段，在建立连接阶段借助于 HTTP ，而在连接阶段则与 HTTP 无关。

建连阶段

从浏览器的 Network 中，找到 ws 连接，可以看到：

General
Request URL:ws://localhost:8080/
Request Method:GET
Status Code:101 Switching Protocols

Response Headers
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: py9bt3HbjicUUmFWJfI0nhGombo=

Request Headers
GET ws://localhost:8080/ HTTP/1.1
Host: localhost:8080
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://localhost:8080
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,zh-TW;q=0.7,la;q=0.6,ja;q=0.5
Sec-WebSocket-Key: 2idFk3+96Hs5hh+c9GOQCg==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

这是一个标准的 HTTP 请求，相比于我们常见的 HTTP 请求协议，请求头中多了几个字段：

Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: 2idFk3+96Hs5hh+c9GOQCg==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

Connection 为 Upgrade ，Upgrade 为 websocket ，表示告知 Nginx 与 Apache 等服务器该次连接并非为 HTTP 连接，实质上是一个 websocket ，因此服务器会转发到相应的 websocket 任务处理；

Sec-WebSocket-Key 是一个 Base64 encode 的值，由浏览器随机生成的，用于验证服务器连接的正确性；

Sec-WebSocket-Versio 表示为使用的 websocket 服务版本；

响应头中：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: py9bt3HbjicUUmFWJfI0nhGombo=

可以看到其返回状态码为 101 ，表示切换协议；

Upgrade 与 Connection 用于回复客户端表示已经切换协议成功；

Sec-WebSocket-Accept 字段与 Sec-WebSocket-Key 相对应，用于验证服务的正确性；

连接阶段

当通过 HTTP 建立连接握手后，接下来则是真正的 Websocket 连接了，其基于 TCP 收发数据，Websocket 封装并开放接口。

WSS

在 HTTP 协议中，很多时候为了加密与安全需要使用 HTTPS 请求（HTTP + TCL）；

相应的，在 Websocket 协议中，也是可以使用加密传输的 —— wss ，比如 wss://localhost:8080。

使用的也是与 HTTPS 一样的证书，在这里一般是交由 Nginx 等服务层去做证书处理。

本文参考文章: https://qiutc.me/post/websocket-guide.html