关于http:为什么有HTTP协议还要有websocket协议

平时咱们关上网页，比方购物网站某宝。都是点一下 列表商品 ，跳转一下网页就到了 商品详情。

从 HTTP 协定的角度来看，就是点一下网页上的某个按钮，前端发一次 HTTP 申请，网站返回一次 HTTP 响应。

这种由客户端被动申请，服务器响应的形式也满足大部分网页的性能场景。

但有没有发现，这种状况下，服务器素来就不会 被动 给客户端发一次音讯。

就像你喜爱的女生从来不会被动找你一样。

但如果当初，你在刷网页的时候 右下角 忽然弹出一个 小广告 ，提醒你【 一个人在家偷偷能力玩哦】。

求知，好学，怠惰，这些刻在你 DNA 里的货色都动起来了。

你点开后发现。

长相平平无奇的古某提醒你 ” 道士 9 条狗，全服横着走 ”。

影帝某辉老师跟你说 ” 系兄弟就来砍我 ”。

来都来了，你就选了个角色进到了游戏界面里。

这时候，上来就是一个小怪，从远处走来，而后疯狂拿木棒子抽你。

你全程没点任何一次鼠标。服务器就主动将怪物的挪动数据和攻打数据源源不断发给你了。

这…. 太暖心了。

打动之余，问题就来了，

像这种 看起来服务器被动发消息给客户端的场景，是怎么做到的？

在真正答复这个问题之前，咱们先来聊下一些相干的常识背景。

应用 HTTP 一直轮询

其实问题的痛点在于，怎么样能力在用户不做任何操作的状况下，网页能收到音讯并产生变更。

最常见的解决方案是，网页的前端代码里一直定时发 HTTP 申请到服务器，服务器收到申请后给客户端响应音讯。

这其实时一种 伪服务器推的模式。

它其实并不是服务器被动发消息到客户端，而是客户端本人一直偷偷申请服务器，只是用户无感知而已。

用这种形式的场景也有很多，最常见的就是 扫码登录。

比方某信公众号平台，登录页面二维码呈现之后，前端 网页基本不晓得用户扫没扫，于是一直去向 后端 服务器询问，看有没有人扫过这个码。而且是以大略 1 到 2 秒的距离去一直发出请求，这样能够保障用户在扫码后能在 1 到 2s 内失去及时的反馈，不至于 等太久。

但这样，会有两个比拟显著的问题

• 当你关上 F12 页面时，你会发现满屏的 HTTP 申请。尽管很小，但这其实也耗费带宽，同时也会减少上游服务器的累赘。
• 最坏状况下，用户在扫码后，须要等个 1~2s，正好才触发下一次 http 申请，而后才跳转页面，用户会感到 显著的卡顿。

应用起来的体验就是，二维码呈现后，手机扫一扫，而后在手机上点个确认，这时候 卡顿等个 1~2s，页面才跳转。

那么问题又来了，有没有更好的解决方案？

有，而且实现起来老本还非常低。

长轮询

咱们晓得，HTTP 申请收回后，个别会给服务器留肯定的工夫做响应，比方 3s，规定工夫内没返回，就认为是超时。

如果咱们的 HTTP 申请 将超时设置的很大 ，比方 30s， 在这 30s 内只有服务器收到了扫码申请，就立马返回给客户端网页。如果超时，那就立马发动下一次申请。

这样就缩小了 HTTP 申请的个数，并且因为大部分状况下，用户都会在某个 30s 的区间内做扫码操作，所以响应也是及时的。

比方，某度云网盘就是这么干的。所以你会发现一扫码，手机上点个确认，电脑端网页就 秒跳转，体验很好。

真两全其美。

像这种发动一个申请，在较长时间内期待服务器响应的机制，就是所谓的 长训轮机制。咱们罕用的音讯队列 RocketMQ 中，消费者去取数据时，也用到了这种形式。

像这种，在用户不感知的状况下，服务器将数据推送给浏览器的技术，就是所谓的 服务器推送 技术，它还有个毫不沾边的英文名，comet技术，大家听过就好。

下面提到的两种解决方案，实质上，其实还是客户端被动去取数据。

对于像扫码登录这样的 简略场景 还能用用。

但如果是网页游戏呢，游戏个别会有大量的数据须要从服务器被动推送到客户端。

这就得说下 websocket 了。

websocket 是什么

咱们晓得 TCP 连贯的两端，同一时间里 ， 单方 都能够 被动 向对方发送数据。这就是所谓的 全双工。

而当初应用最宽泛的 HTTP1.1，也是基于 TCP 协定的， 同一时间里 ，客户端和服务器 只能有一方被动 发数据，这就是所谓的 半双工。

也就是说，好好的全双工 TCP，被 HTTP 用成了半双工。

为什么？

这是因为 HTTP 协定设计之初，思考的是看看网页文本的场景，能做到 客户端发动申请再由服务器响应，就够了，基本就没思考网页游戏这种，客户端和服务器之间都要相互被动发大量数据的场景。

所以为了更好的反对这样的场景，咱们须要另外一个 基于 TCP 的新协定。

于是新的应用层协定 websocket 就被设计进去了。

大家别被这个名字给带偏了。尽管名字带了个 socket，但其实 socket 和 websocket 之间，就跟雷峰和雷峰塔一样，二者靠近 毫无关系。

怎么建设 websocket 连贯

咱们平时刷网页，个别都是在浏览器上刷的，一会刷刷图文，这时候用的是HTTP 协定，一会关上网页游戏，这时候就得切换成咱们新介绍的websocket 协定。

为了兼容这些应用场景。浏览器在 TCP 三次握手 建设连贯之后，都 对立应用 HTTP 协定 先进行一次通信。

• 如果此时是 一般的 HTTP 申请，那后续单方就还是老样子持续用一般 HTTP 协定进行交互，这点没啥疑难。
• 如果这时候是 想建设 websocket 连贯 ，就会在 HTTP 申请里带上一些 非凡的 header 头。

Connection: UpgradeUpgrade: websocketSec-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\nSec-WebSocket-Accept: iBJKv/ALIW2DobfoA4dmr3JHBCY=\r\nUpgrade: websocket\r\nConnection: Upgrade\r\n

http 状态码 =200（失常响应）的状况，大家见得多了。101 的确不常见，它其实是指 协定切换。

之后，浏览器也用同样的 公开算法 将base64 码 转成另一段字符串，如果这段字符串跟服务器传回来的 字符串统一，那验证通过。

就这样经验了一来一回两次 HTTP 握手，websocket 就建设实现了，后续单方就能够应用 webscoket 的数据格式进行通信了。

websocket 抓包

咱们能够用 wireshark 抓个包，理论看下数据包的状况。

下面这张图，留神画了红框的第 2445 行报文，是 websocket 的 第一次握手 ，意思是发动了一次带有 非凡 Header的 HTTP 申请。

下面这个图里画了红框的 4714 行报文，就是服务器在失去第一次握手后，响应的 第二次握手 ，能够看到这也是个 HTTP 类型的报文，返回的状态码是 101。同时能够看到返回的报文 header 中也带有各种websocket 相干的信息，比方Sec-WebSocket-Accept。

下面这张图就是全貌了，从截图上的正文能够看出，websocket 和 HTTP 一样都是基于 TCP 的协定。经验了三次 TCP 握手之后，利用 HTTP 协定降级为 websocket 协定。

你在网上可能会看到一种说法：”websocket 是基于 HTTP 的新协定 ”，其实这并不对 ，因为 websocket 只有在建设连贯时才用到了 HTTP， 降级实现之后就跟 HTTP 没有任何关系了。

这就如同你喜爱的女生通过你要到了你大学室友的微信，而后他们本人就聊起来了。你能说这个女生是通过你去跟你室友沟通的吗？不能。你跟 HTTP 一样，都只是个 工具人。

这就有点 ”借壳生蛋“ 的那意思。

websocket 的音讯格局

下面提到在实现协定降级之后，两端就会用 webscoket 的数据格式进行通信。

数据包在 websocket 中被叫做 帧。

咱们来看下它的数据格式长什么样子。

这外面字段很多，但咱们只须要关注上面这几个。

opcode 字段 ：这个是用来标记这是个 什么类型 的数据帧。比方。

• 等于 1 时是指 text 类型（string）的数据包
• 等于 2 是二进制数据类型（[]byte）的数据包
• 等于 8 是敞开连贯的信号

payload 字段 ：寄存的是咱们 真正想要传输的数据的长度 ，单位是 字节 。比方你要发送的数据是 字符串 "111"，那它的长度就是3。

另外，能够看到，咱们寄存payload 长度的字段有好几个，咱们既能够用最后面的7bit, 也能够用前面的7+16bit 或 7 +64bit。

那么问题就来了。

咱们晓得，在数据层面，大家都是 01 二进制流。我怎么晓得 什么状况下应该读 7bit，什么状况下应该读 7 +16bit 呢？

websocket 会用最开始的 7bit 做标记位。不论接下来的数据有多大，都 先读最先的 7 个 bit，依据它的取值决定还要不要再读个 16bit 或 64bit。

• 如果 最开始的 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，必定够用了。

payload data 字段：这里寄存的就是真正要传输的数据，在晓得了下面的 payload 长度后，就能够依据这个值去截取对应的数据。

大家有没有发现一个小细节，websocket 的数据格式也是  数据头（内含 payload 长度）+ payload data 的模式。

之前写的《既然有 HTTP 协定，为什么还要有 RPC》提到过，TCP 协定自身就是全双工，但间接应用 纯裸 TCP去传输数据，会有 粘包 的 ” 问题 ”。为了解决这个问题，下层协定个别会用 音讯头 + 音讯体 的格局去从新包装要发的数据。

而 音讯头 里个别含有 音讯体的长度，通过这个长度能够去截取真正的音讯体。

HTTP 协定和大部分 RPC 协定，以及咱们明天介绍的 websocket 协定，都是这样设计的。

websocket 的应用场景

websocket 完满继承了 TCP 协定的 全双工 能力，并且还贴心的提供了解决粘包的计划。它实用于 须要服务器和客户端（浏览器）频繁交互 的大部分场景。比方网页 / 小程序游戏，网页聊天室，以及一些相似飞书这样的网页协同办公软件。

回到文章结尾的问题，在应用 websocket 协定的网页游戏里，怪物挪动以及攻打玩家的行为是 服务器逻辑 产生的，对玩家产生的挫伤等数据，都须要由 服务器被动发送给客户端，客户端取得数据后展现对应的成果。

总结

• TCP 协定自身是 全双工 的，但咱们最罕用的 HTTP1.1，尽管是基于 TCP 的协定，但它是 半双工 的，对于大部分须要服务器被动推送数据到客户端的场景，都不太敌对，因而咱们须要应用反对全双工的 websocket 协定。
• 在 HTTP1.1 里。只有客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简略场景，能够应用 定时轮询或者长轮询 的形式实现 服务器推送 (comet) 的成果。
• 对于客户端和服务端之间须要频繁交互的简单场景，比方网页游戏，都能够思考应用 websocket 协定。
• websocket 和 socket 简直没有任何关系，只是叫法类似。
• 正因为各个浏览器都反对 HTTP 协定，所以 websocket 会先利用 HTTP 协定加上一些非凡的 header 头进行握手降级操作，降级胜利后就跟 HTTP 没有任何关系了，之后就用 websocket 的数据格式进行收发数据。