socket的接收端接收数据慢时,会不会被后来的数据包覆盖?(会不会丢失数据包)

1、首先限定下这里讨论的是4层协议,就是传输层的协议

对于tcp来说,有个滑动窗口(滑动窗口是什么自己google),这个机制tcp已经帮你做好了,可以保证在接收端处理的慢/来不及接受数据的时候,发送端就会等待,不会硬塞给接收端的,所以首先接收端是安全的,不会爆掉,不会覆盖。那么此时对于发送端来说,待发送的数据就会越积越多,积满了tcp自己的发送缓冲之后,你再调用send就会报nobufs 的错误码,至于拿到这个错误码之后, 你逻辑怎么处理(是逻辑层再额外加缓冲,还是直接报错,这就是你自己设计系统的时候该考虑的问题了)

对于udp来说,没有滑动窗口,如果发送端频率超出了接受端的处理能力,就丢包,所以反正接收端爆也是不会爆掉的。而极端情况,如果发送端的逻辑send的数据太大,超过了发送端的发送缓冲的处理能力了,在发送端同样会nobufs,之后该怎么处理和tcp一样。所以你如果用udp的话,通常需要自己额外设计一套可靠的机制来保证。

2、同样是4层协议

对于tcp,因为tcp是流协议,已经不管数据包的概念了,所以你第二次recv取到的是第一次recv取到数据之后的数据,就是说假如你发送端发了256个字符‘a’(无论这256个字符a,在ip层,就是3层协议中,被分成了几个包发送效果都一样),假设这256个a都已经到了接收端的recvbuf里面了(而且tcp会保证数据有序,如果有丢包tcp会自动重传,除非socket断掉了),此时你第一次recv(255) 将会取到255个字符a,第二次recv(255)将会取到1个字符a

对于udp,一次recv就是一个udp包,如果recv参数中传的缓存大小,比实际这个udp中的数据小的话,后面的数据就丢掉了,第二次recv是第二个udp包了。而对于发送端来说,如果send的数据太大,超过了一个MTU大小,就会导致发送端ip包分片,接收端ip包重组(如果ip分片有丢失,则重组失败,该udp包会被丢弃)

3、怎么判断一个报文读完

这里我姑且理解你说的报文是指一个逻辑报文,这个就跟4层协议无关了,是上层逻辑设计的问题,通常2种做法

(1)在整个逻辑报文的末尾人为的增加结束标记,收到结束标记就是报文结束,比如我们应用层(7层)的http协议,就是这么干的,加了"\r\n\r\n"来表示一个http包结束了

(2)在整个逻辑报文的开始加一个固定字节数(比如2个字节)的长度标记,也就是说你想send 10个字符a,先send一个2进制的short的10,在发送10个‘a’

发布了12 篇原创文章 · 获赞 10 · 访问量 1100
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览