UDP丢包原因

(转载自 http://www.cnblogs.com/mengyan/archive/2012/10/04/2711340.html)学习之

一、主要丢包原因

1、接收端处理时间过长导致丢包：调用recv方法接收端收到数据后，处理数据花了一些时间，处理完后再次调用recv方法，在这二次调用间隔里,发过来的包可能丢失。对于这种情况可以修改接收端，将包接收后存入一个缓冲区，然后迅速返回继续recv。

2、发送的包巨大丢包：虽然send方法会帮你做大包切割成小包发送的事情，但包太大也不行。例如超过50K的一个udp包，不切割直接通过send方法发送也会导致这个包丢失。这种情况需要切割成小包再逐个send。

3、发送的包较大，超过接受者缓存导致丢包：包超过mtu size数倍，几个大的udp包可能会超过接收者的缓冲，导致丢包。这种情况可以设置socket接收缓冲。以前遇到过这种问题，我把接收缓冲设置成64K就解决了。
int nRecvBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));

具体设置代码可以参考下面链接：
http://blog.sina.com.cn/s/blog_a459dcf5010153mp.html

4、发送的包频率太快：虽然每个包的大小都小于mtu size 但是频率太快，例如40多个mut size的包连续发送中间不sleep，也有可能导致丢包。这种情况也有时可以通过设置socket接收缓冲解决，但有时解决不了。所以在发送频率过快的时候还是考虑sleep一下吧。

5、局域网内不丢包，公网上丢包。这个问题我也是通过切割小包并sleep发送解决的。如果流量太大，这个办法也不灵了。总之udp丢包总是会有的，如果出现了用我的方法解决不了，还有这个几个方法：要么减小流量，要么换tcp协议传输，要么做丢包重传的工作。

二、具体问题分析

1.发送频率过高导致丢包

很多人会不理解发送速度过快为什么会产生丢包，原因就是UDP的SendTo不会造成线程阻塞，也就是说，UDP的SentTo不会像TCP中的SendTo那样，直到数据完全发送才会return回调用函数，它不保证当执行下一条语句时数据是否被发送。（SendTo方法是异步的）这样，如果要发送的数据过多或者过大，那么在缓冲区满的那个瞬间要发送的报文就很有可能被丢失。至于对“过快”的解释，作者这样说：“A few packets a second are not an issue; hundreds or thousands may be an issue.”（一秒钟几个数据包不算什么，但是一秒钟成百上千的数据包就不好办了）。 要解决接收方丢包的问题很简单，首先要保证程序执行后马上开始监听（如果数据包不确定什么时候发过来的话），其次，要在收到一个数据包后最短的时间内重新回到监听状态，其间要尽量避免复杂的操作（比较好的解决办法是使用多线程回调机制）。

2.报文过大丢包

至于报文过大的问题，可以通过控制报文大小来解决，使得每个报文的长度小于MTU。以太网的MTU通常是1500 bytes，其他一些诸如拨号连接的网络MTU值为1280 bytes，如果使用speaking这样很难得到MTU的网络，那么最好将报文长度控制在1280 bytes以下。

3.发送方丢包

发送方丢包：内部缓冲区（internal buffers）已满，并且发送速度过快（即发送两个报文之间的间隔过短）；  接收方丢包：Socket未开始监听；  虽然UDP的报文长度最大可以达到64 kb，但是当报文过大时，稳定性会大大减弱。这是因为当报文过大时会被分割，使得每个分割块（翻译可能有误差，原文是fragmentation）的长度小于MTU，然后分别发送，并在接收方重新组合（reassemble），但是如果其中一个报文丢失，那么其他已收到的报文都无法返回给程序，也就无法得到完整的数据了。

 

 

加一段学习的UDP分包建议：

在进行UDP编程的时候,我们最容易想到的问题就是,一次发送多少bytes好?   
当然,这个没有唯一答案，相对于不同的系统,不同的要求,其得到的答案是不一样的,我这里仅对   
像ICQ一类的发送聊天消息的情况作分析，对于其他情况，你或许也能得到一点帮助:   
首先,我们知道,TCP/IP通常被认为是一个四层协议系统,包括链路层,网络层,运输层,应用层.   
UDP属于运输层,下面我们由下至上一步一步来看:   
以太网(Ethernet)数据帧的长度必须在46-1500字节之间,这是由以太网的物理特性决定的.   
这个1500字节被称为链路层的MTU(最大传输单元).   
但这并不是指链路层的长度被限制在1500字节,其实这这个MTU指的是链路层的数据区.   
并不包括链路层的首部和尾部的18个字节.   
所以,事实上,这个1500字节就是网络层IP数据报的长度限制.   
因为IP数据报的首部为20字节,所以IP数据报的数据区长度最大为1480字节.   
而这个1480字节就是用来放TCP传来的TCP报文段或UDP传来的UDP数据报的.   
又因为UDP数据报的首部8字节,所以UDP数据报的数据区最大长度为1472字节.   
这个1472字节就是我们可以使用的字节数。   
  
当我们发送的UDP数据大于1472的时候会怎样呢？   
这也就是说IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片(fragmentation).   
把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组.   
这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便   
无法重组数据报.将导致丢弃整个UDP数据报。   
  
因此,在普通的局域网环境下，我建议将UDP的数据控制在1472字节以下为好.   
  
进行Internet编程时则不同,因为Internet上的路由器可能会将MTU设为不同的值.   
如果我们假定MTU为1500来发送数据的,而途经的某个网络的MTU值小于1500字节,那么系统将会使用一系列的机   
制来调整MTU值,使数据报能够顺利到达目的地,这样就会做许多不必要的操作.   
  
鉴于Internet上的标准MTU值为576字节,所以我建议在进行Internet的UDP编程时.   
最好将UDP的数据长度控件在548字节(576-8-20)以内.