文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

你真的理解粘包与半包吗?三分钟搞懂它

2024-12-02 01:01

关注

比如,平时我们要寄快递,如果东西太大的话,那么就需要拆成几个包裹来邮寄。

收件人仅收到个别包裹的时候,东西是不完整的,对应到网络传输中,这种情况就叫半包。

只有等接收到全部包裹时,这个东西(传输的信息)才完整,所以半包情况下无法解析出完整的数据,需要等,等接收到全部包裹。

那么问题来了,如何知晓已经收到全部包裹了呢?下文我们再作分析。

再比如,快过年了,我打算给家里的亲戚送点礼物,给每位长辈送个手表,我们都知道手表的体积不大,并且我家里人都住在一个村,所以把给各长辈的礼物打包在一个包裹里邮寄,这样能节省运费。

这种把本应该分多个包传输的数据合成一个包发送的情况,对应到网络传输中,就叫粘包。

看完这个例子之后,应该对粘包与半包有点感觉了,接下来我们看下网络中实际的情况。

实际情况

粘包与半包只有在 TCP 传输的时候才会有,像 UDP 是不会有这种情况的,原因是因为 TCP 是面向流的,数据之间没有界限的,而 UDP 是有的界限的。

如果熟悉 TCP 和 UDP 报文格式的同学肯定知道,TCP 的包没有报文长度,而 UDP 的包有报文长度,这也说明了 TCP 为什么是流式。

所以我为什么说上面的例子不太恰当,因为现实生活中快递的包裹之间其实是有界限的,TCP 则像流水,没有明确的界限。

然后 TCP 有发送缓冲区的概念,UDP 实际上是没这个概念。

假设 TCP 一次传输的数据大小超过发送缓冲区大小,那么一个完整的报文就需要被拆分成两个或更多的小报文,这可能会产生半包的情况,当接收端收到不完整的数据,是无法解析成功的。

如果 TCP 一次传输的数据大小小于发送缓冲区,那么可能会跟别的报文合并起来一块发送,这就是粘包。

此时接收端也无法正常解析报文,需要将其拆成多个正确的报文,才能正常解析。

关于粘包与半包,我还看到有拿 MTU (最大传输单元)说事的,如果发送的数据大于 MTU 那就会出现拆包,导致半包的情况。

我个人觉得这里有点不对,简单理解下,UDP 也是要遵循 MTU 的呀,对吧?那它咋不会发生半包呢?

我们接着来看如何解决粘包与半包。

那如何解决粘包与半包问题呢?

实际常见解决粘包与半包问题有三个方案:

为了说明方便,以下没有按二进制的位等单位来描述。

固定长度

这个其实很简单,比如现在要传输 ABC、EF 这两个包,如果不做处理接收端很可能收到的是 AB、CEF 或者 ABCE、F 等等。

这时候我们固定长度,我们规定每个报文长度都是 3,如果一个报文实际数据不足 3,那么就用空字符填充一下 。

所以我们发送的报文是 :

接收到的情况可能是:

但我们是按照 3 位来处理的,所以一次只会按照 3 位来解析,所以第一次虽然收到的数据是 ABCE,但我们就解析 3 位,即解析出 ABC,留着了个 E,等我们要继续解析 3 位的时候,发现长度不足 3,所以我们暂时先不管,先等等。

后面等到了 F“”,我们发现当下数据又满足 3 位了,所以我们接着解析 EF“” 。

这样就解决了粘包与半包问题。

对应到 Netty 中的实现就是 FixedLengthFrameDecoder,这个类来实现固定长度的解码。

核心逻辑就是我上面说的,我们来看下源码,很简单:

固定长度的优点:简单。

缺点:固定长度很僵硬,不易于扩展,且如果设置过大来满足业务场景的话,会导致空间浪费,因为不足长度的需要填充。

分隔符

这个应该很好理解, 还是拿 ABC、EF 这两个包举例,我在写完 ABC后,插入一个分号,组成ABC;,EF 同理:

这样以分隔符为界限来切分无界限的 TCP 流,来解决粘包与半包问题,这个应该很好理解,既然你 TCP 没界限,我业务上给你搞个界限。

对应到 Netty 中的实现就是 DelimiterBasedFrameDecoder,具体源码就不贴了,有点长,不过道理还是简单的。

一直解析,等识别到分隔符之后,说明前面的数据完整了,于是解析前面的数据,然后继续往后扫描解析。

分隔符的优点:简单,也不会浪费空间。

缺点:需要对内容本身进行处理,防止内容内出现分隔符,这样就会导致错乱,所以需要扫描一遍传输的数据将其转义,或者可以用 base64 编码数据,用 64 个之外的字符作为分隔符即可。

分隔符的处理方式在业界也是常用的,比如 Redis 就用换行符来分隔。

固定长度字段+内容

这个也很好理解,比如协议规定固定 4 位存放内容的长度,这样内容就可以伸缩:

还是拿 ABC、EF 这两个包举例:

解析流程是:先获取 4 位,如果当前收到的数据不够 4 位,那就再等等,够 4 位之后解析得到长度是 3,所以我再往后取 3 位,同样数据如果不够 3 位就再等等,够了的话就解析,这样就获取一个完整的包了。

然后接着往后获取 4 位,解析得到 2,同理根据 2 往后再取 2 位,解析得到 EF。

这种方式就是先解析固定长度的字段,获得后面内容的长度,根据内容长度来获取内容,从而得到一个完整的报文。

对应到 Netty 中的实现就是 LengthFieldBasedFrameDecoder,具体源码就不贴了,有点长,

固定长度字段+内容的优点:可以根据固定字段精准定位,也不用扫描转义字符。

缺点:固定长度字段的设计比较困难,大了浪费空间,毕竟每个报文都带这个长度,小了可能不够用。

总结

好了,我们总结一下。

因为 TCP 是面向流的协议,且利用缓冲区来提高发送的效率,所以会导致粘包/半包情况的发生。

对于这种情况,我们可以在报文上动手脚,可以约定固定长度的报文,或埋入分隔符,或利用固定长度字段+内容等常见的三种方式来解决粘包、半包的问题。

以上三种在 Netty 中都有现成实现类,可直接使用:

FixedLengthFrameDecoder,固定长度

DelimiterBasedFrameDecoder,分隔符

LengthFieldBasedFrameDecoder,定长度字段+内容

建议实验一下,会有更清晰的认识。

来源:yes的练级攻略内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯