TCP粘包和分包问题 原因探究 及 解决办法

处理办法

一般在进行Socket开发时,都会遇到数据包粘包和分包的问题。

而解决该问题的办法需要分两种情况:

1. 对于可允许自定义协议的,可以在应用层自定义一个协议格式:

消息头部 + 消息长度 + 消息正文 + 消息校验 +消息尾部

2. 对于不允许自定义协议的,可以在应用层自定义一个比较大的缓冲区

先将收到的数据包都放到缓冲区中,然后从该缓冲区中选取完整的数据包出来。该缓冲区的实现可以使用环形缓冲区进行优化,避免频繁的数据移动。

关于分包和粘包示例

粘包:发送方分别发送两个字符串”hello”+”world”,接收方却一次性接收到了”helloworld”。

分包:发送方一次性发送字符串”helloworld”,接收方却接收到了两个字符串”hello”和”world”。

socket特性

一般TCP协议能保证以下两点:

  • 顺序不变。例如发送方发送hello,接收方也一定顺序接收到hello,这个是TCP协议承诺的,
  • 分割的包中间不会插入其他数据。

因此以上两点成为我们解决分包、黏包问题的关键。

TCP为什么会分包

TCP是以段(Segment)为单位发送数据的,建立TCP链接后,有一个最大消息长度(MSS)。如果应用层数据包超过MSS,就会把应用层数据包拆分,分成两个段来发送。这个时候接收端的应用层就要拼接这两个TCP包,才能正确处理数据。

相关的,路由器(或以太网)有一个MTU( 最大传输单元),一般是在46-1500字节,除去IP头部20字节,留给TCP的就只有MTU-20字节。所以一般TCP的MSS为MTU-20=1460字节。

当应用层数据超过1460字节时,TCP会分多个数据包来发送。

扩展阅读
TCP的RFC定义MSS的默认值是536,这是因为 RFC 791里说了任何一个IP设备都得最少接收576尺寸的大小(实际上来说576是拨号的网络的MTU,而576减去IP头的20个字节就是536)。

TCP为什么会粘包

有时候,TCP为了提高网络的利用率,会使用一个叫做Nagle的算法。该算法是指,发送端即使有要发送的数据,如果很少的话,会延迟发送。如果应用层给TCP传送数据很快的话,就会把两个应用层数据包“粘”在一起,TCP最后只发一个TCP数据包给接收端。

以下部分为转载:https://www.iteye.com/blog/zhaohuiopensource-1541270

备注:  
一个包没有固定长度,以太网限制在46-1500字节,1500就是以太网的MTU,超过这个量,TCP会为IP数据报设置偏移量进行分片传输,现在一般可允许应用层设置8k(NTFS系)的缓冲区,8k的数据由底层分片,而应用看来只是一次发送。windows的缓冲区经验值是4k,Socket本身分为两种,流(TCP)和数据报(UDP),你的问题针对这两种不同使用而结论不一样。甚至还和你是用阻塞、还是非阻塞Socket来编程有关。  
1、通信长度,这个是你自己决定的,没有系统强迫你要发多大的包,实际应该根据需求和网络状况来决定。对于TCP,这个长度可以大点,但要知道,Socket内部默认的收发缓冲区大小大概是8K,你可以用SetSockOpt来改变。但对于UDP,就不要太大,一般在1024至10K。注意一点,你无论发多大的包,IP层和链路层都会把你的包进行分片发送,一般局域网就是1500左右,广域网就只有几十字节。分片后的包将经过不同的路由到达接收方,对于UDP而言,要是其中一个分片丢失,那么接收方的IP层将把整个发送包丢弃,这就形成丢包。显然,要是一个UDP发包佷大,它被分片后,链路层丢失分片的几率就佷大,你这个UDP包,就佷容易丢失,但是太小又影响效率。最好可以配置这个值,以根据不同的环境来调整到最佳状态。  
send()函数返回了实际发送的长度,在网络不断的情况下,它绝不会返回(发送失败的)错误,最多就是返回0。对于TCP你可以字节写一个循环发送。当send函数返回SOCKET_ERROR时,才标志着有错误。但对于UDP,你不要写循环发送,否则将给你的接收带来极大的麻烦。所以UDP需要用SetSockOpt来改变Socket内部Buffer的大小,以能容纳你的发包。明确一点,TCP作为流,发包是不会整包到达的,而是源源不断的到,那接收方就必须组包。而UDP作为消息或数据报,它一定是整包到达接收方。 


2、关于接收,一般的发包都有包边界,首要的就是你这个包的长度要让接收方知道,于是就有个包头信息,对于TCP,接收方先收这个包头信息,然后再收包数据。一次收齐整个包也可以,可要对结果是否收齐进行验证。这也就完成了组包过程。UDP,那你只能整包接收了。要是你提供的接收Buffer过小,TCP将返回实际接收的长度,余下的还可以收,而UDP不同的是,余下的数据被丢弃并返回WSAEMSGSIZE错误。注意TCP,要是你提供的Buffer佷大,那么可能收到的就是多个发包,你必须分离它们,还有就是当Buffer太小,而一次收不完Socket内部的数据,那么Socket接收事件(OnReceive),可能不会再触发,使用事件方式进行接收时,密切注意这点。这些特性就是体现了流和数据包的区别。

  • 2
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
TCP协议是一种面向连接的可靠传输协议,它将数据分成一个一个的数据包进行传输。但是,由于网络传输的不确定性,TCP粘包分包问题就会出现。 1. TCP粘包问题 TCP粘包问题是指发送方将多个数据包合并成一个数据包发送,接收方无法区分多个数据包的边界,从而无法正确处理数据包。造成TCP粘包问题原因有多种,比如发送方发送的数据包过大、发送速度过快、网络延迟等。 解决方法: (1) 设置消息边界标识符 在发送的消息中添加一个特殊的标识符,如换行符、空格等,用来标识消息的边界。接收方根据标识符来判断消息的边界,将消息分隔成多个数据包。 (2) 定长消息 可以设置一个固定长度的消息,每次发送的数据都是定长的。这样接收方就可以根据固定长度来将消息分隔成多个数据包。 2. TCP分包问题 TCP分包问题是指发送方将一个数据包分成多个数据包发送,接收方接收后需要将多个数据包组合成一个完整的数据包,才能进行处理。造成TCP分包问题原因有多种,比如发送方发送的数据包过大、网络拥塞等。 解决方法: (1) 设置消息长度 在消息中添加消息长度信息,接收方接收到数据后,根据长度信息将多个数据包组合成一个完整的数据包。 (2) 固定长度消息 发送方每次发送的数据都是固定长度的,接收方根据固定长度来将多个数据包组合成一个完整的数据包。 总之,TCP粘包分包问题可以通过合理的协议设计和网络优化来解决。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值