文章目录
题引开篇
有了HTTP，为什么还要用WebSocket呢？
WebSocket
WebSocket概述
WebSocket是基于TCP的轻量级网络通信协议，地位上与HTTP是对等的。
WebSocket的诞生是为了解决HTTP的缺陷。在学HTTP2的时候，以及优化了HTTP的某些缺陷了，如队首阻塞问题，而WebSocket主要是优化”请求-应答“通信模式的问题。
那“请求-应答”的通信模式有什么问题呢？
“请求-应答”模式存在的问题
- “请求-应答”采用的是“半双工”通道，同一时刻只能有一个动作，传输效率低。
- “半双工”通道使得HTTP的服务器只能“被动"响应客户端的请求，无法主动向客户端发送数据。
这就导致HTTP难以应用在动态页面、即时消息、网路游戏等要求“实时通信”的领域。
在WebSocket出现之前，浏览器一般使用轮询polling的方式，不停地向服务器发送HTTP请求，如果轮询的频率比较高，那么也可以看作近似“实时通信”的效果。
WebSocket的特点
WebSocket的特点主要有三个：
- “全双工”通道
- 二进制帧结构
- 服务发现
"全双工"通道
这个好像没什么好说的，就是全双工，使得实时通信的效率更高了。
二进制帧结构
WebSocket的语法、语义和HTTP完全不一样。
WebSocket的头部有四部分组成：
- 结束标志位
- 操作码
- 帧长度
- 掩码
具体可以看看下面这张帧结构图：
- FIN：消息结束的标志位，相当于 HTTP/2 里的“END_STREAM”，表示数据发送完毕。一个消息可以拆成多个帧，接收方看到“FIN”后，就可以把前面的帧拼起来，组成完整的消息。
- RSV：保留位，目前没有任何意义，但三个位置必须都是 0。
- Opcode：操作码，其实就是帧类型，比如 1 表示帧内容是纯文本，2 表示帧内容是二进制数据，8 是关闭连接，9 和 10 分别是连接保活的 PING 和 PONG。
- MASK：表示帧内容是否使用异或操作（xor）做简单的加密。目前的 WebSocket 标准规定，客户端发送数据必须使用掩码，而服务器发送则必须不使用掩码。
- Payload len：表示帧内容的长度。它是另一种变长编码，最少 7 位，最多是 7+64 位，也就是额外增加 8 个字节，所以一个 WebSocket 帧最大是 2^64。
- Masking-key：掩码密钥，它是由上面的标志位“MASK”决定的，如果使用掩码就是 4 个字节的随机数，否则就不存在。
服务发现
WebSocket沿用HTTP的URI格式，但不同的是，WebSocket使用“ws”和“wss”作为URI格式的开头协议名，分别表示明文和加密的WebSocket协议。默认端口为80和443。
WebSocket的握手
WebSocket利用了 HTTP 本身的“协议升级”特性，“伪装”成 HTTP，这样就能绕过浏览器沙盒、网络防火墙等等限制，这也是 WebSocket 与 HTTP 的另一个重要关联点。
客户端请求
WebSocket 的握手是一个标准的 HTTP GET 请求，但要带上两个协议升级的专用头字段：
- “Connection: Upgrade”，表示要求协议“升级”；
- “Upgrade: websocket”，表示要“升级”成 WebSocket 协议。
另外，为了防止普通的 HTTP 消息被“意外”识别成 WebSocket，握手消息还增加了两个额外的认证用头字段（所谓的“挑战”，Challenge）：
- Sec-WebSocket-Key：一个 Base64 编码的 16 字节随机数，作为简单的认证密钥；
- Sec-WebSocket-Version：协议的版本号，当前必须是 13。
服务器升级协议
服务器收到 HTTP 请求报文，看到上面的四个字段，就知道这不是一个普通的 GET 请求，而是 WebSocket 的升级请求，于是就不走普通的 HTTP 处理流程，而是构造一个特殊的“101 Switching Protocols”响应报文，通知客户端，接下来就不用 HTTP 了，全改用 WebSocket 协议通信。（有点像 TLS 的“Change Cipher Spec”）。
服务器响应
WebSocket 的握手响应报文也是有特殊格式的，要用字段“Sec-WebSocket-Accept”验证客户端请求报文，同样也是为了防止误连接。
具体的做法是把请求头里“Sec-WebSocket-Key”的值，加上一个专用的 UUID “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”，再计算 SHA-1 摘要。
encode_base64(
sha1(
Sec-WebSocket-Key + '258EAFA5-E914-47DA-95CA-C5AB0DC85B11' ))
客户端收到响应报文，就可以用同样的算法，比对值是否相等，如果相等，就说明返回的报文确实是刚才握手时连接的服务器，认证成功。
握手完成，后续传输的数据就不再是 HTTP 报文，而是 WebSocket 格式的二进制帧了。
WebSocket的一些缺点
回的报文确实是刚才握手时连接的服务器，认证成功。
握手完成，后续传输的数据就不再是 HTTP 报文，而是 WebSocket 格式的二进制帧了。
WebSocket的一些缺点
WebSocket 虽然是在应用层，但使用方式却与“TCP Socket”差不多，过于“原始”，用户必须自己管理连接、缓存、状态，开发上比 HTTP 复杂的多。