李 濤,韓 鵬,侯冠東,2,詹佳緣

(1.西北工業(yè)大學(xué) 航海學(xué)院,西安 710072; 2.北京展訊高科通信技術(shù)有限公司,北京 100011)

0 概述

以太網(wǎng)作為目前一種通用的局域網(wǎng)通信協(xié)議標(biāo)準(zhǔn)[1],具有通信可靠、傳輸速度快、遠距離傳輸和適配多種傳輸介質(zhì)等優(yōu)點[2]。而TCP/IP協(xié)議具有開放的協(xié)議標(biāo)準(zhǔn),不依賴固定的硬件或軟件系統(tǒng),可以將TCP/IP協(xié)議集成于不同的網(wǎng)絡(luò)標(biāo)準(zhǔn)中,是當(dāng)前應(yīng)用最廣泛的網(wǎng)絡(luò)通信協(xié)議[3-4]之一。在TCP/IP協(xié)議簇中完成數(shù)據(jù)傳輸與控制的協(xié)議主要有TCP[5]和UDP[6-7],TCP協(xié)議可靠性和安全性較高,但由于傳輸過程冗雜,因此速率相對較低;UDP協(xié)議由于其面向無連接、程序機構(gòu)較簡單,因此具有較高的傳輸速率,但存在不可靠、不穩(wěn)定的弊端[8]。目前在國內(nèi)外研究成果中,有研究人員提出將TCP和UDP優(yōu)點相結(jié)合形成RUDP草案[9],但是對RUDP可靠傳輸機制中最重要的確認(rèn)與重傳以及流量控制技術(shù)卻沒有詳細討論,人們在應(yīng)用RUDP協(xié)議時只能自行設(shè)計這些機制,雖然已經(jīng)有部分自行設(shè)計得到了成功應(yīng)用,但是協(xié)議大多使用軟件編程的思想實現(xiàn),對于硬件實現(xiàn)不太適用,此外,直接借用TCP所有的可靠傳輸機制,用硬件實現(xiàn)過于復(fù)雜[10]。基于此,本文通過分析TCP 協(xié)議和可靠UDP協(xié)議,提出一種優(yōu)化的可靠 UDP 協(xié)議 ORUDP,以實現(xiàn)網(wǎng)絡(luò)數(shù)據(jù)包在傳輸過程中保證數(shù)據(jù)可靠性傳輸?shù)墓δ?同時提高傳輸速率。

1 TCP/IP協(xié)議分析及ORUDP方案設(shè)計

1.1 TCP協(xié)議

TCP協(xié)議是一種基于流的、面向連接的可靠數(shù)據(jù)傳輸協(xié)議[11],能實現(xiàn)通信雙方無差錯地發(fā)送和接收網(wǎng)絡(luò)數(shù)據(jù),在傳輸過程中不會出現(xiàn)數(shù)據(jù)丟包、數(shù)據(jù)錯包以及數(shù)據(jù)包重復(fù)、亂序和數(shù)據(jù)較多造成的網(wǎng)絡(luò)擁塞等現(xiàn)象[12]。常見的可靠機制如握手連接、滑動窗口、擁塞窗口、漏發(fā)重發(fā)、累積確認(rèn)等機制雖實現(xiàn)了網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)目煽啃?但這些機制增加了數(shù)據(jù)的復(fù)雜度和數(shù)據(jù)處理的工作量,會導(dǎo)致數(shù)據(jù)的傳輸效率變低,所以 TCP 協(xié)議主要用于對數(shù)據(jù)的可靠性要求比較高而對數(shù)據(jù)傳輸?shù)男室笠话愕膱龊蟍13],其協(xié)議格式如圖1所示。

圖1 TCP協(xié)議格式

1.2 UDP協(xié)議

UDP即用戶數(shù)據(jù)報協(xié)議,與TCP協(xié)議相比,UDP協(xié)議較為簡單,它的特點是提供無連接、盡最大努力交付基于消息包的不可靠數(shù)據(jù)傳輸服務(wù)[14]。由于其無連接性,因此不需要設(shè)計建立連接與連接釋放的功能,可以節(jié)省部分資源,此外它不提供可靠服務(wù)[15],故不需要維護待確認(rèn)數(shù)據(jù),進一步節(jié)約了資源,同時也節(jié)省了重傳、等待確認(rèn)的時間。因為UDP協(xié)議不提供流量控制,所以會節(jié)省用來控制流量的資源[16]。綜上,UDP協(xié)議以損失可靠性為代價換來極高的傳輸效率[17]。UDP協(xié)議由源端口號、目的端口號、長度、校驗和4個部分組成,協(xié)議格式如圖2所示。

圖2 UDP協(xié)議格式

1.3 ORUDP方案設(shè)計

在實際工程應(yīng)用中,需要在傳輸過程中保證數(shù)據(jù)等可靠性傳輸功能,同時還要擁有較高的傳輸速率[18]。據(jù)此,本文依據(jù)RUDP草案,引入并改進TCP可靠機制,在原有的UDP 協(xié)議首部填加一些控制字段而形成一種面向連接的基于消息包的傳輸協(xié)議。在通信雙方傳輸數(shù)據(jù)之前采用與TCP類似的建立連接機制,即三次握手建立連接,數(shù)據(jù)傳輸任務(wù)結(jié)束后雙方獨立關(guān)閉自己的傳輸通道,經(jīng)過四次握手關(guān)閉連接;在可靠機制的設(shè)計中,采用累積確認(rèn)機制,與停止等待協(xié)議相比,既可以保證數(shù)據(jù)傳輸?shù)目煽啃?又能節(jié)省發(fā)送等待確認(rèn)的時間;引入重傳機制,即只要接收方收到了非期望序號的包文,立即給接收方提交重傳請求包,并把期望的序列號發(fā)送給發(fā)送方,發(fā)送方接收到重傳請求包后立刻丟掉當(dāng)前正在傳輸?shù)臄?shù)據(jù)包,從出錯的包文處重新開始發(fā)送,而不是全部發(fā)送;選用比較節(jié)約資源的基于GBN的滑動控制機制并對其進行適當(dāng)改進作為流量控制機制;采用乒乓緩存的機制作為雙隊列加速機制。據(jù)此,設(shè)計方案在UDP協(xié)議高效傳輸?shù)幕A(chǔ)上實現(xiàn)其可靠性。

2 ORUDP原理

2.1 ORUDP格式

2.1.1 ORUDP層級結(jié)構(gòu)

ORUDP協(xié)議是在原有的 UDP 協(xié)議首部填加一些控制字段形成的一種面向連接、基于消息包的傳輸協(xié)議,從網(wǎng)絡(luò)參考模型的角度來看同樣是介于應(yīng)用層和UDP傳輸協(xié)議層之間的一層,其層級結(jié)構(gòu)如圖3所示,它的存在只是為了增加UDP協(xié)議的可靠性。

圖3 ORUDP層級結(jié)構(gòu)

2.1.2 ORUDP格式與字段含義

ORUDP各個字段的含義如下:

1)16位端口號:占用4 Byte,前兩個字節(jié)為源端口號,后兩個字節(jié)為目的端口號,用來區(qū)分通信雙方的不同進程。

2)16位包文長度:占用2 Byte,用來表示 ORUDP 數(shù)據(jù)包文的字節(jié)長度,包括首部和應(yīng)用數(shù)據(jù)。該字段最小值為18,即 ORUDP的首部字節(jié)長度。

3)16位校驗和:該字段填充包文的校驗和,運算方式為二進制反碼求和,參與運算的數(shù)據(jù)不僅包括首部和數(shù)據(jù),而且還要添加 12 Byte的偽首部參與運算,校驗和是用來保證數(shù)據(jù)傳輸?shù)恼_性,ORUDP的可靠傳輸機制主要解決丟包、亂序、重復(fù)問題。

ORUDP可以發(fā)送兩種包文,一種是用來保證可靠傳輸?shù)目刂瓢?另一種是需要傳輸?shù)臄?shù)據(jù)包文,當(dāng)各個控制字段都為0時代表普通數(shù)據(jù)包,否則即為控制包文,格式如圖4所示。

圖4 控制包文格式

ORUDP各個字段的含義如下:

1)1位的標(biāo)志位 SYN:該標(biāo)志位在建立連接時使用,當(dāng) SYN為1且ACK 為0時,代表請求連接包,若另一方同意連接,則把SYN和ACK同時置1,代表一個連接應(yīng)答包,當(dāng)SYN和FIN標(biāo)志位一起為1時代表請求關(guān)閉包。

2)1位的標(biāo)志位 ACK:當(dāng) ACK 值為1時表明這是一個應(yīng)答包,本標(biāo)志位與其他標(biāo)志位配合使用,如當(dāng)SYN和ACK都置1時代表這是一個連接應(yīng)答包,當(dāng)FIN和ACK都置1時代表這是一個關(guān)閉應(yīng)答包,僅有為1時代表數(shù)據(jù)確認(rèn)包。

3)1位的標(biāo)志位 FIN:該標(biāo)志位在關(guān)閉連接時使用,當(dāng)FIN為1且ACK 為0 時,代表請求關(guān)閉包,若另一方同意關(guān)閉,則把FIN和ACK同時置1,代表一個關(guān)閉應(yīng)答包。

4)1位的標(biāo)志位 RETR:當(dāng)RETR為1時表明當(dāng)前是一個重發(fā)請求包,用于重傳機制,發(fā)送方收到重傳請求后會從發(fā)送隊列里面重新傳送數(shù)據(jù)包。

5)1位的標(biāo)志位ACKREQ:當(dāng)ACKREQ為1時表明發(fā)送方已經(jīng)連續(xù)發(fā)送了一批數(shù)據(jù)包并且需要接收方及時確認(rèn)。

6)1位的標(biāo)志位TES:TES用在發(fā)送方和接收方建立連接后開始傳輸數(shù)據(jù)之前,發(fā)送方探測接收方緩存大小。

7)16位的序列號:該字段用來標(biāo)記發(fā)送的數(shù)據(jù)包的順序號,接收方期望包寄存器與之比對產(chǎn)生相應(yīng)的動作。

8)16位的確認(rèn)/重發(fā)序號:該字段用來填充需要確認(rèn)的 ORUDP 包序號或需要重新發(fā)送的 ORUDP 包的序號。

9)16位的重傳地址:該字段用來填充需要重傳的包在發(fā)送方發(fā)送隊列里面的位置,和重傳請求一起使用。

10)16位窗口大小:由于ORUDP采用了改進的滑動窗協(xié)議來進行流量控制,因此要增加16位的窗口大小來進行流量控制。

2.1.3 ORUDP序列號

應(yīng)用層的數(shù)據(jù)需要經(jīng)過ORUDP協(xié)議打包處理。在打包過程中會為每一個包文添加一個序列號,序列號的順序與應(yīng)用層傳送數(shù)據(jù)順序一致。包文序列號的初始值為0,每發(fā)送一個數(shù)據(jù)包,包文的序號就自動加 1。 ORUDP協(xié)議的序列號機制是為了保證接收端可以按序接收,當(dāng)發(fā)生亂序時及時重傳。

2.2 ORUDP連接與釋放

ORUDP在通信雙方傳輸數(shù)據(jù)之前采用與TCP類似的建立連接機制。在開始傳輸數(shù)據(jù)之前,發(fā)送方和接收方必須通過三次握手建立連接。數(shù)據(jù)傳輸任務(wù)結(jié)束后雙方都要獨立關(guān)閉自己的傳輸通道,只有經(jīng)過四次握手才能徹底關(guān)閉連接,具體過程如圖5所示。

圖5 ORUDP連接與釋放過程

2.3 ORUDP可靠機制

2.3.1 ORUDP確認(rèn)機制

ORUDP協(xié)議采用改進的累積確認(rèn)機制,在該機制下接收方收到一批正確的數(shù)據(jù)包才會發(fā)送確認(rèn)消息,與停止等待協(xié)議相比,既可以保證數(shù)據(jù)傳輸?shù)目煽啃?又能節(jié)省發(fā)送等待確認(rèn)及多個確認(rèn)的時間。

累積確認(rèn)機制通常是在接收方設(shè)置一個累積計數(shù)器用來統(tǒng)計正確接收的數(shù)據(jù)包的個數(shù),接收方正確接收N包數(shù)據(jù)后才會向發(fā)送方發(fā)送數(shù)據(jù)確認(rèn)包,發(fā)送方收到數(shù)據(jù)確認(rèn)包后把已經(jīng)發(fā)送的N包數(shù)據(jù)從發(fā)送隊列中清除掉,再從發(fā)送緩存區(qū)裝入N個新的數(shù)據(jù)包繼續(xù)發(fā)送[11]。該確認(rèn)機制的優(yōu)點是減少接收方發(fā)送數(shù)據(jù)確認(rèn)包的頻率,在一定程度上會減少網(wǎng)絡(luò)的擁塞狀況。但該機制容易發(fā)生數(shù)據(jù)傳輸不完整的情況,即當(dāng)發(fā)送方需要發(fā)送的數(shù)據(jù)量較小不能往隊列里面裝夠N包數(shù)據(jù),或者在發(fā)送大量數(shù)據(jù)時剩余的最后一點數(shù)據(jù)同樣不能向隊列里裝夠N包數(shù)據(jù),發(fā)送方一直不能將這些數(shù)據(jù)發(fā)送出去。

為解決這個問題,本文的確認(rèn)時機由發(fā)送方控制,在一定條件下發(fā)送方會主動發(fā)送請求確認(rèn)包,接收方不需要對按序接收的數(shù)據(jù)包進行統(tǒng)計,一旦收到發(fā)送方發(fā)來的請求確認(rèn)包,會發(fā)送數(shù)據(jù)確認(rèn)包。在這種機制下,發(fā)送時機的選擇特別重要,一般的RUDP協(xié)議發(fā)送時機選在發(fā)送隊列中裝滿時,本文除采用這種時機外,還增加了一種時機,即發(fā)送的數(shù)據(jù)量較少或者發(fā)送剩余的少量數(shù)據(jù)時,在這些數(shù)據(jù)都裝到發(fā)送隊列后等待一定時間,如果應(yīng)用層的緩存區(qū)沒有新的數(shù)據(jù)被送入立刻啟動發(fā)送進程,在被發(fā)送到隊列中的最后一包數(shù)據(jù)時發(fā)請求確認(rèn)包。

2.3.2 ORUDP重傳機制

在采用基于GBN的滑動窗口機制中,只有發(fā)送方的超時定時器溢出時才會重傳所有已經(jīng)發(fā)送但還未收到確認(rèn)的數(shù)據(jù)包,這種重傳機制在與本文的確認(rèn)機制一起使用時會出現(xiàn)2個問題:

1)增加發(fā)送方重傳等待時間,假設(shè)發(fā)送方依次發(fā)送了1號～N號共N個數(shù)據(jù)包,在發(fā)送第N號包時把請求確認(rèn)標(biāo)志位置高,代表這是一個請求確認(rèn)包,如果第N-1包在傳輸過程中丟失,當(dāng)接收方接到未按序到達的N號數(shù)據(jù)包時會發(fā)應(yīng)答包。且應(yīng)答包應(yīng)答號為N-2,發(fā)送方收到應(yīng)答包后如果重傳定時器沒有溢出,依然不會立刻重傳第N-1號數(shù)據(jù)包而且重傳定時器會重新記時。

2)容易引起不必要的重傳,還是在上述情況下,如果丟失的是第N包數(shù)據(jù),那么接收方會因為收不到請求確認(rèn)包時而不發(fā)送數(shù)據(jù)確認(rèn)包時,發(fā)送方在重傳定時器溢出后會重傳N-1包數(shù)據(jù)。

為解決上述問題,本文采用立刻重傳的機制,只要接收方收到了非期望序號的包文,立刻給接收方提交重傳請求包,并把期望的序列號發(fā)送給發(fā)送方,發(fā)送方接收到重傳請求包后立刻丟掉當(dāng)前正在傳輸?shù)臄?shù)據(jù)包,從出錯的包文處重新開始發(fā)送,而不是全部發(fā)送。

2.3.3 ORUDP定時器

ORUDP會在建立連接和連接釋放、發(fā)送方發(fā)出請求確認(rèn)包、發(fā)送方發(fā)出窗口探測包、接收方發(fā)出重傳請求包時這4種情況打開重傳定時器,如圖6

所示。發(fā)送方發(fā)出請求連接包需要接收方回復(fù)一個連接應(yīng)答包,發(fā)送方會打開重傳定時器,在定時時間內(nèi)如果沒有收到連接應(yīng)答包,發(fā)送方會重新發(fā)送請求連接包,引入定時重傳機制確保通信雙方在網(wǎng)絡(luò)正常的情況下建立連接。只要發(fā)送方或接收方提交了請求關(guān)閉包,請求關(guān)閉的一方就打開重傳定時器,定時重傳機制和建立連接的情況類似,這里不再詳述。

圖6 4種定時器工作原理

2.4 ORUDP流量控制機制

雖然RUDP草案中并沒有描述如何去控制流量,但如果不對流量進行控制很容易引起接收方緩沖區(qū)溢出。此外,在網(wǎng)絡(luò)環(huán)境不佳時容易引發(fā)網(wǎng)絡(luò)擁塞導(dǎo)致網(wǎng)絡(luò)崩潰?？紤]窗口控制機制的復(fù)雜性和硬件耗費,本文選用比較節(jié)約資源的基于GBN的改進滑動控制機制[19]。

滑動窗口的狀態(tài)由P1、P2、P3這3個指針控制,在TCP協(xié)議中P1、P3只有在發(fā)送方收到數(shù)據(jù)確認(rèn)包時才更新,在本文的設(shè)計中接收方不僅會發(fā)送數(shù)據(jù)確認(rèn)包而且還會發(fā)送重傳請求包,此時也會更新窗口狀態(tài),圖7所示為假設(shè)發(fā)送方收到重傳請求且重傳的包號為31并且通知窗口為20,說明接收方已正確接收前30包的數(shù)據(jù),這時停止發(fā)送即P2停止不動,將P1指向31,P3指向51,P2=P3就停止發(fā)送,只有收到數(shù)據(jù)確認(rèn)包后才能繼續(xù)發(fā)送新的數(shù)據(jù)包。

圖7 滑動窗口示意圖

2.5 ORUDP雙隊列加速機制

應(yīng)用進程一般用FIFO來緩存數(shù)據(jù),但是在FIFO中的數(shù)據(jù)一旦讀出就不再保存,可靠傳輸要求發(fā)送出去的數(shù)據(jù)必須等到相應(yīng)的確認(rèn)包后才能丟失,故而ORUDP使用隊列來緩存應(yīng)用層的數(shù)據(jù)。在軟件實現(xiàn)網(wǎng)絡(luò)協(xié)議棧時,數(shù)據(jù)的發(fā)送和緩存不能同時進行,而在使用硬件實現(xiàn)時可以利用并行計算的特點在發(fā)送數(shù)據(jù)時緩存新的待發(fā)數(shù)據(jù),由于ORUDP是基于包傳輸?shù)?因此在進行窗口滑動時要調(diào)整3個指針的位置,使其都指向數(shù)據(jù)包的首地址,這時不能對窗口進行操作,故而會帶來一些等待時間,為了消除這些時間,ORUDP采用乒乓緩存的機制將發(fā)送隊列拆成2個隊列同時操作,如圖8所示,一個隊列充當(dāng)發(fā)送隊列在滑動窗等可靠機制的管理下進行數(shù)據(jù)發(fā)送,另一個隊列充當(dāng)裝載隊列裝載應(yīng)用進程緩存的數(shù)據(jù),發(fā)送隊列在調(diào)整窗口狀態(tài)時不影響裝載隊列的工作。

圖8 乒乓緩存機制

2.6 ORUDP發(fā)送與接收機制

ORUDP通過握手連接、序列號、確認(rèn)號、滑動窗口、雙隊列等協(xié)同工作確保數(shù)據(jù)高效可靠傳輸。在建立連接后收發(fā)雙方各自啟動自己的接收和發(fā)送進程,發(fā)送方和接收方的工作流程如圖9和圖10所示。

圖9 發(fā)送流程

圖10 接收流程

在建立連接之后發(fā)送方處于空閑狀態(tài),如果應(yīng)用進程需要發(fā)送數(shù)據(jù),首先會把數(shù)據(jù)發(fā)送到自己的FIFO緩沖區(qū)當(dāng)中,后續(xù)的發(fā)送任務(wù)就交給ORUDP處理。處理過程主要由滑動窗口管理及雙隊列加速機制實現(xiàn)。

3 ORUDP邏輯設(shè)計

3.1 ORUDP總體設(shè)計

依據(jù)混合網(wǎng)絡(luò)參考模型,結(jié)合FPGA并行處理的特點,本文采用分層設(shè)計的思想將整個ORUDP協(xié)議棧從上到下分成可靠傳輸層、傳輸層、網(wǎng)絡(luò)層、鏈路層4個部分獨立實現(xiàn),系統(tǒng)結(jié)構(gòu)框架如圖11所示。

圖11 系統(tǒng)結(jié)構(gòu)框架

3.2 ORUDP可靠傳輸層設(shè)計

可靠傳輸是協(xié)議棧中的重點,這一層引入了各種可靠機制來保證數(shù)據(jù)可靠傳輸,為便于實現(xiàn)采用模塊化的思想,將該層拆成6個功能各異的小模塊加以實現(xiàn),具體的劃分結(jié)果如圖12所示。

圖12 可靠傳輸層劃分結(jié)果

3.2.1 連接管理模塊設(shè)計

連接管理模塊包括客戶端/服務(wù)器連接管理模塊,本模塊的作用是負責(zé) ORUDP通信過程的連接管理,作為服務(wù)器要能響應(yīng)客戶端的連接請求,作為客戶端在需要數(shù)據(jù)傳輸之前向服務(wù)器提交連接請求,只有成功建立連接雙方才能正常通信。

依據(jù)ORUDP建立連接和連接斷開過程,設(shè)計客戶端連接管理模塊有限狀態(tài)機如圖13所示,功能為進行有傳輸任務(wù)時客戶端的連接請求處理。對應(yīng)服務(wù)器連接管理模塊工作流程如圖14所示。

圖13 客戶端連接管理模塊狀態(tài)機

圖14 服務(wù)器連接管理模塊狀態(tài)機

3.2.2 數(shù)據(jù)接收模塊設(shè)計

數(shù)據(jù)接收模塊是可靠傳輸層 ORUDP 的解包模塊,本模塊的作用有兩種,一種是識別不同的包文類型,另一種是對普通的數(shù)據(jù)包文進行拆解交付到應(yīng)用層的接收 FIFO 中。依據(jù)功能的不同將 ORUDP 包文分成兩種,一種是與連接管理有關(guān)控制包文,另一種是與數(shù)據(jù)傳輸有關(guān)普通的包文?？刂瓢陌ㄕ埱筮B接包、連接應(yīng)答包、請求關(guān)閉包、關(guān)閉應(yīng)答包和建立應(yīng)答包;普通包文包括窗口探測包、數(shù)據(jù)確認(rèn)包、重傳請求包、請求確認(rèn)包和普通數(shù)據(jù)包?？蛻舳丝梢灾鲃影l(fā)起連接而服務(wù)器只能被動響應(yīng)連接,因此客戶端和服務(wù)器的數(shù)據(jù)接收模塊略有不同,具體表現(xiàn)在只有客戶端可以發(fā)送請求連接包和建立應(yīng)答包,只有服務(wù)器可以發(fā)送連接應(yīng)答包。由前述可知,ORUDP 是靠其首部的前 6 位來區(qū)分包文類型的,將其定義為命令字段,其真值表如表1所示。

表1 命令字段真值表

ORUDP接收普通包文的前提條件是必須處于連接已經(jīng)建立的狀態(tài)或者半關(guān)閉狀態(tài)(只能接收不能發(fā)送普通包文),在需要向?qū)Ψ交貜?fù)普通包文時產(chǎn)生相關(guān)控制信號給命令發(fā)送模塊,由命令發(fā)送模塊封裝成可靠傳輸層的包文。

3.2.3 命令發(fā)送模塊設(shè)計

命令發(fā)送模塊的作用是解析接收模塊和連接管理模塊發(fā)來的控制信息,根據(jù)輸入信息產(chǎn)生可靠傳輸層 ORUDP 控制包文,該模塊可以產(chǎn)生的包文有請求連接包、連接應(yīng)答包、請求關(guān)閉包、關(guān)閉應(yīng)答包、建立應(yīng)答包。普通包文包括窗口探測包、數(shù)據(jù)確認(rèn)包、重傳請求包,不能發(fā)普通數(shù)據(jù)包和請求確認(rèn)包,普通數(shù)據(jù)包不攜帶任何控制信息,而其他包文都有控制信息,因此不宜在本模塊中封裝,其狀態(tài)轉(zhuǎn)移示意圖如圖15所示。

圖15 命令發(fā)送模塊狀態(tài)轉(zhuǎn)移示意圖

3.2.4 數(shù)據(jù)管理模塊設(shè)計

數(shù)據(jù)管理模塊的作用是在雙隊列滑動窗等機制的作用下,將應(yīng)用進程發(fā)送至 FIFO中的數(shù)據(jù)高效可靠地發(fā)送給數(shù)據(jù)打包模塊,可靠傳輸層中所有的可靠機制都在這一模塊實現(xiàn),其他和數(shù)據(jù)傳輸有關(guān)的模塊只是把本模塊流出的數(shù)據(jù)包打包成ORUDP 格式的包文,該模塊的工作流程與狀態(tài)轉(zhuǎn)移、滑動窗口的滑動機制見第2節(jié)。

3.2.5 數(shù)據(jù)打包模塊設(shè)計

數(shù)據(jù)打包模塊的作用是將數(shù)據(jù)管理模塊的包文進行緩存與打包,為了保證包文的完整性,即連續(xù)輸出一包數(shù)據(jù)中間不會有缺失,該模塊使用圖16所示的雙 FIFO 架構(gòu),其中,數(shù)據(jù) FIFO緩存上級數(shù)據(jù)包,信息 FIFO統(tǒng)計完整包文的個數(shù),當(dāng)收到一包完整包文時就向信息 FIFO中寫入數(shù)據(jù),信息 FIFO中有數(shù)據(jù)代表FIFO 中有完整的包文,此時應(yīng)該打包輸出,打包過程和命令發(fā)送模塊打包過程類似,此處不再詳述,為提高傳輸效率,可以去掉包頭的 10個 0XFF,因為數(shù)據(jù)包長度足夠,不必為了拼湊成以太網(wǎng)幀格式而添加額外數(shù)據(jù),但本文為了測試方便與命令發(fā)送模塊統(tǒng)一先添加10個字節(jié)。

圖16 數(shù)據(jù)打包模塊

3.2.6 輪轉(zhuǎn)調(diào)度模塊設(shè)計

輪轉(zhuǎn)調(diào)度模塊的作用是輪流輸出命令發(fā)送模塊和數(shù)據(jù)打包模塊輸出的包文,因為 FPGA 內(nèi)部是并行處理的,命令發(fā)送模塊和數(shù)據(jù)打包模塊同時工作,但是傳輸線上的包文是逐個傳輸?shù)?為防止傳輸數(shù)據(jù)包時丟失命令包,特設(shè)計該模塊同時緩存命令數(shù)據(jù)和普通數(shù)據(jù),命令包的優(yōu)先級大于數(shù)據(jù)包。

3.3 ORUDP互連設(shè)計

經(jīng)過上文的設(shè)計,本文硬件協(xié)議的各個模塊都得以實現(xiàn),為了讓其正常工作還需要將各個模塊相互連接,確定信號的流向。在FPGA中各個模塊相連的過程與實際電路的布線類似,最終的互連結(jié)果如圖17所示,因模塊間的具體連線過于復(fù)雜,這里僅給出信號流向示意圖。

圖17 信號流向示意圖

4 ORUDP實現(xiàn)與測試

4.1 實測環(huán)境搭建

本節(jié)將使用搭載Altera公司Cyclone Ⅳ系列FPGA以及千兆網(wǎng)口的實驗開發(fā)平臺分別作為客戶端和服務(wù)器,為兩塊FPGA芯片裝載客戶端和服務(wù)器邏輯程序,借助SignalTab邏輯分析儀,捕獲芯片內(nèi)部的實時數(shù)據(jù)進行實驗驗證。

搭建好的ORUDP測試系統(tǒng)如圖18所示?？蛻舳诉x用搭載EP4CE15F23C8以及RTL8211網(wǎng)絡(luò)PHY芯片RJ45接口的實驗平臺如圖18中的A所示,服務(wù)器選用搭載EP4CE10F17C8以及RTL8211網(wǎng)絡(luò)PHY芯片RJ45接口的實驗平臺如圖18中的B所示,兩者通過網(wǎng)線直接連接。

圖18 ORUDP測試系統(tǒng)

4.2 可靠性與速度測試

在實驗室環(huán)境下只能近距離傳輸,網(wǎng)絡(luò)上不會有路由,在這種理想環(huán)境下很難出現(xiàn)數(shù)據(jù)包丟失的情況,此處人為制造丟包條件,屏蔽接收方數(shù)據(jù)確認(rèn)的功能,屏蔽以后重新下載到服務(wù)器中,測試客戶端作為發(fā)送方服務(wù)器屏蔽接收方的超時與錯誤重傳功能?？蛻舳税l(fā)送完0號～6號數(shù)據(jù)包文以后進入等待狀態(tài),由于接收方不會回應(yīng)數(shù)據(jù)確認(rèn)包,超時定時器一定會溢出并重新發(fā)送未被確認(rèn)的數(shù)據(jù)包文,如圖19所示,發(fā)送方重傳的數(shù)據(jù)包不是接收方期望的,接收方發(fā)送重傳請求,發(fā)送方收到重傳請求重新發(fā)送要求重傳的數(shù)據(jù)包,如圖20所示。

圖19 數(shù)據(jù)包的重新發(fā)送

圖20 進入等待狀態(tài)的數(shù)據(jù)包

本文選用的測量傳輸速率的方法是計算傳輸定量數(shù)據(jù)包所消耗的時間,從而算出傳輸速率,在實際的測量過程中有很多不確定因素,如環(huán)境的溫度、芯片的工作時長等都會對測試結(jié)果造成一定影響,因此進行了多次測量,將所有測量結(jié)果記錄并求平均。此外,單次測量數(shù)據(jù)量不能太小,否則時間測量的結(jié)果波動較大,降低測量結(jié)果的準(zhǔn)確性。將客戶端和服務(wù)器的雙隊列大小都設(shè)置成35 840 bit,每次傳輸1 536 Mbit大小的數(shù)據(jù)。傳輸完畢后就停止測試,記錄傳輸時間,算出傳輸速率。為了避免偶然性,在4個不同的時間段內(nèi)進行速度測試。表2是在4個不同時間段測試的結(jié)果。

表2 4個不同時間段傳輸速率

文獻[20]使用RTL8211千兆網(wǎng)PHY芯片與FPGA設(shè)計的一種TCP硬件協(xié)議棧,采用FPGA為主控芯片、88E1111為物理層網(wǎng)卡芯片,在沒有實現(xiàn)擁塞控制的情況下,實驗室環(huán)境下最大傳輸速率為360 Mb/s。文獻[21]設(shè)計增強型可靠UDP,并提出了一種補發(fā)機制,利用在發(fā)送端維護數(shù)據(jù)發(fā)送指針和數(shù)據(jù)補發(fā)指針,由補發(fā)指針來完成補發(fā)操作,發(fā)送端發(fā)出去的數(shù)據(jù)包也不需要接收端予以確認(rèn)。應(yīng)用于硬盤式高清數(shù)字機頂盒,在實驗室環(huán)境下最大傳輸速率為300 Mb/s。文獻[22]設(shè)計的基于TCP/IP的PET高速數(shù)據(jù)傳輸系統(tǒng),使用KEK日本高能加速器研究機構(gòu)設(shè)計的基于 FPGA 的TCP以太網(wǎng)協(xié)議棧 SiTCP,選用FPGA作為核心控制芯片,在實驗室環(huán)境下最大傳輸速率為360 Mb/s。而本文實現(xiàn)的ORUDP網(wǎng)絡(luò)協(xié)議棧傳輸速率可達440 Mb/s,性能優(yōu)于一般的TCP硬件網(wǎng)絡(luò)協(xié)議棧。

5 結(jié)束語

本文研究TCP/IP網(wǎng)絡(luò)協(xié)議棧,依據(jù)RUDP草案,引入并改進TCP可靠機制,設(shè)計一種基于消息包、面向連接的高速可靠網(wǎng)絡(luò)傳輸協(xié)議ORUDP。選擇FPGA進行ORUDP協(xié)議棧的邏輯設(shè)計和實現(xiàn),并設(shè)計窗口調(diào)整機制確保消息包的完整性,采用滑動窗口、雙隊列乒乓等機制保證消息包的可靠高速傳輸。在ORUDP網(wǎng)絡(luò)協(xié)議棧上的測試結(jié)果表明,該協(xié)議具有較快的傳輸速度。本文設(shè)計的ORUDP應(yīng)用場景較為簡單,僅考慮 3 臺功能計算機組網(wǎng)的情況,擁塞控制機制較弱,下一步將引入 TCP 慢啟動、快重傳等擁塞控制機制,運用FPGA芯片將GBN機制替換為傳輸效率更高的SR機制,從而提高傳輸速率。