目录使用HTTP不断轮询长轮询websocket是什么怎么建立websocket连接websocket抓包websocket的消息格式websocket的使用场景总结平时我们打开网页比如购物网站某宝。都是点一下列表商品跳转一下网页就到了商品详情。从HTTP协议的角度来看就是点一下网页上的某个按钮前端发一次HTTP请求网站返回一次HTTP响应。这种由客户端主动请求服务器响应的方式也满足大部分网页的功能场景。但有没有发现这种情况下服务器从来就不会主动给客户端发一次消息。就像你喜欢的女生从来不会主动找你一样。但如果现在你在刷网页的时候右下角突然弹出一个小广告提示你【一个人在家偷偷才能玩哦】。求知好学勤奋这些刻在你DNA里的东西都动起来了。你点开后发现。长相平平无奇的古某提示你道士9条狗全服横着走。影帝某辉老师跟你说系兄弟就来砍我。来都来了你就选了个角色进到了游戏界面里。创建角色页面这时候上来就是一个小怪从远处走来然后疯狂拿木棒子抽你。你全程没点任何一次鼠标。服务器就自动将怪物的移动数据和攻击数据源源不断发给你了。这….太暖心了。感动之余问题就来了像这种看起来服务器主动发消息给客户端的场景是怎么做到的在真正回答这个问题之前我们先来聊下一些相关的知识背景。使用HTTP不断轮询其实问题的痛点在于怎么样才能在用户不做任何操作的情况下网页能收到消息并发生变更。最常见的解决方案是网页的前端代码里不断定时发HTTP请求到服务器服务器收到请求后给客户端响应消息。这其实时一种伪服务器推的形式。它其实并不是服务器主动发消息到客户端而是客户端自己不断偷偷请求服务器只是用户无感知而已。用这种方式的场景也有很多最常见的就是扫码登录。比如某信公众号平台登录页面二维码出现之后前端网页根本不知道用户扫没扫于是不断去向后端服务器询问看有没有人扫过这个码。而且是以大概1到2秒的间隔去不断发出请求这样可以保证用户在扫码后能在1到2s内得到及时的反馈不至于等太久。使用HTTP定时轮询但这样会有两个比较明显的问题当你打开F12页面时你会发现满屏的HTTP请求。虽然很小但这其实也消耗带宽同时也会增加下游服务器的负担。最坏情况下用户在扫码后需要等个1~2s正好才触发下一次http请求然后才跳转页面用户会感到明显的卡顿。使用起来的体验就是二维码出现后手机扫一扫然后在手机上点个确认这时候卡顿等个1~2s页面才跳转。不断轮询查看是否有扫码那么问题又来了有没有更好的解决方案有而且实现起来成本还非常低。长轮询我们知道HTTP请求发出后一般会给服务器留一定的时间做响应比如3s规定时间内没返回就认为是超时。如果我们的HTTP请求将超时设置的很大比如30s在这30s内只要服务器收到了扫码请求就立马返回给客户端网页。如果超时那就立马发起下一次请求。这样就减少了HTTP请求的个数并且由于大部分情况下用户都会在某个30s的区间内做扫码操作所以响应也是及时的。长轮询比如某度云网盘就是这么干的。所以你会发现一扫码手机上点个确认电脑端网页就秒跳转体验很好。长轮询的方式来替代真一举两得。像这种发起一个请求在较长时间内等待服务器响应的机制就是所谓的长训轮机制。我们常用的消息队列RocketMQ中消费者去取数据时也用到了这种方式。RocketMQ的消费者通过长轮询获取数据像这种在用户不感知的情况下服务器将数据推送给浏览器的技术就是所谓的服务器推送技术它还有个毫不沾边的英文名comet技术大家听过就好。上面提到的两种解决方案本质上其实还是客户端主动去取数据。对于像扫码登录这样的简单场景还能用用。但如果是网页游戏呢游戏一般会有大量的数据需要从服务器主动推送到客户端。这就得说下websocket了。websocket是什么我们知道TCP连接的两端同一时间里双方都可以主动向对方发送数据。这就是所谓的全双工。而现在使用最广泛的HTTP1.1也是基于TCP协议的同一时间里客户端和服务器只能有一方主动发数据这就是所谓的半双工。也就是说好好的全双工TCP被HTTP用成了半双工。为什么这是由于HTTP协议设计之初考虑的是看看网页文本的场景能做到客户端发起请求再由服务器响应就够了根本就没考虑网页游戏这种客户端和服务器之间都要互相主动发大量数据的场景。所以为了更好的支持这样的场景我们需要另外一个基于TCP的新协议。于是新的应用层协议websocket就被设计出来了。大家别被这个名字给带偏了。虽然名字带了个socket但其实socket和websocket之间就跟雷峰和雷峰塔一样二者接近毫无关系。websocket在四层网络协议中的位置怎么建立websocket连接我们平时刷网页一般都是在浏览器上刷的一会刷刷图文这时候用的是HTTP协议一会打开网页游戏这时候就得切换成我们新介绍的websocket协议。为了兼容这些使用场景。浏览器在TCP三次握手建立连接之后都统一使用HTTP协议先进行一次通信。如果此时是普通的HTTP请求那后续双方就还是老样子继续用普通HTTP协议进行交互这点没啥疑问。如果这时候是想建立websocket连接就会在HTTP请求里带上一些特殊的header头。Connection: Upgrade Upgrade: websocket Sec-WebSocket-Key: T2a6wZlAwhgQNqruZ2YUyg\r\n这些header头的意思是浏览器想升级协议Connection: Upgrade并且想升级成websocket协议Upgrade: websocket。同时带上一段随机生成的base64码Sec-WebSocket-Key发给服务器。如果服务器正好支持升级成websocket协议。就会走websocket握手流程同时根据客户端生成的base64码用某个公开的算法变成另一段字符串放在HTTP响应的Sec-WebSocket-Accept头里同时带上101状态码发回给浏览器。HTTP/1.1 101 Switching Protocols\r\n Sec-WebSocket-Accept: iBJKv/ALIW2DobfoA4dmr3JHBCY\r\n Upgrade: websocket\r\n Connection: Upgrade\r\nhttp状态码200正常响应的情况大家见得多了。101确实不常见它其实是指协议切换。base64转为新的字符串之后浏览器也用同样的公开算法将base64码转成另一段字符串如果这段字符串跟服务器传回来的字符串一致那验证通过。对比客户端和服务端生成的字符串就这样经历了一来一回两次HTTP握手websocket就建立完成了后续双方就可以使用webscoket的数据格式进行通信了。建立websocket连接.drawiowebsocket抓包我们可以用wireshark抓个包实际看下数据包的情况。客户端请求升级为websocket上面这张图注意画了红框的第2445行报文是websocket的第一次握手意思是发起了一次带有特殊Header的HTTP请求。服务器同意升级为websocket协议上面这个图里画了红框的4714行报文就是服务器在得到第一次握手后响应的第二次握手可以看到这也是个HTTP类型的报文返回的状态码是101。同时可以看到返回的报文header中也带有各种websocket相关的信息比如Sec-WebSocket-Accept。两次HTTP请求之后正式使用websocket通信上面这张图就是全貌了从截图上的注释可以看出websocket和HTTP一样都是基于TCP的协议。经历了三次TCP握手之后利用HTTP协议升级为websocket协议。你在网上可能会看到一种说法websocket是基于HTTP的新协议其实这并不对因为websocket只有在建立连接时才用到了HTTP升级完成之后就跟HTTP没有任何关系了。这就好像你喜欢的女生通过你要到了你大学室友的微信然后他们自己就聊起来了。你能说这个女生是通过你去跟你室友沟通的吗不能。你跟HTTP一样都只是个工具人。这就有点借壳生蛋的那意思。HTTP和websocket的关系websocket的消息格式上面提到在完成协议升级之后两端就会用webscoket的数据格式进行通信。数据包在websocket中被叫做帧。我们来看下它的数据格式长什么样子。websocket报文格式这里面字段很多但我们只需要关注下面这几个。opcode字段这个是用来标志这是个什么类型的数据帧。比如。等于1时是指text类型string的数据包等于2是二进制数据类型[]byte的数据包等于8是关闭连接的信号payload字段存放的是我们真正想要传输的数据的长度单位是字节。比如你要发送的数据是字符串111那它的长度就是3。另外可以看到我们存放payload长度的字段有好几个我们既可以用最前面的7bit, 也可以用后面的716bit或764bit。那么问题就来了。我们知道在数据层面大家都是01二进制流。我怎么知道什么情况下应该读7bit什么情况下应该读716bit呢websocket会用最开始的7bit做标志位。不管接下来的数据有多大都先读最先的7个bit根据它的取值决定还要不要再读个16bit或64bit。如果最开始的7bit的值是 0~125那么它就表示了payload 全部长度只读最开始的7个bit就完事了。payload长度在0到125之间如果是1260x7E。那它表示payload的长度范围在126~65535之间接下来还需要再读16bit。这16bit会包含payload的真实长度。payload长度在126到65535之间如果是1270x7F。那它表示payload的长度范围gt;65536接下来还需要再读64bit。这64bit会包含payload的长度。这能放2的64次方byte的数据换算一下好多个TB肯定够用了。payload长度大于等于65536的情况payload data字段这里存放的就是真正要传输的数据在知道了上面的payload长度后就可以根据这个值去截取对应的数据。大家有没有发现一个小细节websocket的数据格式也是数据头内含payload长度 payload data的形式。之前写的《既然有HTTP协议为什么还要有RPC》提到过TCP协议本身就是全双工但直接使用纯裸TCP去传输数据会有粘包的问题。为了解决这个问题上层协议一般会用消息头消息体的格式去重新包装要发的数据。而消息头里一般含有消息体的长度通过这个长度可以去截取真正的消息体。HTTP协议和大部分RPC协议以及我们今天介绍的websocket协议都是这样设计的。消息边界长度标志websocket的使用场景websocket完美继承了TCP协议的全双工能力并且还贴心的提供了解决粘包的方案。它适用于需要服务器和客户端浏览器频繁交互的大部分场景。比如网页/小程序游戏网页聊天室以及一些类似飞书这样的网页协同办公软件。回到文章开头的问题在使用websocket协议的网页游戏里怪物移动以及攻击玩家的行为是服务器逻辑产生的对玩家产生的伤害等数据都需要由服务器主动发送给客户端客户端获得数据后展示对应的效果。websocket的使用场景总结TCP协议本身是全双工的但我们最常用的HTTP1.1虽然是基于TCP的协议但它是半双工的对于大部分需要服务器主动推送数据到客户端的场景都不太友好因此我们需要使用支持全双工的websocket协议。在HTTP1.1里。只要客户端不问服务端就不答。基于这样的特点对于登录页面这样的简单场景可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。对于客户端和服务端之间需要频繁交互的复杂场景比如网页游戏都可以考虑使用websocket协议。websocket和socket几乎没有任何关系只是叫法相似。正因为各个浏览器都支持HTTP协议所以websocket会先利用HTTP协议加上一些特殊的header头进行握手升级操作升级成功后就跟HTTP没有任何关系了之后就用websocket的数据格式进行收发数据。