udp,丢包解决方案.doc

udp,丢包解决方案 篇一：UDP丢包 找了个文章，写UDP丢包问题的，也许真是因为这个原因，当WPE插入到我的程序中时，无意的延迟了sendto的时间，使丢包的可能性减小？？现在在学校，回家试试。 丢包 由于UDP在发送数据前不需要与对方建立连接，因此会出现IP报文丢失现象。即使是在质量最好的局域网络中，也会发生丢包。而在Internet上，丢包率会达到5%！UDP丢包现象主要由于下面几个原因： 发送方丢包：内部缓冲区（internal buffers）已满，并且发送速度过快（即发送两个报文之间的间隔过短）； 接收方丢包：Socket未开始监听； 虽然UDP的报文长度最大可以达到64 kb，但是当报文过大时，稳定性会大大减弱。这是因为当报文过大时会被分割，使得每个分割块（翻译可能有误差，原文是fragmentation）的长度小于MTU，然后分别发送，并在接收方重新组合（reassemble），但是如果其中一个报文丢失，那么其他已收到的报文都无法返回给程序，也就无法得到完整的数据了。 很多人会不理解发送速度过快为什么会产生丢包，原因就是UDP的SendTo不会造成线程阻塞，也就是说，UDP的SentTo不会像TCP中的SendTo那样，直到数据完全发送才会return回调用函数，它不保证当执行下一条语句时数据是否被发送。这样，如果要发送的数据过多或者过大，那么在缓冲区满的那个瞬间要发送的报文就很有可能被丢失。至于对“过快”的解释，作者这样说： “A few packets a second are not an issue; hundreds or thousands may be an issue.”（一秒钟几个数据包不算什么，但是一秒钟成百上千的数据包就不好办了）。 要解决接收方丢包的问题很简单，首先要保证程序执行后马上开始监听（如果数据包不确定什么时候发过来的话），其次，要在收到一个数据包后最短的时间内重新回到监听状态，其间要尽量避免复杂的操作（比较好的解决办法是使用多线程回调机制）。 至于报文过大的问题，可以通过控制报文大小来解决，使得每个报文的长度小于MTU。以太网的MTU通常是1500 bytes，其他一些诸如拨号连接的网络MTU值为1280 bytes，如果使用speaking这样很难得到MTU的网络，那么最好将报文长度控制在1280 bytes以下。 来自 /blog/ UDT 1.介绍随着网络带宽时延产品(BDP)的增加，通常的TCP协议开始变的低效。这是因为他的AIMD（additive increase multiplicative decrease）算法完全减少了TCP拥塞窗口，但不能快速的恢复可用带宽。理论上的流量分析表明TCP在BDP增加到很高的时候比较容易受包损失攻击。 另外，继承自TCP拥塞控制的不公平的RTT也成为在分布式数据密集程式中的严重问题。拥有不同RTT的并发TCP流将不公平地分享带宽。尽管在小的BDP网络中使用通常的TCP实现来相对平等的共享带宽，但在拥有大量BDP的网络中，通常的基于TCP的程式就必须承受严重的不公平的问题。这个RTT基于的算法严重的限制了其在广域网分布式计算的效率，例如：internet上的网格计算。 一直到今天，对标准的TCP的提高一直都不能在高BDP环境中效率和公平性方面达到满意的程度（特别是基于RTT的问题）。例如：TCP的修改，RFC1423（高性能扩展），RFC2018（SACK）、RFC2582（New Reno）、RFC2883（D-SACK）、和RFC2988（RTO计算）都或多或少的提高了点效率，但最根本的AIMD算(来自:WWw.xlT 小龙文 档网:udp,丢包解决方案)法没有解决。HS TCP（RFC 3649）通过根本上改变TCP拥塞控制算法来在高BDP网络中获得高带宽利用率，但公平性问题仍然存在。考虑到上面的背景，需要一种在高BDP网络支持高性能数据传输的传输协议。我们推荐一个应用程式级别的传输协议，叫UDT或基于UDP的数据传输协议并拥有用塞控制算法。 本文描述两个正交的部分，UDP协议和UDT拥塞控制算法。一个应用层级别的协议，位于UDP之上，使用其他的拥塞算法，然而这些本文中描述的算法也能够在其他协议中实现，例如：TCP。 一个协议的参考实现叫[UDT]；周详的拥塞控制算法的性能分析在[GHG04]中能够找到。 2.设计目标UDT主要用在小数量的bulk源共享富裕带宽的情况下，最典型的例子就是建立在光纤广域网上的网格计算，一些研究所在这样的网络上运行他们的分布式的数据密集程式，例如，远程访问仪器、分布式数据挖掘和高分辨率的多媒体流。 UDT的主要目标是效率、公平、稳定。单个的或少量的U