1. 历史演进概览

什么是 WebSocket？它是定义客户端和服务端如何通过 Web 进行通信的一种网络协议，该通信协议于 2011 年被 IETF（互联网工程工作组）定为规范 RFC 6455，并由 RFC7936 补充标准。

在 WebSocket 协定之前，还有几种计划可用于实现即时通信。上面将顺次介绍。

1.1 HTTP1.0/1.1

在 HTTP 1.0/1.1 中，客户端和服务端建设通信，须要通过发送申请与期待响应。因为 HTTP 是无状态的的，每一次申请和响应都须要在 header 中携带大量信息，并且因为其半双工个性，同一时间流量只能单向流动，即申请发送进来，须要始终期待响应的到来，能力做下一步的操作，肯定水平上造成了通信低效。

1.2 轮询

在须要显示股票价格走势等这一类对信息实时性要求较高的场景，如果每次都由用户手动去刷新浏览器获取最新信息，会存在显著滞后性。因而能够设定一个定时器，每个一段时间，就像服务端发送申请获取最新后果，这种办法被称为”轮询“（polling）。

如果能明确晓得服务端数据更新的距离，那么轮询是一个不错的计划。然而大部分时候，是无奈预测数据什么时候更新的，每个固定周期都发送申请查问，会产生很多不必要的申请，造成节约。

1.3 长轮询

长轮询（long polling）则是基于轮询的另一种计划，它也被称为 Comet 或者反向 AJAX。服务端收到客户端申请后，会放弃申请关上，直到有客户端可用的信息或者超时了，才返回可给客户端。这么解决绝对于一般的轮询，长处 是能够缩小不必要的申请。然而当信息更新很频繁时，长轮询绝对于一般轮询的劣势就不再显著。

1.4 HTTP Streaming

后面波及的轮询，每一次申请响应完结后，都会敞开连贯。下一次申请，客户端仍然须要在申请头中携带大量信息。而 HTTP Streaming 流化技术的实现机制是客户端发送一个申请，服务端发送一个继续更新和放弃关上的凋谢响应。每当服务端有客户端可用信息时，就更新响应，然而连贯始终保持关上。通过这种形式来躲避频繁申请带来的不必要开销。

HTTP Stream 存在的 毛病 是和灵便的全双工通信还存在着间隔，还是以单向通信为主，服务端能够自在地发数据给客户端，但客户端缺没方法。

1.5 WebSocket

WebSocket 是一种 全双工 ， 高实时 ， 双向 ，单套接字 长连贯。由一次 HTTP 申请可降级为 WebSocket 连贯，可重用客户端到服务端，服务端到客户端的同一连贯。它和 HTTP 同属于计算机网络七层模型的应用层，基于 TCP 传输，二者的差异性如下。

2. 连贯治理

WebSocket 协定的具体运作次要分为三局部：握手建设连贯 ， 数据传输 ， 敞开连贯。

2.1 握手建设

2.1.1 HTTP 申请降级

在上方图中能够看到 WebSocket 连贯建设的大抵流程为一次 HTTP 的申请与响应，而后便可建设连贯。

初始阶段客户端客户端发送 HTTP Upgrade Request，在 Request Header 中告知服务端将降级为 WebSocket。

其中红色字段为必选。

握手建设一开始由客户端发送一个 HTTP 申请，在 Header 中携带信息告知服务端降级为 WebSocket。其中红色和绿色为必选信息。

Connection 告知服务端为长连贯，且须要降级
Upgrade 告知服务端降级为 WebSocket。
Sec-WebSocket-Version 指定应用的 WebSocket 版本，个别是应用最新的版本，具体有哪些版本，能够参考这里 WebSocket 版本，以后最新版本为 13，所以这里指定该字段的值为 13。

Sec-WebSocket-Key 是一个必选字段，它是一个随机数。这个字段次要和前面服务端返回的Sec-WebSocket-Accept 配套应用，缩小一些歹意连贯和意外连贯。前面会具体介绍

2.1.2 Server response

服务端响应

Sec-WebSocket-Accept 是基于客户端传递的 Sec-WebSocket-Key 计算而来。它有一个公开的算法

首先将 Sec-WebSocket-Key 和一个固定的字符串常量 GUID 拼接起来。

拼接后的字符串通过 SHA1 计算，并转成 Base64 编码，即为Sec-WebSocket-Accept 值。

算法都是公开的，这种解决形式并不是为了加密以保障数据安全。它次要是为了缩小一些意外和歹意连贯，更具体的可概括为如下：

1. 前端应用 Ajax 发送申请时，申请头中是无奈设置 Sec-WebSocket-Key 字段的，这样子能够防止 应用 Ajax 发送 HTTP 申请时意外降级为 WebSocket。
2. 客户端通过辨认 Sec-WebSocket-Accept 是否计算正确，确保晓得服务端已了解 WebSocket 协定(也会有意外，比方服务端单纯计算了Sec-WebSocket-Accept，但没有做具体的 WebSocket 相干操作)。

2.2 音讯传输

Message 音讯 ：一条音讯（message）可由一个或多个帧(Frame) 组成，很多时候会将帧和音讯混用，因为大部分时候一条音讯只应用一个帧。

一个帧的形成如下

FIN 示意音讯的结尾，FIN = 1 即这条音讯完结了。

RSV1, RSV2, RSV3 个别为都为 0。

opcode示意操作码，它由 4 个 bit 组成，即在 16 进制中取值范畴 0~F。它的对应取值如下

0：示意这是一个持续性，一条音讯由多个帧组成，这是其中一个帧。

1：音讯数据类型为文本。（这条音讯蕴含的帧都是文本类型）

2：音讯数据类型为二进制。（这条音讯蕴含的帧都是二进制类型）

8：客户端或服务端向对方发送敞开握手

9：客户端或服务端向对方发送 ping

A：客户端或服务端向对方发送 pong

B~F：为保留操作码。

上图一条音讯由 3 个帧形成，从左往右顺次的法则为：
左 FIN = 0，opcode = 1，示意这是一个文本帧，音讯还没完结
中 FIN = 0, opcode = 0，这是一个继续帧，音讯还没完结
右 FIN = 1，opcode，音讯完结，这是该音讯最初一帧了。

如果一条音讯只有一个帧组成，那么 opcode 取值必然大于 0，FIN 的值固定为 1。

Payload len: 用于示意数据长度，一共 7 位，即取值范畴能够是 0~ 2^7(127)。
数据长度小于等于 125 字节，则应用红色圈出的区域即可，残余的 Extened payload 不应用。
数据长度 126~2^16-1 字节，Payload len值为 126。
数据长度 2^16 ~ 2^64-1，Payload len 值为 127。

2.3 心跳治理

通信双端之间须要通过心跳确保对方还处于连贯状态，心跳实质上也是一条音讯，它含有一个心跳帧。如果辨认心跳帧？基于opcode。
opcode = 9：这是一个 ping，能够和一般的帧一样携带数据。
opcode = A：这是一个 pong (当一端收到 ping 之后，会回复一个 pong 给对方，且必须与 ping 数据雷同)。

2.4 敞开连贯

WebSocket 是基于 TCP 的，须要先敞开下层 WebSocket 连贯，才会敞开 TCP。

要敞开 WebSocket 连贯时，A 端 一个 opcode = 8 的敞开帧发送给对方。敞开帧能够携带数据，阐明连贯敞开的起因。发送敞开帧后，进入 closing 状态，此时能够承受数据，然而无奈发送。B 端收到敞开帧后，会回复一个敞开帧，此时不再承受任何音讯。A 端收到回复后，进入 closed 状态，此时 WebSocket 彻底敞开。

敞开帧的 payload 数据前 2 个字节能够示意敞开会话的起因。

参考资料

https://tools.ietf.org/html/r…
https://time.geekbang.org/cou…
https://en.wikipedia.org/wiki…
https://www.iana.org/assignme…
https://www.cnblogs.com/chyin…
http://www.adambarth.com/pape…
http://websocket.org/quantum….
https://halfrost.com/websocket/
https://sookocheff.com/post/n…
《HTML5 WebSocket 权威指南》