UDT协议详解
基于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一些主要特性的實現
UDT包確認機制是基于時間的定時器實現的。原理：
uses timer-based selective acknowledgement, which generates an acknowledgement at a fixed interval. This means that the faster the transfer speed, the smaller the ratio of bandwidth consumed by control traffic. Meanwhile, at very low bandwidth, UDT acts like protocols using cumulative acknowledgement.
The ACK interval of UDT is the same as the rate control interval (SYN).
To support this scheme, negative acknowledgement (NAK) is used to explicitly feed back packet loss. NAK is generated once a loss is detected so that the sender can react to congestion as quickly as possible. The loss information (sequence numbers of lost packets) will be resent after an increasing interval if there are timeouts indicating that the retransmission or NAK itself has been lost.
UDT流量控制是基于以下三個機制實現的。
new congestion control
DAIMD rate control
dynamic window control
詳細說明在這：http://www.jenkinssoftware.com/raknet/manual/congestioncontrol.html
UDT支持哪些數據傳輸類型
基于流的send， recv。
基于數據報sendmsg，recvmsg。
文件傳輸sendfile，recvfile。
下面我們結合UDT version 4版本來給大家分析下這個版本的UDT所擁有的一些新的特性。
使用了UDP multiplexer（UDP多路復用）機制，這樣做的好處是：
therefore it is possible (and by default) all UDT sockets in one process will share one UDP port. This scheme makes it easier for firewall traversing.
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沖突；
線程安全；
進程間不共享句柄；
錯誤處理；
防火墻穿透；
安全性好；
建立連接快速；
以上就是我依據自己的記憶以及筆記對UDT協議進行的分析總結，筆記在此UDT協議研究.mmap?歡迎大家下載。非常感謝谷云洪博士為我們提供了這么一個優秀的協議。
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 30 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 firsttwo bits "FF" flags the position of the packet is a message. "10" isthe 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 themessage should be delivered in order (1) or not (0). A message to bedelivered in order requires that all previous messages must be eitherdelivered or dropped. The rest 29 bits is the message number, similarto packet sequence number (but independent). A UDT message maycontain multiple UDT packets.Following are the 32-bit time stamp when the packet is sent and thedestination socket ID. The time stamp is a relative value starting from the time when the connection is set up. The time stampinformation is not required by UDT or its native control algorithm.It is included only in case that a user defined control algorithm mayrequire the information (See Section 6). ? The Destination ID is used for UDP multiplexer. Multiple UDT socketcan be bound on the same UDP port and this UDT socket ID is used todifferentiate the UDT connections.3.2.2. 控制包結構
? ? ? 控制包結構如下：
? ? ? ?
0 1 2 30 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 informationis put in bit field 1 - 15 of the header. The contents of thefollowing fields depend on the packet type. The first 128 bits mustexist in the packet header, whereas there may be an empty controlinformation field, depending on the packet type. ? Particularly, UDT uses sub-sequencing for ACK packet. Each ACK packetis assigned a unique increasing 16-bit sequence number, which isindependent of the data packet sequence number. The ACK sequencenumber uses bits 32 - 63 ("Additional Info") in the control packetheader. The ACK sequence number ranges from 0 to (2^31 - 1). ? TYPE 0x0: Protocol Connection HandshakeAdditional Info: UndefinedControl Info:1) 32 bits: UDT version2) 32 bits: Socket Type (STREAM or DGRAM)3) 32 bits: initial packet sequence number4) 32 bits: maximum packet size (including UDP/IP headers)5) 32 bits: maximum flow window size6) 32 bits: connection type (regular or rendezvous) 7) 32 bits: socket ID8) 32 bits: SYN cookie9) 128 bits: the IP address of the peer's UDP socketTYPE 0x1: Keep-aliveAdditional Info: UndefinedControl Info: NoneTYPE 0x2: Acknowledgement (ACK)Additional Info: ACK sequence numberControl Info:1) 32 bits: The packet sequence number to which all theprevious packets have been received (excluding)[The following fields are optional]2) 32 bits: RTT (in microseconds)3) 32 bits: RTT variance4) 32 bits: Available buffer size (in bytes)5) 32 bits: Packets receiving rate (in number of packetsper second)6) 32 bits: Estimated link capacity (in number of packetsper second)TYPE 0x3: Negative Acknowledgement (NAK)Additional Info: UndefinedControl Info:1) 32 bits integer array of compressed loss information(see section 3.9).TYPE 0x4: UnusedTYPE 0x5: ShutdownAdditional Info: UndefinedControl Info: NoneTYPE 0x6: Acknowledgement of Acknowledgement (ACK2)Additional Info: ACK sequence numberControl Info: NoneTYPE 0x7: Message Drop Request:Additional Info: Message IDControl Info:1) 32 bits: First sequence number in the message2) 32 bits: Last sequence number in the messageTYPE 0x7FFF: Explained by bits 16 - 31, reserved for user definedControl PacketFinally, Time Stamp and Destination Socket ID also exist in thecontrol 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
總結
- 上一篇： Gis斜坡单元提取因子值
- 下一篇： 求二阶系统输入单位斜坡响应matlab,