浅谈WebSocket协议-RFC 6455

2023.12.30


这些方式在效率和网络带宽利用率方面存在诸多问题。WebSocket协议应运而生,对外提供了简单的双向数据传输能力。

Labs 导读

在WebSocket出现之前,一个Web应用(即时聊天、多人协作)的客户端和服务端之间常见的双向数据交换方式有短轮询、长轮询、SSE(Server-Sent Events,服务器发送事件)。这些方式在效率和网络带宽利用率方面存在诸多问题。WebSocket协议应运而生,对外提供了简单的双向数据传输能力。

Part 01、介绍 

WebSocket是一种在TCP连接上进行全双工通讯的网络通信协议。在2009年诞生,于2011年被IETF(The Internet Engineering Task Force,国际互联网工程任务组)定为标准并发布RFC 6455互联网标准跟踪文档,2016发布了RFC7936文档进行补充。WebSocket API同时也被W3C定为标准。

图片图片

WebSocket协议设计之初是为了取代HTTP形式的通信,因为RFC6202中提到HTTP协议最初不是用来做双向数据通信的。WebSocket协议并没有完全舍弃HTTP,它基于HTTP基础服务在现有环境中实现了双向通信目标。正如RFC 6455中说的那样,WebSocke的设计哲学是最小约束的框架,唯一的约束就是协议是基于帧而不是流,并且支持Unicode文本和二进制帧两者。

Part 02、  握手  

WebSocket协议分为建连握手、消息传输和断连握手三个部分,整体流程如下图所示。

图片

2.1 建连握手-客户端

为了兼容HTTP服务器侧的应用程序和代理,客户端的建连握手(包括通过代理或通过TLS加密隧道进行的连接)是一个遵循RFC2616中定义的有效HTTP升级请求,客户端连接握手请求header部分字段如下图所示。此外,客户端一旦发送了的连接握手就必须等待来自服务器的响应。

图片

- 请求URI

格式,ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]或者wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ],任何无效值都会造成建连失败

- 请求行

必须是GET方法,HTTP版本至少是1.1

- Upgrade

值必须是“websocket”,ASCII值,不区分大小写

- Connection

值必须包含“Upgrade”,ASCII值,不区分大小写

- Sec-WebSocket-Key

客户端为本次建连随机生成的16字节base64编码的字符串

- Origin

源地址,浏览器客户端必填,非浏览器客户端选填

- Sec-WebSocket-Protocol

客户端支持的一个或多个以逗号分隔的子协议,按优先级排序

- Sec-WebSocket-Version

客户端拟使用协议版本号,值必须为13。历史版本9、10、11和12不再作为有效值

- Sec-WebSocket-Extensions

客户端拟使用协议扩展。目前HyBi Working Group进行了多路复用扩展和压缩扩展,多路复用扩展实现共享底层TCP连接。压缩扩展为WebSocket协议增加了压缩功能,例如 x-webkit-deflate-frame

2.2 建连握手-服务端

当客户端与服务端建立WebSocket连接时,服务端必须回复客户端建连握手请求,握手回复header部分字段如下图所示。

图片图片

- 状态行

HTTP/1.1  101  Switching Protocols,表示接受客户端建连。若服务器想要停止处理客户端的握手,可返回例如401这样的错误代码的HTTP响应

- Upgrade

值必须是“websocket”

- Connection

值必须包含“Upgrade”

- Sec-WebSocket-Accept

若服务端接受客户端连接,生成该值。先将客户端请求头的 Sec-WebSocket-Key值与RFC4122文档中定义的全局唯一标识“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”拼接,然后进行SHA-1哈希再进行base64-encoded得到该值

- Sec-WebSocket-Protocol

服务端拟使用的协议,该值从客户端发送的Sec-WebSocket-Protocol中选择,若服务端都不支持,值为空

- Sec-WebSocket-Extensions

服务端拟使用协议扩展

2.3 断接握手

客户端和服务端都可以发送包含指定控制序列的控制帧(Close控制帧)以开始关闭握手。一方在接收到关闭控制帧时,只需发送一个关闭帧作为响应,然后关闭连接。存在拦截代理等情况下,TCP关闭握手并不总是可靠的端到端握手,上述关闭握手过程旨在补充TCP关闭握手(FIN/ACK)。

Part 03、 数据传输  

客户端一旦和服务端连接握手成功,双方就可以开始数据传输了。这是一个双向通信信道,在遵循RFC 6455规范中“消息”概念的基础上,双方均可以独立地随意发送数据。一条消息包含一个或者多个数据帧(不一定对应于网络层中的消息),Websocket帧格式如下图所示。

图片

3.1 帧结构

- FIN

1位,表示是否是一条消息的最后一个分片。

- RSV1, RSV2, RSV3

1位,扩展功能未使用的情况下默认值为0。

- Opcode

4位,定义“Playload data”数据类型。

  • 0(十进制):连续帧
  • 1:文本帧
  • 2:二进制帧
  • 3-7:预留非控制帧
  • 8:连接关闭帧
  • 9:心跳ping帧
  • 10:心跳pong帧
  • 11-15:预留控制帧

- MASK

1位,是否屏蔽“Playload data”,1是,0否。

- Payload length

7位,或者7+16位,或者7+64位,表示Payload data的长度。具体地,Payload length小于125,数据长度用Payload length表示;Payload length等于126,数据长度用Payload length后面16位表示;Payload length等于127,数据长度用Payload length后面64位表示。

- Masking-key

32位,存放客户端发送的掩码。为了防止代理缓存污染攻击,RFC6455中要求掩码必须来自强大的熵源,不可被预测。常规算法以字节为步长遍历载荷数据, 对于载荷数据的第i个字节, 做i对4取模得到j,掩码覆盖后的载荷数据的第i个字节的值为原第i个字节与Masking-Key的第j个字节做按位异或操作。

- Payload data

载荷数据分为扩展数据和应用数据两种,扩展数据在握手阶段协商是否使用,应用数据在扩展数据之后。

3.2 控制帧

控制帧由Opcode值确定,协议当前定义的控制帧的操作码包括 0x8 (Close)、0x9(Ping)、和0xA(Pong)。控制帧必须有一个小于等于125字节的有效载荷长度,对于Close控制帧有效载荷的前2个字节表示状态码,剩余字节表示关闭原因,如下图所示。

图片

3.3 消息分片

消息分片指将概念上的一条“消息”通过多个数据帧发送。消息分片允许发送未知大小的消息,而不必缓冲整条消息。同时,消息分片结合多路复用协议的扩展,可以分割消息为更小的分段以共享输出通道。

协议中分片消息开始帧的FIN位为0,opcode位为非0表示该帧为某消息分片,中间帧FIN位为0,opcode位为0,最后通过FIN位为1,opcode为0标识分片结束。协议要求分片数据帧按顺序发送到另一端。

Part 04、总结 

WebSocke是设计在TCP层之上,不需要考虑数据长度,数据粘包拆包。也能通过扩展功能与HTTP/2多路复用结合,充分利用带宽。开发者只需在服务端和客户端代码中按序处理消息分片逻辑。