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

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

0 概述

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

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

1.1 TCP協(xié)議

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

圖1 TCP協(xié)議格式

1.2 UDP協(xié)議

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

圖2 UDP協(xié)議格式

1.3 ORUDP方案設(shè)計(jì)

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

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

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

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

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

圖4 控制包文格式

ORUDP各個(gè)字段的含義如下:

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

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

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

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

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

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

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

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

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

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

2.1.3 ORUDP序列號

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

2.2 ORUDP連接與釋放

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

圖5 ORUDP連接與釋放過程

2.3 ORUDP可靠機(jī)制

2.3.1 ORUDP確認(rèn)機(jī)制

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

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

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

2.3.2 ORUDP重傳機(jī)制

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

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

2)容易引起不必要的重傳,還是在上述情況下,如果丟失的是第N包數(shù)據(jù),那么接收方會(huì)因?yàn)槭詹坏秸埱蟠_認(rèn)包時(shí)而不發(fā)送數(shù)據(jù)確認(rèn)包時(shí),發(fā)送方在重傳定時(shí)器溢出后會(huì)重傳N-1包數(shù)據(jù)。

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

2.3.3 ORUDP定時(shí)器

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

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

圖6 4種定時(shí)器工作原理

2.4 ORUDP流量控制機(jī)制

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

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

圖7 滑動(dòng)窗口示意圖

2.5 ORUDP雙隊(duì)列加速機(jī)制

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

圖8 乒乓緩存機(jī)制

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

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

圖9 發(fā)送流程

圖10 接收流程

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

3 ORUDP邏輯設(shè)計(jì)

3.1 ORUDP總體設(shè)計(jì)

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

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)接收模塊是可靠傳輸層 ORUDP 的解包模塊,本模塊的作用有兩種,一種是識別不同的包文類型,另一種是對普通的數(shù)據(jù)包文進(jìn)行拆解交付到應(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ù)包。客戶端可以主動(dòng)發(fā)起連接而服務(wù)器只能被動(dòng)響應(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ù)普通包文時(shí)產(chǎn)生相關(guān)控制信號給命令發(fā)送模塊,由命令發(fā)送模塊封裝成可靠傳輸層的包文。

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

命令發(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è)計(jì)

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

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

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

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

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

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

3.3 ORUDP互連設(shè)計(jì)

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

圖17 信號流向示意圖

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

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

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

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

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

4.2 可靠性與速度測試

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

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

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

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

表2 4個(gè)不同時(shí)間段傳輸速率

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

5 結(jié)束語

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