支持差異化可協商的數據通信機制

寇文龍，李鳳華,3，董秀則，曹曉剛，耿魁，李青

（1.西安電子科技大學網絡與信息安全學院，陜西 西安 710071；2.中國科學院信息工程研究所，北京 100093；3.中國科學院大學網絡空間安全學院，北京 100049；4.北京電子科技學院電子通信工程系，北京 100070；5.中國電信股份有限公司研究院，北京 100033）

1 引言

隨著云計算和物聯網等新型網絡的大規模部署和應用，5G 移動通信的全球化商用[1]，服務器與終端設備、服務器與硬件計算資源、不同終端設備之間、終端設備與硬件計算資源之間的通信越來越頻繁[2]，設計高效、可靠的通信方法是數據通信中亟須解決的問題。

云環境和物聯網中存在海量、差異化的硬件計算資源和終端設備[3]。數據通信時面臨以下2 個挑戰：如何根據計算資源和終端設備的資源情況和接收能力進行協商，實現差異化、可協商的通信；如何根據不同硬件計算資源和設備的狀態，動態調整通信速率，進行數據發送和重傳，降低丟包率，提高通信的穩定性、可靠性和效率[4]。此外，對B5G和6G 移動通信的研究已經引起了學術界和工業界的廣泛關注，通信與計算融合是未來數據通信的一大趨勢[5]，實現差異化可協商的數據通信對通信與計算融合的數據通信至關重要。

光纖等高速網絡通信設備的快速發展為云計算和物聯網帶來了更大的帶寬支撐，但是數據通信性能卻沒有隨著通信帶寬的提升而得到顯著提高。其原因是目前云環境和物聯網中的大部分設備是基于TCP/IP 協議族進行數據通信的[6]，而TCP/IP協議族在傳統的低帶寬低時延網絡中運行穩定且性能良好，但不適用于高帶寬低時延的網絡環境。TCP 流量控制的一種方法是快速重傳，基于重復確認（ACK,acknowledge）來間接判斷重傳，其每次只能重傳一個數據段，導致通信速度遠低于理論的傳輸帶寬；另一種方法是選擇重傳，一個ACK 中可包含多個待重傳數據段，但是需要設置相當容量的緩存。TCP 的擁塞避免算法會產生一些不必要或者錯誤的擁塞判斷，進而由于指數級的擁塞避讓策略導致通信性能大大降低[7]。針對上述問題，研究人員提出了多種優化方案來提高TCP 在高速通信環境[8]中的性能，但是收效甚微。此外，大部分改進協議在設計時沒有考慮通信雙方硬件資源和處理能力的差異，導致某些改進協議只適用于高性能的設備[9]，不能根據設備的不同實現差異化的數據通信。并且由于處理能力的差異，通信雙方在進行數據通信的同時還需要兼顧數據處理等其他工作，現有的通信協議不能根據通信雙方處理能力的差異進行動態調整[10]，降低了通信的效率。

針對上述問題，本文提出了支持差異化、可協商的數據通信機制。本文主要貢獻如下。

1) 提出了參數協商方法，根據接收端計算能力和接收能力的不同，發送端與接收端協商合適的滑動窗口大小和同步包序號，實現差異化、可協商的數據通信。

2) 設計重傳反饋機制，提出3 種ACK，分別是正常接收ACK、重傳ACK 和丟棄ACK。其中，正常接收ACK 表示數據包被接收端正確接收，重傳ACK 表示數據包需要發送端重新發送，丟棄ACK 表示數據包被接收端丟棄。正常接收ACK 采用累計確認機制，重傳ACK 包含一個或多個需要重傳的包序號，提高了數據重傳的效率，同時ACK準確反饋接收端的數據接收狀態，發送端根據接收端數據接收情況動態調整發送速率，進行數據發送和重傳，有效緩解通信過程中的鏈路擁塞情況，降低通信的丟包率，提高通信效率和可靠性。

3) 發送端和接收端采用不同滑動窗口大小以不同通信速率進行多對多、并行異步的數據通信。通過服務器和計算單元架構模式進行實驗仿真，實驗結果證明了該機制能夠根據接收端能力差異進行動態自適應的數據通信，提高了通信的可靠性和效率。

2 相關工作

由于云計算和物聯網中各種應用對高性能數據通信的迫切需求以及傳統數據通信協議本身在云環境和物聯網中的不足，使研究適用于新環境下的高速數據通信方法成為熱點，本文主要從數據通信方法本身入手，對相關研究進行論述。

He 等[11]提出可靠增強UDP（RBUDP,reliable blast user datagram protocol），采用UDP+TCP 的方式實現可靠傳輸，其中，UDP 用來傳輸數據，TCP用來傳輸控制信息。其主要思路是發送端利用UDP發送所有數據，發送完成后利用TCP 發送一個傳輸完成信號，接收端接收數據并記錄，待接收到傳輸完成信號后利用TCP 反饋數據接收情況，發送端根據反饋信息重新發送丟失的數據，重復上述過程直到所有數據被成功接收。Kachan 等[12]在10 Gbit/s鏈路上對RBUDP 的性能進行了驗證，其性能、資源消耗等均表現較好。但是RBUDP 主要針對批量數據傳輸，不適用于流式應用；需要事先獲取鏈路速度來決定發送端數據包的發送速度；對傳輸的數據量有限制，因為接收端需要緩存所有的數據，數據量過大可能導致接收端異常。Meiss[13]針對RBUDP 的不足提出了Tsunami 協議，其改進之處有以下兩點：定時反饋數據接收情況，根據反饋信息動態調整發送時延或者速度以實現擁塞控制。Tsunami 協議解決了RBUDP 對傳輸內容大小的限制，但其擁塞控制機制過于簡單，在長距離網絡傳輸中不能準確反映傳輸鏈路的擁堵狀況。

Syzov 等[14]在高速數據通信環境下提出多線程收發和自適應資源分配的通信方案，以解決單通路UDP 數據收發時帶寬利用率不足的問題。該方案在高速大數據量傳輸時性能表現很好，但是線程管理和冗余資源回收機制的不足導致該方案不能根據傳輸速度的變化動態調整系統資源的消耗。

基于RUDP，Luo 等[15]針對航空自組織網絡[16]中可靠高效數據傳輸問題提出了帶噴泉碼的可靠UDP（FRUDP,fountain code and reliable UDP），Nasser 等[17]提出了一種緊湊型可靠 UDP（compact-RUDP,compact reliable UDP），陳波等[18]提出了一種新型可靠數據傳輸協議 ARUDP（argument reliable UDP），上述3 種協議都是在可靠UDP 基礎上添加控制機制來降低通信過程中的丟包率，以達到提高通信效率的目的。Christensen 等[19]提出在現場可編程門陣列（FPGA,field programmable gate array）和數字信號處理器（DSP,digital signal processor）等硬件設備上實現可靠UDP 通信，通過修改網絡最大包長度來提高傳輸性能。

文獻[20-21]針對高速長距離網絡中大量數據傳輸的性能需求，提出了一種高速批量數據傳輸協議DCUDP（double cubic UDP），通過三次方速率控制提高協議在高帶寬產品網絡上的可伸縮性，并采用隨機算法來減輕連續丟失和丟失同步的影響。該協議在帶寬利用率、CPU 資源占用率和協議公平性等方面均表現良好，但是在進入穩定狀態之前會出現擁塞窗口抖動的現象，為數據傳輸帶來了不穩定因素，并且對丟包的原因分析不透徹，同樣會導致傳輸效率降低。

Gu 等[22]提出基于UDP 的數據傳輸（UDT,UDP-based data transfer），其通過接收端周期性發送反饋信息，丟包時立即發送否定式確認信息來通知發送端丟包情況，采用隨著減少增加的加性增乘性降（DAIMD,additive increase and multiplicative decrease with decreasing increase）算法來調整發送端的數據發送速率，同時UDT 采用類似于TCP 的滑動窗口機制來控制發送端，減少發送無意義數據包的數量，達到擁塞控制的效果。UDT 協議本身復雜度較高，這在很大程度上限制了協議本身的傳輸效率。

Eckart 等[23]提出了性能自適應的UDP（PA-UDP,performance adaptive UDP），該協議主要針對文件傳輸而設計，通過簡單比較剩余文件大小和接收端緩沖區可用空間來實現。PA-UDP 還通過數學模型來調節發送速率，避免接收端緩沖區溢出。但PA-UDP 的數學模型出發點并不準確，即磁盤讀寫速率與數據傳輸速率的快慢情況不能完全確定，因此可能存在傳輸效率不高的問題。

現有的數據通信方法大致從兩方面來設計擁塞避免算法，分別是丟包率和接收端緩沖區利用率，即根據丟包率或者接收端緩沖區利用率來調整發送端的數據發送速率，進而提高通信效率。但這些協議實現的復雜度較高，需要考慮的因素較多，對通信的性能影響較大，并且大多數改進協議是針對特定應用場景設計的，通用性不強。

除了對通信協議本身的研究之外，對TCP/IP棧在不同平臺上實現的研究也較多。Sidler 等[24]在Xilinx VC709 FPGA 開發板上設計并實現了協議棧，最多支持10 000 個連接，萬兆環境下通信速度達到8.5 Gbit/s，但是資源消耗較大，尤其是塊隨機存取內存（BRAM,block random access memory）占用達到21%，對在FPGA 上實現的其他應用影響較大。在此基礎上，Sidler 等[25]提出使用雙倍速率同步動態隨機存取內存（DDR SDRAM，double data rate synchronous dynamic random access memory）進行數據存取，內存消耗降低了50%，雖然數據通信的時延降低了，但FPGA 邏輯資源占用卻有增無減，主要原因是需要額外消耗邏輯資源來存儲控制DDR SDRAM 存取數據的邏輯。因此，數據通信機制需要根據不同設備硬件資源的差異來動態調整用于數據通信的資源消耗。

本文所提數據通信機制從以下三方面進行研究：設計參數協商機制，根據設備處理能力的差異動態調整通信的資源消耗和通信速度；設計簡潔高效的滑動窗口機制，保證通信的高效性；設計自定義協議，實現反饋確認和選擇重傳來保證通信的可靠性，根據接收端當前處理能力動態調整發送端的發送速度，降低通信鏈路的擁塞風險。

3 差異化、可協商的數據通信機制模型

本節以服務器與計算單元/終端設備應用場景為例，對服務器與計算單元之間通信的各類需求進行分析，提出了差異化、可協商的數據通信機制的模型。

3.1 應用場景分析

云計算環境下，服務器與計算單元或者服務器與終端設備通信的應用場景如圖1 所示。一個服務器需要與多個計算單元或者終端設備進行并行、高效、可靠通信。而各計算單元或者終端設備的計算資源、帶寬等均不相同，導致不同計算單元或者終端設備的數據處理能力具有很大的差異性。

圖1 應用場景

假設計算單元為FPGA 計算單元，每個FPGA計算單元功能不同，帶寬不同，數據處理能力不同，每個FPGA 計算單元可以承受的最大通信速率以及需要的通信速率也不相同。假設FPGA 計算單元為密碼計算單元，不同密碼算法所需的計算資源不同，數據處理能力不同、帶寬也不相同。服務器與FPGA 計算單元進行通信時，需要根據每個FPGA計算單元的資源情況，采用合適的通信速率進行差異化數據通信。此外，實際通信過程中，服務器需要根據每個FPGA 計算單元實際的數據接收情況和數據處理情況動態調整通信速率，及時準確判斷數據丟包情況，進行數據發送和重傳，降低丟包率，提高通信的效率和可靠性。

下面以密碼服務為例闡述本文所提數據通信機制在密碼服務系統中的應用。密碼服務系統模型由5 個模塊組成，如圖2 所示。其中，屬于串聯關系的模塊有數據接收、密碼服務調度、密碼服務匯聚和數據發送模塊，負責整個密碼作業數據流的處理工作；屬于并聯關系的模塊是密碼算法運算模塊，密碼算法運算模塊由不同種類、不同數量的密碼算法知識產權（IP,intellectual property）核組成，各個密碼算法IP 核之間是并聯關系，即不同類型的密碼算法處于并行工作狀態，在密碼算法運算過程中互不影響。

圖2 密碼服務系統模型

數據接收模塊采用滑動窗口和選擇重傳機制保證密碼服務數據包的正確性和完整性，提高數據傳輸的性能；密碼服務調度模塊將正確接收的密碼服務數據包根據密碼算法類型的不同分發到密碼算法運算模塊中不同的密碼算法的IP 核進行處理；密碼服務匯聚模塊對運算完成后的密碼服務數據包進行聚合；數據發送模塊同樣采用滑動窗口和選擇重傳機制來保證數據傳輸的正確性和性能。

令數據接收模塊從接收數據包完成到開始接收下一個數據包的時間間隔為t1；密碼服務調度模塊從數據接收模塊讀取一個數據包完成到開始讀取下一個數據包的時間間隔為t2；密碼算法運算模塊中的密碼算法IP 核從密碼服務調度模塊排隊讀取數據包的時間間隔為tin，根據算法IP 核的不同分別表示為tin2、tin3、tin4；密碼服務匯聚模塊從密碼算法IP 核中取數據包的時間間隔為tout，根據算法IP 核的不同分別表示為tout2、tout3、tout4；數據發送模塊從密碼服務匯聚模塊讀取數據包的時間間隔為t3；數據發送模塊從發送數據包完成到開始發送下一個數據包的時間間隔為t4；則密碼服務系統處理一個密碼服務數據包的額外時間開銷 Δt為

其中，i=1,…,x，j=1,…,y，k=1,…,z。

為降低密碼服務處理的額外時間開銷，可充分利用FPGA 并行工作的特性，算法IP 核采用全流水的設計方式，處理模塊之間使用先進先出（FIFO,first input first output）存儲器進行解耦，實現數據包的不間斷處理，使密碼服務調度、密碼算法運算和密碼服務匯聚等模塊間的時間間隔降為0，即

則密碼服務數據包的額外時間開銷僅與數據發送和接收的時間相關，即

3.2 通信機制模型

針對上述應用場景，本文提出了支持差異化、可協商的數據通信機制。通信機制模型如圖3 所示。通信機制包含三部分，分別為參數協商、數據發送和數據接收。

圖3 通信機制模型

參數協商是指通信開始之前，通信雙方根據自身硬件資源大小和數據處理能力協商出合適的滑動窗口大小、同步包序號等關鍵參數。參數協商分為參數協商請求和參數協商反饋。參數協商請求由發送端發給接收端，內含發送端期望的接收端滑動窗口大小和同步包序號。參數協商反饋由接收端發給發送端，內含接收端滑動窗口大小和同步包序號。參數協商充分考慮不同數據通信終端硬件資源和數據處理能力的差異，通過協商避免因數據通信的原因影響設備其他功能的正常運轉，同時避免因通信兩端數據處理能力差異導致的數據包丟失，保證數據傳輸的高效性。

數據發送包括發送數據和處理ACK。發送端根據自身當前滑動窗口狀態和接收端當前數據處理情況綜合判斷是否滿足數據發送條件，如果滿足數據發送條件則發送數據，否則接收并處理接收端反饋的ACK 信息。ACK 信息分為3 種，分別是正常接收ACK、重傳ACK 和丟棄ACK。其中，正常接收ACK 表示該包序號對應的數據包被接收端正確接收，正常接收ACK 采用累計確認機制，即發送端收到某一正常接收ACK，則表示該包序號之前的數據包均被接收端接收到。重傳ACK 表示該包序號對應的數據包需要發送端重新發送，重傳ACK中可包含一個或多個待重傳包序號，以提高數據重傳效率。丟棄ACK 表示該包序號對應的數據包不在接收端滑動窗口范圍內，被接收端丟棄。數據發送根據反饋的ACK 信息及時地對數據進行確認和重傳，保證數據傳輸的穩定性和性能。

數據接收包括接收數據和反饋ACK。接收端對接收的數據包進行解析，首先根據數據包序號和接收端滑動窗口狀態確定數據包的接收狀態，然后根據數據包的接收狀態生成正常接收ACK、重傳ACK 和丟棄ACK。除了ACK 信息，接收端還將數據處理情況反饋給發送端，使發送端據此動態調整數據發送速率，避免通信鏈路的擁塞，提高數據傳輸的高效性。

本文采用時間自動機對所提數據通信機制進行數學建模，定義3 個模塊，分別是參數協商、數據發送和數據接收模塊。

3.2.1參數協商模塊

參數協商模塊的時間自動機定義為A=。

其中，La表示參數協商模塊的位置集合，包含3 個位置，Init 表示初始位置，Request 表示發起參數協商請求，Done 表示參數協商完成；La0表示參數協商模塊的起始位置，即Init；∑a表示參數協商模塊的有限字符集合，send_request 表示發送參數協商請求包，recv_reply表示接收參數協商反饋包；Xa表示參數協商模塊的有限時鐘集合；Ia表示參數協商的映射，為La中的每一個位置指定Φ(Xa)的一個時鐘約束；Ea表示參數協商模塊位置遷移關系集合。

參數協商模塊時間自動機如圖4 所示。通信雙方開始參數協商時，發送send_request 消息，消息中包含發送端期望同步包序號以及期望接收端滑動窗口大小，接收端收到send_request 消息后根據自身接收能力和資源使用情況，確定接收端滑動窗口大小和同步包序號，并通過recv_reply 消息返回給發送端，如果發送端在等待MAX_DELAY時間后仍未收到recv_reply 消息，則返回初始狀態。

圖4 參數協商模塊時間自動機

以本文實驗所用的FPGA 計算單元為例，設備當前接收能力由設備可用作滑動窗口的邏輯資源量決定，而滑動窗口在FPGA 計算單元內部的實現主要由三部分組成，分別是塊存儲器BRAM、查找表（LUT,look up table）和觸發器（FF,flip flop）。這3 種邏輯資源的剩余量決定了設備的當前接收能力。

令FPGA 計算單元BRAM 剩余量為R，LUT剩余量為L，FF 剩余量為F。設單位滑動窗口BRAM 占用量為α，LUT 占用量為β，FF 占用量為γ，滑動窗口大小為w。則w需滿足以下條件

3.2.2數據發送模塊

數據發送模塊的時間自動機定義為S=。

其中，Ls表示數據發送模塊的位置集合，包含6 個位置，Idle 表示空閑，SendData 表示發送數據，RetransData 表示重傳數據，RecvAck 表示接收ACK，SendSucess 表示數據發送成功，UpdateStatus表示更新滑動窗口狀態；Ls0表示數據發送模塊的起始位置，即Idle；∑s表示數據發送模塊的有限字符集合，msg[id]表示發送的數據內容，ack[id]表示接收的ACK；Xs表示數據發送模塊的有限時鐘集合；Is表示數據發送的映射，為Ls中的每一個位置指定Φ(Xs)的一個時鐘約束；Es表示數據發送模塊位置遷移關系集合。

數據發送模塊時間自動機如圖5 所示。數據發送時首先判斷是否滿足數據發送條件，即發送端滑動窗口未滿并且接收端滑動窗口空閑節點數量大于正在發送的數據包數量。其中，發送端滑動窗口未滿是指發送端滑動窗口中有空閑節點來發送新的數據包，如式(7)所示；接收端滑動窗口空閑節點數量是指接收端滑動窗口中可用來接收新數據包的空閑節點，如式(8)所示；正在發送的數據包數量是指發送端已經發出但尚未收到確認的數據包數量，如式(9)所示。

圖5 數據發送模塊時間自動機

然后根據接收端反饋的ACK 包來解析正常接收數據包、重傳數據包和丟棄數據包，進行數據包的確認和重傳，并獲取接收端的接收包序號和處理包序號，以此判斷接收端當前的數據接收能力，進而動態調整數據發送速率，降低通信中的擁塞情況和丟包率，提高通信效率。

3.2.3數據接收模塊

數據接收模塊的時間自動機定義為R=

其中，Lr表示數據接收模塊的位置集合，包含3 個位置，Idle 表示空閑，RecvData 表示接收數據，SendAck 表示發送ACK；Lr0表示數據接收模塊的起始位置，即Idle；∑r表示數據接收模塊的有限字符集合，msg[id]表示接收的數據內容，ack[id]表示發送的ACK；Xr表示數據接收模塊的有限時鐘集合；Ir表示數據接收的映射，為Lr中的每一個位置指定Φ(Xr)的一個時鐘約束；Er表示數據接收模塊位置遷移關系集合。

數據接收模塊時間自動機如圖6 所示。數據接收模塊主要作用是接收數據，并根據數據接收情況返回ACK。接收端根據當前滑動窗口狀態對接收的數據包進行判斷，將數據包標記為正常接收數據包、重傳數據包和丟棄數據包，并結合當前接收端處理能力的變化生成ACK 返回給發送端。通過反饋接收端的數據處理能力，通信雙方能夠自動適應通信速度的變化。

圖6 數據接收模塊時間自動機

4 差異化、可協商的數據通信流程

發送端和接收端在完成參數協商之后進行數據發送和接收。本文設計了ACK 包，在實際通信時，接收端根據數據接收情況生成ACK 包。發送端根據ACK 包及時了解接收端數據的接收和處理情況，動態調整數據發送速率；解析需要重傳的數據，對需要重傳的數據及時進行重傳。此外，本文設計了發送端滑動窗口狀態和接收端滑動窗口狀態，分別表示發送端和接收端數據發送和接收情況。

4.1 參數協商

發送端和接收端在數據通信前，通過參數協商得到雙方合適的滑動窗口大小和同步包序號。

4.1.1參數協商中的包結構

參數協商主要根據參數協商包和參數協商反饋包進行協商。

參數協商包結構可表示為AgreePkt={ExpectAgreeSeq,ExpectWindowSize}其中，ExpectAgreeSeq 表示期望同步包序號，ExpectWindowSize 表示期望接收端滑動窗口大小。

參數協商反饋包結構可表示為AgreeRespPkt={RecvAgreeSeq,RecvWindowSize}其中，RecvAgreeSeq 表示接收端同步包序號，RecvWindowSize 表示接收端滑動窗口大小。

4.1.2參數協商流程

發送端設置期望同步包序號、期望接收端滑動窗口大小，構造參數協商包發送給接收端。

接收端收到參數協商包后，解析出參數協商包中的期望同步包序號和發送端期望滑動窗口大小。接收端根據參數協商包中的期望同步包序號確定同步包序號，根據自身接收能力和資源使用情況、發送端期望滑動窗口大小等確定接收端滑動窗口大小；然后根據同步包序號和接收端滑動窗口大小構造參數協商包反饋包返回給發送端。

發送端接收到參數協商反饋包后，解析并記錄同步包序號和接收端滑動窗口大小，然后確定雙方共同的同步包序號和滑動窗口大小。

發送端和接收端采用參數協商步驟協商出通信雙方合適的滑動窗口大小、同步包序號等關鍵參數，使通信雙方以一個合適的速度開始數據通信，避免了通信剛開始時速率過快或者過慢導致的通信效率低下。此外，參數協商機制充分考慮通信雙方資源使用情況和處理能力的差異，針對不同的設備采用不同的速率進行通信，實現差異化、可協商的數據通信。

4.2 數據通信

發送端和接收端完成參數協商之后即可進行正常的數據通信。

4.2.1數據通信中的包結構

數據通信主要包括數據包和ACK 包。數據包表示待傳輸的有效數據，ACK 包表示接收端根據數據接收和處理情況生成的反饋包。

數據包結構可表示為

其中，Seq 表示數據包的包序號，Cmd 表示數據包的命令字段，Length 表示數據包中Data 的長度，Data 表示待傳輸的數據。

ACK 包結構可表示為

其中，RecvSeq 表示一段時間內接收端滑動窗口內已確認接收的連續數據包的最后包序號；ProcessSeq 表示一段時間內接收端滑動窗口內已處理的連續數據包的最后包序號；NormalAck 表示正常接收數據包集合，即數據包按序正確到達接收端；RetransAck 表示重傳數據包集合，即在傳輸過程中被丟棄或者出現錯誤的、需要發送端重新發送的數據包；AbortAck 表示丟棄數據包集合，即不在接收端接收范圍內，被接收端丟棄的數據包。

4.2.2數據通信流程

數據發送時，發送端設計了待發送隊列、待確認隊列、ACK 隊列，分別用來保存待發送的數據包、待確認的數據包以及接收端反饋的ACK 包。

當滿足數據包發送條件時，發送端從待發送隊列中取出一個或多個待發送的數據包按照4.2.1 節數據包結構來構造數據包發送給接收端，并保存到待確認隊列中。

當不滿足數據包發送條件時，發送端從ACK包隊列中取出一個ACK 包，解析接收端接收包序號、接收端處理包序號。讀取ACK 包中正常接收數據包集合，將正常數據包序號對應的數據包從發送端待確認隊列中刪除；讀取ACK 包中的重傳數據包集合，將重傳數據包序號對應的數據包從發送端待確認隊列中重新發送給接收端；讀取ACK 包中的丟棄數據包集合，如果丟棄數據包序號對應的數據包在發送端待確認隊列中，繼續判斷發送端滑動窗口狀態是否正常，如果發送端滑動窗口狀態不正常，調整發送端滑動窗口狀態后，再將發送端待確認隊列中對應的數據包發送給接收端，如果丟棄數據包序號對應的數據包不在發送端待確認隊列中，不作任何處理。

數據發送完成或者ACK 包處理完成后，更新發送端滑動窗口狀態。

發送端滑動窗口狀態可表示為

其中，發送端讀指針SendRptr 表示發送端滑動窗口的下界；發送端寫指針SendWptr 表示發送端滑動窗口的上界；發送端發送包序號SendSeq 表示發送端一段時間內已經發送的數據包的最后包序號；數據包發送狀態SendStatus 表示在滑動窗口內數據包的發送狀態，數據包發送狀態包括已發送、已確認接收；接收端接收包序號RecvSeq 表示一段時間內接收端滑動窗口內已確認接收的連續數據包的最后包序號；接收端處理包序號ProcessSeq 表示一段時間內接收端滑動窗口內已處理的連續數據包的最后包序號；發送端確認包序號SendConfirmSeq 表示一段時間內發送端已經確認發送成功的連續數據包的最后包序號；發送端滑動窗口大小SendWindowSize 表示發送端滑動窗口所占資源空間的大小。

數據接收時，接收端根據數據接收和處理情況生成ACK 包反饋給發送端。

首先，接收端解析接收到的數據包，獲取數據包序號，并判斷包序號是否在接收端滑動窗口范圍內，如果不在范圍內，則標記該包序號為丟棄數據包序號。如果在接收端滑動窗口范圍內，則搜索接收端滑動窗口處理包序號至當前數據包序號之間是否有數據包的狀態為未收到，如果接收端滑動窗口處理包序號至當前數據包序號之間的數據包都收到，則將接收端滑動窗口處理包序號至當前數據包序號之間的數據包序號標記為正常接收數據包序號；如果接收端滑動窗口處理包序號至當前數據包序號之間有數據包的狀態為未收到，則標記未收到的數據包序號為重傳數據包序號，其余為正常數據包序號。然后，根據數據包的接收狀態生成正常接收數據包集合、重傳數據包集合和丟棄數據包集合，將接收端接收包序號、接收端處理包序號、正常接收數據包集合、重傳數據包集合和丟棄數據包集合按照4.2.1 節ACK 包結構來構造ACK 包發送給發送端。最后，更新接收端滑動窗口狀態。

接收端滑動窗口狀態可表示為

其中，接收端讀指針RecvRptr 表示接收端滑動窗口的下界；接收端寫指針RecvWptr 表示接收端滑動窗口的上界；接收端接收包序號RecvSeq 表示一段時間內接收端滑動窗口內已確認接收的連續數據包的最后包序號；接收端處理包序號ProcessSeq 表示一段時間內接收端滑動窗口內已處理的連續數據包的最后包序號；數據包接收狀態RecvStatus 表示在接收端滑動窗口內的數據包的接收狀態，數據包接收狀態包括收到、未收到；接收端滑動窗口大小RecvWindowSize 表示接收端滑動窗口所占資源空間的大小。

數據通信時，發送端根據數據包發送條件，充分考慮接收端接收速率的變化，動態調整發送端的數據包發送速率，能夠有效降低數據傳輸的丟包率；同時，充分利用了接收端反饋的ACK 包，對發送端待確認隊列中的數據包進行確認和重傳，發送端根據接收端不同接收能力和狀態動態自適應地發送和重傳，提高了通信效率和可靠性。

數據通信時，發送端可以給不同接收端發送數據，接收端可以同時作為發送端，原來的發送端也可以同時作為接收端，進行雙向通信，即一臺設備或一個系統或一個組件或一個線程或一個進程中可以同時部署發送端和接收端，以實現發送端和接收端的多對多、并行、全雙工、雙向通信。

5 實驗與結果分析

5.1 實驗環境

為驗證本文所提通信機制的性能，本文在服務器-計算單元的架構中實現了該通信機制，包括一臺X86 平臺的服務器和一套高級通信計算架構（ATCA,advanced telecommunications computing architecture）平臺系統。其中，服務器使用Intel公司的82599ES 10 Gbit/s 網卡或者Mellanox 公司的100 Gbit/s 網卡進行數據通信；ATCA 平臺系統由交換板和業務板組成，其架構如圖7 所示，交換板和業務板之間、業務板和子卡之間均通過背板數據總線進行數據交換，子卡上每個FPGA 計算單元的帶寬為10 Gbit/s。

圖7 ATCA 平臺系統架構

服務器和ATCA平臺系統通過10 Gbit/s 多模光纖或者100 Gbit/s 電纜進行數據通信。實驗所用的軟硬件環境如表1 所示。本文實驗是在服務器和FPGA 計算單元上分別使用C 語言和Verilog 語言實現的，服務器端使用數據平面開發套件（DPDK,data plane development kit）接收和發送網絡數據包。

表1 實驗環境

5.2 通信機制容錯效果分析

容錯實驗的基本原理是服務器端向FPGA 計算單元發送文件，FPGA 計算單元收到文件后將文件返回給服務器端，服務器端在發送文件內容的過程中隨機丟棄若干個數據包，最后查看服務器端接收到的文件和發送的文件內容是否一致，以此來檢驗通信協議的重傳機制是否有效，同時檢驗通信協議在鏈路擁塞情況比較嚴重的情況下的通信效率。實驗共設置4 組丟包測試，丟包率依次增加，實驗結果如表2 所示。

表2 通信協議容錯實驗結果

從表2 可以看出，隨著丟包率的增加，文件傳輸所需時間逐漸增加，傳輸速度隨之降低。但即使丟包率達到20%，即模擬通信系統網絡嚴重擁塞的情況下，本文所提通信協議依然能夠正確完成數據傳輸任務，并且傳輸速度仍然維持在較高的水平，實驗證明本文所提通信協議具有較強的容錯能力，并且通信效率高。

5.3 通信機制性能分析

5.3.1轉發性能分析

轉發實驗的基本原理是在測試服務器和FPGA計算單元分別設置不同大小的滑動窗口，測試服務器分別使用不同數據包大小發送大量數據給FPGA計算單元，FPGA 計算單元收到數據之后再轉回測試服務器，數據傳輸完成后根據傳輸數據量和所用時間計算通信速率。

轉發實驗共配置2 種實驗環境，一種是測試服務器通過10 Gbit/s 網卡與FPGA 計算單元進行通信，另一種是測試服務器通過100 Gbit/s 網卡與FPGA 計算單元進行通信。每種環境在實驗時共設置8 組滑動窗口大小，5 種數據包大小。

實驗結果分別如圖8 和圖9 所示。從實驗結果可以看出，隨著通信兩端滑動窗口大小和數據包數據長度的增加，通信速率也隨之增長。當滑動窗口大小較小時，通信速率較低，旨在模擬運算性能較差，或者通信能力較弱的設備，如物聯網通信設備；在滑動窗口大小為14 和16 時，通信速率達到最大值，接近10 Gbit/s 網口的線速。使用100 Gbit/s 網卡通信時的最高速度與使用10 Gbit/s網卡通信時的速度基本一致，是因為FPGA 計算單元的物理網口的規格是10 Gbit/s，達到了端口性能的上限。

圖8 通信協議速率10 Gbit/s 網卡實驗結果

圖9 通信協議速率100 Gbit/s 網卡實驗結果

搭建實驗環境，將2 個測試服務器通過10 Gbit/s光纖連接，并在2 個服務器上對UDTv4 協議、RBUDP 和本文所提通信協議進行對比實驗，通過設置丟包率來模擬網絡環境的變化，以測試在不同網絡環境下3 種協議的性能，實驗結果如圖10所示。

圖10 10 Gbit/s 網絡環境下3 種通信機制的性能對比

UDTv4 協議在無丟包的情況下通信速率僅有4 Gbit/s，在0.1%丟包率的情況下通信速率降低到不足200 Mbit/s，性能較差。RBUDP 的性能與本文所提機制較為接近，但隨著丟包率的增大，RBUDP與本文所提通信機制的性能差異逐漸增大。

在上述實驗基礎上，本文搭建測試環境，測試服務器通過100 Gbit/s 網卡與8 個FPGA 計算單元同時進行通信，每個FPGA 計算單元均設置滑動窗口大小為16，數據包大小為1 000 B，測試結果如圖11 所示。

圖11 通信協議速率100 Gbit/s 網卡多FPGA 計算單元實驗結果

由于每個FPGA 型號都相同，計算資源和處理能力一致，因此每個FPGA 計算單元的通信速率均約為9.15 Gbit/s，接近10 Gbit/s 網口的線速，從實驗結果可以看出，本文所提通信機制在多數據流同時通信時具有很好的公平性。

此外，按照3.1 節所述密碼服務系統模型搭建測試環境，驗證本文所提數據通信機制的穩定性和性能，并在所提數據通信機制的基礎上驗證整機對外提供密碼服務的能力。單個FPGA 計算單元的商用密碼4 算法電碼本（ECB,electronic codebook）模式加解密速度為7.34 Gbit/s。由于密碼算法運算的計算開銷會導致密碼運算的性能比轉發的性能低，隨著FPGA 計算單元數量的增加密碼服務系統整體的商用密碼4 算法ECB 模式加解密性能基本達到了線性增長，整機性能達到234.88 Gbit/s。

5.3.2資源占用情況分析

表3 列出了文獻[24-25]方案和本文方案在XC7K325T 芯片上的資源占用情況。表3 數據顯示，本文方案所占硬件資源總體較少，既節省了硬件資源，又能保證數據通信的可靠性、穩定性和高性能。

表3 XC7K325T 資源占用情況

6 結束語

本文針對云計算、物聯網中，服務器與海量差異化的計算單元和終端設備之間高速率、高可靠性、低時延、自適應的數據通信需求，設計了支持差異化、可協商的數據通信機制；通過參數協商根據接收端能力的不同，協商出合適的滑動窗口大小和同步包序號，采用不同通信速率，實現差異化可協商的數據通信；設計重傳反饋機制，根據ACK 準確反饋接收端數據接收狀態，發送端動態自適應地進行數據的發送和重傳，有效緩解通信過程中的擁塞情況，降低丟包率，提高通信可靠性和效率。本文在服務器-FPGA 計算單元架構上進行實驗，對本文設計的數據通信機制的有效性和性能進行了測試，結果表明所提機制能夠根據計算單元能力的不同，進行差異化、并行、高效、可靠的數據通信。本文所提通信機制已應用在某密碼設備中，驗證了通信機制的高效性。