專利名稱：Udx協(xié)議棧、基于udx協(xié)議的數(shù)據(jù)傳輸系統(tǒng)及方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信及互聯(lián)網(wǎng)數(shù)據(jù)傳輸技術(shù)，尤其涉及一種通用數(shù)據(jù)交換(UDX， Universal Data eXchange)協(xié)議棧、基于UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)及方法。
背景技術(shù)：
通信及互聯(lián)網(wǎng)等需要進行數(shù)據(jù)傳輸?shù)膱龊?，常用到傳輸控制協(xié)議(TCP)、基于UDP 的可靠傳輸協(xié)議(UDT，UDP-based Data Transfer Protocol)，其能夠用于有線、無線通信領(lǐng)域，個人計算機(PC)之間或手持終端、移動通信設(shè)備通過有線或無線網(wǎng)絡(luò)進行數(shù)據(jù)通信。 如，在移動終端與PC，PC與PC之間進行數(shù)據(jù)交換。但傳統(tǒng)網(wǎng)絡(luò)使用的TCP通信協(xié)議中擁塞控制機制建立在擁塞是網(wǎng)絡(luò)丟包原因的基礎(chǔ)上，而且為了兼容不同TCP實現(xiàn)的友好性，所以該機制不能適應(yīng)有線、無線網(wǎng)絡(luò)中高誤碼率、高延遲造成的鏈路丟包以及加速慢等情況。以傳統(tǒng)TCP協(xié)議為例，由于其發(fā)展歷史及實現(xiàn)原理有其先天和后天的原因，在很多應(yīng)用領(lǐng)域已經(jīng)不能滿足現(xiàn)有需求。為了和早期的TCP1. 1版本兼容，在算法上，采用的是保守算法，在超時重傳及發(fā)送窗口增大算法上趨于保守，使效率有一定損失。另一方面，算法在重傳策略上，也存在一些缺陷，恢復(fù)速度相對較慢。而且TCP主要是針對有線網(wǎng)設(shè)計， 在誤碼率較高的情況下，性能急劇下降。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種UDX協(xié)議棧、基于UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)及方法，以有效降低有線、無線網(wǎng)絡(luò)中的丟包率，提高傳輸效率及響應(yīng)速度，提高信道的利用率和網(wǎng)絡(luò)性能。為達到上述目的，本發(fā)明的技術(shù)方案是這樣實現(xiàn)的
一種通用數(shù)據(jù)交換UDX協(xié)議棧，包括鏈路層、網(wǎng)絡(luò)層、傳輸層及應(yīng)用層；其傳輸層采用 UDX協(xié)議，該UDX協(xié)議能夠與TCP協(xié)議、UDT協(xié)議共存于傳輸層。其中，所述UDX協(xié)議的包封裝結(jié)構(gòu)分為UDX連接包頭、UDX中轉(zhuǎn)包、UDX普通數(shù)據(jù)包以及UDX應(yīng)答包四種；其中
所述UDX連接包頭，長度為39字節(jié)，包括10字節(jié)的UDX包頭、20字節(jié)的萬網(wǎng)地址 S0CKADDR、2字節(jié)的最大窗口數(shù)、2字節(jié)的連接時間戳、1位服務(wù)器是否拒絕標(biāo)志位、7位連接過程中狀態(tài)、4字節(jié)的連接時攜帶的數(shù)據(jù)長度以及連接時攜帶的數(shù)據(jù)；
所述UDX中轉(zhuǎn)包，包括10字節(jié)的UDX包頭、64位的目的地址DEST和數(shù)據(jù)源；
所述UDX普通數(shù)據(jù)包，包括10字節(jié)的UDX包頭和數(shù)據(jù)域兩部分；
所述UDX應(yīng)答包，包括10字節(jié)的UDX包頭、8位的ack個數(shù)和8字節(jié)的ack數(shù)據(jù)。其中，所述UDX包頭，包括1位P2P標(biāo)志位、1位第一中轉(zhuǎn)注冊標(biāo)志位、1位第二中轉(zhuǎn)注冊標(biāo)志位、1位中轉(zhuǎn)包標(biāo)志位、4位保留位、16位校驗和位以及7字節(jié)的UDX子包。進一步地，所述所述UDX子包，包括16位的發(fā)送時間、32位的包序號、1位有效計算RTT標(biāo)志位、1位ack占位數(shù)為0標(biāo)志、4位包類型指示位和2位子通道序號位。
一種基于UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)，包括接入萬維網(wǎng)的應(yīng)用服務(wù)器、工作站、個人計算機、移動終端、終端監(jiān)視器以及數(shù)字信號處理DSP攝像頭；所述應(yīng)用服務(wù)器、工作站、個人計算機、移動終端、終端監(jiān)視器、數(shù)字信號處理攝像頭分別使用UDX協(xié)議連接萬維網(wǎng)；所述應(yīng)用服務(wù)器、工作站、個人計算機、移動終端、終端監(jiān)視器、數(shù)字信號處理攝像頭均能夠通過萬維網(wǎng)利用UDX協(xié)議在相互之間傳輸數(shù)據(jù)。其中，所述工作站、個人計算機、移動終端、終端監(jiān)視器、數(shù)字信號處理攝像頭均通過自身的UDX模塊接入萬維網(wǎng)。其中，工作站和個人計算機的UDX模塊中，包含應(yīng)用邏輯子模塊和通信子模塊。其中，移動終端中的的UDX模塊中，包含JAVA/C++應(yīng)用子模塊和通信子模塊。其中，終端監(jiān)視器和DSP攝像頭中，包含圖像處理子模塊和通信子模塊。一種基于UDX協(xié)議的數(shù)據(jù)傳輸方法，包括如下步驟
A、發(fā)送端通過UDX協(xié)議連接包與接收端進行三次握手，建立通信鏈路；
B、發(fā)送端通過UDX普通數(shù)據(jù)包向所述接收端發(fā)送數(shù)據(jù)；
C、接收端收到所述UDX普通數(shù)據(jù)包后，向所述接收端發(fā)送應(yīng)答包，并回傳發(fā)送時間和計算往返時間；
D、發(fā)送端接收到應(yīng)答包后，如果所述數(shù)據(jù)包接收成功，由應(yīng)用層解析數(shù)據(jù)，并由接收端驗證數(shù)據(jù)完整性。本發(fā)明所提供的UDX協(xié)議棧、基于UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)及方法，具有以下優(yōu)占.
^ \\\ ·
采用該UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)，能在高延遲、高丟包率的環(huán)境下，與TCP協(xié)議或其它同類協(xié)議相比，仍然能保持較高的傳輸效率、更少的丟包率和較佳的實時性，因而能有效利用現(xiàn)有的網(wǎng)絡(luò)帶寬，在單位時間內(nèi)可以傳輸更多的有效數(shù)據(jù)，提高吞吐量。


圖1為本發(fā)明基于UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)示意圖； 圖IA為工作站、個人計算機中UDX模塊的結(jié)構(gòu)示意圖； 圖IB為移動終端中UDX模塊的結(jié)構(gòu)示意圖IC為監(jiān)控設(shè)備、DSP攝像頭中UDX模塊的結(jié)構(gòu)示意圖； 圖2A為所述UDX協(xié)議的UDX連接包頭(39字節(jié)+額外數(shù)據(jù))結(jié)構(gòu)示意圖； 圖2B為所述UDX協(xié)議的UDX中轉(zhuǎn)包頭(18字節(jié))結(jié)構(gòu)示意圖； 圖2C為所述UDX協(xié)議的UDX普通數(shù)據(jù)包結(jié)構(gòu)示意圖2D為所述UDX協(xié)議的UDX應(yīng)答包(18字節(jié)+額外sack位，動態(tài)長度)結(jié)構(gòu)示意圖； 圖3為在PC后臺控制端與移動終端設(shè)備間利用UDX協(xié)議建立通信連接及通信的過程示意圖3A為本發(fā)明在PC后臺控制端與移動終端設(shè)備間利用UDX協(xié)議建立通信連接及進行通信的過程示意圖3B為圖3A所示網(wǎng)絡(luò)應(yīng)用TCP協(xié)議進行音頻傳輸?shù)倪^程以及其帶寬利用率的對應(yīng)情況示意圖3C為圖3A所示網(wǎng)絡(luò)應(yīng)用UDX協(xié)議進行音頻傳輸?shù)倪^程以及其帶寬利用率的對應(yīng)情況示意圖4為同等條件下利用TCP協(xié)議與UDX協(xié)議進行數(shù)據(jù)傳輸?shù)男Ч麑Ρ仁疽鈭D； 圖5為同等條件下利用UDT協(xié)議與UDX協(xié)議進行數(shù)據(jù)傳輸?shù)男Ч麑Ρ仁疽鈭D。
具體實施例方式下面結(jié)合附圖及本發(fā)明的實施例對本發(fā)明的方法作進一步詳細的說明。圖1為本發(fā)明基于UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)示意圖，如圖1所示，主要包括接入萬維網(wǎng)的應(yīng)用服務(wù)器、工作站、個人計算機、移動終端、終端監(jiān)視器以及數(shù)字信號處理(DSP)攝像頭；其中
所述應(yīng)用服務(wù)器、工作站、個人計算機、移動終端、終端監(jiān)視器、數(shù)字信號處理攝像頭分別使用UDX協(xié)議連接萬維網(wǎng)；所述應(yīng)用服務(wù)器、工作站、個人計算機、移動終端、終端監(jiān)視器、數(shù)字信號處理攝像頭均能夠通過萬維網(wǎng)利用UDX協(xié)議在相互之間傳輸數(shù)據(jù)。所述工作站、個人計算機、移動終端、終端監(jiān)視器、數(shù)字信號處理攝像頭均通過自身的UDX模塊接入萬維網(wǎng)。工作站和個人計算機的UDX模塊中，包含應(yīng)用邏輯子模塊和通信子模塊。所述工作站、個人計算機均能夠通過該應(yīng)用邏輯子模塊和通信子模塊與其它工作站、個人計算機以及移動終端、終端監(jiān)視器或DSP攝像頭利用UDX協(xié)議進行數(shù)據(jù)傳輸。移動終端中的的UDX模塊中，包含JAVA/C++應(yīng)用子模塊和通信子模塊。所述移動終端能夠通過該JAVA/C++應(yīng)用子模塊和通信子模塊與其它移動終端、工作站、個人計算機、終端監(jiān)視器或DSP攝像頭利用UDX協(xié)議進行數(shù)據(jù)傳輸。終端監(jiān)視器和DSP攝像頭中，包含圖像處理子模塊和通信子模塊。所述終端監(jiān)視器或DSP攝像頭能夠通過該圖像處理子模塊和通信子模塊與其它DSP攝像頭、終端監(jiān)視器、 移動終端、工作站或個人計算機利用UDX協(xié)議進行數(shù)據(jù)傳輸。本發(fā)明所述的UDX協(xié)議，是基于標(biāo)準(zhǔn)C++語言開發(fā)的協(xié)議棧，具有跨平臺、支持現(xiàn)有的主流平臺，如WIN、Linux、Mac、IOS等，并且32/64位兼容。能夠方便應(yīng)用于各種通信產(chǎn)品中，可集成在數(shù)字信號處理(DSP)芯片中，或可固化在硬件中，也可以純軟件的形式應(yīng)用在各種網(wǎng)絡(luò)的數(shù)據(jù)傳輸場合。該UDX協(xié)議，由于采用通用的開發(fā)語言，利用其它輔助技術(shù)，在不同的平臺上靈活應(yīng)用，能夠極大方便研發(fā)工作的進行，節(jié)約研發(fā)成本并縮短產(chǎn)品開發(fā)周期。如，在個人計算機上，可以編譯成Win32動態(tài)庫或靜態(tài)庫供應(yīng)用層調(diào)用。在移動設(shè)備上，如google的android操作系統(tǒng)上，利用JAVA調(diào)用NDK接口，間接調(diào)用UDX. SO文件， 包括蘋果系統(tǒng)，都可以很方便移值。同時也支持DSP設(shè)備，UDX協(xié)議也提供了 C接口，這樣在DSP中也可以使用，從而使協(xié)議互通，系統(tǒng)無縫聯(lián)接，發(fā)揮最大功能。這里，所述UDX協(xié)議，類似TCP/IP協(xié)議。其協(xié)議棧分為應(yīng)用層(Application)、傳輸層(Transport)、網(wǎng)絡(luò)層(Network)和鏈路層(Link)四層。在本UDX協(xié)議棧中，該UDX協(xié)議能夠與TCP協(xié)議、UDP協(xié)議以及UDT協(xié)議共存于傳輸層。下面介紹該UDX協(xié)議的數(shù)據(jù)包結(jié)構(gòu)。圖2A 圖2D分別為UDX協(xié)議的連接包、中轉(zhuǎn)包、普通數(shù)據(jù)包和應(yīng)答包封裝結(jié)構(gòu)示意圖。
如圖2A所示，UDX連接包頭，包括39字節(jié)(1字節(jié)=8位)和額外數(shù)據(jù)，該連接包頭包括有UDX包頭(10字節(jié))、S0CKADDR(即萬網(wǎng)地址20字節(jié))、最大窗口數(shù)(2字節(jié))、連接時間戳(2字節(jié))、服務(wù)器是否拒絕標(biāo)志位(1位)、連接過程中狀態(tài)(7位)、連接時攜帶的數(shù)據(jù)長度 (4字節(jié))以及連接時攜帶的數(shù)據(jù)。其中，UDX包頭(10字節(jié))進一步包括P2P標(biāo)志位(1位)、 中轉(zhuǎn)注冊標(biāo)志1 (1位)、中轉(zhuǎn)注冊標(biāo)志2 (1位)、中轉(zhuǎn)包(1位)、保留位(4位)、校驗和(16 位)和UDX子包(7字節(jié))。所述UDX子包，進一步包括發(fā)送時間(16位)、包序號(32位)、有效計算RTT標(biāo)志位(1位)、ack占位數(shù)為0標(biāo)志(1位)、包類型(4位)和子通道序號(2位)。如圖2B所示，UDX中轉(zhuǎn)包(18字節(jié)+數(shù)據(jù)域)，包括UDX包頭(10字節(jié))、DEST (目的地址64位)和數(shù)據(jù)域三部分。其中，UDX包頭部分與UDX連接包頭相同。如圖2C所示，UDX普通數(shù)據(jù)包，包括UDX包頭(10字節(jié))和數(shù)據(jù)域兩部分。其中， UDX包頭部分與UDX連接包頭相同。如圖2D所示，UDX應(yīng)答包(18字節(jié)+額外sack位，動態(tài)長度)，包括UDX包頭(10 字節(jié))、ack個數(shù)(8位)和ack數(shù)據(jù)(長度根據(jù)ack個數(shù)X 8)，該ack數(shù)據(jù)又稱動態(tài)長度。其中，UDX包頭部分與UDX連接包頭相同。圖3為本發(fā)明在PC后臺控制端與移動終端設(shè)備間利用UDX協(xié)議建立通信連接及進行通信的過程示意圖，如圖3所示，假設(shè)以PC后臺控制端與移動終端設(shè)備進行語音對講， 該過程包括
1)移動終端(發(fā)送端，客戶端)通過UDX協(xié)議中的連接包與PC (接收端，服務(wù)器端)進行三次握手后，建立數(shù)據(jù)通信鏈路。當(dāng)連接建立成功后，就能夠進行有效的數(shù)據(jù)通信了。移動終端將用戶名和密碼通過UDX協(xié)議的普通數(shù)據(jù)包進行傳遞，普通數(shù)據(jù)與連接包的區(qū)別在于其只有UDX包頭，緊接著就是數(shù)據(jù)域(用于承載數(shù)據(jù))，每個包中的序號從0開始，32位無符號序號增長，用完后，又從0開始，這樣可以無限循環(huán)使用序號。接收方，當(dāng)收到普通包后，就會發(fā)送應(yīng)答包，應(yīng)答包中也有序號，并回傳發(fā)送時間，以便發(fā)送方計算往返時間。發(fā)送方收到應(yīng)答包，如果序號匹配表示接收成功返回應(yīng)用層，應(yīng)用層解析數(shù)據(jù)，PC 方驗證數(shù)據(jù)的完整性后，通信過程就完成。在我們這里，PC收到用戶名和密碼，校驗通過后，即可進行業(yè)務(wù)數(shù)據(jù)交換。這一過程一直持續(xù)到連接斷開。移動終端采集到話筒語音后，采用AMR窄帶壓縮，調(diào)用UDX接口進行傳輸，PC方通過UDX回調(diào)接口接收到數(shù)據(jù)，解壓，并調(diào)用系統(tǒng)多媒體API進行回放，PC講話原理也類似， PC方采集，壓縮通過UDX接口發(fā)送給移動終端，移動終端解碼，并回放，這樣對講功能就是這樣實現(xiàn)了。使用UDX的好處是，它能有效的利用無線網(wǎng)絡(luò)，比傳輸?shù)钠渌鼌f(xié)議來說，語音質(zhì)量會更清晰，因為它會完整的重發(fā)丟失的數(shù)據(jù)包，如果數(shù)據(jù)包丟失就會使語音數(shù)據(jù)產(chǎn)生噪音。2)連接斷開UDX協(xié)議采用是瘦斷開，或叫不安全斷開，向遠端發(fā)送四次斷開包， 本地立即斷開。斷開包，只有一個UDX包頭，只是“包類型”為UDX_BR0KEN標(biāo)志，由于UDX協(xié)議在應(yīng)用層實現(xiàn)，而且往往應(yīng)用一半是斷開，一半處于應(yīng)用層關(guān)閉的時候，所以必須馬上退出不能等待這個斷開包是否發(fā)給了對方。但是對方如果收不到斷開消息，也可以等待超時自動斷開，因而不會造成資源的浪費。下面以移動終端(假設(shè)接入WCDMA網(wǎng)絡(luò))、個人計算機利用TCP或UDX協(xié)議通過萬維網(wǎng)與應(yīng)用流媒體服務(wù)器進行音頻傳輸?shù)膽?yīng)用為例(如圖3A所示)，對TCP協(xié)議和UDX協(xié)議的不同點進行進一步介紹
圖3B為圖3A所示網(wǎng)絡(luò)應(yīng)用TCP協(xié)議進行音頻傳輸?shù)倪^程以及其帶寬利用率的對應(yīng)情況示意圖，從圖中可以看出，由于TCP協(xié)議的實現(xiàn)原理會造成短暫的寬帶沒有充分利用，這一般是在丟包時發(fā)生，一般的有線網(wǎng)絡(luò)不會有這么嚴重，就算丟包也會很快恢復(fù)，但是在無線環(huán)境，丟包這一現(xiàn)象更加頻繁，而TCP的這一缺陷，使其不適合在無線，或高延遲網(wǎng)絡(luò)使用，特別象音視頻這類，實時性和吞吐量要求較高的應(yīng)用。由于TCP協(xié)議書波動速度傳送， 大大降低了帶寬利用率。如圖所示，該移動終端的上傳速率在8KB左右，下載速率在15 25KB左右。圖3C為圖3A所示網(wǎng)絡(luò)應(yīng)用UDX協(xié)議進行音頻傳輸?shù)倪^程以及其帶寬利用率的對應(yīng)情況示意圖，從圖中可以看出，由于UDX協(xié)議的實現(xiàn)原理及本發(fā)明中采取了一系列改進措施，能夠充分利用帶寬，提高響應(yīng)速度，即使發(fā)生丟包，UDX協(xié)議的快速重傳算法，也會很快恢復(fù)網(wǎng)絡(luò)流量，從而節(jié)省不必要的重傳，間接節(jié)省運營成本和用戶的費用。所以，UDX協(xié)議非常適合象音視頻這類，實時性和吞吐量要求較高的應(yīng)用。 本發(fā)明中的UDX協(xié)議的實現(xiàn)，采用了滑動窗口協(xié)議，但是，在其具體控制方面與傳統(tǒng)的TCP協(xié)議算法有較大不同，控制思想也不同。UDX協(xié)議控制思想，主要是通過測量兩端RTT往返時間，換算通道流量，通過控制發(fā)送流量來進行擁塞控制。其中，與傳統(tǒng)的TCP、UDT協(xié)議等其它協(xié)議相比，有如下一些不同之處
第一、帶寬估計算法。對帶寬的評估，預(yù)測，在檢測最大發(fā)送窗口的時候，是參照RENO算法，丟包檢測。 但是在這個過程中，UDX還檢測了 ACK的回復(fù)率，當(dāng)出現(xiàn)ACK回復(fù)頻率發(fā)生變化(變化率K > 0.35)時表明現(xiàn)在網(wǎng)絡(luò)出現(xiàn)了波動，可以預(yù)測已經(jīng)達到擁塞臨界，這有點象VEGAS—樣， 可以提前預(yù)測出現(xiàn)擁塞，這時UDX調(diào)整慢啟動閥值，提前進入擁塞避免階段。結(jié)合了 SACK算法，每個ACK協(xié)帶了多個應(yīng)答包，從而精確實現(xiàn)了選擇性重傳。減少了不必要的重傳。與傳統(tǒng)ACK不同點是，協(xié)帶了更多的ACK，而且設(shè)計了新的ACK結(jié)構(gòu)，增加壓縮ACK方法，從而應(yīng)答數(shù)據(jù)量也比較少。在擁塞避免階段，通過計算DIFF=minrtt* (wnd/minrtt-wnd/rtt) <avgbew*0. 35f。 提前預(yù)測擁塞，這個不同點在avgbew，這個值是通過ACK應(yīng)答計算而來，接近真實值，從而避免了傳統(tǒng)VEGAS的計算值不準(zhǔn)確(一般不準(zhǔn)確發(fā)生在，由于網(wǎng)關(guān)的硬件限速)。丟包檢測算法，每個發(fā)送包上記錄了，上次發(fā)送的時間和最大發(fā)送序號，當(dāng)收到 ACK時和當(dāng)前對應(yīng)量進行比較，可以精確知道哪個包需要重傳，而不必等到超時到來。從而可以快速響應(yīng)重傳節(jié)省了時間?？焖倩謴?fù)，當(dāng)UDX聯(lián)續(xù)收到二個新的ACK時立即恢復(fù)到先前的發(fā)送窗口，減少了恢復(fù)開消。結(jié)合WEST WOOD的，通過統(tǒng)計方式計算流量，通過RTT/WND =BEff的公式，計算理論發(fā)送窗口和實際窗口進行比較，從而提高穩(wěn)定性，使發(fā)送穩(wěn)定在實際的帶寬。
第二、快速重傳。UDX協(xié)議的ACK設(shè)計，其實就是SACK協(xié)議，但是實現(xiàn)手法是不同于SACK，SACK是首尾序號對，而UDX是一個起始序號，及后面的相對序號組成，這樣可以容納更多的ACK.當(dāng)發(fā)送方收到任何一個ACK時就可以準(zhǔn)確的確定哪個包已經(jīng)丟掉了，這時可以馬上重傳，而不需要等到超時后再重傳，從而提高了實時性及間接的提高了吞吐量。第三、AIDM上改進。慢啟動階段和TCP類是W += 1，擁塞避免階段是W += 1/W ；
UDX協(xié)議在窗口管理上，也采用了不同的設(shè)計方法。其中引入了一個飽和狀態(tài)，也就是最佳狀態(tài)。而實際發(fā)送速度是這個最佳狀態(tài)時的1.25倍發(fā)送速度。這樣可以保證較高的
竟?fàn)幮浴DX中，度量的單位是當(dāng)前流量，控制窗口的核心思想是，控制流量的增量。當(dāng)增量趨近于實際流量的<=5%波動時，認為，流量已經(jīng)最大，這時進入飽和狀態(tài)，當(dāng)UDX進入飽和狀態(tài)時，轉(zhuǎn)入擁塞避免加速模式，窗口不增大反而會減小，達到一個動態(tài)平橫，使發(fā)送速度， 始終穩(wěn)定在一個水平上。另外不同點是，窗口控制是，傳統(tǒng)TCP是每周期增長幅度最大為1，而UDX是ACK驅(qū)動窗口增長的，并沒有限制在RTT內(nèi)變化值，所以，它的加速可能會在一個RTT內(nèi)超過1。UDX針對不同的網(wǎng)絡(luò)進行了 RTT的自動適應(yīng)算法，引入了一個自定義的“理論流量”的概念，它與實際收到的數(shù)據(jù)計算的流理進行比較，當(dāng)理論流量小于實際流量時會對窗口進行校正，使其保持在當(dāng)前流量的窗口大小，這樣流量更加平穩(wěn)，不會出現(xiàn)偏差。只有流量的平穩(wěn)性才能讓其它參數(shù)有意義，否則流量控制成為空談，這也是其它算法的缺點。
丟包控制UDX每收到一個丟包信號時，會對擁塞窗口進行調(diào)整，采用sstresh = wnd*a, wnd +=b ；其中a，b (可負)是UDX經(jīng)驗值，具體參數(shù)可以調(diào)整。結(jié)合丟包控制UDX在每100個ACK到來會計算一次丟包率，根據(jù)丟包率對A，B進行調(diào)整，這樣更能結(jié)合實際網(wǎng)絡(luò)狀況對窗口進行調(diào)整。為了追求最大速度，UDX是適當(dāng)?shù)脑试S丟包，以保證數(shù)據(jù)的最大吞吐量。第四、算法上優(yōu)化。重傳策略上不同與其它算法，超時重傳是由ACK驅(qū)動，而不是僅依靠定時器，這樣可以更快的重傳數(shù)據(jù)，增加實時性。由于UDP的特性，目前UDX是采用1.5倍計算的超時時間。超時時間為RTT + 4*|dRTT|，如果按傳統(tǒng)的TCP的指數(shù)退避算法計算超時時間，在丟包和大延遲的網(wǎng)絡(luò)，性能會急劇下降。UDX主要重傳發(fā)生在ACK到來時，由于收到ACK，說明網(wǎng)絡(luò)正常，這時重發(fā)數(shù)據(jù)，比盲目依靠定時器重傳可靠的多。UDX定時器只會每次發(fā)一個重發(fā)包，當(dāng)網(wǎng)絡(luò)恢復(fù)時，就會重新依靠ACK把重發(fā)包快速發(fā)出去。啟動加速時，UDX是通過理論流量作為參考的，當(dāng)計算的理論流量，在〈1/MINRTT時，UDX是忽略丟包的，這樣可以較快的加速到實際最大帶寬
第五、針對無線調(diào)整。無線網(wǎng)絡(luò)主要特性和有線網(wǎng)絡(luò)還是比較明顯。其特點是，波動大，流量不穩(wěn)定，丟包率不固定，完全受環(huán)境的信號影響。從這個特性上來看，UDX的若干改進還是比較適合這種環(huán)境，較其它算法，更有抗丟包和干擾。比如，ACK設(shè)計及快速重傳等，提高了吞吐量和響應(yīng)時間。
第六、友好性。UDX相對TCP來說，是完全不友好的，一般UDX和TCP同時運行，TCP所占流量基本一半不到。較其它算法更具有搶占性。這個主要原因還是由于UDX協(xié)議的算法特征決定的。UDX在超時重傳上比較精確，造成別人的算法還沒有來得及恢復(fù)窗口時，UDX已經(jīng)恢復(fù)到了最佳窗口從而更多的利用帶寬。終上所述，通過以上幾個改進，在高延遲網(wǎng)絡(luò)和無線網(wǎng)絡(luò)，網(wǎng)絡(luò)傳輸性能，實時性有了比較大的提高，充份利用網(wǎng)絡(luò)。由于UDX協(xié)議的上述特點，故，應(yīng)用UDX協(xié)議能夠在高延遲，高丟包率的環(huán)境下，比傳統(tǒng)TCP或其它同類協(xié)議有更高的傳輸效率，更少的丟包率，更好的實時性，能有效利用現(xiàn)有物理帶寬，從而可以傳輸更多的有效數(shù)據(jù)，提高吞吐量。需要特別強調(diào)的是將該UDX協(xié)議應(yīng)用在無線通信領(lǐng)域上，對實時性有較明顯提高。如，在3G網(wǎng)絡(luò)中應(yīng)用TCP協(xié)議，假設(shè)網(wǎng)絡(luò)時延為300毫秒，一般一個指令來回至少需要 800毫秒至1秒的時間，如果在信號不好的地方，則需要更多時間。而應(yīng)用UDX協(xié)議通常只需要700毫秒左右的時間?？梢姡琔DX協(xié)議確實能提高網(wǎng)絡(luò)響應(yīng)的實時性。與UDX協(xié)議還能明顯提高網(wǎng)絡(luò)的吞吐量，請參考圖5。圖4為同等條件下利用TCP協(xié)議與UDX協(xié)議進行數(shù)據(jù)傳輸?shù)男Ч麑Ρ仁疽鈭D。如圖所示，以帶寬為2M的網(wǎng)絡(luò)做為測試環(huán)境，通過WANemv2. 2模擬軟件修改延遲和丟包率，假設(shè)該鏈路的時延為500ms、丟包率為15%。通過流量監(jiān)控軟件我們可以看到兩者在相同鏈路上的吞吐量差別，TCP由于丟包和折半式窗口衰減，速度逐漸下降。而UDX在吞吐量上一直保持不變，維持在210KB左右的流量在傳輸，在吞吐量上，本測試情況下，有53%左右的提高。可見，UDX協(xié)議能明顯提高數(shù)據(jù)的吞吐量。圖5為同等條件下利用UDT協(xié)議與UDX協(xié)議進行數(shù)據(jù)傳輸?shù)男Ч麑Ρ仁疽鈭D，如圖所示，在控制臺中以采用UDT4. 6版的客戶端連上公網(wǎng)的服務(wù)器模擬發(fā)送數(shù)據(jù)，我們記錄其發(fā)送有效數(shù)據(jù)速度，對appclient的輸出信息做簡單修改，輸出的第一列是實時速度，最后一列是丟包數(shù)，第二列是發(fā)送總數(shù)，統(tǒng)計并輸入表格后，進行對比，UDT4. 6版的在發(fā)送速度在最高點，開始在140KB左右，平均速度在87. 47KB/s,而丟包率在38. 4%。以采用UDX協(xié)議的Windows客戶端為測試工具，從界面上顯示的實時數(shù)據(jù)，與平均數(shù)據(jù)并列制成圖，從圖中看出，采用UDX協(xié)議的客戶端平均速度是187. 9KB，很顯然遠大于 UDT協(xié)議的客戶端，而且測試工具中顯示丟包率是12%，也遠小于UDT協(xié)議，再從流量軟件上看兩者的流量圖區(qū)別在于，UDT開始發(fā)包很猛，流量比較高，然后馬上降下來，而且不能保持。后者采用UDX協(xié)議，流量相對穩(wěn)定，且密集、飽滿。下面以500ms延遲，15%丟包鏈路為例
由于TCP的超時計算是采用指數(shù)退避算法，其超時精度是粗精度，造成巨大的誤差，而 UDX采用精確SACK確認重傳分組，并且超時也是采用準(zhǔn)確的計算超時時間⑶RRENT_RTT + 4 X I DRTT I，并且限定最大值為 AVG_RTT + —min (400ms, 0. 2f*CURRENT_RTT)，更能夠準(zhǔn)確重輸，在丟包環(huán)境，無線環(huán)境，以500ms延遲，15%丟包鏈路為例，UDX較TCP在響應(yīng)速度上，我們以echo方式回應(yīng)3K測試數(shù)據(jù)為例，做完整測試10次測量，UDX平均響應(yīng)時間為 522MS，而TCP響應(yīng)時間平均在754ms.其響應(yīng)速度要快754_522=232ms，響應(yīng)速度有34%左右的提高。可見，采用UDX協(xié)議，能夠明顯提高響應(yīng)速度。 以上所述，僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
權(quán)利要求
1.一種通用數(shù)據(jù)交換UDX協(xié)議棧，包括鏈路層、網(wǎng)絡(luò)層、傳輸層及應(yīng)用層；其特征在于， 其傳輸層采用UDX協(xié)議，該UDX協(xié)議能夠與TCP協(xié)議、UDT協(xié)議共存于傳輸層。
2.根據(jù)權(quán)利要求1所述的UDX協(xié)議棧，其特征在于，所述UDX協(xié)議的包封裝結(jié)構(gòu)分為 UDX連接包頭、UDX中轉(zhuǎn)包、UDX普通數(shù)據(jù)包以及UDX應(yīng)答包四種；其中所述UDX連接包頭，長度為39字節(jié)，包括10字節(jié)的UDX包頭、20字節(jié)的萬網(wǎng)地址 S0CKADDR、2字節(jié)的最大窗口數(shù)、2字節(jié)的連接時間戳、1位服務(wù)器是否拒絕標(biāo)志位、7位連接過程中狀態(tài)、4字節(jié)的連接時攜帶的數(shù)據(jù)長度以及連接時攜帶的數(shù)據(jù)；所述UDX中轉(zhuǎn)包，包括10字節(jié)的UDX包頭、64位的目的地址DEST和數(shù)據(jù)源；所述UDX普通數(shù)據(jù)包，包括10字節(jié)的UDX包頭和數(shù)據(jù)域兩部分；所述UDX應(yīng)答包，包括10字節(jié)的UDX包頭、8位的ack個數(shù)和8字節(jié)的ack數(shù)據(jù)。
3.根據(jù)權(quán)利要求2所述的UDX協(xié)議棧，其特征在于，所述UDX包頭，包括1位P2P標(biāo)志位、1位第一中轉(zhuǎn)注冊標(biāo)志位、1位第二中轉(zhuǎn)注冊標(biāo)志位、1位中轉(zhuǎn)包標(biāo)志位、4位保留位、16 位校驗和位以及7字節(jié)的UDX子包。
4.根據(jù)權(quán)利要求3所述的UDX協(xié)議棧，其特征在于，所述所述UDX子包，包括16位的發(fā)送時間、32位的包序號、1位有效計算RTT標(biāo)志位、1位ack占位數(shù)為0標(biāo)志、4位包類型指示位和2位子通道序號位。
5.一種基于UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)，包括接入萬維網(wǎng)的應(yīng)用服務(wù)器、工作站、個人計算機、移動終端、終端監(jiān)視器以及數(shù)字信號處理DSP攝像頭；其特征在于，所述應(yīng)用服務(wù)器、 工作站、個人計算機、移動終端、終端監(jiān)視器、數(shù)字信號處理攝像頭分別使用UDX協(xié)議連接萬維網(wǎng)；所述應(yīng)用服務(wù)器、工作站、個人計算機、移動終端、終端監(jiān)視器、數(shù)字信號處理攝像頭均能夠通過萬維網(wǎng)利用UDX協(xié)議在相互之間傳輸數(shù)據(jù)。
6.根據(jù)權(quán)利要求5所述的基于UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)，其特征在于，所述工作站、 個人計算機、移動終端、終端監(jiān)視器、數(shù)字信號處理攝像頭均通過自身的UDX模塊接入萬維網(wǎng)。
7.根據(jù)權(quán)利要求5或6所述的基于UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)，其特征在于，工作站和個人計算機的UDX模塊中，包含應(yīng)用邏輯子模塊和通信子模塊。
8.根據(jù)權(quán)利要求5或6所述的基于UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)，其特征在于，移動終端中的的UDX模塊中，包含JAVA/C++應(yīng)用子模塊和通信子模塊。
9.根據(jù)權(quán)利要求5或6所述的基于UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)，其特征在于，終端監(jiān)視器和DSP攝像頭中，包含圖像處理子模塊和通信子模塊。
10.一種基于UDX協(xié)議的數(shù)據(jù)傳輸方法，其特征在于，包括如下步驟A、發(fā)送端通過UDX協(xié)議連接包與接收端進行三次握手，建立通信鏈路；B、發(fā)送端通過UDX普通數(shù)據(jù)包向所述接收端發(fā)送數(shù)據(jù)；C、接收端收到所述UDX普通數(shù)據(jù)包后，向所述接收端發(fā)送應(yīng)答包，并回傳發(fā)送時間和計算往返時間；D、發(fā)送端接收到應(yīng)答包后，如果所述數(shù)據(jù)包接收成功，由應(yīng)用層解析數(shù)據(jù)，并由接收端驗證數(shù)據(jù)完整性。
全文摘要
本發(fā)明公開一種通用數(shù)據(jù)交換(UDX)協(xié)議棧、基于UDX協(xié)議的數(shù)據(jù)傳輸系統(tǒng)及方法，該協(xié)議棧包括鏈路層、網(wǎng)絡(luò)層、傳輸層及應(yīng)用層，其傳輸層采用UDX協(xié)議，其能夠與TCP協(xié)議、UDT協(xié)議共存。該傳輸系統(tǒng)包括接入萬維網(wǎng)的應(yīng)用服務(wù)器、工作站、個人計算機、移動終端、終端監(jiān)視器以及數(shù)字信號處理(DSP)攝像頭；所述應(yīng)用服務(wù)器、工作站、個人計算機等分別使用UDX協(xié)議連接萬維網(wǎng)；所述應(yīng)用服務(wù)器、工作站、個人計算機、移動終端、終端監(jiān)視器、數(shù)字信號處理攝像頭均能夠通過萬維網(wǎng)利用UDX協(xié)議在相互之間傳輸數(shù)據(jù)。采用本發(fā)明，能有效降低有線、無線網(wǎng)絡(luò)中的丟包率，提高傳輸效率及響應(yīng)速度，提高信道的利用率和提升網(wǎng)絡(luò)性能。
文檔編號H04L29/06GK102325146SQ20111033493
公開日2012年1月18日 申請日期2011年10月28日 優(yōu)先權(quán)日2011年10月28日
發(fā)明者李良剛 申請人:武漢杰瑞誠光電科技有限公司