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 类提供了一些常量表示链接状态：

   1. WebSocket.CONNECTING 0 链接还没开启；
   2. WebSocket.OPEN 1 链接已开启并准备好进行通讯；
   3. WebSocket.CLOSING 3 链接正在关闭的过程当中；
   4. WebSocket.CLOSED 4 链接已经关闭，或者链接没法创建；

2. 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 等服务层去作证书处理。