基于UDP的数据传输协议（UDP-based Data Transfer Protocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。 顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。 由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。
1. 简介
带宽时延积BDP
即链路上的最大比特数，也称以比特为单位的链路长度。
计算方法：
Bandwidth-Delay-Product = delay*bandwidth
由于有往返时间的要求，在收到来自接收方的确认信号之前(ACK)，发送方可以最多发送两个这样的带宽时延积。如果传送的信息量不能填满这样的“管道”，则链路未被充分利用。
随着网络带宽时延积(BDP)的增加，通常的TCP协议开始变的低效。这是因为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算法没有解决。HS TCP（RFC 3649）通过根本上改变TCP拥塞控制算法来在高BDP网络中获得高带宽利用率，但公平性问题仍然存在。
考虑到上面的背景，需要一种 在高BDP网络支持高性能数据传输的传输协议。我们推荐一个应用程式级别的传输协议，叫UDT或基于UDP的数据传输协议，并拥有拥塞控制算法。
本文描述两个正交的部分，UDP协议和UDT拥塞控制算法。一个应用层级别的协议，位于UDP之上，使用其他的拥塞算法，然而这些本文中描述的算法也能够在其他协议中实现，例如：TCP。
一个协议的参考实现叫[UDT]；周详的拥塞控制算法的性能分析在[GHG04]中能够找到。
-
UDT协议是什么？是一种基于UDP的数据传输协议（UDP-based Data Transfer Protocol，简称UDT）。
-
UDT协议的主要作用是什么？UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。
-
那么UDT与UDP的区别又是什么？UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。
-
UDT的使用场景是什么？由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。
UDT协议的主要特性有哪些？
-
基于UDP的应用层协议： 有基本网络知识的朋友都知道TCP和UDP的区别和使用场景，但是有没有一种协议能同时兼顾TCP协议的安全可靠和UDP协议的高效，那么UDT就是一种。
-
面向连接的协议：面向连接意味着两个使用协议的应用在彼此交换数据之前必须先建立一个连接，当然UDT是逻辑上存在的连接通道。这种连接的维护是基于握手、Keep-alive（保活）以及关闭连接。
-
可靠的协议：依靠包序号机制、接收者的ACK响应和丢包报告、ACK序号机制、重传机制(基于丢包报告和超时处理)来实现数据传输的可靠性。
-
双工的协议：每个UDT实例包含发送端和接收端的信息。
-
单播的数据流。
-
新的拥塞算法，并且具有可扩展的拥塞控制框架：新的拥塞控制算法不同于基于窗口的TCP拥塞控制算法(慢启动和拥塞避免)，是混合的基于窗口的、基于速率的拥塞控制算法。可扩展的拥塞控制框架开源的代码和拥塞控制的C++类架构，可支持开发者派生专用的拥塞控制算法。
-
带宽估计：UDT使用对包(PP -- Packet pair)的机制来估计带宽值。即每16个包为一组,最后一个是对包,即发送方不用等到下一个发送周期内再发送。接收方接收到对包后对其到达时间进行记录,可结合上次记录的值计算出链路的带宽(计算的方法称为中值过滤法), 并在下次ACK中进行反馈。
UDT一些主要特性的实现
-
new congestion control
-
DAIMD rate control
-
dynamic window control
UDT支持哪些数据传输类型
-
基于流的send， recv。
-
基于数据报sendmsg，recvmsg。
-
文件传输sendfile，recvfile。
下面我们结合UDT version 4版本来给大家分析下这个版本的UDT所拥有的一些新的特性。
-
使用了UDP multiplexer（UDP多路复用）机制，这样做的好处是：
UDT流控采用可配置的拥塞控制算法，你可以关闭它、配置它，改良它来实现自己需要的流控策略。
采用新的资源管理（内存管理）和共享的拥塞控制方法来支持更多并发的UDT连接。有关内存管理的介绍如下：
UDT4 has a new buffer management module that enables all UDT sockets in one process can share protocol buffer. The goodness it brings is the much less memory usage for multiple UDT connections compared to previous versions.
UDT4 can automatically resize its buffer in order to reduce memory usage while providing maximum throughput.
Because of the new memory management scheme, overlapped IO has been removed from UDT4. If your existing code uses overlapped IO, you need to modify it to use regular IO. This is the only change needed for exiting code to move from UDT3 to UDT4.
其他的特点：
不和原生socket api冲突；
线程安全；
进程间不共享句柄；
错误处理；
防火墙穿透；
安全性好；
建立连接快速；
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 session中。MSS能够通过应用程式来安装，MTU是其最优值（包括任何包头）。
UDT拥塞控制算法将速率控制和窗口（流量控制）合并起来，前者调整包的发送周期，后者限制最大的位（未？）被应答的包。在速率控制中使用的参数通过带宽估计技术来更新，他继承来自基于接收的包方法。同时，速率控制周期是估计RTT的常量，流控制参数依赖于对方的数据到达速度，另外接收端释放的缓冲区的大小。
3.2. 包结构
UDT有两种包：数据包和控制包。他们通过包头的第一位来区分（标志位）。假如是0，表示是数据包，1表示是控制包。
3.2.1. 数据包
数据包结构如下显示：
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Packet Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |FF |O| Message Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Socket ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
数据包以0开头，包序号是UDT数据包头中唯一的内容。它是个无符号整数，使用标志位后的31位，UDT包是基于序列的，例如，每个非重传的包都增加序号1。序号在到达最大值2^31-1的时候覆盖。紧跟在这些数据后面的是应用程式数据。
The next 32-bit field in the header is for the messaging. The first two bits "FF" flags the position of the packet is a message. "10" is the first packet, "01" is the last one, "11" is the only packet, and "00" is any packets in the middle. The third bit "O" means if the message should be delivered in order (1) or not (0). A message to be delivered in order requires that all previous messages must be either delivered or dropped. The rest 29 bits is the message number, similar to packet sequence number (but independent). A UDT message may contain multiple UDT packets. Following are the 32-bit time stamp when the packet is sent and the destination socket ID. The time stamp is a relative value starting
from the time when the connection is set up. The time stamp information is not required by UDT or its native control algorithm. It is included only in case that a user defined control algorithm may require the information (See Section 6).
The Destination ID is used for UDP multiplexer. Multiple UDT socket can be bound on the same UDP port and this UDT socket ID is used to differentiate the UDT connections.
3.2.2. 控制包结构
控制包结构如下：
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Additional Info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Socket ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Control Information Field ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are 8 types of control packets in UDT and the type information is put in bit field 1 - 15 of the header. The contents of the following fields depend on the packet type. The first 128 bits must exist in the packet header, whereas there may be an empty control information field, depending on the packet type.
Particularly, UDT uses sub-sequencing for ACK packet. Each ACK packet
is assigned a unique increasing 16-bit sequence number, which is
independent of the data packet sequence number. The ACK sequence
number uses bits 32 - 63 ("Additional Info") in the control packet
header. The ACK sequence number ranges from 0 to (2^31 - 1).
TYPE 0x0: Protocol Connection Handshake
Additional Info: Undefined
Control Info:
1) 32 bits: UDT version
2) 32 bits: Socket Type (STREAM or DGRAM)
3) 32 bits: initial packet sequence number
4) 32 bits: maximum packet size (including UDP/IP headers)
5) 32 bits: maximum flow window size
6) 32 bits: connection type (regular or rendezvous)
7) 32 bits: socket ID
8) 32 bits: SYN cookie
9) 128 bits: the IP address of the peer's UDP socket
TYPE 0x1: Keep-alive
Additional Info: Undefined
Control Info: None
TYPE 0x2: Acknowledgement (ACK)
Additional Info: ACK sequence number
Control Info:
1) 32 bits: The packet sequence number to which all the
previous packets have been received (excluding)
[The following fields are optional]
2) 32 bits: RTT (in microseconds)
3) 32 bits: RTT variance
4) 32 bits: Available buffer size (in bytes)
5) 32 bits: Packets receiving rate (in number of packets
per second)
6) 32 bits: Estimated link capacity (in number of packets
per second)
TYPE 0x3: Negative Acknowledgement (NAK)
Additional Info: Undefined
Control Info:
1) 32 bits integer array of compressed loss information
(see section 3.9).
TYPE 0x4: Unused
TYPE 0x5: Shutdown
Additional Info: Undefined
Control Info: None
TYPE 0x6: Acknowledgement of Acknowledgement (ACK2)
Additional Info: ACK sequence number
Control Info: None
TYPE 0x7: Message Drop Request:
Additional Info: Message ID
Control Info:
1) 32 bits: First sequence number in the message
2) 32 bits: Last sequence number in the message
TYPE 0x7FFF: Explained by bits 16 - 31, reserved for user defined
Control Packet
Finally, Time Stamp and Destination Socket ID also exist in the
control packets.
UDT 的 ACK包使用子序列。每个ACK/ACK2包有一个无符号的16位序号，它跟数据包序列号不相关。ACK序列号使用控制包头中的32 - 63 位("Additional Info")。
使用位16-31。应答需要从0到（2^16-1）。ACK序列号的范围从0~( 2^31 - 1 )。
注意，对于数据和控制包来说，能够从UDP协议头中得到实际的包大小。包大小信息能被用来得到有效的数据负载和NAK包中的控制信息字段大小。
3.3. 定时器
UDT在接收端使用4个定时器来触发不同的周期事件，每个定时器都有不同的周期，并且它们之间是相互独立的。这4个定时器包括 速率控制、应答、丢失报告（negative应答NAK）和重传/连接维护。
UDT中的定时器使用系统时间作为源。UDT接收端主动查询系统时间来检查一个定时器是否过期。对于某个定时器T来说，其拥有周期TP，将定变量t用来记录最近定时器T被配置或复位的时间。假如定时器T在系统时间t0被设置或者复位（ t = t0 ），那么任何t1（ t1 - t >= TP ）是定时器T过期的条件，定时器T过期会触发周期性事件E。
四个定时器是：RC定时器（原文为SND定时器）、ACK定时器、NAK定时器、EXP定时器。他们的周期分别是：RCTP、ATP、NTP、ETP。
RC定时器（SND定时器）只用于发送端，用来发送基于速率的包。另外三个定时器只用于接收端。
RC定时器用来触发周期性的速率控制。（见6.1）
ACK定时器用来触发应答包（ACK）。它的周期由拥塞控制模块决定。然而，如果拥塞控制不需要触发基于时间的ACK，UDT会在0.01s内发送一个ACK。
NAK被用来触发丢失包应答（NAK包）。它的周期是动态的，为4 * RTT_+ RTTVar + SYN。其中RTTVar是RTT的方差（where RTTVar is the variance of RTT samples）。
EXP重传定时器被用来触发一个数据包的重传和维护连接状态。它的周期是动态的，为N * (4 * RTT + RTTVar + SYN)，其中N为连续超时次数。为了避免不必要的超时，实现中会使用一个最小的门限值（例如：0.5s）。
推荐的周期粒度是微秒。然而，除了RC定时器外，精准的时间保持不是必要的。
（在这篇文章的余下部分，一个定时器变量机会用来表示定时器本身，也会用来表示它的周期，这取决于它的上下文。例如，ACK即可以用来表示ACK事件，也可以用来表示ACK周期。）
在每次bounded UDP接收操作（假如收到一个UDP包，一些额外的必须的数据处理时间）时查询系统时间来检查四个定时器是否已过期。UDP接收时间溢出值是实现的一个选择，这依赖于循环查询的负担和事件周期精确度之间的权衡。速率控制事件更新包发送周期STP，UDT发送端使用STP来安排数据包的发送。假定一个数据包在时间t0被发送，那么下一次包发送时间是（t0+ STP）。换句话说，假如前面的包发送花费了t’时间，发送端将等待（STP-t’）来发送下一个数据包（假如 STP - t’ = 0 ，就无需等待了）。这个等待间隔需要一个高精确度的实现，推荐使用CPU时钟周期粒度。
3.4. 发送端算法
3.4.1. 数据结构和变量A． SND PKT历史窗口：一个循环数组记录每个数据包的开始时间
B． 发送端丢失链表：发送段丢失列表是个连接链表，用来存储被接收方NAK包中返回的丢失包序号。这些数字以增加的顺序存储。
3.4.2. 数据发送算法A． 假如发送端的丢失链表是非空的，重传第一个在list中的包，并删除该成员，到5。
B． 等待有应用程式数据需要发送
C． 假如未应答的包数量超过了两量窗口的大小，转到1。假如不是包装一个新的包并发送他。
D．假如当前包的序号是16n，n是个整数，转第2步。
E． 在SND PKT历史窗口中记录包的发送时间
F． 假如这是自上次发送速率降低之后的第一个包，等外SYN时间。
G．等外（STP – t）时间，t是第1到第4步之间的总时间，然后转到1。
3.5. 接收端算法
3.5.1. 数据结构和变量
A． 接收端丢失链表：是个duple连接链表，元素的值包括：丢失数据包的序号、最近丢失包的反馈时间和包已被反馈的次数。值以包序号增序的方式存储。
B． 应答历史窗口：每个发送ACK的和时间一个循环数组；由于其循环的特性，意味着假如数组中没有更多空间的时候新的值将覆盖老的值。
C． RCV PKT历史窗口：一个用来记录每个包到达时间的循环数组。
D．对包窗口：一个用来记录每个探测包对之间的时间间隔。
E． LRSN：一个用来记录最大接收数据包需要的变量。LRSN被初始化为初始序号减1。
3.5.2. 数据接收算法
A． 查询系统时间来检查RC、ACK、NAK、或EXP定时器是否过期。假如任一定时器过期，处理事件（本节下面介绍）并复位过期的定时器。
B． 启动一个时间bounded UDP接收。假如每个包到，转1。
C． 配置exp-count为1，并更新ETP为：ETP=RTT+4*RTTVar + ATP。
D．假如任何的发送数据包已被应答，复位EXP时间变量。
E． 检查包头的标志位。假如是个控制包，根据类型处理他，然后转1。
F． 假如当前数据包的需要是16n+1，n是个整数，记录当前包和上个在对包窗口中数据包的时间间隔。
G．在PKT历史窗口中记录包到达时间
H． 假如当前数据包的序号大于LRSN+1，将任何在（但不包括）这两个值之间的序号放入接收丢失链表，并在一个NAK包中将这些序号发送给发送端。假如序号小于LRSN，从接收丢失链表中删除他。
I． 更新LRSN，转1。
3.5.3. RC定时器
到通过速率控制算法来更新STP（见3.6节）。
过程如下：
A． 按照下面的原则查找接收端所接收到的任何包之前的序号：假如接收者丢失链表是空的，ACK号码是LRSN+1，否则是在接收丢失队列中的最小序号。
B． 假如应答号不大于曾被ACK2应答的最大应答号，或等于上次应答的应答号并且两次应答之间的时间间隔小于RTT+4*RTTVar，停止（不发送应答）。
C． 分配这个应答一个唯一增加的ACK序列号，推荐采用ACK序列号按步骤1增加，并且重叠在达到最大值之后。
D．根据下面的算法来计算包的抵达速度：使用PKT历史窗口中的值计算最近16个包抵达间隔（AI）中值。在这16个值中，删除那些大于AI*8或小于AI*8的包，假如最后剩余8个值，计算他们的平均值(AI’)，包抵达速度是1/AI’（每秒包的数量），否则是0。
E． 根据3.7节中的内容为每端（W）计算流量窗口。然后计算有效的流量窗口大小为：最大（W，可用接收方缓冲大小），2）。
F． 根据下面的算法来计算连接容量估计。假如流量控制快启动阶段（3.7）一直继续，返回0，否则计算最近16个对包间隔（PI），这些值在对包窗口中，那么连接容量就是1/PI（每秒包的数量）。
G．打包应答序列号，应答号，RTT，RTT 变量，有效的流量窗口大小并估计连接，将他们放入ACK包中，然后发送出去。
H． 记录ACK序列号，应答号和这个应答的开始时间，并放入历史窗口中。
3.5.4. 处理NAK定时器到时
Ø 查找接受方的丢失链表，找到任何上次反馈时间是（k*（RTT+4*RTTVar ) ）前的包，k当前这个包的反馈次数加1，假如没有反馈丢失，停止。
Ø 压缩第一步中得到的序号（见3.9），然后在一个NAK包中发送他们到发送方。
Ø 假如不是停止流量控制快启动阶段。
3.5.5. 处理EXP定时器
A． 假如发送端的丢失链表不是空的，停止
B． 将任何未应答的包放到发送端的丢失链表中
C． 假如(exp-count>16)并且自上次从对方接收到一个包以来的总时间超过3秒，或这个时间已超过3分钟了，这被认为是连接已断开，关闭UDT连接。
D．假如没有数据，也就没有应答，发送一个保活包给对端，否则将任何未应答包的序号放入发送丢失列表中。
E． 更新exp-count为：exp-count= exp-count+1
F． 更新ETP为：ETP=exp-count*（RTT+4*RTTVar）+ATP。
3.5.6. 收到应答包
A． 更新最大的应答序号
B． 更新RTT和RTTVar为：RTT = rtt， RTTVar = rv；rtt和rv是ACK包中的RTT和RTTVar值。
C． 更新NTP和ETP为：NTP=RTT+4*RTTVar；ETP=exp-count*（RTT+4*RTTVar）+ATP。
D． 更新连接容量估计：B=（B*7+b）/8，b是ACK包带的值。
E． 更新流量窗口大小为ACK中的值。
F． 发送ACK2包，并配置和ACK序号相同的应答号到对端
G． 复位EXP定时器
3.5.7. 当收到NAK包的时候
A． 将任何NAK包中带的序号放入发送方的丢失列表中
B． 通过速率控制来更新STP（见3.6）
C． 复位EXP定时器
3.5.8. 当收到ACK2包
Ø 在ACK历史窗口中根据接收到的ACK2序列号查找行营的ACK包。
Ø 更新曾被应答的最大应答号
Ø 根据ACK2的到达时间和ACK离开时间计算新的rtt值，并且更新RTT和RTTVar值为：
RTTVar = (RTTVar *3 +abs(rtt-RTT)/4
RTT = (RTT *7+rtt)/8
RTT和RTTVar的初始值是0.1秒和0.05秒。
Ø 更新NTP和ETP为：
NTP = RTT；
ETP = (exp-count +1)* RTT+ATP
3.5.9. 当收到保活包的时候什么也不做
3.5.10. 当收到连接握手和关闭包的时候
见3.8节
3.6. 速度控制算法
3.6.1. 速率控制
快启动STP被初始为最小的时间精度（1个CPU周期或1毫秒）。这是在快启动阶段，一般收到一个ACK包其携带的估计带宽大于0这个阶段就停止了。包的发送周期被配置为1/W，W是ACK携带的流量窗口的大小。
快启动阶段仅仅在开始一个UDT连接的时候发生，且不会在UDT连接的以后再出现。在快启动阶段之后，下面的算法就要工作了。
3.6.2. 当RC定时器时间到
1． 假如在上一个RCTP时间内，没有收到一个ACK，停止
2． 计算在上个RCTP时间内的丢失率，计算方法是根据总共发送的包和NAK反馈中总共丢失包的数量。假如丢失率大于0.1%，停止。
3． 下个RCTP时间内发送包的增加数量如下计算：(inc)
If (B
Else inc = max (10^(ceil(log10((B-C)*MSS*8)))*Beta/MSS,1/MSS)
B是连接容量估计，C是当前的发送速度。两个都计算为每秒多少个包。MSS是以字节计算的；Beta是值为0.0000015的常量。
4． 更新STP：STP=（STP*RCTP）/（STP*inc + RCTP）
5． 计算真正的数据发送周期（rsp），从SND PKT历史窗口中得到，假如（STP）配置STP为（0.5 * rsp）。
6． 假如（STP），配置STP为1.0。
3.6.3. 当收到NAK包时
3.6.3.1. 数据结构和变量
1． LSD：自上次速率降低后发送的最大序号
2． NumNAK：自上次LSD更新以后的NAK数量
3． AvgNAK：当最大序号大于LSD时两次事件之间的NAK移动的平均数。
4． DR：在1到AvgNAK之间的随机平均数。
3.6.3.2. 算法
1． 假如NAK中最大的丢失序列号大于LSD：
增加STP为：STP=STP*（1+1/8）
更新AvgNAK为：AvgNAK = （AvgNAK *7 +NumNAK）/8
更新DR
复位 NumNAK = 0
记录LSD
2． 否则，增加NumNAK按照1个步骤增加；假如NumNAK % DR = 0；增加STP为：STP=STP*（1+1/8）；记录LSD。
3.7. 流量控制算法
流量控制窗口大小（W）初始值是16。
3.7.1. 当ACK定时器到的时候
1． 流量控制快启动：假如没有NAK产生或W没有到达或超过15个包，并且AS>0，流量窗口大小更新为应答包的总数量。
2． 否则，假如（AS>0），W更新为：（AS是包的到达速度）
W= ceil (W *0.875+AS* (RTT +ATP) *0.125)
3． 限制W到对方最大流量窗口大小。
3.8. 连接建立和关闭
一个UDT实体首先作为一个SERVER启动，当一个客户端需要连接的时候其发送握手包。客户端在从服务端接收到一个握手响应包或时间溢出之前，应该每隔一段时间发送一个握手包（时间间隔由响应时间和系统overhead来权衡）。
握手包有如下信息：
1． UDT版本：这个值是兼容的目的。当前的版本是2
2． 初始序号：这是发送这个UDT实体将来用于发送数据包的起始序号。他必须是个在1到（2^31-1）之间的随机值。另外，建议这个值在合理的时间历史窗口中不应该重复。
3． MSS：数据包的大小（通过IP有效负载来度量）
4． 最大的流量窗口大小：这是接收到握手信息的UDT实体允许的最大流量窗口大小，窗口大小通常限制为接收端的数据结构大小。
服务器接收到一个握手包之后，比较MSS值和他自己的值并配置他自己的值为较小的值。结果值也在握手响应中被发送到客户端，另外更有服务器的版本信息，初始序列号，最大流量窗口大小。
版本字段用来检查两端的兼容性。初始序列号和最大流量窗口大小用于初始化接收到这个握手包的UDT实体参数。
服务器在第一步完成以后就准备发送或接收数据。然而，只要从同一个客户端接收任何握手包，其应该发送响应包。
客户端一旦得到服务器的一个握手响应其就进入发送和接收数据状态。配置他自己的MSS为握手响应包中的值并初始化相应的参数为包中的值（序列号、最大流量窗口）。假如收到任何其他的握手信息，丢掉他。
假如其中的UDT实体要关闭，他将发送一个关闭信息到对端；对方收到这个信息以后将自己关闭。这个关闭信息通过UDP传输，仅仅发送一次，并不确保一定收到。假如消息没有收到，对方将根据时间溢出机制来关闭连接。
3.9. 丢失信息的压缩方案
NAK包中携带的丢失信息是个32-bit整数的数组。假如数组的中数字是个正常的序号（第1位是0），这意味着这个序号的包丢失了，假如第1位是1，意味着从这个号码开始（包括该号码）到下一个数组中的元素（包括这个元素值）之间的包（他的第1位必须是0）都丢失。
例如，下面的NAK中携带的信息：
0x00000002, 0x80000006, 0x0000000B, 0x0000000E
上面的信息表明序号为：2，6，7，8，9，10，11，14的包都丢了。
4. 效率和公平性
UDT能够充分利用当前有线网络的单独于连接容量的可用带宽 、RTT、后台共存流、给定的连接比特错误率。UDT在没有数据包丢失的情况下从0bits/s到90%带宽需要一个常量时间，这个时间是7.5秒。UDT并不适合无线网络。
UDT的确满足单瓶劲网络拓扑的最大-最小公平性。在多个瓶劲情况下，根据最大最小原则他能确保较小瓶劲连接或至少一半的平等共享(it guarantees that flows over smaller bottleneck links obtain at least half of their fair share according to max-min rule)。RTT对公平性都一点影响。
当和大块的TCP流共存的时候，TCP能占用比UDT更多的带宽，除了三种情况：
1． 网络BDP很大，TCP不能利用他们的公平共享带宽。这种情况下，UDT将占用TCP不能利用的带宽。
2． 连接容量是如此的小，从而导致UDT的带宽估计技术不能最有的工作；模拟显示这个极限连接容量大约是100kb/s。
3． 在使用FIFO队列作为网络路径的网络中，假如队列大小大于BDP，TCP的共享带宽随着队列大小的增加而降低。然而，抵达UDT的共享带宽是，队列大小通常超过实际路由器/交换机提供的数量。
当短（timewise）类似web的TCP流和小的并发UDT流共存的时候，UDT在TCP流上的效果很小。
更多的分析在[GHG03]。
5. 安全考虑UDT并没有使用特定的安全机制，相反，他依赖于应用程式提供的授权和底层提供的安全机制。
然而，由于UDP是无连接的，UDT实现应该检查任何达到的包是否是预期的来源。这是从socket的API连接概念中继承而来，其连接只是接收指定来源的数据。
6.UDT SOURCE CODE LINK
http://blog.csdn.net/yclzh0522/article/details/7019491
http://www.douban.com/note/218239055/
http://tools.ietf.org/search/draft-gg-udt-03
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
