2024年4月14日发(作者：姬惜天)
找了个文章，写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 inc
rease multiplicative decrease）算法完全减少了TCP拥塞窗口，但不能快速的恢复可用带宽。理论上的流量分析表明
TCP在BDP增加到很高的时候比较容易受包损失攻击。
另外，继承自TCP拥塞控制的不公平的RTT也成为在分布式数据密集程式中的严重问题。拥有不同RTT的并发T
CP流将不公平地分享带宽。尽管在小的BDP网络中使用通常的TCP实现来相对平等的共享带宽，但在拥有大量BDP
的网络中，通常的基于TCP的程式就必须承受严重的不公平的问题。这个RTT基于的算法严重的限制了其在广域网分
布式计算的效率，例如：internet上的网格计算。
一直到今天，对标准的TCP的提高一直都不能在高BDP环境中效率和公平性方面达到满意的程度（特别是基于R
TT的问题）。例如：TCP的修改，RFC1423（高性能扩展），RFC2018（SACK）、RFC2582（New Reno）、RFC
2883（D-SACK）、和RFC2988（RTO计算）都或多或少的提高了点效率，但最根本的AIMD算法没有解决。HS TC
P（RFC 3649）通过根本上改变TCP拥塞控制算法来在高BDP网络中获得高带宽利用率，但公平性问题仍然存在。
考虑到上面的背景，需要一种在高BDP网络支持高性能数据传输的传输协议。我们推荐一个应用程式级别的传输
协议，叫UDT或基于UDP的数据传输协议并拥有用塞控制算法。
本文描述两个正交的部分，UDP协议和UDT拥塞控制算法。一个应用层级别的协议，位于UDP之上，使用其他
的拥塞算法，然而这些本文中描述的算法也能够在其他协议中实现，例如：TCP。
一个协议的参考实现叫[UDT]；周详的拥塞控制算法的性能分析在[GHG04]中能够找到。
2. 设计目标UDT主要用在小数量的bulk源共享富裕带宽的情况下，最典型的例子就是建立在光纤广域网上的网
格计算，一些研究所在这样的网络上运行他们的分布式的数据密集程式，例如，远程访问仪器、分布式数据挖掘和高分
辨率的多媒体流。
UDT的主要目标是效率、公平、稳定。单个的或少量的UDT流应该利用任何高速连接提供的可用带宽，即使带宽
变化的很剧烈。同时，任何并发的流必须公平地共享带宽，不依赖于不同的带宽瓶劲、起始时间、RTT。稳定性需要包
发送速率应该一直会聚可用带宽很快，并且必须避免拥塞碰撞。
UDT并不是在瓶劲带宽相对较小的和大量多元短文档流的情况下用来取代TCP的。
UDT主要作为TCP的朋友，和TCP并存，UDT分配的带宽不应该超过根据MAX-MIN规则的最大最小公平共享原
则。（备注，最大最小规则允许UDT在高BDP连接下分配TCP不能使用的可用带宽）。我们
3. 协议说明3.1. 概述UDT是双工的，每个UDT实体有两个部分：发送和接收。发送者根据流量控制和速率控
制来发送（和重传）应用程式数据。接收者接收数据包和控制包，并根据接收到的包发送控制包。发送和接收程式共享
同一个UDP端口来发送和接收。
接收者也负责触发和处理任何的控制事件，包括拥塞控制和可靠性控制和他们的相对机制，例如RTT估计、带宽
估计、应答和重传。
UDT总是试着将应用层数据打包成固定的大小，除非数据不够这么大。和TCP相似的是，这个固定的包大小叫做
MSS（最大包大小）。由于期望UDT用来传输大块数据流，我们假定只有很小的一部分不规则的大小的包在UDT ses
sion中。MSS能够通过应用程式来安装，MTU是其最优值（包括任何包头）。
UDT拥塞控制算法将速率控制和窗口（流量控制）合并起来，前者调整包的发送周期，后者限制最大的位被应答的
包。在速率控制中使用的参数通过带宽估计技术来更新，他继承来自基于接收的包方法。同时，速率控制周期是估计R
TT的常量，流控制参数依赖于对方的数据到达速度，另外接收端释放的缓冲区的大小。
3.2. 包结构UDT有两种包：数据包和控制包。他们通过包头的第一位来区分（标志位）。假如是0，表示是数据
包，1表示是控制包。
3.2.1. 数据包
数据包结构如下显示：
0 1 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2024年4月14日发(作者：姬惜天)
找了个文章，写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 inc
rease multiplicative decrease）算法完全减少了TCP拥塞窗口，但不能快速的恢复可用带宽。理论上的流量分析表明
TCP在BDP增加到很高的时候比较容易受包损失攻击。
另外，继承自TCP拥塞控制的不公平的RTT也成为在分布式数据密集程式中的严重问题。拥有不同RTT的并发T
CP流将不公平地分享带宽。尽管在小的BDP网络中使用通常的TCP实现来相对平等的共享带宽，但在拥有大量BDP
的网络中，通常的基于TCP的程式就必须承受严重的不公平的问题。这个RTT基于的算法严重的限制了其在广域网分
布式计算的效率，例如：internet上的网格计算。
一直到今天，对标准的TCP的提高一直都不能在高BDP环境中效率和公平性方面达到满意的程度（特别是基于R
TT的问题）。例如：TCP的修改，RFC1423（高性能扩展），RFC2018（SACK）、RFC2582（New Reno）、RFC
2883（D-SACK）、和RFC2988（RTO计算）都或多或少的提高了点效率，但最根本的AIMD算法没有解决。HS TC
P（RFC 3649）通过根本上改变TCP拥塞控制算法来在高BDP网络中获得高带宽利用率，但公平性问题仍然存在。
考虑到上面的背景，需要一种在高BDP网络支持高性能数据传输的传输协议。我们推荐一个应用程式级别的传输
协议，叫UDT或基于UDP的数据传输协议并拥有用塞控制算法。
本文描述两个正交的部分，UDP协议和UDT拥塞控制算法。一个应用层级别的协议，位于UDP之上，使用其他
的拥塞算法，然而这些本文中描述的算法也能够在其他协议中实现，例如：TCP。
一个协议的参考实现叫[UDT]；周详的拥塞控制算法的性能分析在[GHG04]中能够找到。
2. 设计目标UDT主要用在小数量的bulk源共享富裕带宽的情况下，最典型的例子就是建立在光纤广域网上的网
格计算，一些研究所在这样的网络上运行他们的分布式的数据密集程式，例如，远程访问仪器、分布式数据挖掘和高分
辨率的多媒体流。
UDT的主要目标是效率、公平、稳定。单个的或少量的UDT流应该利用任何高速连接提供的可用带宽，即使带宽
变化的很剧烈。同时，任何并发的流必须公平地共享带宽，不依赖于不同的带宽瓶劲、起始时间、RTT。稳定性需要包
发送速率应该一直会聚可用带宽很快，并且必须避免拥塞碰撞。
UDT并不是在瓶劲带宽相对较小的和大量多元短文档流的情况下用来取代TCP的。
UDT主要作为TCP的朋友，和TCP并存，UDT分配的带宽不应该超过根据MAX-MIN规则的最大最小公平共享原
则。（备注，最大最小规则允许UDT在高BDP连接下分配TCP不能使用的可用带宽）。我们
3. 协议说明3.1. 概述UDT是双工的，每个UDT实体有两个部分：发送和接收。发送者根据流量控制和速率控
制来发送（和重传）应用程式数据。接收者接收数据包和控制包，并根据接收到的包发送控制包。发送和接收程式共享
同一个UDP端口来发送和接收。
接收者也负责触发和处理任何的控制事件，包括拥塞控制和可靠性控制和他们的相对机制，例如RTT估计、带宽
估计、应答和重传。
UDT总是试着将应用层数据打包成固定的大小，除非数据不够这么大。和TCP相似的是，这个固定的包大小叫做
MSS（最大包大小）。由于期望UDT用来传输大块数据流，我们假定只有很小的一部分不规则的大小的包在UDT ses
sion中。MSS能够通过应用程式来安装，MTU是其最优值（包括任何包头）。
UDT拥塞控制算法将速率控制和窗口（流量控制）合并起来，前者调整包的发送周期，后者限制最大的位被应答的
包。在速率控制中使用的参数通过带宽估计技术来更新，他继承来自基于接收的包方法。同时，速率控制周期是估计R
TT的常量，流控制参数依赖于对方的数据到达速度，另外接收端释放的缓冲区的大小。
3.2. 包结构UDT有两种包：数据包和控制包。他们通过包头的第一位来区分（标志位）。假如是0，表示是数据
包，1表示是控制包。
3.2.1. 数据包
数据包结构如下显示：
0 1 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1