Socket的半包,粘包与分包的问题

概述

关于半包、粘包和分包的现象产生,是因为TCP当中只有流的概念,没有包的概念. ,而面向流的通信是无消息保护边界的。由于TCP无消息保护边界, 需要在消息接收端处理消息边界问题,因此自然产生了如何分包。


半包
指接受方没有接受到一个完整的包,只接受了部分,这种情况主要是由于TCP为提高传输效率,将一个包分配的足够大,导致接受方并不能一次接受完。( 在长连接和短连接中都会出现)。 

粘包与分包 
指发送方发送的若干包数据到接收方接收时粘成一包,从接收缓冲区看,后一包数据的头紧接着前一包数据的尾。出现粘包现象的原因是多方面的,它既可能由发送方造成,也可能由接收方造成。发送方引起的粘包是由TCP协议本身造成的,TCP为提高传输效率,发送方往往要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少,通常TCP会根据优化算法把这些数据合成一包后一次发送出去,这样接收方就收到了粘包数据。接收方引起的粘包是由于接收方用户进程不及时接收数据,从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区,用户进程从该缓冲区取数据,若下一包数据到达时前一包数据尚未被用户进程取走,则下一包数据放到系统接收缓冲区时就接到前一包数据之后,而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据,这样就一次取到了多包数据。分包是指在出现粘包的时候我们的接收方要进行分包处理。(在长连接中都会出现) 

什么时候需要考虑半包的情况?    
从备注中我们了解到Socket内部默认的收发缓冲区大小大概是8K,但是我们在实际中往往需要考虑效率问题,重新配置了这个值,来达到系统的最佳状态。 
一个实际中的例子:用mina作为服务器端,使用的缓存大小为10k,这里使用的是短连接,所有不用考虑粘包的问题。 
问题描述:在并发量比较大的情况下,就会出现一次接受并不能完整的获取所有的数据。 
处理方式: 
1.通过包头+包长+包体的协议形式,当服务器端获取到指定的包长时才说明获取完整。 

2.指定包的结束标识,这样当我们获取到指定的标识时,说明包获取完整。  

什么时候需要考虑粘包的情况?    

1.当时短连接的情况下,不用考虑粘包的情况 
2.如果发送数据无结构,如文件传输,这样发送方只管发送,接收方只管接收存储就ok,也不用考虑粘包 
3.如果双方建立连接,需要在连接后一段时间内发送不同结构数据 
处理方式: 
接收方创建一预处理线程,对接收到的数据包进行预处理,将粘连的包分开 
注:粘包情况有两种,一种是粘在一起的包都是完整的数据包,另一种情况是粘在一起的包有不完整的包 

备注: 
一个包没有固定长度,以太网限制在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),可能不会再触发,使用事件方式进行接收时,密切注意这点。这些特性就是体现了流和数据包的区别。  
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在网络通信中,由于数据传输的特性,会出现粘包分包问题粘包(Packet Sticking)是指发送发送的数据包被接收方连续接收到,多个数据包被黏在一起,导致接收方无法正确解析数据。这可能是因为发送发送的数据包没有明确的边界,接收方无法确定每个数据包的开始和结束位置。 分包(Packet Splitting)是指发送发送的数据包被接收方拆分成多个数据包接收。这可能是因为发送发送的数据包过大,导致网络传输过程中被拆分成多个小包进行传输。 出现粘包分包问题的原因主要有以下几点: 1. 发送方连续发送多个数据包时,底层传输协议可能会将多个数据包合并成一个大的数据块进行传输,导致接收方接收到的数据不完整。 2. 发送发送的数据包大小超过了接收方的缓冲区大小,导致数据被拆分成多个小包进行传输。 3. 网络传输中存在延迟或拥塞,导致数据包到达顺序发生变化。 为了解决粘包分包问题,可以采用以下几种方法: 1. 使用固定长度的数据包:在每个数据包的前面添加固定长度的头部信息,指示该数据包的长度,接收方根据头部信息来切分数据包。 2. 使用特殊字符作为分隔符:在数据包之间添加特殊字符作为分隔符,接收方根据分隔符来切分数据包。 3. 使用长度字段:在数据包的头部添加一个表示数据包长度的字段,接收方根据长度字段来切分数据包。 4. 使用消息边界:在传输协议中定义消息边界,保证每个数据包都是一个完整的消息。 具体选择哪种方法取决于你的应用需求和实际情况。在实际开发中,可以根据协议规范或业界常用的做法来处理粘包分包问题

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值