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

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

1 引言

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

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

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

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

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

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

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

2 相關(guān)工作

由于云計算和物聯(lián)網(wǎng)中各種應(yīng)用對高性能數(shù)據(jù)通信的迫切需求以及傳統(tǒng)數(shù)據(jù)通信協(xié)議本身在云環(huán)境和物聯(lián)網(wǎng)中的不足，使研究適用于新環(huán)境下的高速數(shù)據(jù)通信方法成為熱點，本文主要從數(shù)據(jù)通信方法本身入手，對相關(guān)研究進行論述。

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

Syzov 等[14]在高速數(shù)據(jù)通信環(huán)境下提出多線程收發(fā)和自適應(yīng)資源分配的通信方案，以解決單通路UDP 數(shù)據(jù)收發(fā)時帶寬利用率不足的問題。該方案在高速大數(shù)據(jù)量傳輸時性能表現(xiàn)很好，但是線程管理和冗余資源回收機制的不足導(dǎo)致該方案不能根據(jù)傳輸速度的變化動態(tài)調(diào)整系統(tǒng)資源的消耗。

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

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

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

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

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

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

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

3 差異化、可協(xié)商的數(shù)據(jù)通信機制模型

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

3.1 應(yīng)用場景分析

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

圖1 應(yīng)用場景

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

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

圖2 密碼服務(wù)系統(tǒng)模型

數(shù)據(jù)接收模塊采用滑動窗口和選擇重傳機制保證密碼服務(wù)數(shù)據(jù)包的正確性和完整性，提高數(shù)據(jù)傳輸?shù)男阅埽幻艽a服務(wù)調(diào)度模塊將正確接收的密碼服務(wù)數(shù)據(jù)包根據(jù)密碼算法類型的不同分發(fā)到密碼算法運算模塊中不同的密碼算法的IP 核進行處理；密碼服務(wù)匯聚模塊對運算完成后的密碼服務(wù)數(shù)據(jù)包進行聚合；數(shù)據(jù)發(fā)送模塊同樣采用滑動窗口和選擇重傳機制來保證數(shù)據(jù)傳輸?shù)恼_性和性能。

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

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

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

則密碼服務(wù)數(shù)據(jù)包的額外時間開銷僅與數(shù)據(jù)發(fā)送和接收的時間相關(guān)，即

3.2 通信機制模型

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

圖3 通信機制模型

參數(shù)協(xié)商是指通信開始之前，通信雙方根據(jù)自身硬件資源大小和數(shù)據(jù)處理能力協(xié)商出合適的滑動窗口大小、同步包序號等關(guān)鍵參數(shù)。參數(shù)協(xié)商分為參數(shù)協(xié)商請求和參數(shù)協(xié)商反饋。參數(shù)協(xié)商請求由發(fā)送端發(fā)給接收端，內(nèi)含發(fā)送端期望的接收端滑動窗口大小和同步包序號。參數(shù)協(xié)商反饋由接收端發(fā)給發(fā)送端，內(nèi)含接收端滑動窗口大小和同步包序號。參數(shù)協(xié)商充分考慮不同數(shù)據(jù)通信終端硬件資源和數(shù)據(jù)處理能力的差異，通過協(xié)商避免因數(shù)據(jù)通信的原因影響設(shè)備其他功能的正常運轉(zhuǎn)，同時避免因通信兩端數(shù)據(jù)處理能力差異導(dǎo)致的數(shù)據(jù)包丟失，保證數(shù)據(jù)傳輸?shù)母咝浴?/p>

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

數(shù)據(jù)接收包括接收數(shù)據(jù)和反饋ACK。接收端對接收的數(shù)據(jù)包進行解析，首先根據(jù)數(shù)據(jù)包序號和接收端滑動窗口狀態(tài)確定數(shù)據(jù)包的接收狀態(tài)，然后根據(jù)數(shù)據(jù)包的接收狀態(tài)生成正常接收ACK、重傳ACK 和丟棄ACK。除了ACK 信息，接收端還將數(shù)據(jù)處理情況反饋給發(fā)送端，使發(fā)送端據(jù)此動態(tài)調(diào)整數(shù)據(jù)發(fā)送速率，避免通信鏈路的擁塞，提高數(shù)據(jù)傳輸?shù)母咝浴?/p>

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

3.2.1參數(shù)協(xié)商模塊

參數(shù)協(xié)商模塊的時間自動機定義為A=。

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

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

圖4 參數(shù)協(xié)商模塊時間自動機

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

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

3.2.2數(shù)據(jù)發(fā)送模塊

數(shù)據(jù)發(fā)送模塊的時間自動機定義為S=。

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

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

圖5 數(shù)據(jù)發(fā)送模塊時間自動機

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

3.2.3數(shù)據(jù)接收模塊

數(shù)據(jù)接收模塊的時間自動機定義為R=

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

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

圖6 數(shù)據(jù)接收模塊時間自動機

4 差異化、可協(xié)商的數(shù)據(jù)通信流程

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

4.1 參數(shù)協(xié)商

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

4.1.1參數(shù)協(xié)商中的包結(jié)構(gòu)

參數(shù)協(xié)商主要根據(jù)參數(shù)協(xié)商包和參數(shù)協(xié)商反饋包進行協(xié)商。

參數(shù)協(xié)商包結(jié)構(gòu)可表示為AgreePkt={ExpectAgreeSeq,ExpectWindowSize}其中，ExpectAgreeSeq 表示期望同步包序號，ExpectWindowSize 表示期望接收端滑動窗口大小。

參數(shù)協(xié)商反饋包結(jié)構(gòu)可表示為AgreeRespPkt={RecvAgreeSeq,RecvWindowSize}其中，RecvAgreeSeq 表示接收端同步包序號，RecvWindowSize 表示接收端滑動窗口大小。

4.1.2參數(shù)協(xié)商流程

發(fā)送端設(shè)置期望同步包序號、期望接收端滑動窗口大小，構(gòu)造參數(shù)協(xié)商包發(fā)送給接收端。

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

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

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

4.2 數(shù)據(jù)通信

發(fā)送端和接收端完成參數(shù)協(xié)商之后即可進行正常的數(shù)據(jù)通信。

4.2.1數(shù)據(jù)通信中的包結(jié)構(gòu)

數(shù)據(jù)通信主要包括數(shù)據(jù)包和ACK 包。數(shù)據(jù)包表示待傳輸?shù)挠行?shù)據(jù)，ACK 包表示接收端根據(jù)數(shù)據(jù)接收和處理情況生成的反饋包。

數(shù)據(jù)包結(jié)構(gòu)可表示為

其中，Seq 表示數(shù)據(jù)包的包序號，Cmd 表示數(shù)據(jù)包的命令字段，Length 表示數(shù)據(jù)包中Data 的長度，Data 表示待傳輸?shù)臄?shù)據(jù)。

ACK 包結(jié)構(gòu)可表示為

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

4.2.2數(shù)據(jù)通信流程

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

當滿足數(shù)據(jù)包發(fā)送條件時，發(fā)送端從待發(fā)送隊列中取出一個或多個待發(fā)送的數(shù)據(jù)包按照4.2.1 節(jié)數(shù)據(jù)包結(jié)構(gòu)來構(gòu)造數(shù)據(jù)包發(fā)送給接收端，并保存到待確認隊列中。

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

數(shù)據(jù)發(fā)送完成或者ACK 包處理完成后，更新發(fā)送端滑動窗口狀態(tài)。

發(fā)送端滑動窗口狀態(tài)可表示為

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

數(shù)據(jù)接收時，接收端根據(jù)數(shù)據(jù)接收和處理情況生成ACK 包反饋給發(fā)送端。

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

接收端滑動窗口狀態(tài)可表示為

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

數(shù)據(jù)通信時，發(fā)送端根據(jù)數(shù)據(jù)包發(fā)送條件，充分考慮接收端接收速率的變化，動態(tài)調(diào)整發(fā)送端的數(shù)據(jù)包發(fā)送速率，能夠有效降低數(shù)據(jù)傳輸?shù)膩G包率；同時，充分利用了接收端反饋的ACK 包，對發(fā)送端待確認隊列中的數(shù)據(jù)包進行確認和重傳，發(fā)送端根據(jù)接收端不同接收能力和狀態(tài)動態(tài)自適應(yīng)地發(fā)送和重傳，提高了通信效率和可靠性。

數(shù)據(jù)通信時，發(fā)送端可以給不同接收端發(fā)送數(shù)據(jù)，接收端可以同時作為發(fā)送端，原來的發(fā)送端也可以同時作為接收端，進行雙向通信，即一臺設(shè)備或一個系統(tǒng)或一個組件或一個線程或一個進程中可以同時部署發(fā)送端和接收端，以實現(xiàn)發(fā)送端和接收端的多對多、并行、全雙工、雙向通信。

5 實驗與結(jié)果分析

5.1 實驗環(huán)境

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

圖7 ATCA 平臺系統(tǒng)架構(gòu)

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

表1 實驗環(huán)境

5.2 通信機制容錯效果分析

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

表2 通信協(xié)議容錯實驗結(jié)果

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

5.3 通信機制性能分析

5.3.1轉(zhuǎn)發(fā)性能分析

轉(zhuǎn)發(fā)實驗的基本原理是在測試服務(wù)器和FPGA計算單元分別設(shè)置不同大小的滑動窗口，測試服務(wù)器分別使用不同數(shù)據(jù)包大小發(fā)送大量數(shù)據(jù)給FPGA計算單元，F(xiàn)PGA 計算單元收到數(shù)據(jù)之后再轉(zhuǎn)回測試服務(wù)器，數(shù)據(jù)傳輸完成后根據(jù)傳輸數(shù)據(jù)量和所用時間計算通信速率。

轉(zhuǎn)發(fā)實驗共配置2 種實驗環(huán)境，一種是測試服務(wù)器通過10 Gbit/s 網(wǎng)卡與FPGA 計算單元進行通信，另一種是測試服務(wù)器通過100 Gbit/s 網(wǎng)卡與FPGA 計算單元進行通信。每種環(huán)境在實驗時共設(shè)置8 組滑動窗口大小，5 種數(shù)據(jù)包大小。

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

圖8 通信協(xié)議速率10 Gbit/s 網(wǎng)卡實驗結(jié)果

圖9 通信協(xié)議速率100 Gbit/s 網(wǎng)卡實驗結(jié)果

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

圖10 10 Gbit/s 網(wǎng)絡(luò)環(huán)境下3 種通信機制的性能對比

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

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

圖11 通信協(xié)議速率100 Gbit/s 網(wǎng)卡多FPGA 計算單元實驗結(jié)果

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

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

5.3.2資源占用情況分析

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

表3 XC7K325T 資源占用情況

6 結(jié)束語

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