WebSocket协议解析

WebSocket协议解析

文章目录

• WebSocket解决了什么问题？
• 简介
• 设计原理
• 协议格式
• • 数据帧格式
  • 掩码
  • • 掩码算法
    • 掩码作用
• 流程
• • URI格式
  • 握手建立
  • • 客户端
    • 服务端
  • 如何验证握手被服务器接受？
  • 心跳帧
  • 关闭帧
  • • 关闭帧的错误码
• 如何维持长连接
• 应用场景
• 负载均衡
• Chrome分析WebSocket
• • 过滤器
  • 表格列
  • 消息颜色
• 参考资料

推荐一个免费的架构师课程 C/C++Linux服务器开发/后台架构师

WebSocket解决了什么问题？

我们已经有了 HTTP 协议，为什么还需要另一个协议？它能带来什么好处？
因为 HTTP 协议有一个缺陷：通信只能由客户端发起。所以我们如果想要获取
举例来说，我们想了解今天的天气，只能是客户端向服务器发出请求，服务器返回查询结果。HTTP 协议做不到服务器主动向客户端推送信息，所以服务器有连续的状态变化，客户端要获知就非常麻烦，我们只能使用轮询的方式去查询。轮询的效率非常低，非常浪费资源，所以websocket就诞生了。

简介

WebSocket在2008年诞生，2011成为国际标准，如今所有浏览器均已支持，Websocket已经广泛应用。其定义在RFC6455
WebSocket的最大特点就是服务器可以向客户端推送消息，是真正的双向平等对话，属于服务器推送技术。其特点如下：

• 建立在TCP协议之上，服务端实现比较容易。
• 与HTTP协议有着良好的兼容性。默认端口也是80和443，并且握手采取HTTP协议。
• 数据格式轻量，性能开销小，通信高效。
• 可以发送文本也可以发送二进制数据。
• 没有同源限制，客户端可以与任意服务器通信。
• 协议标识符是WS，加密则为wss，服务器网址就是URL。


设计原理

• 元数据：与HTTP协议不同，websocket的元数据是由应用层自行传输的。
• websocket是基于帧来传输而不是基于流的，每一帧要么承载字符数据，要么成长二进制数据。
• 基于浏览器同源策略模型，可以使用Access-Control-Allow-Origin等头部。
• 基于URI、子协议支持同主机同端口上的多个服务。

协议格式

学习协议必然要学习他的协议定义，WebSocket的最小单位是帧，由1个或多个帧组成一条消息。

• 发送端：将消息切割成多个帧，并发送。
• 接收端：接收消息帧，并将关联的帧重新组装成完整的消息。

数据帧格式

  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 ...                |
 +---------------------------------------------------------------+

• FIN：1bit，如果是1，表示这是消息的最后一个分片，如果是0表示不是消息的分片
• RSV1,RSV2,RSV3：各占1bit，一般情况全为0。当采用websocket扩展时，这三个标志位可以非0，且值含义由扩展进行定义。如果出现非零的值且没有采用websocket扩展连接出错。
• Opcode：4bit。
  • 0：延续帧，表示本次分片，当前收到的数据帧为其中一个数据分片。
  • 1：文本真。
  • 2：二进制帧。
  • 3-7：为非控制帧保留。
  • 8：连接断开。
  • 9：心跳帧ping。
  • 10：心跳帧pong。
  • B-F：保留
• Mask：1bit。表示是否对数据载荷进行掩码 *** 作。从客户端向服务器发送数据时需要对数据进行掩码 *** 作，当从服务端向客户端发送数据时，不需要对数据及逆行掩码 *** 作。如果服务端接收到的数据没有进行过掩码 *** 作，服务端就需要断开连接。如果mask为1，那么masking-key中会定义一个掩码键，并用这个掩码键来对数据进行反掩码。所有客户端发送到服务端的数据帧mask都是1。
• Payload Length：数据的长度，单位是字节，为7位或7+16位或1+64位。
  • 0-126：数据长度为x字节。
  • 126：后续2个字节为16位无符号整数，为数据的长度.
  • 127：后续8个字节为64位无符号整数，为数据长度。

掩码 掩码算法

掩码键（Masking-key）是由客户端挑选出来的32位的随机数。掩码 *** 作不会影响数据载荷的长度。掩码、反掩码 *** 作都采用如下算法：
首先，假设：

• 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

掩码作用


流程 URI格式

ws-URI：ws://host:[:port]path[?query]

• 默认为80

wss-URI：wss://host:[:port]path[?query]

• 默认为443

连接说明：

• host和port：主机名与端口
• shema：是否基于SSL
• 访问资源：URI
• 握手随机数：Sec-WebSocket-Key
• 选择子协议：Sec-WebSocket-Protocol
• 扩展协议：Sec-WebSocket-Extensions
• CORS跨域：Origin

握手建立 客户端

GET /?encoding=text HTTP/1.1 
Host: websocket.taohui.tech 
Accept-Encoding: gzip, deflate 
Sec-WebSocket-Version: 13 
Origin: http://www.websocket.org 
Sec-WebSocket-Extensions: permessage-deflate 
Sec-WebSocket-Key: c3SkgVxVCDhVCp69PJFf3A== 
Connection: keep-alive, Upgrade 
Pragma: no-cache 
Cache-Control: no-cache 
Upgrade: websocket

服务端

HTTP/1.1 101 Web Socket Protocol Handshake 
Server: openresty/1.13.6.2 
Date: Mon, 10 Dec 2018 08:14:29 GMT 
Connection: upgrade 
Access-Control-Allow-Credentials: true 
Access-Control-Allow-Headers: content-type 
Access-Control-Allow-Headers: authorization 
Access-Control-Allow-Headers: x-websocket-extensions 
Access-Control-Allow-Headers: x-websocket-version
Access-Control-Allow-Headers: x-websocket-protocol 
Access-Control-Allow-Origin: http://www.websocket.org 
Sec-WebSocket-Accept: yA9O5xGLp8SbwCV//OepMPw7pEI= 
Upgrade: websocket

如何验证握手被服务器接受？

• 请求中的 Sec-WebSocket-Key 随机数
  • 例如 Sec-WebSocket-Key: A1EEou7Nnq6+BBZoAZqWlg==
• 响应中的 Sec-WebSocket-Accept 证明值

1. 拼接值，服务端会将客户端的Sec-WebSocket-Key和GUID拼接，GUID在RFC4122中规定，例如A1EEou7Nnq6+BBZoAZqWlg==258EAFA5-E914-47DA-95CA-C5AB0DC85B11
2. 将拼接后的进行SHA1编码
3. 将SHA1编码再进行Hex base64编码
4. 然后将其放到Sec-WebSocket-Accept: cT8V7OIhhhL8rbFZgoGjU4DReQ8=

心跳帧

websocket使用ping、pong心跳帧来维持连接
ping帧：opcode=9可以含有数据
pong帧：opcode=A必须与ping帧数据相同

关闭帧

websocket定义了关闭帧，opcode=8，发送关闭帧后，不再发送任何数据，接受到关闭帧后，不再接受任何数据。

关闭帧的错误码 错误码含义1000正常关闭1001表示浏览器页面跳转或者服务器将要关机1002发现协议错误1003接收到不能处理的数据帧（例如某端不能处理二进制消息）1004预留1005预留（不能用在关闭帧里），期望但没有接收到错误码1006预留（不能用在关闭帧里），期望给出非正常关闭的错误码1007消息格式不符合 opcode（例如文本帧里消息没有用 UTF8 编码）1008接收到的消息不遵守某些策略（比 1003、1009 更一般的错误）1009消息超出能处理的最大长度1010客户端明确需要使用扩展，但服务器没有给出扩展的协商信息1011服务器遇到未知条件不能完成请求1015预留（不能用在关闭帧里），表示 TLS 握手失败 如何维持长连接

• HTTP长连接只能基于简单的超时（常见为65秒）。
• WebSocket连接基于ping/pong心跳机制维持。

应用场景

• 聊天d幕
• 实时提醒
• 客户端同步
• 实时数据展示
• 远程交互
• 扫码返回
• 位置实时跟踪
• 在线状态

负载均衡

Websocket负载设计通常需要加入一层消息分发系统来完成，所以其负载均衡相对HTTP来说会比较复杂。

Chrome分析WebSocket 过滤器

• 按类型：WS
• 属性过滤：is:running

表格列

• Data：消息负载。如果消息为纯文本，则在此处显示。对于二进制 *** 作码，此列将显示 *** 作码的名称和代码。支持以下 *** 作码：Continuationframe、Binaryframe、Connection Close frame、Ping frame和Pong frame。
• Length：消息负载的长度（以字节为单位）。
• Time：收到或发送的时间。

消息颜色

Chrome根据消息不同外框的颜色不同，分别如下：

• 浅绿色：发送到服务器的文本消息。
• 白色：接收到的文本消息。
• 浅黄色：WebSocket *** 作码。
• 浅红色：错误。


参考资料

https://www.ruanyifeng.com/blog/2017/05/websocket.html
https://www.cnblogs.com/chyingp/p/websocket-deep-in.html
https://developer.mozilla.org/zh-CN/docs/Web/API/WebSocket/WebSocket