websocket
背景:扫码登录场景
http定时轮询和长轮询实现
- 定时轮询:每隔几秒发送一次请求,耗费资源,用户体验差
- 长轮询:将http的超时时间设置为较长,比如30s,30s内用户没有登录,发起下一次请求
http协议将全双工的TCP协议用成了半双工,也就是同一时间里只能有一方主动向对方发送数据,不适用于网页游戏这种客户端和服务端需要互相推送大量数据的情况
websocket协议解决了这个问题,TCP三次握手建立连接后,先用http协议通信一次,进行协议的升级,切换到websocket协议
Sec-WebSocket-Key是一串base64编码,Sec-WebSocket-Accept通过公开的算法将其转换为另一串字符串,浏览器也用同样的公开算法将base64码转成另一段字符串,如果这段字符串跟服务器传回来的字符串一致,那验证通过。后续就可以用websocket进行通信。
// 请求头
Connection: Upgrade
Upgrade: WebSocket
Sec-WebSocket-Key: T2a6wZlAwhgQNqruZ2YUyg==\r\n
// 响应头
HTTP/1.1 101 Switching Protocols\r\n
Sec-WebSocket-Accept: iBJKv/ALIW2DobfoA4dmr3JHBCY=\r\n
Upgrade: WebSocket\r\n
Connection: Upgrade\r\n
101响应码指的是协议切换

websocket的数据称为帧,主要需要关注opcode字段,opcode记录传输数据的格式
- opcode等于 1: text类型(string)的数据包
- opcode等于 2: 二进制数据类型([]byte)的数据包
- opcode等于 8: 关闭连接的信号

payload长度有效防止TCP粘包,存放的是我们真正想要传输的数据的长度,单位是字节,payload长度到底是使用7位还是后面的也使用,要根据最前面7位payload长度字段中的数值判断
- 如果最开始的7bit的值是 0~125,那么它就表示了 payload 全部长度,只读最开始的7个bit就完事了。
- 如果是126(0x7E)。那它表示payload的长度范围在 126~65535 之间,接下来还需要再读16bit。这16bit会包含payload的真实长度。
- 如果是127(0x7F)。那它表示payload的长度范围>=65536,接下来还需要再读64bit。这64bit会包含payload的长度。这能放2的64次方byte的数据,换算一下好多个TB,肯定够用了
总结:
websocket适用于服务端和客户端频繁交互的场景
WebSocket协议详解:从定时轮询到服务端推送,
本文介绍了WebSocket协议如何解决HTTP协议在全双工需求下的问题,包括定时轮询和长轮询的局限,以及WebSocket的握手过程、帧结构和opcode的重要性。重点阐述了WebSocket适用于服务端和客户端频繁交互的场景。
6998

被折叠的 条评论
为什么被折叠?



