UDT協(xié)議-基于UDP的可靠數(shù)據(jù)傳輸協(xié)議_第1頁
UDT協(xié)議-基于UDP的可靠數(shù)據(jù)傳輸協(xié)議_第2頁
UDT協(xié)議-基于UDP的可靠數(shù)據(jù)傳輸協(xié)議_第3頁
UDT協(xié)議-基于UDP的可靠數(shù)據(jù)傳輸協(xié)議_第4頁
免費(fèi)預(yù)覽已結(jié)束,剩余1頁可下載查看

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、UDT協(xié)議-基于UDP的可靠數(shù)據(jù)傳輸協(xié)議分類:其他發(fā)布時(shí)間:2006-09-0111:13:03來源:技術(shù)文檔大全UDT 協(xié)議-基于 UDP 的可靠數(shù)據(jù)傳輸協(xié)議1 .介紹隨著網(wǎng)絡(luò)帶寬時(shí)延產(chǎn)品(BDP)的增加,通常的TCP協(xié)議開始變的低效。這是因?yàn)樗腁IMD(additiveincreasemultiplicativedecrease)算法徹底減少了TCP擁塞窗口,但不能快速的恢復(fù)可用帶寬。理論上的流量分析表明TCP在BDP增加到很高的時(shí)候比較容易受包損失攻擊。另外,繼承自TCP擁塞控制的不公平的RTT也成為在分布式數(shù)據(jù)密集程序中的嚴(yán)重問題。擁有不同RTT的并發(fā)TCP流將不公平地分享帶寬。盡管

2、在小的BDP網(wǎng)絡(luò)中使用通常的TCP實(shí)現(xiàn)來相對(duì)平等的共享帶寬,但在擁有大量BDP的網(wǎng)絡(luò)中,通常的基于TCP的程序就必須承受嚴(yán)重的不公平的問題。這個(gè)RTT基于的算法嚴(yán)重的限制了其在廣域網(wǎng)分布式計(jì)算的效率,例如:internet上的網(wǎng)格計(jì)算。一直到今天,對(duì)標(biāo)準(zhǔn)的TCP的提高一直都不能在高BDP環(huán)境中效率和公平性方面達(dá)到滿意的程度(特別是基于RTT的問題)。例如:TCP的修改,RFC1423(高性能擴(kuò)展),RFC2018(SACK)、RFC2582(NewReno)、RFC2883(D-SACK)、和RFC2988(RTO計(jì)算)都或多或少的提高了點(diǎn)效率,但最根本的AIMD算法沒有解決。HSTCP(RF

3、C3649)通過根本上改變TCP擁塞控制算法來在高BDP網(wǎng)絡(luò)中獲得高帶寬利用率,但公平性問題仍然存在。考慮到上面的背景,需要一種在高BDP網(wǎng)絡(luò)支持高性能數(shù)據(jù)傳輸?shù)膫鬏攨f(xié)議。我們推薦一個(gè)應(yīng)用程序級(jí)別的傳輸協(xié)議,叫UDT或基于UDP的數(shù)據(jù)傳輸協(xié)議并擁有用塞控制算法。本文描述兩個(gè)正交的部分,UDP協(xié)議和UDT擁塞控制算法。一個(gè)應(yīng)用層級(jí)別的協(xié)議,位于UDP之上,使用其他的擁塞算法,然而這些本文中描述的算法也可以在其他協(xié)議中實(shí)現(xiàn),例如:TCP。一個(gè)協(xié)議的參考實(shí)現(xiàn)叫UDT;詳細(xì)的擁塞控制算法的性能分析在GHG04中可以找到。2 .設(shè)計(jì)目標(biāo)UDT主要用在小數(shù)量的bulk源共享富裕帶寬的情況下,最典型的例子就

4、是建立在光纖廣域網(wǎng)上的網(wǎng)格計(jì)算,一些研究所在這樣的網(wǎng)絡(luò)上運(yùn)行他們的分布式的數(shù)據(jù)密集程序,例如,遠(yuǎn)程訪問儀器、分布式數(shù)據(jù)挖掘和高分辨率的多媒體流。UDT的主要目標(biāo)是效率、公平、穩(wěn)定。單個(gè)的或少量的UDT流應(yīng)該利用所有高速連接提供的可用帶寬,即使帶寬變化的很劇烈。同時(shí),所有并發(fā)的流必須公平地共享帶寬,不依賴于不同的帶寬瓶勁、起始時(shí)間、RTTo穩(wěn)定性要求包發(fā)送速率應(yīng)該一直會(huì)聚可用帶寬非常快,并且必須避免擁塞碰撞。UDT并不是在瓶勁帶寬相對(duì)較小的和大量多元短文件流的情況下用來取代TCP的。UDT主要彳為TCP的朋友,和TCP并存,UDT分配的帶寬不應(yīng)該超過根據(jù)MAX-MIN規(guī)則的最大最小公平共享原則。

5、(備注,最大最小規(guī)則允許UDT在高BDP連接下分配TCP不能使用的可用帶寬)。我們3 .協(xié)議說明3.1. 概述UDT是雙工的,每個(gè)UDT實(shí)體有兩個(gè)部分:發(fā)送和接收。發(fā)送者根據(jù)流量控制和速率控制來發(fā)送(和重傳)應(yīng)用程序數(shù)據(jù)。接收者接收數(shù)據(jù)包和控制包,并根據(jù)接收到的包發(fā)送控制包。發(fā)送和接收程序共享同一個(gè)UDP端口來發(fā)送和接收。接收者也負(fù)責(zé)觸發(fā)和處理所有的控制事件,包括擁塞控制和可靠性控制和他們的相對(duì)機(jī)制,例如RTT估計(jì)、帶寬估計(jì)、應(yīng)答和重傳。UDT總是試著將應(yīng)用層數(shù)據(jù)打包成固定的大小,除非數(shù)據(jù)不夠這么大。和TCP相似的是,這個(gè)固定的包大小叫做MSS(最大包大小)。由于期望UDT用來傳輸大塊數(shù)據(jù)流,

6、我們假定只有很小的一部分不規(guī)則的大小的包在UDTsession中。MSS可以通過應(yīng)用程序來安裝,MTU是其最優(yōu)值(包括所有包頭)。UDT擁塞控制算法將速率控制和窗口(流量控制)合并起來,前者調(diào)整包的發(fā)送周期,后者限制最大的位被應(yīng)答的包。在速率控制中使用的參數(shù)通過帶寬估計(jì)技術(shù)來更新,它繼承來自基于接收的包方法。同時(shí),速率控制周期是估計(jì)RTT的常量,流控制參數(shù)依賴于對(duì)方的數(shù)據(jù)到達(dá)速度,另外接收端釋放的緩沖區(qū)的大小。3.2. 包結(jié)構(gòu)UDT有兩種包:數(shù)據(jù)包和控制包。他們通過包頭的第一位來區(qū)分(標(biāo)志位)。如果是0,表示是數(shù)據(jù)包,1表示是控制包。3.2.1.數(shù)據(jù)包數(shù)據(jù)包結(jié)構(gòu)如下顯示:01340123456

7、78901234567890123456789010I 包序號(hào)應(yīng)用數(shù)據(jù)包序號(hào)是UDT數(shù)據(jù)包頭中唯一的內(nèi)容。它是一個(gè)無符號(hào)整數(shù),使用標(biāo)志位后的31位,UDT使用包基礎(chǔ)的需要,例如,每個(gè)非重傳的包都增加序號(hào)1。序號(hào)在到達(dá)最大值2A31-1的時(shí)候覆蓋。緊跟在這些數(shù)據(jù)后面的是應(yīng)用程序數(shù)據(jù)。3.2.2.控制包控制包結(jié)構(gòu)如下:013401234567890123456789012345678901類型保留 ACK 序號(hào)控制信息字段有6種類型的控制包在UDT中,bit1-3表示這些信息。前32位在包頭中必須存在。控制信息字段包括0(例如,它不存在)或者多個(gè)32位無符號(hào)整數(shù),這由包類型決定。UDT使用應(yīng)答子序

8、號(hào)的方法。每個(gè)ACK/ACK2包有一個(gè)無符號(hào)的16位序號(hào),它獨(dú)立于數(shù)據(jù)包需要。它使用位16-31。應(yīng)答需要從0到(2人16-1)。位16-31在其他控制包中沒有定義。類型說明控制信息000協(xié)議連接握手.32 位 UDT 版本32 位內(nèi)部順序號(hào)32 位 MSS(字節(jié))4.32 位最大流量窗口大?。ㄗ止?jié))001?;顩]有010應(yīng)答,位 16-31 是應(yīng)答序號(hào)1.32 位包序號(hào),先前接收到的包序號(hào)e5232 位,RTT(微秒)e5232 位,RTT 變量或者 RTTVar(微秒)e5232 位,流量窗口大?。ò臄?shù)量)e5232 位,連接容量估計(jì)(每秒包的數(shù)量)011Negative 應(yīng)答(NAK)丟

9、失信息的 32 位整數(shù)數(shù)組,見 3.9 節(jié)100保留這種類型的控制信息保留作為擁塞警告使用,從接收到發(fā)送端。 一個(gè)擁塞警告能被 ECN 或包延遲增加趨勢(shì)的度量方法觸發(fā)。101關(guān)閉110應(yīng)答一個(gè)應(yīng)答(ACK2)16-31 位,應(yīng)答序號(hào)。1114-15 的解釋保留將來使用注意,對(duì)于數(shù)據(jù)和控制包來說,可以從UDP協(xié)議頭中得到實(shí)際的包大小。包大小信息能被用來得到有效的數(shù)據(jù)負(fù)載和NAK包中的控制信息字段大小。3.3. 定時(shí)器UDT在接收端使用4個(gè)定時(shí)器來觸發(fā)不同的周期事件,包括速率控制、應(yīng)答、丟失報(bào)告(negative應(yīng)答)和重傳/連接維護(hù)。UDT中的定時(shí)器使用系統(tǒng)時(shí)間作為源。UDT接收端主動(dòng)查詢系統(tǒng)時(shí)

10、間來檢查一個(gè)定時(shí)器是否過期。對(duì)于某個(gè)定時(shí)器T來說,其擁有周期TP,將定變量t用來記錄最近T被設(shè)置或復(fù)位的時(shí)間。如果T在系統(tǒng)時(shí)間t0(t=t0)被復(fù)位,那么任何t1(t1-t=TP)是T過期的條件。四個(gè)定時(shí)器是:RC定時(shí)器、ACK定時(shí)器、NAK定時(shí)器、EXP定時(shí)器。他們的周期分別是:RCTP、ATP、NTP、ETP。RC定時(shí)器用來觸發(fā)周期性的速率控制。ACK定時(shí)器用來觸發(fā)周期性的有選擇的應(yīng)答(應(yīng)答包)。RCTP和ATP是常量值,值為:RCTP=ATP=0.01秒。NAK被用來觸發(fā)negative應(yīng)答(NAK包)。重傳定時(shí)器被用來觸發(fā)一個(gè)數(shù)據(jù)包的重傳和維護(hù)連接狀態(tài)。他們周期依賴于對(duì)于RTT的估計(jì)。

11、ETP值也依賴于連續(xù)EXP時(shí)間溢出的次數(shù)。推薦的RTT初始值是0.1秒,而NTP和ETP的初始值是:NTP=3*RTT,ETP=3*RTT+ATP。在每次boundedUDP接收操作(如果收到一個(gè)UDP包,一些額外的必須的數(shù)據(jù)處理時(shí)間)時(shí)查詢系統(tǒng)時(shí)間來檢查四個(gè)定時(shí)器是否已經(jīng)過期。推薦的周期粒度是微秒。UDP接收時(shí)間溢出值是實(shí)現(xiàn)的一個(gè)選擇,這依賴于循環(huán)查詢的負(fù)擔(dān)和事件周期精確度之間的權(quán)衡。速率控制事件更新包發(fā)送周期,UDT發(fā)送端使用STP來安排數(shù)據(jù)包的發(fā)送。假定一個(gè)在時(shí)間t0被發(fā)送,那么下一次包發(fā)送時(shí)間是(t0+STP)。換句話說,如果前面的包發(fā)送花費(fèi)了t時(shí)間,發(fā)送端將等待(STP-t)來發(fā)送下

12、一個(gè)數(shù)據(jù)包(如果STP-t0,就不需要等待了)。這個(gè)等待間隔需要一個(gè)高精確度的實(shí)現(xiàn),推薦使用CPU時(shí)鐘周期粒度。3.4. 發(fā)送端算法3.4.1.數(shù)據(jù)結(jié)構(gòu)和變量A.SNDPKT 歷史窗口:一個(gè)循環(huán)數(shù)組記錄每個(gè)數(shù)據(jù)包的開始時(shí)間B.發(fā)送端丟失鏈表:發(fā)送段丟失列表是一個(gè)連接鏈表,用來存儲(chǔ)被接收方 NAK 包中返回的丟失包序號(hào)。這些數(shù)字以增加的順序存儲(chǔ)。3.4.2.數(shù)據(jù)發(fā)送算法A.如果發(fā)送端的丟失鏈表是非空的,重傳第一個(gè)在 list 中的包,并刪除該成員,到 5。B.等待有應(yīng)用程序數(shù)據(jù)需要發(fā)送C.如果未應(yīng)答的包數(shù)量超過了兩量窗口的大小,轉(zhuǎn)到 1。如果不是包裝一個(gè)新的包并發(fā)送它。D.如果當(dāng)前包的序號(hào)是 1

13、6n,n 是一個(gè)整數(shù),轉(zhuǎn)第 2 步。E.在 SNDPKT 歷史窗口中記錄包的發(fā)送時(shí)間F.如果這是自上次發(fā)送速率降低之后的第一個(gè)包,等外 SYN 時(shí)間。G.等外(STP-1)時(shí)間,t 是第 1 到第 4 步之間的總時(shí)間,然后轉(zhuǎn)到 1。3.5. 接收端算法3.5.1.數(shù)據(jù)結(jié)構(gòu)和變量A.接收端丟失鏈表:是一個(gè) duple 連接鏈表,元素的值包括:丟失數(shù)據(jù)包的序號(hào)、最近丟失包的反饋時(shí)間和包已經(jīng)被反饋的次數(shù)。值以包序號(hào)增序的方式存儲(chǔ)。B.應(yīng)答歷史窗口:每個(gè)發(fā)送 ACK 的和時(shí)間一個(gè)循環(huán)數(shù)組;由于其循環(huán)的特性,意味著如果數(shù)組中沒有更多空間的時(shí)候新的值將覆蓋老的值。C.RCVPKT 歷史窗口:一個(gè)用來記錄每

14、個(gè)包到達(dá)時(shí)間的循環(huán)數(shù)組。D.對(duì)包窗口:一個(gè)用來記錄每個(gè)探測(cè)包對(duì)之間的時(shí)間間隔。E.LRSN:一個(gè)用來記錄最大接收數(shù)據(jù)包需要的變量。LRSN 被初始化為初始序號(hào)減 1。據(jù)接收算法A.查詢系統(tǒng)時(shí)間來檢查 RC、ACK、NAK、或 EXP 定時(shí)器是否過期。如果任一定時(shí)器過期,處理事件(本節(jié)下面介紹)并復(fù)位過期的定時(shí)器。B.啟動(dòng)一個(gè)時(shí)間 boundedUDP 接收。如果每個(gè)包到,轉(zhuǎn) 1。C,設(shè)置 exp-count 為 1,并更新 ETP 為:ETP=RTT+4*RTTVar+ATP。D.如果所有的發(fā)送數(shù)據(jù)包已經(jīng)被應(yīng)答,復(fù)位 EXP 時(shí)間變量。E.檢查包頭的標(biāo)志位。如果是一個(gè)控制包,根據(jù)類型處理它,然

15、后轉(zhuǎn) 1。F.如果當(dāng)前數(shù)據(jù)包的需要是 16n+1,n 是一個(gè)整數(shù),記錄當(dāng)前包和上個(gè)在對(duì)包窗口中數(shù)據(jù)包的時(shí)間間隔。G.在 PKT 歷史窗口中記錄包到達(dá)時(shí)間H.如果當(dāng)前數(shù)據(jù)包的序號(hào)大于 LRSN+1,將所有在(但不包括)這兩個(gè)值之間的序號(hào)放入接收丟失鏈表,并在一個(gè) NAK 包中將這些序號(hào)發(fā)送給發(fā)送端。如果序號(hào)小于 LRSN,從接收丟失鏈表中刪除它。I.更新 LRSN,車專1。C 定時(shí)器到通過速率控制算法來更新STP(見3.6節(jié))。過程如下:A.按照下面的原則查找接收端所接收到的所有包之前的序號(hào):如果接收者丟失鏈表是空的,ACK 號(hào)碼是LRSN+1,否則是在接收丟失隊(duì)列中的最小序號(hào)。B.如果應(yīng)答號(hào)不大于曾經(jīng)被 ACK2 應(yīng)答的最大應(yīng)答號(hào),或等于上次應(yīng)答的應(yīng)答號(hào)并且兩次應(yīng)答之間的時(shí)間間隔小于RTT+4*RTTVar,停止(不發(fā)送應(yīng)答)。C.分配這個(gè)應(yīng)答一個(gè)唯一增加的 ACK 序列號(hào),推薦采用 ACK 序列號(hào)按步驟 1 增加,并且重疊在達(dá)到最大值之后。D.根據(jù)下面的算法來計(jì)算包的抵達(dá)速度:使用 PKT 歷史窗口中的值計(jì)算最近 16 個(gè)包抵達(dá)間隔(AI)中值。在這 16 個(gè)值中, 刪除那些大于 AI*8 或小于 AI*8 的包, 如果最后剩余 8 個(gè)值, 計(jì)算他們的平均值(AI,) 包抵達(dá)速度是 1/AI(每秒包的數(shù)量),否則是 0。E.根據(jù) 3.7 節(jié)中的內(nèi)

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論