王繼昌,呂高鋒,劉忠沛,楊翔瑞

(國防科技大學(xué)計(jì)算機(jī)學(xué)院,湖南 長沙 410073)

1 引言

QUIC(Quick UDP Internet Connection)是與TCP并行部署在用戶空間的一種新型、安全、通用的互聯(lián)網(wǎng)傳輸協(xié)議[1-4]。它向下基于操作系統(tǒng)提供UDP套接字層,向上為應(yīng)用層協(xié)議(如HTTP3[5])提供可靠且安全的多流傳輸通道(Multi-Stream)。QUIC與TCP架構(gòu)的對(duì)比如圖1所示。在傳輸功能(Quic-transport)方面,協(xié)議棧內(nèi)置擁塞控制、流量控制和丟包恢復(fù)(Quic-recovery)等功能模塊,實(shí)現(xiàn)類似TCP協(xié)議的擁塞控制(Congestion Control)、可信(Reliability)傳輸。在連接管理方面,建立狀態(tài)機(jī),對(duì)網(wǎng)絡(luò)連接的建立、保持、遷移、終止等狀態(tài)進(jìn)行管理,使QUIC具備面向連接的特性。在安全性能方面,QUIC內(nèi)置TLS(Transport Layer Security)1.3[6],使用quic記錄層(quic-record)模塊代替TLS1.2[7]中的記錄層(Record Layer)對(duì)報(bào)文加密/解密,它比當(dāng)前廣泛使用的TLS1.2更加安全,可以更好地保障用戶的隱私和通信安全。此外,QUIC沒有使用UDP端口來標(biāo)識(shí)一條傳輸層連接,而是采用連接標(biāo)示符CID(Connection ID),既為QUIC增加了連接遷移的特性,又保持了與現(xiàn)有網(wǎng)絡(luò)生態(tài)的兼容性。

Figure 1 Comparison of QUIC and TCP圖1 QUIC與TCP的對(duì)比

QUIC協(xié)議可以代替TCP+TLS來完成數(shù)據(jù)的安全可靠傳輸。與傳統(tǒng)的TCP協(xié)議相比,有以下3個(gè)顯著優(yōu)勢[8,9]:(1)多流(Multi-Stream)傳輸可緩解TCP協(xié)議特有的隊(duì)頭阻塞(Head-of-line Blocking)[10]問題;(2)更短的數(shù)據(jù)傳輸延遲,QUIC采用了TLS1.3的早期數(shù)據(jù)(Early Data)機(jī)制,2個(gè)終端在一定時(shí)間內(nèi)的重新連接,可以實(shí)現(xiàn)0-RTT數(shù)據(jù)傳輸延遲;(3)可插拔擁塞控制,由于部署在用戶空間,QUIC不需要操作系統(tǒng)和內(nèi)核的支持,就能夠在運(yùn)行過程中通過調(diào)用不同的程序接口實(shí)現(xiàn)不同的擁塞控制算法,甚至在不同連接上啟用特定于該連接的擁塞控制算法[8]。

QUIC具備諸多優(yōu)于TCP的設(shè)計(jì)[8,9],但是在處理報(bào)文時(shí),其CPU占用率是同等條件下TCP的3.5倍,這阻礙了QUIC被廣泛部署[11]。當(dāng)前網(wǎng)絡(luò)技術(shù)飛速發(fā)展,鏈路帶寬在過去的幾年增加了4～10倍,CPU資源(運(yùn)算速率、核心數(shù)、Cache資源等)的發(fā)展卻停滯不前。緊缺的計(jì)算資源限制了QUIC協(xié)議棧的性能發(fā)揮。為了破除這一障礙,Yang等人[12]對(duì)4種符合QUIC規(guī)范的開源實(shí)現(xiàn)進(jìn)行了測試和分析,指出CPU占用率的功能部件主要有以下2類(如圖2所示):

(1)用戶態(tài)與內(nèi)核態(tài)之間的數(shù)據(jù)拷貝,占用了協(xié)議相關(guān)的總CPU使用率的50%左右。該問題可通過引入DPDK(Data Plane Development Kit)[13]和Netmap[14]等內(nèi)核零拷貝框架解決。

(2)報(bào)文加密/解密AEAD(Authenticated Encryption with Associated Data)[15]操作。在存在內(nèi)核零拷貝優(yōu)化的情況下,加密/解密功能模塊最高可將每條連接的CPU計(jì)算資源占用率提高至40%,且當(dāng)前還沒有行之有效的方法降低AEAD的CPU占用率。

Figure 2 Detailed division of CPU usage[12]圖2 CPU占用率詳細(xì)劃分[12]

QUIC傳輸協(xié)議因其部署方便、多流并發(fā)等優(yōu)于TCP的特性,在未來數(shù)據(jù)中心網(wǎng)絡(luò)中的應(yīng)用必定更加廣泛。如何在保證QUIC傳輸性能的同時(shí),克服CPU占用率過高的缺點(diǎn),在當(dāng)前的硬件設(shè)備上對(duì)QUIC協(xié)議棧功能模塊的優(yōu)化設(shè)計(jì)成為當(dāng)前的研究熱點(diǎn)。本文基于DPU(Data Processing Unit)[16]平臺(tái)提出了卸載QUIC加密/解密的NanoBPF(Nano Berkeley Packet Filter)模型。該模型利用DPU支持的卸載眾核特性,將RISC眾核卸載至DPU上,結(jié)合了快速數(shù)據(jù)路徑XDP(eXpress Data Path)[17]的設(shè)計(jì)思想,通過在DPU上引導(dǎo)啟動(dòng)eBPF(extended Berkeley Packet Filter)代碼作為運(yùn)行時(shí)環(huán)境,以XDP程序的形式將加密/解密AEAD操作卸載至eBPF中。加密/解密AEAD操作完全在DPU眾核上執(zhí)行,減少主機(jī)的CPU開銷,從而提高報(bào)文吞吐率,滿足未來數(shù)據(jù)中心網(wǎng)絡(luò)的海量報(bào)文快速處理的需求。

本文在Genesys2開發(fā)板上對(duì)NanoBPF(Nano Berkeley Packet Filter)進(jìn)行評(píng)估,主要在本地實(shí)驗(yàn)場景測試QUIC協(xié)議的吞吐率,對(duì)性能提升進(jìn)行評(píng)估;在基于Docker[18]的網(wǎng)絡(luò)拓?fù)渲性O(shè)置瓶頸鏈路,測試TCP與QUIC共存時(shí)的帶寬占比,評(píng)估其公平性和可部署性。評(píng)估結(jié)果表明,報(bào)文加密/解密的軟件卸載能提高近13%的報(bào)文吞吐率,性能提升明顯。在與TCP共存的瓶頸鏈路中,帶寬占比達(dá)到閾值后,保持了相對(duì)靜止?fàn)顟B(tài),且研究表明,該帶寬比可以通過動(dòng)態(tài)修改QUIC滑動(dòng)窗口參數(shù)來保證瓶頸鏈路上的公平性[8],為NanoBPF模型在未來數(shù)據(jù)中心網(wǎng)絡(luò)中的廣泛部署提供了參考依據(jù)。

2 協(xié)議卸載與優(yōu)化方法相關(guān)研究

本節(jié)對(duì)協(xié)議卸載與優(yōu)化的相關(guān)研究做了細(xì)致調(diào)查分析,為NanoBPF的設(shè)計(jì)提供參考。以下分別從硬件卸載、RISC-V眾核加速和XDP數(shù)據(jù)包快速處理3個(gè)方面闡述協(xié)議優(yōu)化的典型方法及存在的不足。

2.1 面向無狀態(tài)功能模塊的硬件卸載

TOE(TCP Offload Engine)[19]充分探討了TCP在可重構(gòu)硬件上卸載的工作。作為傳輸層協(xié)議的QUIC,也可以進(jìn)行同樣的嘗試。仿照TOE的設(shè)計(jì)思想,Yang等人[12]通過剖析4種不同QUIC實(shí)現(xiàn),分析不同協(xié)議構(gòu)建塊的CPU成本,提出硬件/軟件協(xié)同設(shè)計(jì)的QUIC加速方案,在基于通用FPGA的智能網(wǎng)卡上實(shí)現(xiàn)部分協(xié)議棧的卸載?？紤]到現(xiàn)有可編程網(wǎng)卡的可用資源有限,卸載整個(gè)或者部分協(xié)議棧實(shí)現(xiàn)起來比較困難且通用性不強(qiáng),Hay等人[20]認(rèn)為,目前在用戶空間中實(shí)現(xiàn)的QUIC無法像TCP等舊協(xié)議棧一樣,依靠硬件卸載提升性能,但是可以設(shè)計(jì)一個(gè)接口來支持硬件卸載。他們從IPsec加密和傳輸分段可以顯著降低TCP協(xié)議棧對(duì)CPU利用率的研究中受到啟發(fā),提出了對(duì)QUIC短報(bào)頭報(bào)文的AES-GCM[21]加密/解密以及QUIC報(bào)文分段進(jìn)行卸載的方法。通過測試可知,卸載加密/解密和報(bào)文分段將CPU利用率降低了15%,吞吐量增加了32%。

以上2個(gè)方案中,面向無狀態(tài)功能模塊的硬件卸載的思想值得借鑒,但是加密/解密密鑰的管理和傳輸配置等依然由QUIC協(xié)議棧生成和控制,硬件與主機(jī)之間需要進(jìn)行頻繁的交互。缺乏有效的交互機(jī)制(如零拷貝),導(dǎo)致上下文切換和數(shù)據(jù)拷貝的開銷過大,很大程度上制約了QUIC的性能提升。

2.2 基于RISC-V眾核的并行處理

Ibanez等人[22]為最小化分布式應(yīng)用中RPC的尾部延遲,提出了一種通過擴(kuò)展RISC-V核建立的新型網(wǎng)絡(luò)優(yōu)化原型——NanoPU(Nano Processing Unit)。它在每個(gè)芯片上實(shí)例化512個(gè)RISC-V微核,每個(gè)核分配16 KB的L1緩存。在分布式應(yīng)用場景中,該芯片能夠達(dá)到350 Mpkts/s處理速度,比軟件處理方案快了近50倍,線到線(Line-To-Line)延遲僅為65 ns,比當(dāng)前最先進(jìn)的技術(shù)的快了13 s。理想情況下,網(wǎng)卡維護(hù)一個(gè)全局RX隊(duì)列,微內(nèi)核可以從這個(gè)隊(duì)列中提取下一個(gè)處理消息,從而實(shí)現(xiàn)最低的預(yù)期等待時(shí)間。但是,僅有一個(gè)全局隊(duì)列是不合理的,因?yàn)樗笏械暮送瑫r(shí)從一個(gè)全局RX隊(duì)列中讀取數(shù)據(jù)。為此,NanoPU中啟用了JBSQ(2)(Join Bounded Shortest Queue)[23]硬件核心選擇算法,對(duì)全局隊(duì)列中的任務(wù)進(jìn)行科學(xué)調(diào)度,其中“2”表示每個(gè)核中未完成任務(wù)的最大數(shù)量。

NanoPU的超高性能以及超低延遲的實(shí)現(xiàn),很大程度上得益于基于改進(jìn)的RISC-V多核并行設(shè)計(jì)以及對(duì)RPC請(qǐng)求的直接響應(yīng)。其借助RISC指令集的微內(nèi)核實(shí)現(xiàn)報(bào)文處理加速的設(shè)計(jì)思想為協(xié)議性能優(yōu)化提供了有力參考。但是,NanoPU的眾多微內(nèi)核的管理與調(diào)度成為了制約NanoPU性能躍升的瓶頸,如果管理不當(dāng),會(huì)造成內(nèi)核之間的數(shù)據(jù)污染。而且,NanoPU的部署相對(duì)困難,功能固化,無法靈活卸載多種協(xié)議模塊,在適應(yīng)多樣化用戶需求的網(wǎng)絡(luò)環(huán)境中的可部署性相對(duì)較差。

2.3 基于eBPF的XDP通用協(xié)議棧優(yōu)化

H?iland-J?rgensen等人[17]提出了一種基于eBPF的新型通用的、可編程報(bào)文處理框架——XDP(eXpress Data Path)。XDP可以看作是一種軟件卸載,卸載協(xié)議棧的關(guān)鍵功能模塊的同時(shí),允許內(nèi)核的網(wǎng)絡(luò)棧處理其余部分,支持定制的高速報(bào)文處理與內(nèi)核特性混合工作模式。性能評(píng)估表明,XDP在單個(gè)CPU核上實(shí)現(xiàn)了高達(dá)24 Mb/s的原始數(shù)據(jù)包處理性能。雖然比不上DPDK,但是保留了內(nèi)核安全性和管理的兼容性,并提供了穩(wěn)定的編程接口。Vieira等人[24]在5G網(wǎng)絡(luò)下提出了基于eBPF和XDP的報(bào)文快速處理設(shè)計(jì),用以降低報(bào)文處理延遲。在操作系統(tǒng)分配套接字緩沖區(qū)(Socket Buffer)之前,通過設(shè)備驅(qū)動(dòng)程序接收鏈中的一個(gè)鉤子(Hook),在內(nèi)核中實(shí)現(xiàn)快速的包處理。當(dāng)報(bào)文被接收時(shí),包含BPF程序的鉤子就會(huì)被執(zhí)行。其中,eBPF虛擬機(jī)在設(shè)備驅(qū)動(dòng)程序的上下文中運(yùn)行,為自定義報(bào)文處理程序提供安全的運(yùn)行時(shí)環(huán)境。

Figure 3 NanoBPF model圖3 NanoBPF 模型

基于eBPF的XDP通用協(xié)議棧加速為協(xié)議優(yōu)化提供了可部署的兼容性以及可編程的靈活性。但是,當(dāng)前的XDP程序只能掛載到操作系統(tǒng)的內(nèi)核中,運(yùn)行時(shí)驗(yàn)證和編譯進(jìn)程將會(huì)占用大量的主機(jī)CPU資源,從而限制主機(jī)處理數(shù)據(jù)的性能。鑒于此類問題,Kicinski等人[25]提出了一種將XDP程序卸載到智能網(wǎng)卡的設(shè)計(jì)理念,與DPDK[13]將網(wǎng)絡(luò)流上載(Upload)到用戶程序的內(nèi)核旁路模式相反,eBPF智能網(wǎng)卡采用卸載模式(Offload),由灌入智能網(wǎng)卡中的XDP程序直接處理數(shù)據(jù)流。該研究為本文中基于DPU以eBPF/XDP程序的形式卸載QUIC加密/解密模型提供了思路和細(xì)節(jié)參考。

3 NanoBPF加密/解密卸載模型

當(dāng)CPU的計(jì)算資源成為制約協(xié)議棧性能發(fā)揮的關(guān)鍵瓶頸時(shí),通?？梢圆捎糜布遁d、片上多核并行和XDP軟件卸載相結(jié)合的方式進(jìn)行優(yōu)化。Yang等人[12]的測量結(jié)果為模型設(shè)計(jì)提供了重要的背景支撐。以該研究結(jié)論為出發(fā)點(diǎn),本文提出基于DPU中RISC眾核的協(xié)議卸載模型——NanoBPF。結(jié)合協(xié)議棧通用優(yōu)化框架,選擇QUIC中CPU占用率較高的報(bào)文加密/解密模塊進(jìn)行卸載,以期達(dá)到性能優(yōu)化的目的。

3.1 NanoBPF模型

NanoBPF模型如圖3所示。該模型按照功能可劃分為PISA硬件傳輸(Protocol Independent Switch Architecture HW Transport)、報(bào)文分類(Packet Classifier)、報(bào)文加密/解密(Pakcet Crypto)和核心選擇(Core Sel)4個(gè)模塊。受NanoPU[22]中基于P4的硬件流水線啟發(fā),PISA硬件傳輸模塊對(duì)接受到的報(bào)文進(jìn)行3層以下的預(yù)處理。報(bào)文分類器根據(jù)QUIC報(bào)文的分類邏輯,對(duì)傳入的報(bào)文進(jìn)行分類,可調(diào)用XDP返回碼(Return Code)實(shí)現(xiàn)報(bào)文的重定向。報(bào)文加密/解密模塊在核心選擇模塊選定的核心上,對(duì)分類后的報(bào)文進(jìn)行加密/解密處理,并在加密/解密結(jié)束前調(diào)用Redirect返回碼,將數(shù)據(jù)直接送往用戶空間。RISC多核eBPF代碼運(yùn)行在DPU上,為功能模塊的運(yùn)行提供安全的運(yùn)行時(shí)環(huán)境。其中,功能模塊均為受限的C語言編碼,在被LLVM/Clang編譯器編譯成字節(jié)碼后,依靠BPF_maps完成功能模塊的動(dòng)態(tài)加載。

NanoBPF結(jié)合了eBPF的工作模型以及NanoPU的眾核并行設(shè)計(jì)思想,有以下3個(gè)方面的優(yōu)點(diǎn):

(1)XDP可以在不中斷的情況下進(jìn)行動(dòng)態(tài)重編程,修改功能模塊的邏輯;

(2)既不需要專用的硬件支持,也不需要專門用于報(bào)文處理的資源,在商用DPU上就能夠?qū)崿F(xiàn);

(3)eBPF能夠以最好的性能執(zhí)行XDP程序,且在DPU網(wǎng)卡上執(zhí)行,無需修改內(nèi)核和操作系統(tǒng)。

3.2 功能模塊

下面依次描述各模塊的設(shè)計(jì)以及功能。

3.2.1 PISA硬件傳輸(PISA HW Transport)

為了減少協(xié)議棧傳輸邏輯處理所導(dǎo)致的主機(jī)開銷,本文參考NanoPU[22]設(shè)計(jì)架構(gòu)中基于P4的PISA流水線,對(duì)接收的報(bào)文進(jìn)行預(yù)處理。硬件傳輸模塊主要處理3層(3-Layer)以下數(shù)據(jù)幀頭:

(1)添加/去除數(shù)據(jù)幀頭,完成太網(wǎng)幀之間與QUIC報(bào)文之間的轉(zhuǎn)化;

(2)從接收的消息中提取元數(shù)據(jù)參數(shù),用于組裝/分段和亂序報(bào)文;

(3)重組(Reassembly)緩存區(qū)接收的亂序報(bào)文,分包(Packetization)緩沖區(qū)對(duì)發(fā)送報(bào)文進(jìn)行分段。

硬件傳輸模塊工作在流水線(Pipeline)模式下,可以同時(shí)處理多個(gè)以太網(wǎng)幀,當(dāng)主機(jī)建立起一個(gè)QUIC連接之后,主機(jī)CPU可以不再關(guān)注報(bào)文發(fā)送和接收情況,由PISA負(fù)責(zé)報(bào)文的發(fā)送、接收、確認(rèn)、重傳、校驗(yàn)等處理。硬件傳輸模塊能夠有效地釋放CPU時(shí)鐘周期,而且硬件實(shí)現(xiàn)的傳輸控制模塊的響應(yīng)速度要遠(yuǎn)快于軟件的,能夠進(jìn)一步降低處理時(shí)延。

3.2.2 報(bào)文分類(Packet Classifier)

作為XDP功能流水線的接入點(diǎn),它以XDP程序的形式掛載到eBPF虛擬機(jī)中,主要通過報(bào)文頭的flag字段以及報(bào)文號(hào)字段共同確定報(bào)文的類型,調(diào)用XDP返回碼對(duì)報(bào)文進(jìn)行分類處理,決定報(bào)文下一步的處理流程。處理過程如下:截取傳入報(bào)文的報(bào)文頭第0個(gè)字節(jié)header[0],執(zhí)行header[0]& 0x80,確定是報(bào)頭類型;然后執(zhí)行header[0]&0x30或者h(yuǎn)eader[0]&0x40,進(jìn)一步驗(yàn)證報(bào)文的合法性。相關(guān)規(guī)定表明:(1)在長報(bào)頭報(bào)文中,除最初的Initial報(bào)文、Retry報(bào)文和版本協(xié)商報(bào)文外,其他報(bào)文均需要經(jīng)過加密保護(hù),通過執(zhí)行header[0]& 0x30得出不同的值,確定以上3種報(bào)文類型;(2)短報(bào)頭通常為1-RTT報(bào)文,且header[0]&0x40位必須為1。

以輸入流為例,對(duì)于識(shí)別出不同類型的報(bào)文頭的處理原則為:(1)將不滿足以上條件的報(bào)文調(diào)用Drop返回碼作丟棄處理;(2)無需解密的報(bào)文調(diào)用Pass返回碼交付到網(wǎng)絡(luò)子系統(tǒng);(3)需要進(jìn)行解密操作的報(bào)文交付到全局隊(duì)列(Global Queue)緩存。

輸出流以相反的順序進(jìn)行處理,在交付到硬件傳輸單元前,再次對(duì)報(bào)文頭部進(jìn)行分類驗(yàn)證處理。eBPF與用戶空間之間的數(shù)據(jù)交流可通過調(diào)用Redirect返回碼,攜帶重定向的參數(shù)實(shí)現(xiàn)。

3.2.3 報(bào)文加密/解密(Pakcet Crypto)

QUIC報(bào)文的加密/解密主要分為AEAD和報(bào)頭保護(hù)2個(gè)部分。AEAD中的加密算法通常在QUIC初始化過程中被確定,其中最常使用的是AES_GCM,也是在運(yùn)行過程中CPU占用率最高的環(huán)節(jié)。AES_GCM加密算法目前有多種實(shí)現(xiàn)方案,其中以軟件實(shí)現(xiàn)方案為眾。得益于開源eBPF運(yùn)行時(shí)環(huán)境的動(dòng)態(tài)載入特性,可以將AES_GCM的C語言實(shí)現(xiàn)編譯成BPF字節(jié)碼,在執(zhí)行之前由eBPF自帶的JIT編譯器編譯成本地RISC操作碼,由DPU核解釋執(zhí)行。通過測試,該AES_GCM實(shí)現(xiàn)能夠以不低于2.4 Gbps的速率處理報(bào)文。報(bào)頭保護(hù)的操作比較簡單,在加密完成之后使用報(bào)頭保護(hù)密鑰以及密文樣本加密生成5字節(jié)掩碼與報(bào)頭的相應(yīng)字段進(jìn)行異或操作。

以上實(shí)現(xiàn)方法與已有同類軟件算法相比,一方面經(jīng)過JIT編譯后的操作碼能夠以最高性能運(yùn)行,提升了數(shù)據(jù)加解密的處理速度;另一方面釋放了主機(jī)CPU處理加密/解密的時(shí)鐘周期。

3.2.4 核心選擇(Core Sel)

在數(shù)據(jù)流量較大時(shí),為防止出現(xiàn)進(jìn)程餓死或者計(jì)算資源浪費(fèi)的問題,傳入的報(bào)文必須面向多核心作負(fù)載均衡。該模塊的設(shè)計(jì)依賴于軟件實(shí)現(xiàn)的改進(jìn)的SJBSQ(4)(Software-based JBSQ)調(diào)度算法,算法偽碼如算法1所示。為輸入或者輸出的數(shù)據(jù)流量維護(hù)一個(gè)全局隊(duì)列,并在每個(gè)核心上維護(hù)每核的隊(duì)列,通過特定的調(diào)度算法,將處理的任務(wù)下發(fā)到不同的內(nèi)核進(jìn)行處理。

算法1SJBSQ(4)

輸入：Cid,Core;/*Cidfor connection id,Coreis a structure,include couter,bitmap and max number*/

輸出：True,False。

1.functionCoreselection(Cid,Core)

2.tmp←index←HASH(Cid,core.max);

3.ret←SELECT(index,tmp,Core);

4.ifret=waitqueuethen

5.returnFalse;

6.else

7. process by the selected core;

8.UPDATECORE(index,core);

9.returnTrue;

10.endif

11.endfunction

12./*Overall process of core selection algorithm.*/

13.functionUPDATECORE(index,core)

14.core.counter[index] --;

15.ifcore.bitmap[index]=1then

16.core.bitmap[index] ← 0;

17.core.counter[index]++;

18.endif

19.endfunction

20./* Processing logic for counters and bitmaps after a core has processed a task.*/

21.functionSELECT(index,tmp,Core)

22.ifindex+1=tmpthen

23.ret←waitquenen;

24.returnret;/*The core is busy,so wait*/

25.endif

26.ifcore.bitmap[index]=0then

27.ifcore.counter[index]=4then/* Counters cannot exceed 4 */

28.core.bitmap[index] ← 1;

29.endif

30.ret←index;

31.else

32.ret←SELECT(index++,tmp,core);

33.endif

34.returnret;

35.endfunction

36./* Select the core to process the next task.*/

該算法采用由2個(gè)表實(shí)現(xiàn)。第1個(gè)表由每核位圖通過連接id的索引號(hào)動(dòng)態(tài)映射到各連接ID號(hào);第2個(gè)表由內(nèi)核維護(hù)一個(gè)不大于4的計(jì)數(shù)器,控制等待處理的報(bào)文數(shù)量。報(bào)文到達(dá)時(shí)首先檢驗(yàn)該連接ID對(duì)應(yīng)索引號(hào)的位圖是否為1,如果不為1,則進(jìn)一步查驗(yàn)計(jì)數(shù)器的值加1后是否為4,如果為4,則將該核心對(duì)應(yīng)的位圖置為1,待報(bào)文處理完成后恢復(fù)為零,且計(jì)數(shù)器減去相應(yīng)的值。位圖為1時(shí)索引號(hào)自增,按照相同邏輯在下一個(gè)核心上處理。如果所有核心上的等待處理報(bào)文數(shù)均為4,則進(jìn)入阻塞等待狀態(tài)。通過SJBSQ(4)調(diào)度算法,可以科學(xué)地選擇運(yùn)行的內(nèi)核,核心選擇功能模塊由綁定的核心(Core 0)進(jìn)行單獨(dú)管理。

3.3 報(bào)文處理流程

結(jié)合以上對(duì)各模塊的介紹,從入、出、加密/解密處理3個(gè)階段描述NanoBPF的報(bào)文處理流程。

3.3.1 Ingress入流水線

報(bào)文到達(dá)網(wǎng)卡時(shí),可編程PISA流水線按照QUIC協(xié)議的處理邏輯進(jìn)行預(yù)處理,并將處理完成的報(bào)文交付給重組緩沖區(qū)。此時(shí),在緩沖區(qū)中,為每條需要交付給應(yīng)用的消息維護(hù)一段元數(shù)據(jù),該元數(shù)據(jù)包含連接配置信息、消息編號(hào)等。經(jīng)過緩沖區(qū)重組的報(bào)文與元數(shù)據(jù)一并交付給eBPF。由于eBPF屬于事件觸發(fā)(Event Driver),報(bào)文一到達(dá),XDP程序就開始運(yùn)行。

首先由報(bào)文分類器通過報(bào)文頭部的flag字段對(duì)報(bào)文類型進(jìn)行解析,識(shí)別報(bào)文號(hào)空間。報(bào)文分類后的處理可以分為以下3種情況:(1)報(bào)文類型無法識(shí)別,通過XDP的Drop返回碼將報(bào)文丟棄。(2)識(shí)別為握手報(bào)文、版本協(xié)商報(bào)文或者Retry報(bào)文時(shí),由于QUIC協(xié)議棧以明文的形式處理這些報(bào)文,XDP允許將報(bào)文上傳(Pass)到內(nèi)核網(wǎng)絡(luò)棧,同時(shí)主機(jī)CPU會(huì)分配并填充一個(gè)skb(socket buffer),由內(nèi)核協(xié)議棧繼續(xù)處理。(3)識(shí)別為需加密/解密處理的報(bào)文時(shí),將報(bào)文交付到eBPF代碼中的全局隊(duì)列中,并提取報(bào)文的連接ID為索引,對(duì)eBPF和用戶空間各自維護(hù)的狀態(tài)表(State Table)表項(xiàng)進(jìn)行同步,獲取報(bào)文解密信息。在眾核選擇模塊根據(jù)連接ID為報(bào)文分配處理的內(nèi)核之后,在相應(yīng)的內(nèi)核上進(jìn)行解密處理,最后通過Netmap零拷貝機(jī)制,應(yīng)用程序從共享內(nèi)存中提取數(shù)據(jù)。

3.3.2 Egress流水線

應(yīng)用程序下發(fā)的消息可以分為2種情況進(jìn)行處理:(1)當(dāng)應(yīng)用程序下發(fā)的消息不需要進(jìn)行加密處理時(shí),直接將數(shù)據(jù)交付給主機(jī)的QUIC協(xié)議棧進(jìn)行處理,完成之后,由eBPF通過其中的XDP程序轉(zhuǎn)發(fā)到Packetization緩沖區(qū)。(2)需要進(jìn)行加密處理時(shí),應(yīng)用程序線程通過Netmap[14]機(jī)制將消息和相關(guān)的元數(shù)據(jù)發(fā)送到DPU的緩存空間,用戶空間與eBPF代碼維護(hù)的狀態(tài)表根據(jù)連接ID索引進(jìn)行表項(xiàng)信息同步,獲取該消息的加密信息;使用獲取到的加密信息對(duì)該消息進(jìn)行加密,由XDP程序?qū)⒓用芎蟮臄?shù)據(jù)交付到重組緩沖區(qū),由硬件傳輸模塊根據(jù)報(bào)文元數(shù)據(jù)、UDP的負(fù)載情況進(jìn)行分段處理,之后與元數(shù)據(jù)一并交付給PISA流水線,根據(jù)攜帶的元數(shù)據(jù)添加相應(yīng)的報(bào)文頭,通過網(wǎng)口轉(zhuǎn)發(fā)至相應(yīng)的網(wǎng)絡(luò)節(jié)點(diǎn)。

3.3.3 報(bào)文加密/解密處理

報(bào)文加密/解密分為AEAD和報(bào)頭保護(hù)2個(gè)部分。其中AEAD處理的數(shù)據(jù)量較大,流程比較復(fù)雜,占據(jù)了大部分的時(shí)鐘周期;而報(bào)頭保護(hù)每個(gè)報(bào)文只需進(jìn)行一次AES加密/解密,其余均為異或操作,相比AEAD簡便得多。所以,在處理一個(gè)QUIC報(bào)文時(shí),報(bào)頭保護(hù)操作所占用的CPU資源可忽略不計(jì)。

Figure 4 Encryption logic of AES_GCM圖4 AES-GCM加密邏輯

(1)AEAD。AES-GCM是帶認(rèn)證和加密的算法,即可以對(duì)給定的原文生成加密數(shù)據(jù)和認(rèn)證碼。在獲取到需要加密/解密的報(bào)文以及相應(yīng)的密鑰之后,AES_GCM的加密流程如圖4所示。準(zhǔn)備工作:檢查報(bào)文長度,并通過相應(yīng)的填充方式對(duì)報(bào)文進(jìn)行填充,使其長度為16字節(jié)的整數(shù)倍。①將消息按每組16字節(jié)分成明文組,同時(shí)啟動(dòng)計(jì)數(shù)器(Counter)。按照前8位根據(jù)初始向量iv(initial vector)生成隨機(jī)數(shù),后8位全為零的規(guī)則生成計(jì)數(shù)器Counter+0,使用密鑰加密第0個(gè)計(jì)數(shù)器值;②將消息元數(shù)據(jù)的副本作為附加消息與初始密鑰作有限域的乘法,得到Mh0;③從第1個(gè)計(jì)數(shù)器開始,計(jì)數(shù)器值在前一個(gè)計(jì)數(shù)器的基礎(chǔ)上加1,依次將加密后的計(jì)數(shù)器值與明文分組相與,得到初步的加密數(shù)據(jù);④再依次將初步加密數(shù)據(jù)與前一個(gè)Mh相與,直到明文處理結(jié)束得到MhN;⑤當(dāng)消息分組加密處理完成之后,最后得到的加密數(shù)據(jù)塊MhN與第0個(gè)計(jì)數(shù)器的加密值Ek0相與,得到用來認(rèn)證本條消息的檢驗(yàn)值(Tag)。其中IV為握手過程生成的初始向量,key在QUIC初始化時(shí)生成。

Figure 5 Workflow of eBPF圖5 eBPF工作流程

(2)報(bào)頭保護(hù)。AEAD完成后,從報(bào)文號(hào)(packet number)字段開始往后第4個(gè)字節(jié)起,截取128 b的密文樣本作為樣本。獲取報(bào)頭保護(hù)密鑰,使用AES_ECB算法對(duì)樣本進(jìn)行加密生成5 B的掩碼。該掩碼與報(bào)文頭部的特定位進(jìn)行異或(XOR),取第1字節(jié)最低有效5位(短報(bào)頭)或者最低有效4位(長報(bào)頭)以及報(bào)文號(hào)字段。以此實(shí)現(xiàn)對(duì)報(bào)頭的保護(hù)。

4 性能評(píng)估

4.1 原型系統(tǒng)實(shí)現(xiàn)

原型系統(tǒng)采用主機(jī)+DPU設(shè)計(jì)模型實(shí)現(xiàn),DPU采用Genesys 開發(fā)板,該開發(fā)板擁有接近16 Mb的BRAM,內(nèi)部時(shí)鐘頻率達(dá)到450 MHz。主機(jī)配置為Intel?CoreTMi7-10510U CPU,1.8 GHz,8 GB RAM,操作系統(tǒng)采用Ubuntu18.04和Linux 4.18.0-25-generic。基于DPU開發(fā)板實(shí)例化多核Ariane CPU[26],使用默認(rèn)的每核配置:16 KB的L1指令和數(shù)據(jù)緩存,512 KB的L2共享緩存。將eBPF作為BootLoader(引導(dǎo)加載程序)的第2階段引導(dǎo)程序加載到SoC的內(nèi)存中[27],作為運(yùn)行時(shí)環(huán)境,一旦完成加載,前端(Front-end)服務(wù)器將信號(hào)首先寫入CPU 0的軟件中斷寄存器,然后由CPU 0將信號(hào)寫入系統(tǒng)中其他CPU的軟件中斷寄存器,最后跳轉(zhuǎn)到DRAM的開頭位置,開始執(zhí)行XDP程序。

在保證程序調(diào)用接口通用的情況下,XDP的各個(gè)模塊可在用戶態(tài)通過BFP_maps動(dòng)態(tài)加載到eBPF中,工作流程如圖5所示。首先在用戶空間,使用受限制的C庫(eBPF庫)對(duì)功能模塊編程后,編譯成BPF字節(jié)碼(Bytecode),注入到DPU網(wǎng)卡后,會(huì)對(duì)BPF的安全性進(jìn)行校驗(yàn)。在有事件觸發(fā)的情況下,由特定于精簡指令集(RISC)的JIT(Just-In-Time)編譯器動(dòng)態(tài)優(yōu)化編譯成RISC的操作碼(Operation Code),該操作碼存入DPU的緩存中,并在后續(xù)處理時(shí)由Ariane眾核CPU并發(fā)解釋執(zhí)行。

4.2 實(shí)驗(yàn)設(shè)計(jì)與測試拓?fù)?/h3>

QUIC采用的開源quant[28]代碼,是一種使用Warpcore用戶空間零拷貝的UDP/IP棧,支持Netmap快速I/O架構(gòu)。對(duì)quant源碼進(jìn)行了相應(yīng)的修改:(1)修改密鑰存儲(chǔ)方式,顯性的將連接過程中生成的密鑰和配置信息以文本的形式存入主機(jī)內(nèi)存中。方便DPU處理器按照狀態(tài)表中同步的信息路徑直接獲取。(2)將主機(jī)協(xié)議棧中AEAD操作進(jìn)一步細(xì)化,對(duì)需要加密/解密處理報(bào)文的AEAD操作進(jìn)行了旁路。(3)在報(bào)文處理的路徑上添加條件調(diào)用語句,在接收到符合卸載條件的報(bào)文時(shí),觸發(fā)BPF代碼中的處理邏輯,進(jìn)行XDP流水線處理。

為了測試本文模型的性能優(yōu)化效果,主要進(jìn)行以下3個(gè)實(shí)驗(yàn)。(1)在本地場景中,使用千兆網(wǎng)線將2臺(tái)主機(jī)(Server、Client)與DPU連接,以TCP的平均吞吐量為基準(zhǔn),測試模型在分別運(yùn)行QUIC和TCP協(xié)議棧時(shí)的平均吞吐量占比,以評(píng)估模型的性能提升效果。(2)在基于docker的仿真網(wǎng)絡(luò)場景(拓?fù)淙鐖D6所示)中,通過流量控制工具TC(Traffic Control)[29]設(shè)置瓶頸鏈路測試與TCP并存時(shí)(iperf持續(xù)發(fā)送TCP流量)的帶寬占比,觀察QUIC協(xié)議與TCP在瓶頸鏈路下的公平性。(3)在實(shí)驗(yàn)(2)的基礎(chǔ)上,通過調(diào)整QUIC協(xié)議的緩沖區(qū)大小,確保2種協(xié)議之間的公平性。3個(gè)實(shí)驗(yàn)均測試協(xié)議棧(quant_nomal、quant_offload)在傳輸不同大小文件(512 KB、1 MB、5 MB和10 MB)時(shí)的下載完成時(shí)間,從而計(jì)算各類協(xié)議的傳輸帶寬以及帶寬比。

Figure 6 Container-based test topology圖6 基于容器的測試拓?fù)?/p>

4.3 測試結(jié)果與分析

4.3.1 網(wǎng)絡(luò)吞吐率對(duì)比

吞吐率占比隨傳輸文件大小的變化情況如圖7所示。從與TCP在平均吞吐率的對(duì)比來看,傳輸小文件(0.5 MB)時(shí),由于使能了QUIC的0-RTT等特性,最大可獲得19%的性能提升。此外,由于傳輸?shù)奈募^小,不足以觸發(fā)大量的加密/解密卸載進(jìn)程,所以quant_offload比quant_ normal增加了6%平均吞吐率。從圖7可以看出,quant_offload對(duì)比quant_normal的優(yōu)勢隨著文件的增大而提升,在傳輸大文件(10 MB)時(shí),可獲得13%的吞吐率提升。同時(shí)也發(fā)現(xiàn),quant對(duì)比TCP的性能優(yōu)勢隨著傳輸文件的增大而進(jìn)一步減弱,最后在傳輸大文件(10 MB)時(shí),要稍低于TCP的,這主要是因?yàn)閭鬏敃r(shí)間較長,0-RTT建立的優(yōu)勢并不明顯,且quant作為實(shí)驗(yàn)階段的協(xié)議棧,相比TCP其傳輸性能的優(yōu)化程度還比較低。

Figure 7 Occupancy ratio of throughput圖7 平均吞吐率占比

4.3.2 鏈路帶寬占比

在瓶頸鏈路(B=5 Mbps,RTT=50 ms)上的帶寬占有率對(duì)比如圖8所示。由于TCP流量采用iperf[30]軟件持續(xù)發(fā)包,在啟動(dòng)QUIC協(xié)議之初,TCP占據(jù)了絕大部分的帶寬,隨著傳輸文件的增大,QUIC的帶寬占比逐漸增加,最后達(dá)到閾值0.66(quant_normal)和0.68(quant_offload)。而QUIC協(xié)議帶寬占比較高的原因在于其滑動(dòng)窗口值增長較快,該問題可以通過動(dòng)態(tài)調(diào)整擁塞控制算法的配置(緩沖區(qū)大小)來解決[8,9]。從圖8可以看出,quant_offload由于數(shù)據(jù)處理性能更高,滑動(dòng)窗口增加的速度更快,更早達(dá)到閾值。

Figure 8 Bandwidth occupancy ratio圖8 帶寬占比

4.3.3 鏈路公平性

瓶頸鏈路(B=5 Mbps,RTT=50 ms)上的帶寬占比顯示了QUIC與TCP協(xié)議的不公平性(如圖8所示),通過文獻(xiàn)[8,9]可知,其不公平性與協(xié)議緩沖區(qū)大小相關(guān)。本節(jié)考慮2種QUIC代碼在設(shè)置不同的緩沖區(qū)大小(13 KB,30 KB,60 KB)時(shí),分別測試傳輸10 MB文件時(shí)與TCP的帶寬占用。如圖9所示,對(duì)于13 KB緩沖區(qū),QUIC占據(jù)近3倍的TCP鏈路帶寬。對(duì)于30 KB緩沖區(qū)(=帶寬×延遲),大約為1.5倍的TCP鏈路帶寬。而對(duì)于60 KB的緩沖區(qū),被認(rèn)為是過度緩沖,TCP和QUIC公平地分享瓶頸鏈路。通過以上評(píng)估和分析,驗(yàn)證了基于NanoBPF的加密/解密卸載模型既能有效地提升QUIC協(xié)議的報(bào)文處理性能,又能通過動(dòng)態(tài)調(diào)整協(xié)議的緩沖區(qū)大小來保證與TCP在瓶頸鏈路上的公平性。

Figure 9 Bottleneck link bandwidth occupancy圖9 瓶頸鏈路帶寬占用

5 結(jié)束語

QUIC作為一個(gè)新型的傳輸協(xié)議,在設(shè)計(jì)上針對(duì)TCP的不足進(jìn)行了優(yōu)化?，F(xiàn)有測量數(shù)據(jù)表明,QUIC在計(jì)算資源緊缺的網(wǎng)絡(luò)設(shè)備中,QUIC的性能不如TCP的。其瓶頸主要在于強(qiáng)制的加密/解密雖然帶來了比TCP+TLS1.2更高的安全性能和更低的握手時(shí)延,但是大量的計(jì)算資源被報(bào)文保護(hù)操作占用,限制了QUIC協(xié)議棧潛在的性能優(yōu)勢。針對(duì)這一問題,本文進(jìn)行了協(xié)議優(yōu)化的相關(guān)研究,借鑒XDP協(xié)議棧優(yōu)化以及RISC眾核并行的方法,設(shè)計(jì)了基于DPU中RISC眾核的協(xié)議卸載模型——NanoBPF,基于RISC Ariane眾核CPU實(shí)現(xiàn)并行處理,將QUIC協(xié)議棧中的AEAD操作以XDP程序的形式進(jìn)行卸載,在PISA流水線設(shè)計(jì)基礎(chǔ)上,添加了基于QUIC傳輸邏輯的硬件傳輸模塊,負(fù)責(zé)報(bào)文的收發(fā)控制。實(shí)驗(yàn)評(píng)估結(jié)果表明,采用NanoBPF加密/解密卸載以及優(yōu)化模型,提升了13%的協(xié)議棧傳輸性能,且在與TCP共存的瓶頸鏈路條件下能夠?qū)崿F(xiàn)與TCP協(xié)議的公平性。