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’