WebSocket协议解析

概要

项目中的IM系统是基于WebSocket做的，所以这里聊一下。
说到WS，不得不提HTTP,HTTP是基于TCP，面向文本的，无状态的，半双工通信协议。由于HTTP1.0的缺陷，后面版本做相应的优化：

• 每次请求都要建立TCP连接，并且请求一个文档需要两倍RTT(一个是TCP握手，一个是请求和接收文档)。针对这种情况HTTP1.1引入了keep-alive机制，实现了建立一次TCP连接，可发送多次请求。
• HTTP是明文传输，所以有一个中间人攻击的漏洞。针对这种情况引入了HTTPS(HTTP+TLS),实现了防窃听（数据加密）、防冒充（身份验证）、防篡改（完整性校验）。
• HTTP的请求一般是非流水线模式【收到上一个请求的响应后才能发下一个请求】（注意现代浏览器并不启用流水线模式，实现复杂，问题多），这里有队头阻塞问题，所以有了HTTP2。
• HTTP2只是解决了应用层的队头阻塞问题，但是TCP有丢包重传等机制，所以传输层也有队头阻塞问题，这个时候就要HTTP3登场了，引入 QUIC 协议，基于UDP,可以完美解决队头阻塞问题。

通过上面分析HTTP迭代的原因，那么WS的出现是为了解决HTTP什么问题呢？

针对HTTP请求-响应这种半双工通信模式，既要实现全双工通信

为什么要这样呢？主要是因为在没有WS之前，HTTP要实现IM,服务端事件推送等实时场景是很麻烦的，常见的有短轮询，长轮询，SSE（Server Send Event)，针对实时通讯的场景方案都不是很优秀，所以有了WS，它最初是在 HTML5 中引入的。经过多年发展后，该协议慢慢被多个浏览器支持，RFC 在 2011 年就把该协议作为一个国际标准，叫 rfc6455。

也许是为了修复HTTP缺陷而诞生的，所以WS的建立是依赖HTTP的，同样规定默认使用80,443端口，当然其错误码是与HTTP不重合的。

一、WS原理

WebSocket 是一种基于TCP长连接，面向报文（二进制），支持全双工通信的网络协议。其与HTTP是平级的，相比HTTP1.1,优点如下：

• 支持全双工通信，实时性更强；
• 客户端与服务端通信的最小单位是帧（frame），由1个或多个帧组成一条完整的消息。即发送端将消息切割成多个帧，并发送给接收端；接收端接收消息帧，并将关联的帧重新组装成完整的消息；
• 长连接，有状态；
• 较少的控制开销。连接创建后，WS客户端、服务端进行数据交换时，协议控制的数据包头部较小，不像HTTP每次请求都要携带那么多头；
• 支持扩展。ws协议定义了扩展，用户可以扩展协议，或者实现自定义的子协议（比如支持自定义压缩算法等）。

1.1、帧格式

WebSocket主要是解决HTTP无法实时通信的问题，所以没有HTTP2 的多路复用，优先级等复杂功能，所以二进制帧格式](https://www.rfc-editor.org/rfc/rfc6455.html#page-27)简单：

可以看到帧头是16bit，2字节：

• 第一个字节：
  前四位是标志位，第一个标志位是FIN,表示报文结束，因为一个消息可能被拆分成多帧，当接收方收到携带FIN标志位的帧时，就会把前面的帧拼起来组成完整的消息。后三位是保留标志位，必须设置为0，除非想要自定义扩展。
  后四位是opcode,也就是帧类型，比如0表示连续帧，1表示帧内容是文本，2表示帧内容是二进制，8表示关闭连接，9和10表示ping和pong等
• 第二个字节：
  它的第一位是掩码标志位 MASK，表示帧内容是否使用异或操作（xor）做简单的加密，当该位被设置为 1 时表示加密，设置为 0 时表示不加密。如果加密了，那么必须解密才能得到正确内容。目前的 WebSocket 标准规定，客户端发送数据必须使用掩码加密，而服务器发送则不使用掩码加密。
  后面7位表示Payload Length，也就是有效负载或者说有效业务消息的长度，并且采用的是大端存储。但是7位大表示127，如果payload data大于127字节咋办？？
  所以就引入了 Extended payload length 来表示真是的Payload Length：
  Payload Length ==127，则 后面8字节表示 Extended payload length；
  Payload Length ==126，则 后面2字节表示 Extended payload length；
  Payload Length < 126，则 没有 Extended payload length；

可知最大payload data长度 可以用8字节表示。

二、WS实战

• WS是基于HTTP协议实现的。
• WSS是基于HTTPS协议实现的,即完成tls握手后再进行协议升级。

WS建立复用了 HTTP 的握手请求过程。
客户端通过 HTTP 请求与 WebSocket 服务端协商升级协议。协议完成后，后续的数据交互则遵循 WebSocket 的协议。

2.1、客户端发起协议升级请求

GET /websocket HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Sec-WebSocket-Version: 13 #表示WS的版本。如果服务端不支持该版本，需要返回一个Sec-WebSocket-Versionheader头，里面包含服务端支持的版本号
Origin: http://www.jsons.cn
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: 9zQPEx8m0sqMkV1vanwJIA== #与服务端响应首部的Sec-WebSocket-Accept是配套的，提供基本的防护，比如恶意的连接，或者无意的连接(比如特殊的HTTP请求被意外识别成WS)
Connection: keep-alive, Upgrade   #告诉服务端要升级协议了
Sec-Fetch-Dest: websocket
Sec-Fetch-Mode: websocket
Sec-Fetch-Site: cross-site
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket             #告诉服务端要升级成WS协议

2.2、服务端响应协议升级

HTTP/1.1 101 Switching Protocols  #状态码 101 表示协议切换成功
Upgrade: websocket  #表示升级到WS协议
Connection: Upgrade  #表示协议升级
Sec-WebSocket-Accept: MzzLu4vmstovah28VVOvEgveq8o=  #根据客户端请求首部的 Sec-WebSocket-Key 计算出来
#将 Sec-WebSocket-Key 跟 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 拼接。
#通过 SHA1 计算出摘要，并转成 base64 字符串。计算公式如下：
# Base64(sha1(Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11))

协议升级完成后就完全遵循WS协议发送接收数据了。

2.3、核心事件

WebSocket协议也是事件驱动的，客户应用程序不需要轮序服务来得到更新的数据，消息和事件将在服务器发送它们的时候异步到达。

1. open 连接建立时触发
2. message 接收/发送消息时触发
3. error 通信发生错误时触发
4. close 连接关闭时触发

2.4、心跳保活

这个其实在1.1小节已经说过了，就是opcode类型，通过ping和pong来实现，不需要自己再写保活接口了，只需要使用ping/pong即可。
以go gorilla/websocket为例：

func WebSocket(c *gin.Context) {
   //支持协议升级
	conn, err := (&websocket.Upgrader{CheckOrigin: func(r *http.Request) bool { return true }}).Upgrade(c.Writer,      	c.Request, nil)
	if err != nil {
		http.NotFound(c.Writer, c.Request)
		return
	}
	//添加保活机制
	conn.SetPongHandler(func(appData string) error {
		library.ZapDebug(appData)
		//check something
		return nil
	})
	//deal websocket connect
	for {
	  //接收消息
		mt, msg, err := conn.ReadMessage()
		if err != nil { //错误，打Trace，因为可能是主动或者网络问题
			library.ZapDebug("ReadMessage err:%v", err)
			continue
		}
		//这里可以go func(){}() 包一下解决并发问题
		{
			//业务处理
			library.ZapDebug("mt=%v,msg=%v", mt, string(msg))
			//响应消息
			err = conn.WriteMessage(mt, []byte(fmt.Sprintf("hello:%s", msg)))
			if err != nil {
				library.ZapDebug("WriteMessage err:%v", err)
			}
		}
	}
}

三、总结

经过上述内容，可以知道WS可以看做是对HTTP打的补丁，主要是为了解决HTTP半双工通信弊端，侧重处理数据实时通信场景。

这里再说下WS为什么没有替代HTTP，反而后面出了一样支持长连接的HTTP2 ？

1. WS协议简单，可以说只是在TCP之上提供了数据拆包组包的功能。所以对于静态资源的请求效率是低下的，而不像HTTP2提供了多路复用，请求优先级等特性来提高传输效率，增强页面渲染。
2. 长连接，全双工通信是WS相比于HTTP的一大优势，其实HTTP2也有，但奈何浏览器为了提高页面渲染效率往往还是同时开多个TCP连接。可以这样说，WS与HTTP各有优势，在页面渲染和短请求场景下选HTTP，在实时通信，如IM等场景下选WS,二者结合使用最好。
3. 长连接也并不是银弹，随着在线用户增加，相同资源下，其最大在线用户数量理论上不如HTTP。
4. 长连接的负载均衡不如短连接灵活，简单。

可以这样说，如果不是浏览器是个沙河环境，不允许用户使用TCP，说不定WS压根不会诞生。