收录网站的二级域名,wordpress虚拟币接口,wordpress添加小说板块,网站开发会计科目文章目录 概要一、WS原理1.1、帧格式 二、WS实战2.1、客户端发起协议升级请求2.2、服务端响应协议升级2.3、核心事件2.4、心跳保活 三、总结 概要
项目中的IM系统是基于WebSocket做的#xff0c;所以这里聊一下。 说到WS#xff0c;不得不提HTTP,HTTP是基于TCP#xff0c;面… 文章目录 概要一、WS原理1.1、帧格式 二、WS实战2.1、客户端发起协议升级请求2.2、服务端响应协议升级2.3、核心事件2.4、心跳保活 三、总结 概要
项目中的IM系统是基于WebSocket做的所以这里聊一下。 说到WS不得不提HTTP,HTTP是基于TCP面向文本的无状态的半双工通信协议。由于HTTP1.0的缺陷后面版本做相应的优化
每次请求都要建立TCP连接并且请求一个文档需要两倍RTT(一个是TCP握手一个是请求和接收文档)。针对这种情况HTTP1.1引入了keep-alive机制实现了建立一次TCP连接可发送多次请求。HTTP是明文传输所以有一个中间人攻击的漏洞。针对这种情况引入了HTTPS(HTTPTLS),实现了防窃听数据加密、防冒充身份验证、防篡改完整性校验。HTTP的请求一般是非流水线模式【收到上一个请求的响应后才能发下一个请求】注意现代浏览器并不启用流水线模式实现复杂问题多这里有队头阻塞问题所以有了HTTP2。HTTP2只是解决了应用层的队头阻塞问题但是TCP有丢包重传等机制所以传输层也有队头阻塞问题这个时候就要HTTP3登场了引入 QUIC 协议基于UDP,可以完美解决队头阻塞问题。
通过上面分析HTTP迭代的原因那么WS的出现是为了解决HTTP什么问题呢
针对HTTP请求-响应这种半双工通信模式既要实现全双工通信
为什么要这样呢主要是因为在没有WS之前HTTP要实现IM,服务端事件推送等实时场景是很麻烦的常见的有短轮询长轮询SSEServer 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)简单 可以看到帧头是16bit2字节
第一个字节 前四位是标志位第一个标志位是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;q0.8,zh-TW;q0.7,zh-HK;q0.5,en-US;q0.3,en;q0.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协议也是事件驱动的客户应用程序不需要轮序服务来得到更新的数据消息和事件将在服务器发送它们的时候异步到达。
open 连接建立时触发message 接收/发送消息时触发error 通信发生错误时触发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 somethingreturn nil})//deal websocket connectfor {//接收消息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
WS协议简单可以说只是在TCP之上提供了数据拆包组包的功能。所以对于静态资源的请求效率是低下的而不像HTTP2提供了多路复用请求优先级等特性来提高传输效率增强页面渲染。长连接全双工通信是WS相比于HTTP的一大优势其实HTTP2也有但奈何浏览器为了提高页面渲染效率往往还是同时开多个TCP连接。可以这样说WS与HTTP各有优势在页面渲染和短请求场景下选HTTP在实时通信如IM等场景下选WS,二者结合使用最好。长连接也并不是银弹随着在线用户增加相同资源下其最大在线用户数量理论上不如HTTP。长连接的负载均衡不如短连接灵活简单。
可以这样说如果不是浏览器是个沙河环境不允许用户使用TCP说不定WS压根不会诞生。
