websocket学习|青训营笔记

“这是我参与「第五届青训营 」伴学笔记创作活动的第 5 天

今天是农历初四，开始重新学习啦！

• 如何实现在用户无感知的情况下进行相关的控制操作（扫码登录）

  • 在前端设置定期发送请求（伪控制），具有一定的延迟时间
  • 请求到达服务器时进行等待，即轮询，当收到消息的时候返回

• HTTP协议的劣势

  • 我们知道TCP连接的两端，同一时间里，双方都可以主动向对方发送数据。即全双工。而现在使用最广的HTTP1.1，也是基于TCP协议的，同一时间里，客户端和服务器只能有一方主动发数据，这就是所谓的半双工。也就是说，好好的全双工TCP，被HTTP用成了半双工。这是由于HTTP协议设计之初，考虑的是看看网页文本的场景，能做到客户端发起请求再由服务器响应，就够了，根本就没考虑网页游戏这种，客户端和服务器之间都要互相主动发大量数据的场景。所以为了更好的支持这样的场景，我们需要另外一个基于TCP的新协议。于是新的应用层协议websocket就被设计出来了

• 这里注意socket和websocket的关系就像java和javascript的关系一样，毫无关系，并且websocket是应用层协议

• 为了兼容这些使用场景。浏览器在TCP三次握手建立连接之后，都统一使用HTTP协议先进行一次通信。

  • 如果此时是普通的HTTP请求，那后续双方就还是老样子继续用普通HTTP协议进行交互，这点没啥疑问。
  • 如果这时候是想建立websocket连接，就会在HTTP请求里带上一些特殊的header头

• "websocket是基于HTTP的新协议"，其实这并不对，因为websocket只有在建立连接时才用到了HTTP，升级完成之后就跟HTTP没有任何关系了，HTTP只是创建连接的工具人

• 上面提到在完成协议升级之后，两端就会用webscoket的数据格式进行通信。数据包在websocket中被叫做帧。具体结构如下

• 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的数据格式进行收发数据。