websocket和http的瓜葛以及websocket协议实现

目录 前言. websocket和http的瓜葛 http的弊端引出为什么需要websocket 引出问题 &…

目录

前言.

websocket和http的瓜葛

http的弊端引出为什么需要websocket

引出问题 — 服务器无法主动向客户端发送数据, 如果服务端存在一定地状态变更, 却无法实时地主动向客户端推送这个数据

解决问题 — websocket全双工地通讯协议地诞生, 服务器可以主动向客户端发送数据

websocket的特点

报文分析

websocket在我们生活中的实例场景(服务器(后端)向网页客户端(前端)实时刷新数据)

websocket协议的实现分块分析, 如何在reactor的基础上封装websocket应用层协议 (哪些协议究竟是如何封装实现的)

过程分析

握手细节:

基于TCP连接完成之后,进行一次握手的意义

细节分析: 如何区别握手数据 和 普通交互数据 ?

握手细节核心: Sec-WebSocket-Key —> Sec-WebSocket-Accept

transform 数据推送的细节 — 数据封包和解包.

做自定义协议必须的三部分. 基于tcp的自定义应用层协议

线上测试工具 + 我的测试结果

总结本文


前言.

  • 由于本文的websocket的实现我是基于reactor写的, 所以需要用到我之前写的reactor实现的部分代码, 如果对于reactor不太熟悉的友友可以去康康

epoll高度封装reactor,几乎所有可见服务器的底层框架_小杰312的博客-CSDN博客epoll高度封装reactor,几乎所有可见服务器的底层框架https://blog.csdn.net/weixin_53695360/article/details/123894158?spm=1001.2014.3001.5502

websocket和http的瓜葛

http的弊端引出为什么需要websocket

  • http是一种无状态, 无连接, 非持久化单向半双工应用层协议
  • 啥叫作无状态, 对于历史连接是完全没有记忆的, 每一次连接都是新的连接
  • 无连接的和非持久化其实是一个意思, 一次请求, 一次响应, 不会持续.
  • 单向半双工指的是 通信请求只能由客户端发起, 服务端只能对于请求做出应答, 服务端不能主动地向客户端发送数据

引出问题 — 服务器无法主动向客户端发送数据, 如果服务端存在一定地状态变更, 却无法实时地主动向客户端推送这个数据

  • 针对上述问题, 最开始地时候还是使用http, 只不过通过定时轮询长轮询地方式来解决服务器需要向客户端主动发送数据地问题.

  • 定时轮询, 不断地定时地询问服务器, 你需要发送消息吗, 不断地请求, 定时发出询问, 如果服务器需要发送数据到客户端, 询问来了就可以发送状态变更,数据到客户端了
  • 定时轮询地弊端:可能存在很严重地延时性, 而且不断地轮询及其浪费占用服务端地资源, 增大服务端压力,不断地建立连接浪费资源 存在很多无效请求 服务器表示,不停的建立连接,大量消耗我的带宽和资源, 我需要很快的处理连接 , 而很多时候我都没有数据跟新, 存在大量无效请求服务器表示我很被动呀

借鉴一个兄弟的生活案例,便于理解: 【WebSocket 协议】Web 通信的下一步进化_我想养只猫 •͓͡•ʔ的博客-CSDN博客你可以在谷歌、百度搜索中找到许多类似的定义,但是我想通过一些简单和明显的例子来说明这这些。作为 HTML5 计划的一部分,开发的 WebSocket 规范引入了 WebSockethttps://blog.csdn.net/qq_41103843/article/details/124116838?utm_source=app&app_version=5.3.0&code=app_1562916241&uLinkId=usr1mkqgl919blen 上述大佬写的前端的websocket实现一个网页聊天室, 而且对于websocket的解释也是相当的优秀, 我的外卖例子均是借鉴它的

我们平时点外卖 (轮询实例)

0秒:食物到了吗?(客户)
0秒:正在配送。(外卖小哥)
1秒:食物到了吗?(客户)
1秒:正在配送。(外卖小哥)
2秒:食物到了吗?(客户)
2秒:正在配送。(外卖小哥) 2秒及其之间那么多询问都是无效询问

3秒:食物到了吗?(客户)
3秒:是的,先生,这是您的外卖。(外卖小哥)

  • 升级为长轮询,也仅仅只能解决延时性地问题, 能达到实时地将服务端地状态数据推送到客户端地目的, 但是http连接始终打开,长连接,浪费系统资源, 客户端需要等待服务端响应,服务端也一直被客户端占用. (一直占用服务器, 无效占用)

长轮询生活实例

0秒:食物到了吗?(客户)

。。。 中间电话一直不挂断, 直到外卖送到
3秒:是的,先生,这是您的外卖。(外卖小哥)

解决问题 — websocket全双工地通讯协议地诞生, 服务器可以主动向客户端发送数据

  • 阶段分为 一次握手阶段 + 数据交互阶段
  • 主要核心:全双工, 服务器可以主动向客户端发送数据

websocket的特点

  • 建立在TCP协议上, 服务器端的实现比较容易
  • 与HTTP协议有着良好的兼容性, 默认端口也是80和443,并且握手阶段基于HTTP协议
  • 数据格式比较轻量,性能开销小,通信高效
  • 可以发送文本, 也可以发送二进制数据

报文分析

  • 注意: 上述框着的升级为websocket其实是告知服务器客户端想要建立的是websocket连接, 你支持吗, 如果服务器支持,在响应报文中也一定存在返回这两个头部字段
  • 响应

  • Sec-WebSocket-Accept其实是根据客户端的Key做Hash之后返回的结果

  • websocket在我们生活中的实例场景(服务器(后端)向网页客户端(前端)实时刷新数据)

  1. 弹幕的实时刷新
  2. 扫描微信二维码后的页面跳转
  3. 股票数据的实时刷新

websocket协议的实现分块分析, 如何在reactor的基础上封装websocket应用层协议 (哪些协议究竟是如何封装实现的)

  • 过程分析

  • 握手细节:

  • 基于TCP连接完成之后,进行一次握手的意义

  • 握手:确保服务器是支持websocket 协议的, 也就是服务器应答一下客户端, 你的升级请求我收到了,我是支持websocket升级的

细节分析: 如何区别握手数据 和 普通交互数据 ?

  • 其实核心在于区分不同的阶段, 状态 — 状态机, 区分各个状态
  • 状态机 — http协议底层也存在, 协议封装必不可少的部分,因为需要进行区分不同的阶段, 是握手建立连接的阶段, 还是数据交互的阶段 … 这些http协议底层肯定是需要区分的
  • 每一个连接都拥有如下三种状态

握手细节核心: Sec-WebSocket-Key —> Sec-WebSocket-Accept

  • 为什么 需要经过层层加密 key -> Accept key ?
  • 为了安全起见, 为了证明它们可以处理websocket请求。 密匙认证.
  • 加密过程伪代码如下: 获取accept.

  • transform 数据推送的细节 — 数据封包和解包.

  • 如下是websocket独有的数据帧格式, 握手之后的数据发送都需要按照数据帧的格式对需要发送的数据进行一个处理

  • 做自定义协议必须的三部分. 基于tcp的自定义应用层协议

  1. 操作码. eg: FIN RSV
  2. 包长度
  3. mask-key
  • 数据封包函数 + 数据解包函数 (具体的封包解包过程我还没有吃透, 如果后面有机会小杰希望可以重新分析来过, 如下目前是借鉴的前辈的代码)

  • 再注意一下recv数据之后需要按照不同的状态进行调用不同的函数进行处理数据

  • 整体代码:

  • 线上测试工具 + 我的测试结果

websocket在线测试WebSocket 在线测试 工具 物联网http://www.websocket-test.com/

总结本文

  • 本文从http的弊端入手分析为啥需要websocket这个全新的应用层协议出来
  • 为了解决服务器需要向客户端主动推送数据的问题. 后端服务器向前端网页主动推送数据.
  • http 轮询 长连接 虽然也可以,但是轮询延迟长,而且不断地建立无效连接,结果服务器压根不需要推送数据,这样就很浪费资源, 长轮询,虽说是解决了延迟问题,可是不断地占据着服务器,对于服务器资源也是一种浪费, 毕竟你霸占服务器然而很长事件才需要推送一次数据
  • 于是全新地服务器可以主动推送数据地, 基于tcp地全双工地websocket 诞生了
  • websocket分为 握手和数据交互两大阶段。 握手阶段是基于http升级的.
  • 为了区分recv的时候的数据阶段,于是状态机诞生了
  • 握手阶段的核心在于,密匙确认服务端是否支持websocket. key—-> accept
  • 经过 str += GUID SHA-1(str) hash 然后base64_encode (str);
  • 然后我们基于tcp如果需要封装自己的应用层协议:

特有数据帧格式:1. 操作码 2. 包长度 3, mask-key

本文来自网络,不代表软粉网立场,转载请注明出处:https://www.rfff.net/p/4423.html

作者: HUI

发表评论

您的电子邮箱地址不会被公开。

返回顶部