支持差異化可協(xié)商的數(shù)據(jù)通信機(jī)制

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

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

1 引言

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

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

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

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

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

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

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

2 相關(guān)工作

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

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

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

基于RUDP，Luo 等[15]針對(duì)航空自組織網(wǎng)絡(luò)[16]中可靠高效數(shù)據(jù)傳輸問(wèn)題提出了帶噴泉碼的可靠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ǔ)上添加控制機(jī)制來(lái)降低通信過(guò)程中的丟包率，以達(dá)到提高通信效率的目的。Christensen 等[19]提出在現(xiàn)場(chǎng)可編程門陣列（FPGA,field programmable gate array）和數(shù)字信號(hào)處理器（DSP,digital signal processor）等硬件設(shè)備上實(shí)現(xiàn)可靠UDP 通信，通過(guò)修改網(wǎng)絡(luò)最大包長(zhǎng)度來(lái)提高傳輸性能。

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

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

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

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

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

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

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

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

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

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

圖1 應(yīng)用場(chǎng)景

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

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

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

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

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

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

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

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

3.2 通信機(jī)制模型

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

圖3 通信機(jī)制模型

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

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

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

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

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

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

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

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

圖4 參數(shù)協(xié)商模塊時(shí)間自動(dòng)機(jī)

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

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

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

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

其中，Ls表示數(shù)據(jù)發(fā)送模塊的位置集合，包含6 個(gè)位置，Idle 表示空閑，SendData 表示發(fā)送數(shù)據(jù)，RetransData 表示重傳數(shù)據(jù)，RecvAck 表示接收ACK，SendSucess 表示數(shù)據(jù)發(fā)送成功，UpdateStatus表示更新滑動(dòng)窗口狀態(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ā)送模塊的有限時(shí)鐘集合；Is表示數(shù)據(jù)發(fā)送的映射，為L(zhǎng)s中的每一個(gè)位置指定Φ(Xs)的一個(gè)時(shí)鐘約束；Es表示數(shù)據(jù)發(fā)送模塊位置遷移關(guān)系集合。

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

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

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

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

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

其中，Lr表示數(shù)據(jù)接收模塊的位置集合，包含3 個(gè)位置，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ù)接收模塊的有限時(shí)鐘集合；Ir表示數(shù)據(jù)接收的映射，為L(zhǎng)r中的每一個(gè)位置指定Φ(Xr)的一個(gè)時(shí)鐘約束；Er表示數(shù)據(jù)接收模塊位置遷移關(guān)系集合。

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

圖6 數(shù)據(jù)接收模塊時(shí)間自動(dòng)機(jī)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

發(fā)送端和接收端完成參數(shù)協(xié)商之后即可進(jìn)行正常的數(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ù)包的包序號(hào)，Cmd 表示數(shù)據(jù)包的命令字段，Length 表示數(shù)據(jù)包中Data 的長(zhǎng)度，Data 表示待傳輸?shù)臄?shù)據(jù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 實(shí)驗(yàn)與結(jié)果分析

5.1 實(shí)驗(yàn)環(huán)境

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

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

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

表1 實(shí)驗(yàn)環(huán)境

5.2 通信機(jī)制容錯(cuò)效果分析

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

表2 通信協(xié)議容錯(cuò)實(shí)驗(yàn)結(jié)果

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

5.3 通信機(jī)制性能分析

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3.2資源占用情況分析

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

表3 XC7K325T 資源占用情況

6 結(jié)束語(yǔ)

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