我们来看分析一下 “分片问题”

2>、分片问题

我们知道 UDP 是不可靠的传输协议，为了减少 UDP 包丢失的风险，我们最好能控制 UDP 包在 IP层协议的传输过程中不要被切割。

这是为什么呢？

如果 MTU 是1500，Client 发送一个 8000字节大小的 UDP 包，那么 Server 端阻塞模式下接包，在不丢包的情况下，recvfrom(9000) 是收到 1500，还是 8000。如果某个 IP 分片丢失了，recvfrom(9000)，又返回什么呢？

根据 UDP 通信的有界性，在 buf 足够大的情况下，接收到的一定是一个完整的数据包，UDP 数据在下层的分片和组片问题由 IP 层来处理，提交到 UDP 传输层一定是一个完整的 UDP 包，那么 recvfrom(9000) 将返回 8000。如果某个 IP 分片丢失，udp 里有个 CRC 检验，如果包不完整就会丢弃，也不会通知是否接收成功，所以 UDP 是不可靠的传输协议，那么 recvfrom(9000) 将阻塞。

分片分的越多，虽然在传输层都是一次 send，一次 recv ，但在传输过程中，会传输多次，那么丢包的概论就越大，如何解决丢包问题呢？

三、UDP 丢包的原因

前提：

在不考虑 IP 层的分片丢失，CRC 检验包不完整的情况下

1、UDP 缓冲区满，造成的丢包

如果 socket缓冲区满了，应用程序没来得及处理在缓冲区中的 UDP 包，那么后续来的 UDP 包会被内核丢弃，造成丢包。

在 socket 缓冲区满造成丢包的情况下，可以通过增大缓冲区的方法来缓解UDP丢包问题。但是，如果服务已经过载了，简单的增大缓冲区并不能解决问题，反而会造成滚雪球效应，造成请求全部超时，服务不可用。

2、UDP 缓冲区过小或文件过大，造成的丢包：

如 果Client 发送的 UDP 报文很大，而 socket 缓冲区过小无法容下该 UDP 报文，那么该报文就会丢失。

以前遇到过这种问题，我把接收缓冲设置成 64K 就解决了。

int nRecvBuf=32*1024;//设置为32K

setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));