【后台开发】【TCP协议】封包和拆包

  • UDP是个“数据包”协议,两段数据间是有界限的,在接收端要么接收不到数据要么就是接收一段完整的数据。
  • TCP是个“流”协议,是没有界限的一串数据。连续调用两次send分别发送两段数据date1和date2,接收端可以出现的接收情况:
  1. 先接收到date1,然后接收到date2;
  2. 先接收到date1的部分,然后接收到date1余下部分和date2;
  3. 先接收到date1全部和date2部分,然后接收到date2余下的部分;
  4. 一次性接收到date1和date2的全部数据。

上述2、3、4就会产生粘包现象,就需要把接收到的数据进行拆包,拆成一个个独立的数据包,而为了拆包就必须在发送端进行封包

产生粘包的原因:
  1. 由Nagle算法1造成的发送端粘包:Nagle算法是一种改善网络传输效率的算法,但也可能造成困扰。
  2. 接收端接受不及时造成的接收端粘包:当应用层由于某些原因未能及时从TCP缓冲区取出数据,就会造成TCP缓冲区中存放了多段数据。
封包

封包就是给一段数据加上包头,这样一来数据包就分为包头和包体两部分内容了。包头其实是个大小固定的结构体,其中有个结构体成员变量表示包体的长度。根据固定的包头长度以及包头中含有的包体长度的变量值就能正确的拆分出一个完整的数据包。


  1. Nagle算法详见【后台开发】【TCP/IP】TCP协议选项—>Nagle算法。 ↩︎

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
Netty中的TCP粘包和拆包问题是由于底层的TCP协议无法理解上层的业务数据而导致的。为了解决这个问题,Netty提供了几种解决方案。其中,常用的解决方案有四种[1]: 1. 固定长度的拆包器(FixedLengthFrameDecoder):将每个应用层数据包拆分成固定长度的大小。这种拆包器适用于应用层数据包长度固定的情况。 2. 行拆包器(LineBasedFrameDecoder):将每个应用层数据包以换行符作为分隔符进行分割拆分。这种拆包器适用于应用层数据包以换行符作为结束符的情况。 3. 分隔符拆包器(DelimiterBasedFrameDecoder):将每个应用层数据包通过自定义的分隔符进行分割拆分。这种拆包器适用于应用层数据包以特定分隔符作为结束标志的情况。 4. 基于数据包长度的拆包器(LengthFieldBasedFrameDecoder):将应用层数据包的长度作为接收端应用层数据包的拆分依据。根据应用层协议中包含的数据包长度进行拆包。这种拆包器适用于应用层协议中包含数据包长度的情况。 除了使用这些拆包器,还可以根据业界主流协议的解决方案来解决粘包和拆包问题[3]: 1. 消息长度固定:累计读取到长度和为定长LEN的报文后,就认为读取到了一个完整的信息。 2. 使用特殊的分隔符:将换行符或其他特殊的分隔符作为消息的结束标志。 3. 在消息头中定义长度字段:通过在消息头中定义长度字段来标识消息的总长度。 综上所述,Netty提供了多种解决方案来解决TCP粘包和拆包问题,可以根据具体的业务需求选择合适的解决方案[1][3]。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值