基于FPGA的ORUDP協議棧設計與實現

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

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

0 概述

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

1 TCP/IP協議分析及ORUDP方案設計

1.1 TCP協議

TCP協議是一種基于流的、面向連接的可靠數據傳輸協議[11],能實現通信雙方無差錯地發送和接收網絡數據,在傳輸過程中不會出現數據丟包、數據錯包以及數據包重復、亂序和數據較多造成的網絡擁塞等現象[12]。常見的可靠機制如握手連接、滑動窗口、擁塞窗口、漏發重發、累積確認等機制雖實現了網絡數據傳輸的可靠性,但這些機制增加了數據的復雜度和數據處理的工作量,會導致數據的傳輸效率變低,所以 TCP 協議主要用于對數據的可靠性要求比較高而對數據傳輸的效率要求一般的場合[13],其協議格式如圖1所示。

圖1 TCP協議格式

1.2 UDP協議

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

圖2 UDP協議格式

1.3 ORUDP方案設計

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

2 ORUDP原理

2.1 ORUDP格式

2.1.1 ORUDP層級結構

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

圖3 ORUDP層級結構

2.1.2 ORUDP格式與字段含義

ORUDP各個字段的含義如下:

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

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

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

ORUDP可以發送兩種包文,一種是用來保證可靠傳輸的控制包文,另一種是需要傳輸的數據包文,當各個控制字段都為0時代表普通數據包,否則即為控制包文,格式如圖4所示。

圖4 控制包文格式

ORUDP各個字段的含義如下:

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

2)1位的標志位 ACK:當 ACK 值為1時表明這是一個應答包,本標志位與其他標志位配合使用,如當SYN和ACK都置1時代表這是一個連接應答包,當FIN和ACK都置1時代表這是一個關閉應答包,僅有為1時代表數據確認包。

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

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

5)1位的標志位ACKREQ:當ACKREQ為1時表明發送方已經連續發送了一批數據包并且需要接收方及時確認。

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

7)16位的序列號:該字段用來標記發送的數據包的順序號,接收方期望包寄存器與之比對產生相應的動作。

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

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

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

2.1.3 ORUDP序列號

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

2.2 ORUDP連接與釋放

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

圖5 ORUDP連接與釋放過程

2.3 ORUDP可靠機制

2.3.1 ORUDP確認機制

ORUDP協議采用改進的累積確認機制,在該機制下接收方收到一批正確的數據包才會發送確認消息,與停止等待協議相比,既可以保證數據傳輸的可靠性,又能節省發送等待確認及多個確認的時間。

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

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

2.3.2 ORUDP重傳機制

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

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

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

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

2.3.3 ORUDP定時器

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

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

圖6 4種定時器工作原理

2.4 ORUDP流量控制機制

雖然RUDP草案中并沒有描述如何去控制流量,但如果不對流量進行控制很容易引起接收方緩沖區溢出。此外,在網絡環境不佳時容易引發網絡擁塞導致網絡崩潰。考慮窗口控制機制的復雜性和硬件耗費,本文選用比較節約資源的基于GBN的改進滑動控制機制[19]。

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

圖7 滑動窗口示意圖

2.5 ORUDP雙隊列加速機制

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

圖8 乒乓緩存機制

2.6 ORUDP發送與接收機制

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

圖9 發送流程

圖10 接收流程

在建立連接之后發送方處于空閑狀態,如果應用進程需要發送數據,首先會把數據發送到自己的FIFO緩沖區當中,后續的發送任務就交給ORUDP處理。處理過程主要由滑動窗口管理及雙隊列加速機制實現。

3 ORUDP邏輯設計

3.1 ORUDP總體設計

依據混合網絡參考模型,結合FPGA并行處理的特點,本文采用分層設計的思想將整個ORUDP協議棧從上到下分成可靠傳輸層、傳輸層、網絡層、鏈路層4個部分獨立實現,系統結構框架如圖11所示。

圖11 系統結構框架

3.2 ORUDP可靠傳輸層設計

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

圖12 可靠傳輸層劃分結果

3.2.1 連接管理模塊設計

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

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

圖13 客戶端連接管理模塊狀態機

圖14 服務器連接管理模塊狀態機

3.2.2 數據接收模塊設計

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

表1 命令字段真值表

ORUDP接收普通包文的前提條件是必須處于連接已經建立的狀態或者半關閉狀態(只能接收不能發送普通包文),在需要向對方回復普通包文時產生相關控制信號給命令發送模塊,由命令發送模塊封裝成可靠傳輸層的包文。

3.2.3 命令發送模塊設計

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

圖15 命令發送模塊狀態轉移示意圖

3.2.4 數據管理模塊設計

數據管理模塊的作用是在雙隊列滑動窗等機制的作用下,將應用進程發送至 FIFO中的數據高效可靠地發送給數據打包模塊,可靠傳輸層中所有的可靠機制都在這一模塊實現,其他和數據傳輸有關的模塊只是把本模塊流出的數據包打包成ORUDP 格式的包文,該模塊的工作流程與狀態轉移、滑動窗口的滑動機制見第2節。

3.2.5 數據打包模塊設計

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

圖16 數據打包模塊

3.2.6 輪轉調度模塊設計

輪轉調度模塊的作用是輪流輸出命令發送模塊和數據打包模塊輸出的包文,因為 FPGA 內部是并行處理的,命令發送模塊和數據打包模塊同時工作,但是傳輸線上的包文是逐個傳輸的,為防止傳輸數據包時丟失命令包,特設計該模塊同時緩存命令數據和普通數據,命令包的優先級大于數據包。

3.3 ORUDP互連設計

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

圖17 信號流向示意圖

4 ORUDP實現與測試

4.1 實測環境搭建

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

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

圖18 ORUDP測試系統

4.2 可靠性與速度測試

在實驗室環境下只能近距離傳輸,網絡上不會有路由,在這種理想環境下很難出現數據包丟失的情況,此處人為制造丟包條件,屏蔽接收方數據確認的功能,屏蔽以后重新下載到服務器中,測試客戶端作為發送方服務器屏蔽接收方的超時與錯誤重傳功能。客戶端發送完0號～6號數據包文以后進入等待狀態,由于接收方不會回應數據確認包,超時定時器一定會溢出并重新發送未被確認的數據包文,如圖19所示,發送方重傳的數據包不是接收方期望的,接收方發送重傳請求,發送方收到重傳請求重新發送要求重傳的數據包,如圖20所示。

圖19 數據包的重新發送

圖20 進入等待狀態的數據包

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

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

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

5 結束語

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