RFC-6455 The WebSocket Protocol 浅读

什么是WebSokcet?

WebSocket是一种协议,并且是各大主流浏览器作为客户端支持的协议。它的目标就是用来替代基于 XMLHTTPRequest和长轮询的解决方案。应用在时时弹幕，消息推送，棋牌游戏等需要及时通讯的业务场景。

握手

WebSocket连接有两个阶段：握手（handshake）和数据传输（data transfer）。此握手非TCP三次握手，但是目的差不多，就是客户端告诉浏览器我想要使用WebSocket协议进行通讯。客户端需要发送如下请求，它是一个 HTTP Upgrade 请求：

 GET /chat HTTP/1.1
 Host: server.example.com
 Upgrade: websocket
 Connection: Upgrade
 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
 Origin: http://example.com
 Sec-WebSocket-Protocol: chat, superchat
 Sec-WebSocket-Version: 13

那么如果握手成功的话，服务器响应：

 HTTP/1.1 101 Switching Protocols
 Upgrade: websocket
 Connection: Upgrade
 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
 Sec-WebSocket-Protocol: chat

客户端发送握手请求

Uri要满足如下格式:

ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]

在与服务端建立连接时，客户端必须方发送握手请求，请求是一个HTTP的升级协议（Upgrade）请求。并且该请求必须满足
- 握手请求必须是一个正常的HTTP请求。
- 请求方法必须为GET，并且HTTP协议最低为1.1
- 请求头必须包含Host
- 请求头必须包含Upgrade，并且值为websocket
- 请求头必须包含Connection，并且值为Upgrade
- 请求头必须包含Sec-WebSocket-Key，值为经过Base64转换的长度为16字节的一组数据
- 请求头必须包含Origin，如果客户端是浏览器这个值肯定是有的，如果非浏览器的客户端，这个值可以随意改。
- 请求头必须包含Sec-WebSocket-Version，并且值为13
- 请求头可以带一个Sec-WebSocket-Protocol，这个值告诉服务端客户端想用的子协议，多个用逗号分开
- 请求头可以带一个Sec-WebSocket-Extensions，这个值告诉服务端客户端支持的协议级别的扩展。
- 请求头可以带一个和权限校验相关的头，例如Cookie，Authentication等

当客户端将握手请求发出去之后，就要等待服务端的响应了。当服务端成功响应之后，客户端还需要做如下校验：

返回的响应码非101，例如401，500，403，503 等等，客户端连接失败
返回的响应头部不包含Upgrade或者Upgrade的值不是websocket，客户端连接失败
返回的响应头部不包含Connection或者Connection的值不是Upgrade，客户端连接失败
返回的响应头部不包含Sec-WebSocket-Accept或者Sec-WebSocket-Accept的值并不是Base64(SHA1(Sec-WebSocket-Key+"258EAFA5-E914-47DA-95CA-C5AB0DC85B11")),客户端连接失败
返回的响应头部Sec-WebSocket-Extensions中的值并不是客户端发送的Sec-WebSocket-Extensions中的值，客户端连接失败
返回的响应头部Sec-WebSocket-Protocol中的值并不是客户端发送的Sec-WebSocket-Protocol中的值，客户端连接失败

服务端接收握手请求

如果服务端在处理请求过程中不满足一下任何一点，服务端都会终止处理该请求

必须是HTTP1.1+的GET请求
包含Host请求头
包含Upgrade值为WebSocket的请求头
包含Connection值为Upgrade的请求头
包含Sec-WebSocket-Key值为16字节长度的Base64字符串
包含Sec-WebSocket-Version值为13的请求头
非必须：Origin
非必须：Sec-WebSocket-Protocol
非必须：Sec-WebSocket-Extensions

当服务端确定这是一个正常的握手请求并且愿意处理此请求，那么服务端需要回应一个HTTP响应：

状态码必须为 101 Switching Protocol
Upgrade：WebSocket
Connection：Upgrade
Sec-WebSocket-Accept，如上文所说，值为：Base64(SHA1(Sec-WebSocket-Key+"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))
Sec-WebSocket-Protocol,根据客户端传的值
Sec-WebSocket-Extensions，根据客户端传的值

至此，握手结束。连接状态由CONNECTING进入OPEN状态

协议帧

WebSocket的协议帧格式如下：

FIN 1bit

包结束标志，1 代表最后一个消息包，0代表某一段消息包
RSV1, RSV2, RSV3: 每个1bit，共3bit

值为0，除非协议扩展（Extensions）声明了非0的值的含义。如果服务端收到非0的值，并且没有相应的定义，那么服务端将直接终止连接。
Opcode 4bit

x0 后续帧

x1 文本帧

x2 二进制帧

x3-X7 非控制帧预留

x8 关闭连接

x9 PING

xA PONG

xB-xF 控制帧预留
Mask 1 bit 是否掩码。客户端向服务器发送，必须掩码。服务端向客户端发送不需掩码
PayLoad Length 7bits,7+16bits,7+64bits，如果值为 0-125，则数据包长度为0-125.如果值为126，则后2个字节为数据包长度：16bit。如果值为127，则后8个字节为数据包长度：64bit。
Masking-Key, 0-4bits.是否有值取决于 Mask 标识位是否为1.
Extension data X bytes 如果在握手时协商了扩展，会有值，否则为0
Application data y bytes 剩余消息包
PayLoad data （x+y）bytes 总消息包=Extension data + Application data.如果有掩码，解码公式如下：

body[i] = body[i] ^ body[i % 4]

代码解析

下面我用tio网络通讯框架代码来解释一下上文中的内容，不必纠结具体代码，只要大概理解代码功能即可。

具体协议升级代码如下：

以上就是握手部分Http协议升级过程的代码部分。没有什么难理解的地方，只要对着文档要求去实现即可。不过要注意的是，这里是升级协议的过程，如果有其他业务处理，比如访问权限校验失败等，可以直接返回 HttpStatusCode 401.

协议帧解析：

总结

大致过了一遍RFC-6455文档，发现还是官方文档中解释的更详细的也更清楚一些，但是苦于英语水平不过关，有些部分理解起来比较困难。

参考资料

RFC-6455