WebSocket 协议详解
一、WebSocket 协议背景
早期，在网站上推送消息给用户，只能通过轮询的方式或 Comet 技术。轮询就是浏览器每隔几秒钟向服务端发送 HTTP 请求，然后服务端返回消息给客户端。
轮询技术一般在浏览器上就是使用 setInerval 或 setTimeout
这种方式的缺点：
需要不断的向服务端发送 HTTP 请求，这种就比较浪费带宽资源。而且发送 HTTP 请求只能由客户端发起，这也是早期 HTTP1.0/1.1 协议的一个缺点。它做不到由服务端向客户端发起请求。
为了能实现客户端和服务端的双向通信，经过多年发展于是 WebSocket 协议在 2008 年就诞生了。
它最初是在 HTML5 中引入的。经过多年发展后，该协议慢慢被多个浏览器支持，RFC 在 2011 年就把该协议作为一个国际标准，叫 rfc6455。
HTTP1.0 协议有个性质：它是一个无状态的协议。客户端每次发起一个请求，然后服务端回复一个请求，这次连接就会关闭。客户端断开与服务端的连接。而 WebSocket 协议不会关闭。
HTTP1.1 协议加了一个 Keep-Alive 的属性，这个不能看作是一个长连接，它是对 TCP 连接的设置使用，是对这一次的连接存活最大时间设置。在这次存活时间内可以继续发送 HTTP 消息。对于这个属性每个服务器有一个默认超时时间，最终还是会关闭。而 WebSocket 协议是一个长连接，虽然它也是建立在 TCP 之上，但是它通过 HTTP 协议握手成功后，成为 WebSocket 协议，之后交互数据不需要发送 HTTP Header 和 HTTP Request 数据，WebSocket 有自己的数据编码协议。WebSocket 协议本身也对探测服务端是否存活作了规定，详细情况请看下面的内容。
简单图解对比下 2 个协议交互情况：
二、协议简介
WebSocket 是一种支持双向通信的网络协议。
- 双向通信：客户端（比如浏览器）可以向服务端发送消息，服务端也可以主动向客户端发送消息。
这样就实现了客户端和服务端的双向通信，那么上面所说的消息推送就比较容易实现了。
原先的 HTTP1.0/1.1 只能是客户端向服务端发送消息。
协议特点：
- 建立在 TCP 协议之上。
- WebSocket 协议是从 HTTP 协议升级而来。
- 与 HTTP 协议良好兼容新。默认端口是 80 和 443，握手阶段采用 HTTP 协议。
- 数据格式比较轻量，通信效率高，性能开销小。
- 可以发送文本，也可以发送二进制数据。
- 没有同源限制，客户端可以与任意服务端通信。
- 协议标识符是 ws（如果加密，则为 wss），服务器网址就是 URL。
- 可以支持扩展，定了扩展协议。
- 保持连接状态，websocket 是一种有状态的协议，通信就可以省略部分状态信息。
- 实时性更强，因为是双向通信协议，所以服务端可以随时向客户端发送数据。
三、HTTP 升级到 WebSocket 过程
WebSocket 协议建立复用了 HTTP 的握手请求过程。
客户端通过 HTTP 请求与 WebSocket 服务端协商升级协议。协议完成后，后续的数据交互则遵循 WebSocket 的协议。
- 客户端发起协议升级请求
GET / HTTP/1.1
Host: localhost:8080
Origin: http://127.0.0.1:3000
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw==
说明：上面请求信息忽略了 HTTP 的一些非必要头部请求信息，剔除多余的干扰。
- Origin: http://127.0.0.1:3000 ： 原始的协议和URL
- Connection: Upgrade：表示要升级协议了
- Upgrade: websocket：表示要升级到 WebSocket 协议；
- Sec-WebSocket-Version: 13：表示 WebSocket 的版本。如果服务端不支持该版本，需要返回一个
Sec-WebSocket-Versionheader，里面包含服务端支持的版本号 - Sec-WebSocket-Key：与后面服务端响应首部的 Sec-WebSocket-Accept 是配套的，提供基本的防护，比如恶意的连接，或者无意的连接
- 服务端响应协议升级
HTTP/1.1 101 Switching Protocols
Connection:Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: Oy4NRAQ13jhfONC7bP8dTKb4PTU=
-
HTTP/1.1 101 Switching Protocols： 状态码 101 表示协议切换
-
Sec-WebSocket-Accept：根据客户端请求首部的 Sec-WebSocket-Key 计算出来
将 Sec-WebSocket-Key 跟 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 拼接。
通过 SHA1 计算出摘要，并转成 base64 字符串。计算公式如下：
Base64(sha1(Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11)) -
Connection:Upgrade：表示协议升级
-
Upgrade: websocket：升级到 websocket 协议
四、WebSocket 数据交换
数据帧格式
在 WebSocket 协议中，客户端与服务端数据交换的最小信息单位叫做帧（frame），由 1 个或多个帧按照次序组成一条完整的消息（message）。
数据传输的格式是由 ABNF 来描述的。
WebSocket 数据帧的统一格式如下图：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+
（https://www.rfc-editor.org/rfc/rfc6455.html#section-5.2 Base Framing Protocol）
上面图中名词解释：
| 名词 | 说明 | 大小 |
|---|---|---|
| FIN | 如果是 1，表示这是消息（message）的最后一个分片（fragment）；如果是 0，表示不是是消息（message）的最后一个分片（fragment） | 1 个比特 |
| RSV1, RSV2, RSV3 | 一般情况下全为 0。当客户端、服务端协商采用 WebSocket 扩展时，这三个标志位可以非 0，且值的含义由扩展进行定义。如果出现非零的值，且并没有采用 WebSocket 扩展，连接出错 | 各占 1 个比特 |
| opcode | 操作代码，Opcode 的值决定了应该如何解析后续的数据载荷（data payload）。如果操作代码是不认识的，那么接收端应该断开连接（fail the connection） | 4 个比特 |
| mask | 表示是否要对数据载荷进行掩码操作。从客户端向服务端发送数据时，需要对数据进行掩码操作；从服务端向客户端发送数据时，不需要对数据进行掩码操作。 如果服务端接收到的数据没有进行过掩码操作，服务端需要断开连接。 如果 Mask 是 1，那么在 Masking-key 中会定义一个掩码键（masking key），并用这个掩码键来对数据载荷进行反掩码。所有客户端发送到服务端的数据帧，Mask 都是 1。 |
1 个比特 |
| Payload length | 数据载荷的长度，单位是字节。假设数 Payload length === x，如果： x 为 0~126：数据的长度为 x 字节。 x 为 126：后续 2 个字节代表一个 16 位的无符号整数，该无符号整数的值为数据的长度。 x 为 127：后续 8 个字节代表一个 64 位的无符号整数（最高位为 0），该无符号整数的值为数据的长度。 此外，如果 payload length 占用了多个字节的话，payload length 的二进制表达采用网络序（big endian，重要的位在前）。 |
为 7 位，或 7+16 位，或 1+64 位。 |
| Masking-key | 所有从客户端传送到服务端的数据帧，数据载荷都进行了掩码操作，Mask 为 1，且携带了 4 字节的 Masking-key。如果 Mask 为 0，则没有 Masking-key。 备注：载荷数据的长度，不包括 mask key 的长度。 |
0 或 4 字节（32 位 |
| Payload data | 载荷数据：包括了扩展数据、应用数据。其中，扩展数据 x 字节，应用数据 y 字节。The "Payload data" is defined as "Extension data" concatenated with "Application data". 扩展数据：如果没有协商使用扩展的话，扩展数据数据为 0 字节。所有的扩展都必须声明扩展数据的长度，或者可以如何计算出扩展数据的长度。此外，扩展如何使用必须在握手阶段就协商好。如果扩展数据存在，那么载荷数据长度必须将扩展数据的长度包含在内。 应用数据：任意的应用数据，在扩展数据之后（如果存在扩展数据），占据了数据帧剩余的位置。载荷数据长度 减去 扩展数据长度，就得到应用数据的长度。 |
(x+y) 字节 |
表中 opcode 操作码：
- %x0：表示一个延续帧（continuation frame）。当 Opcode 为 0 时，表示本次数据传输采用了数据分片，当前收到的数据帧为其中一个数据分片。
- %x1：表示这是一个文本帧（frame），text frame
- %x2：表示这是一个二进制帧（frame），binary frame
- %x3-7：保留的操作代码，用于后续定义的非控制帧。
- %x8：表示连接断开。connection close
- %x9：表示这是一个 ping 操作。a ping
- %xA：表示这是一个 pong 操作。a pong
- %xB-F：保留的操作代码，用于后续定义的控制帧。
数据帧另外一种表达方式
ws-frame = frame-fin ; 1 bit in length
frame-rsv1 ; 1 bit in length
frame-rsv2 ; 1 bit in length
frame-rsv3 ; 1 bit in length
frame-opcode ; 4 bits in length
frame-masked ; 1 bit in length
frame-payload-length ; either 7, 7+16,
; or 7+64 bits in
; length
[ frame-masking-key ] ; 32 bits in length
frame-payload-data ; n*8 bits in
; length, where
; n >= 0
frame-fin = %x0 ; more frames of this message follow
/ %x1 ; final frame of this message
; 1 bit in length
frame-rsv1 = %x0 / %x1
; 1 bit in length, MUST be 0 unless
; negotiated otherwise
frame-rsv2 = %x0 / %x1
; 1 bit in length, MUST be 0 unless
; negotiated otherwise
frame-rsv3 = %x0 / %x1
; 1 bit in length, MUST be 0 unless
; negotiated otherwise
frame-opcode = frame-opcode-non-control /
frame-opcode-control /
frame-opcode-cont
frame-opcode-cont = %x0 ; frame continuation
frame-opcode-non-control= %x1 ; text frame
/ %x2 ; binary frame
/ %x3-7
; 4 bits in length,
; reserved for further non-control frames
frame-opcode-control = %x8 ; connection close
/ %x9 ; ping
/ %xA ; pong
/ %xB-F ; reserved for further control
; frames
; 4 bits in length
frame-masked = %x0
; frame is not masked, no frame-masking-key
/ %x1
; frame is masked, frame-masking-key present
; 1 bit in length
frame-payload-length = ( %x00-7D )
/ ( %x7E frame-payload-length-16 )
/ ( %x7F frame-payload-length-63 )
; 7, 7+16, or 7+64 bits in length,
; respectively
frame-payload-length-16 = %x0000-FFFF ; 16 bits in length
frame-payload-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF
; 64 bits in length
frame-masking-key = 4( %x00-FF )
; present only if frame-masked is 1
; 32 bits in length
frame-payload-data = (frame-masked-extension-data
frame-masked-application-data)
; when frame-masked is 1
/ (frame-unmasked-extension-data
frame-unmasked-application-data)
; when frame-masked is 0
frame-masked-extension-data = *( %x00-FF )
; reserved for future extensibility
; n*8 bits in length, where n >= 0
frame-masked-application-data = *( %x00-FF )
; n*8 bits in length, where n >= 0
frame-unmasked-extension-data = *( %x00-FF )
; reserved for future extensibility
; n*8 bits in length, where n >= 0
frame-unmasked-application-data = *( %x00-FF )
; n*8 bits in length, where n >= 0
客户端到服务端的掩码算法
https://www.rfc-editor.org/rfc/rfc6455.html#section-5.3 Client-to-Server Masking
掩码键（Masking-key）是由客户端挑选出来的 32 位的随机数。掩码操作不会影响数据载荷的长度。掩码、反掩码操作都采用如下算法：
举例说明：
Octet i of the transformed data ("transformed-octet-i") is the XOR of octet i of the original data ("original-octet-i") with octet at index i modulo 4 of the masking key ("masking-key-octet-j"): j = i MOD 4 transformed-octet-i = original-octet-i XOR masking-key-octet-j
- original-octet-i：为原始数据的第 i 字节。
- transformed-octet-i：为转换后的数据的第 i 字节。
- j：为i mod 4的结果。
- masking-key-octet-j：为 mask key 第 j 字节。
算法描述为： original-octet-i 与 masking-key-octet-j 异或后，得到 transformed-octet-i。
j = i MOD 4
transformed-octet-i = original-octet-i XOR masking-key-octet-j
数据分片
分片的目的：
- 有了消息分片，发送一个消息的时候，就可以发送未知大小的信息。如果消息不能被分片，那么就不得不缓冲整个消息，以便计算长度。而有了分片就可以选择合适大小缓冲区来缓冲分片。
- 第二个目的是可以使用多路复用。
WebSocket 的每条消息（message）可能被切分为多个数据帧。
当 WebSocket 的接收方接收到一个数据帧时，会根据 FIN 值来判断是否收到消息的最后一个数据帧。
从上图可以看出，FIN = 1 时，表示为消息的最后一个数据帧；FIN = 0 时，则不是消息的最后一个数据帧，接收方还要继续监听接收剩余数据帧。
opcode 表示数据传输的类型，0x01 表示文本类型的数据；0x02 表示二进制类型的数据；0x00 比较特殊，表示延续帧（continuation frame），意思就是完整数据对应的数据帧还没有接收完。
更多分片内容请看这里：https://www.rfc-editor.org/rfc/rfc6455.html#section-5.4
消息分片example：
Client: FIN=1, opcode=0x1, msg="hello"
Server: (process complete message immediately) Hi.
Client: FIN=0, opcode=0x1, msg="and a"
Server: (listening, new message containing text started)
Client: FIN=0, opcode=0x0, msg="happy new"
Server: (listening, payload concatenated to previous message)
Client: FIN=1, opcode=0x0, msg="year!"
Server: (process complete message) Happy new year to you too!
(具体例子见：https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers)
五：怎么保持连接
在第二小结中我们介绍了 websocket 的特点，其中有一个是保持连接状态。
websocket 是建立在 tcp 之上，那也就是客户端与服务端的 tcp 通道要保持连接不断开。
怎么保持呢？可以用心跳来实现。
其实 websocket 协议早就想到了，它的帧数据格式中有一个字段 opcode，定义了 2 种类型操作， ping 和 pong，opcode 分别是 0x9、0xA。
说明：对于长时间没有数据往来的连接，如果依旧长时间保持连接的状态，那么就会浪费连接资源。
[完]
