當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

UDT 最新协议分析

發(fā)布時間：2023/12/14 编程问答 35 豆豆

生活随笔收集整理的這篇文章主要介紹了 UDT 最新协议分析小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

UDT4 最新協(xié)議分析

背景
協(xié)議
- 與IETF草案版本差異
- 簡介
- 數(shù)據(jù)結(jié)構(gòu)
- - 數(shù)據(jù)包
  - 控制包
- 定時器
- 兩種連接模式
- 數(shù)據(jù)發(fā)送與接收
- - 發(fā)送端算法
  - - 發(fā)送端數(shù)據(jù)結(jié)構(gòu)
    - 數(shù)據(jù)發(fā)送算法
  - 接收端算法
  - - 接收端數(shù)據(jù)結(jié)構(gòu)
    - 數(shù)據(jù)接收算法
  - 流控
  - 丟包信息壓縮
- 可配置的擁塞控制
- - CCC接口
  - 原生控制算法
  - - 當(dāng)ACK包被接收
    - 當(dāng)NAK包被接收
- 效率與安全

背景

網(wǎng)絡(luò)帶寬占用與實際物理管道通信能力之間的矛盾愈加突出，TCP越來越不能滿足需求，傳輸效率提升需求很迫切。如果對這個領(lǐng)域細(xì)分的話，其實每個細(xì)分領(lǐng)域的需求各不一樣，比如分布式計算，實時通信，直播，在線游戲等。有些對實時性要求更高，也有些對數(shù)據(jù)完整性要求更高，當(dāng)然也有兩者兼而有之。

為什么會出現(xiàn)網(wǎng)絡(luò)傳輸效率降低呢？這有網(wǎng)絡(luò)擁塞的原因，也有傳輸協(xié)議的問題。從網(wǎng)絡(luò)擁塞上來說，最根本還是中間網(wǎng)關(guān)或管道的限制。當(dāng)大量數(shù)據(jù)涌入一個流量限制通路，路由器排隊丟失導(dǎo)致丟包；如果路由器性能不足，或者出現(xiàn)故障，也會出現(xiàn)大量的數(shù)據(jù)丟失。如果采用TCP傳輸，會導(dǎo)致數(shù)據(jù)重傳，以及傳輸窗口降低影響效率，也存在重新選路的可能。

UDT（UDP-based Data Transfer Protocol）主要針對當(dāng)前TCP進(jìn)行長距離傳輸大量數(shù)據(jù)時的性能表現(xiàn)較差而提出，建立在UDP之上，引入新的擁塞控制以及可靠性，支持可靠的流式傳輸（類似TCP），以及部分可靠的數(shù)據(jù)報傳輸（增強(qiáng)UDP）。除了高速數(shù)據(jù)傳輸之外的其它應(yīng)用領(lǐng)域，例如點到點技術(shù)（P2P），防火墻穿透，多媒體數(shù)據(jù)傳輸?shù)鹊取?/p>

協(xié)議

與IETF草案版本差異

協(xié)議內(nèi)容以代碼UDT4中包含的draft-gg-udt-xx為準(zhǔn)，更新時間為2013年。在IETF中的協(xié)議版本為draft-gg-udt-03，更新時間為2010年。

簡介

UDT是面向連接的雙工協(xié)議，每個UDT實體有兩個部分：發(fā)送和接收。發(fā)送者根據(jù)流量控制和速率控制來發(fā)送（和重傳）應(yīng)用程序數(shù)據(jù)。接收者接收數(shù)據(jù)包和控制包，并根據(jù)接收到的包發(fā)送控制包。發(fā)送和接收程序共享同一個UDP端口來發(fā)送和接收。

接收者也負(fù)責(zé)觸發(fā)和處理所有的控制事件，包括擁塞控制和可靠性控制和他們的相對機(jī)制，例如RTT估計、帶寬估計、應(yīng)答和重傳。所以整個系統(tǒng)依靠接收者對網(wǎng)絡(luò)的統(tǒng)計與計算進(jìn)行調(diào)節(jié)。

因為使用UDP傳輸，所以可能需要對應(yīng)用層數(shù)據(jù)進(jìn)行分包與重組，這樣就決定了需要有字節(jié)包頭格式。流式傳輸時需要填滿上一分包，這一點與TCP類似。從傳輸效率來看，使用流式傳輸效率更高，尤其針對大量的數(shù)據(jù)或者大塊數(shù)據(jù)。

UDT在傳輸效率優(yōu)化時，同樣希望可以兼顧到公平，所以也有自己的擁塞控制算法和流控措施。速率控制調(diào)整包的發(fā)送周期（RTT估計），擁塞窗口限制傳輸?shù)骄W(wǎng)絡(luò)的數(shù)據(jù)量（接收方數(shù)據(jù)到達(dá)速度，接收緩沖窗口大小）。

數(shù)據(jù)結(jié)構(gòu)

數(shù)據(jù)包

第一個bit為0，標(biāo)識數(shù)據(jù)包。
FF標(biāo)識一個消息中各個包的位置，11：單獨的數(shù)據(jù)包，10：一個數(shù)據(jù)流中的第一個數(shù)據(jù)包，01：一個數(shù)據(jù)流中的最后一個數(shù)據(jù)包。緊隨其后的bit位標(biāo)記是否立即發(fā)送數(shù)據(jù)。
Destination Socket ID是在端口復(fù)用時用來區(qū)分哪一個連接的數(shù)據(jù)。因為UDT支持多個連接使用同一個端口。

控制包

第1 bit為1，標(biāo)識控制包。第2-16bit標(biāo)識控制報的類型，UDT定義了8種數(shù)據(jù)類型，其余暫時保留，根據(jù)不同的類型，Additional Info與control Information內(nèi)容也會不同。

TYPE 0x0: Protocol Connection Handshake

Additional Info:

Undefined

Control Info:

32 bits: UDT version

32 bits: Socket Type (STREAM or DGRAM) 32 bits: Socket Type (STREAM or DGRAM)

32 bits: initial packet sequence number 32 bits: initial packet sequence number

32 bits: maximum packet size (including UDP/IP headers) 32 bits: maximum packet size (including UDP/IP headers)

32 bits: maximum flow window size 32 bits: maximum flow window size

32 bits: connection type (regular or rendezvous) 32 bits: connection type (regular or rendezvous)

32 bits: socket ID 32 bits: socket ID

32 bits: SYN cookie 32 bits: SYN cookie

128 bits: the IP address of the peer’s UDP socket128 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:

32 bits: The packet sequence number to which all the previous packets have been received (excluding)
[The following fields are optional]

32 bits: RTT (in microseconds)

32 bits: RTT variance

32 bits: Available buffer size (in bytes)

32 bits: Packets receiving rate (in number of packets per second)

32 bits: Estimated link capacity (in number of packets per second)

TYPE 0x3: Negative Acknowledgement (NAK)

Additional Info:

Undefined

Control Info:

32 bits integer array of compressed loss information

TYPE 0x4: Congestion/Delay Warning

Additional Info：

Undefined

Control Info：

None

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:

32 bits: First sequence number in the message

32 bits: Last sequence number in the message

定時器

協(xié)議定義了四個定時器ACK，NAK，EXP和SND。SND在發(fā)送端，其余在接收端。不同定時器觸發(fā)不同的周期事件，包括速率控制、應(yīng)答、丟失報告（negative應(yīng)答）和重傳/連接維護(hù)。定時器使用系統(tǒng)時間，并主動查詢是否到期。

SND定時器用來觸發(fā)周期性的速率控制。

ACK定時器周期被CC控制，周期性的有選擇的發(fā)送ACK包，檢查周期不超過一個SYN時間 0.01秒。

NAK被用來觸發(fā)發(fā)送NAK包。重傳定時器被用來觸發(fā)一個數(shù)據(jù)包的重傳和維護(hù)連接狀態(tài)。他們周期依賴于對于RTT的估計，周期動態(tài)更新為4 * RTT + RTTVar + SYN，RTTVar為RTT樣本方差。

EXP被用于觸發(fā)丟包重傳和維護(hù)連接狀態(tài)。周期動態(tài)更新為 N * (4 * RTT + RTTVar + SYN)， N 為連續(xù)超時的次數(shù)，且周期最小值被設(shè)定，默認(rèn)為0.5秒，以防止太頻繁被觸發(fā)。

兩種連接模式

C/S模式：客戶端服務(wù)器模式，傳統(tǒng)模式。由客戶端向服務(wù)器端發(fā)起連接請求。而服務(wù)器端需要先建立監(jiān)聽，以便接受連接請求。

Rendezvous模式：會和模式，通信雙方同時向?qū)Ψ桨l(fā)送連接請求。這種情況，在NAT穿越后較多用到。不能接受C/S模式下的連接請求。

對于已經(jīng)建立UDT連接的雙方來說，發(fā)送方發(fā)送一個關(guān)閉請求，且只發(fā)送一次。如果接受沒有接收到，需要等到16*EXP后再自行關(guān)閉?？偝瑫r有最小最大閾值，參考值設(shè)置為3秒到30秒。

數(shù)據(jù)發(fā)送與接收

發(fā)送端根據(jù)擁塞控制和流量控制，決定如何發(fā)送數(shù)據(jù)包或者重傳可能丟失的數(shù)據(jù)包。接收端負(fù)責(zé)觸發(fā)控制事件NAK、ACK和EXP，處理所有相關(guān)控制機(jī)制。

發(fā)送端算法

發(fā)送端數(shù)據(jù)結(jié)構(gòu)

發(fā)送丟失鏈表（Sender’s Loss List）
記錄從接收端返回的NAK包記錄的丟包信息以及觸發(fā)超時事件時的包序號（發(fā)生超時事件時會插入鏈表）。

數(shù)據(jù)發(fā)送算法

如果發(fā)送端丟失鏈表非空，重傳發(fā)送丟失鏈表第一個序號的包，并刪除該節(jié)點。 Goto 5。

在消息模式下，如果包已經(jīng)在發(fā)送丟失鏈表中滯留了超過應(yīng)用設(shè)定的生存時間TTL值，發(fā)送消息丟棄請求，并移除發(fā)送丟失鏈表中所有關(guān)聯(lián)包。Goto 1。

等待，直到有應(yīng)用數(shù)據(jù)被發(fā)送。

如果未確認(rèn)的數(shù)據(jù)包數(shù)量已經(jīng)超過流量/擁塞窗口，將停下來等待ACK到來。Goto 1。否則，將打包一個新的數(shù)據(jù)包并發(fā)送出去。

如果當(dāng)前包的序號為 16 n（可能超時），其中n是一個整數(shù)，Goto 2。

等待（SND - t），Goto 1。其中SND為由CC更新的包間時間間隔，t是從1)到5）的總時間。

接收端算法

接收端數(shù)據(jù)結(jié)構(gòu)

接收端丟失鏈表
包括一個二元組和一個參數(shù)。二元組為檢測到丟包的序號，和最新反饋的時間。參數(shù)k是每一個包被NAK反饋的次數(shù)。丟失鏈表中序號升序排列。
ACK 歷史窗口
記錄每個發(fā)送的ACK，以及發(fā)送時間。循環(huán)數(shù)組。
PKT 歷史窗口
記錄每個數(shù)據(jù)包的到達(dá)時間。循環(huán)數(shù)組。
包對窗口
記錄每個探測包隊的間隔時間。循環(huán)數(shù)組。
LRSN
記錄接收到的數(shù)據(jù)包最大序號，初始化為1。
ExpCount
記錄連續(xù)發(fā)生EXP超時時間的次數(shù)。

數(shù)據(jù)接收算法

數(shù)據(jù)接收算法

查詢系統(tǒng)時間，檢查ACK，NAK，EXP定時器是否已經(jīng)過期。如果存在任意一個定時器過期，都需要處理該定時器到期的對應(yīng)事件，并重置關(guān)聯(lián)時間變量。對于ACK，也會檢查ACK 包間隔。

開始存在時間限制的UDP接收過程。如果沒有包到達(dá)，Goto 1。

重置ExpCount 為1。如果沒有未確認(rèn)數(shù)據(jù)，或者收到ACK，NAK控制包，重置EXP 定時器。

檢查包頭的標(biāo)志位，如果是控制包，按照類型處理，并 Goto 1。

如果當(dāng)前包的序號是16n + 1，記錄這個包和在包對窗口記錄的最近一個數(shù)據(jù)包的時間間隔。其中n是一個整數(shù)。

在PKT歷史窗口中記錄包到達(dá)時間。

如果當(dāng)前數(shù)據(jù)包的序號sn大于 LRSN + 1，將所有介于（LRSN+1, sn）區(qū)間的所有報序號加入接收丟失鏈表。
如果當(dāng)前數(shù)據(jù)包的序號小于LRSN，從接收丟失鏈表中刪除。

更新LRSN，Goto 1。

ACK定時器事件處理過程

接收端根據(jù)如下規(guī)則查找接收到所有包之前的序號（最后確認(rèn)的最大ACK序號，即為ACK number）：
如果接收丟失鏈表非空，ACK 序號為 LRSN + 1；否則，ACK 序號為接收丟失鏈表中最小序號。

如果ACK number等于被ACK2 確認(rèn)的最大ACK序號，或者等于不超過2 RTT的上一個ACK的最大序號，停止處理（不發(fā)送這個ACK）。

每個ACK序號為唯一單調(diào)遞增的，將RTT，RTTVar，流窗口大小（可用接收緩沖大小）填充到ACK包中。如果這個ACK不是被ACK定時器觸發(fā)的，發(fā)送ACK并停止處理。

包到達(dá)速度計算：
計算存儲在PKT歷史窗口中最近16個包到達(dá)時間的中值A(chǔ)I。去掉大于 AI * 8或者AI/8的值。如果剩余超過8個，計算均值 AI’和包到達(dá)速率 1/AI’（每秒包到達(dá)個數(shù)），否則，小于8個則返回0。

鏈路容量估計：
計算包對窗口中最近的16個包對時間間隔的中值PI，鏈路容量值為1/PI（每秒包數(shù)量）。

將包到達(dá)菽粟和鏈路容量估計值打包到ACK包中發(fā)送。

記錄當(dāng)前ACK序號，ACK確認(rèn)前的最大ACK序號以及ACK發(fā)送時間將被記錄在ACK歷史窗口中。

ACK定時器事件處理過程

如果ACK number等于被ACK2 確認(rèn)的最大ACK序號，或者等于不超過2 RTT的上一個ACK的最大序號，停止處理（不發(fā)送這個ACK）。

鏈路容量估計：
計算包對窗口中最近的16個包對時間間隔的中值PI，鏈路容量值為1/PI（每秒包數(shù)量）。

將包到達(dá)菽粟和鏈路容量估計值打包到ACK包中發(fā)送。

記錄當(dāng)前ACK序號，ACK確認(rèn)前的最大ACK序號以及ACK發(fā)送時間將被記錄在ACK歷史窗口中。

NAK事件處理過程

搜索接收丟失鏈表，尋找最后的反饋時間在 k*RTT的所有包序號，k初始化為2，并且每次反饋增加1。通過NAK將所有包反饋給發(fā)送端。

EXP事件處理過程

將所有未確認(rèn)的包添加到發(fā)送丟失鏈表中。

如果ExpCount > 16，并且ExpCount被重置為1至少過去3秒，或者3分鐘過去了，關(guān)閉UDT連接并退出。

如果發(fā)送丟失鏈表為空，發(fā)送keep-alive包到對端。

ExpCount自增1.

接收到ACK 控制包的處理過程

更新最大確認(rèn)序號。

使用相同的ACK序號返回一個ACK2作為確認(rèn)的確認(rèn)。

更新RTT與RTTVar。

更新ACK和NAK周期為 4 * RTT + RTTVar + SYN。

更新流窗口大小。

如果是一個輕量級ACK，終止處理。（light ACK）

更新包到達(dá)速率為：A = (A * 7 + a) / 8，其中a為ACK中攜帶的相應(yīng)值。

更新鏈路容量估計值：B = (B * 7 + b) / 8，其中b為ACK中攜帶的相應(yīng)值。

更新發(fā)送端緩沖，釋放已經(jīng)被確認(rèn)的緩沖。

更新發(fā)送丟失鏈表，移除已經(jīng)被確認(rèn)的所有包序號。

接收到NAK 控制包的處理過程

將NAK中攜帶的所有序號添加到發(fā)送丟失鏈表中。

通過碼率控制（rate control）更新SND周期。

重置EXP時間變量。

接收到ACK2控制包的處理過程

根據(jù)ACK2中的ACK序號，在ACK歷史窗口中找到關(guān)聯(lián)的ACK。

更新被確認(rèn)的最大ACK序號。

根據(jù)ACK2到達(dá)時間和ACK離開時間，計算新的RTT：RTT = (RTT * 7 + rtt) / 8。

更新RTTVar：RTTVar = (RTTVar * 3 + abs(RTT - rtt)) / 4。

更新ACK 與 NAK周期為： 4 * RTT + RTTVar + SYN。

接收到消息丟失請求的處理過程

在接收緩沖中標(biāo)記所有屬于同一個消息的包，使得不再可讀。

在接收丟失鏈表中移除所有對應(yīng)的包。

流控

流量控制窗口初始值設(shè)置為16。
接收到ACK消息時，流窗口大小更新為接收端當(dāng)前的可用緩沖大小。

丟包信息壓縮

NAK包中攜帶的丟失信息是一個32-bit整數(shù)的數(shù)組。如果數(shù)組的第一位為0，表示這個序號的包丟失，如果第1位是1，意味著從這個號碼開始（包括該號碼）到下一個數(shù)組中的元素（包括這個元素值）之間的包（它的第1位必須是0）都丟失。例如，下面的NAK中攜帶的信息：
0x00000002, 0x80000006, 0x0000000B, 0x0000000E
上面的信息表明序號為：2，6，7，8，9，10，11，14的包都丟了

可配置的擁塞控制

UDT中的擁塞控制使用一種開放式的框架，用戶可以較容易的實現(xiàn)自定義的算法，或者在多個算法之間切換。在UDT的控制算法框架中，已經(jīng)實現(xiàn)了原生的控制算法。

用戶定義的算法可能重定義許多控制流程以及適配一些UDT參數(shù)。這些流程將在某一時間出現(xiàn)時被調(diào)用，例如，當(dāng)ACK接收到時，控制算法可能增加擁塞窗口大小。

CCC接口

UDT允許用戶接入兩個擁塞控制參數(shù)：擁塞窗口大小和包間發(fā)送時間間隔。用戶可以通過調(diào)整參數(shù)適配這兩個參數(shù)來實現(xiàn)基于窗口的控制，基于速率的控制或者混合方法。另外，下列參數(shù)也將被公開：

往返時延（RTT）。

最大包大小（Maximum Segment/Packet Size）。

估計帶寬。

目前為止被發(fā)送的最新的包序號。

接收端的包到達(dá)速率。

UDT實現(xiàn)同樣可以公開一些其他的參數(shù)，這些信息被在用戶自定義的擁塞控制算法中使用，以挑戰(zhàn)包發(fā)送速率。

下列的控制事件能通過CCC進(jìn)行重定義（比如通過回調(diào)的方式）：

Init：當(dāng)UDTsocket被連接時。

close：當(dāng)UDT socket被關(guān)閉時。

onACK：當(dāng)接收到ACK時。

onLOSS：當(dāng)接收到NACK時。

onTimeout：發(fā)生一個超時時。

onPktSent：當(dāng)一個數(shù)據(jù)包被發(fā)送時；

onPktRecv：當(dāng)一個數(shù)據(jù)包到達(dá)時。

用戶還可以在自定義算法中調(diào)整下列參數(shù)：

ACK interval：ACK可能每間隔固定數(shù)量包進(jìn)行發(fā)送。用戶可以自定義時間間隔。如果值為-1，意味著在包到達(dá)時沒有ACK被發(fā)送。

ACK Timer：ACK也可以以固定的時間間隔進(jìn)行發(fā)送，在UDT中是強(qiáng)制的。最大和缺省ACK時間間隔為SYN。

RTO：UDT用 4 * RTT + RTTVar 來估計RTO，用戶可以重定義。

原生控制算法

如果用戶沒有自定義控制算法，那么UDT缺省使用原生的控制算法，并被CCC執(zhí)行。

UDT原生算法是一種混合型的擁塞控制算法，因此需要調(diào)整擁塞窗口大小和包間間隔。原生算法使用基于定時器的ACK，ACK之間的時間間隔為SYN。

出視擁塞控制窗口大小為16個包，并且包間間隔為0，算法以慢啟動開始，直到第一個ACK或NAK到來。

當(dāng)ACK包被接收

如果當(dāng)前處于慢啟動階段，設(shè)置擁塞窗口大小為包到達(dá)速率與（RTT+SYN）的乘積，慢啟動結(jié)束。停止處理。

設(shè)置擁塞窗口大小：CWND = A * (RTT + SYN) + 16。

下一個SYN周期內(nèi)需要發(fā)送的包數(shù)量增加值為：
if (B <= C) inc = min_inc
else inc = max(10^(ceil( log10( (B-C) * PS * 8 ) )) * Beta/PS, min_inc)
其中，B 為鏈路容量估計，C為當(dāng)前發(fā)送速率估計，單位包數(shù)/秒。
Beta 是常數(shù) 0.0000015，min_inc 為最小增加值，0.01，表示每秒至少增加一個包(SYN)。

SND 周期更新為：
SND = (SND * SYN) / (SND * inc + SYN)

在碼率降低時有四個參數(shù)將被使用，初始值為圓括號內(nèi)值：

AvgNAKNum (1)：一個擁塞周期內(nèi)的平均NAK包數(shù)。

NAKCount (1)：當(dāng)前周期內(nèi)的NAK目前的數(shù)量。

DecCount(1)：一個擁塞周期的平均NAK數(shù)量。

LastDecSeq（初始序號-1）：上次包發(fā)送速率降低時的最大包序號。

一個擁塞周期被定義為介于 2個NAK包之間，并且第一個最大的丟包序號大于LastDecSeq。

當(dāng)NAK包被接收

如果處于慢啟動階段，慢啟動結(jié)束。
如果被觀察到接收速率被從包間間隔設(shè)置為 1/recvrate，停止。
否則，根據(jù)當(dāng)前窗口大小（cwnd / rtt + SYN）設(shè)置發(fā)送速率，繼續(xù)以步驟2中方法減少窗口。

如果這個NAK開始一個新的擁塞周期，增加包間時間間隔snd: snd = snd * 1.125。
更新AvgNAKNum，重置NAKCount為1，計算DecRandom為1到AvgNAKNum之間的一個平均分布的隨機(jī)數(shù)，更新LastDecSeq。停止。

如果DecCount <= 5，并且NAKCount == DecCount * DecRandom：
a. 更新SND period: SND = SND * 1.125；
b. DecCount以增加值1進(jìn)行增加；
c. 記錄當(dāng)前最大發(fā)送序號LastDecSeq。

效率與安全

UDT原生控制算法被設(shè)計給海量數(shù)據(jù)在高帶寬時延積網(wǎng)絡(luò)傳輸數(shù)據(jù)的。這也就解釋了為什么在日常使用中有些應(yīng)用批判UDT效果不佳的問題，尤其在無線網(wǎng)絡(luò)。

所以永遠(yuǎn)不要期望存在一種算法適合所有的網(wǎng)絡(luò)狀態(tài)，只能與具體的業(yè)務(wù)進(jìn)行分析，才能優(yōu)化出更好的效果。與其抱怨算法的太差，不如回頭梳理自己的需求是否一致以及如何修改或者創(chuàng)新。

UDT安全機(jī)制類似與TCP。

總結(jié)

以上是生活随笔為你收集整理的UDT 最新协议分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇：用MUI花两天时间快速开发『One·一个
下一篇：锂电池和锂离子电池命名规则