令瑞林 李峻峰 李 丹

(清華大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)系 北京 100084)

基于多核平臺(tái)的高速網(wǎng)絡(luò)流量實(shí)時(shí)捕獲方法

令瑞林 李峻峰 李 丹

(清華大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)系 北京 100084)

(lrl14@mails.tsinghua.edu.cn)

隨著互聯(lián)網(wǎng)上應(yīng)用的豐富和網(wǎng)絡(luò)帶寬的增長(zhǎng)，帶來(lái)的安全問(wèn)題也與日劇增，除了傳統(tǒng)的垃圾郵件、病毒傳播、DDoS攻擊外，還出現(xiàn)了新型的隱蔽性強(qiáng)的攻擊方式.網(wǎng)絡(luò)探針工具是一種部署在局域網(wǎng)出口處的旁路設(shè)備，能夠收集當(dāng)前進(jìn)出網(wǎng)關(guān)的全部流量并進(jìn)行分析，而網(wǎng)絡(luò)探針工具中最重要的模塊就是數(shù)據(jù)包的捕獲.傳統(tǒng)的Linux網(wǎng)絡(luò)協(xié)議棧在捕獲數(shù)據(jù)包時(shí)有諸多性能瓶頸，無(wú)法滿(mǎn)足高速網(wǎng)絡(luò)環(huán)境的要求.介紹了基于零拷貝、多核并行化等技術(shù)的多種新型的數(shù)據(jù)包捕獲引擎，并基于Intel DPDK平臺(tái)設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)可擴(kuò)展的數(shù)據(jù)包捕獲系統(tǒng)，它能夠利用接收端擴(kuò)展(receiver-side scaling, RSS)技術(shù)實(shí)現(xiàn)多核并行化的數(shù)據(jù)包捕獲、模塊化的上層處理流程.除此之外，還討論了更有效、更公平的將數(shù)據(jù)包分發(fā)到不同的接收隊(duì)列所應(yīng)使用的Hash函數(shù).經(jīng)過(guò)初步的實(shí)驗(yàn)驗(yàn)證，該系統(tǒng)能夠?qū)崿F(xiàn)接近線(xiàn)速的收包并且多個(gè)CPU核心間實(shí)現(xiàn)負(fù)載均衡.

數(shù)據(jù)包捕獲；接收端擴(kuò)展；多核；DPDK平臺(tái)；Hash函數(shù)

隨著通信技術(shù)的發(fā)展，互聯(lián)網(wǎng)早已成為了全球資源的共享平臺(tái)，實(shí)現(xiàn)了人與機(jī)、人與人、物與物之間的互聯(lián).互聯(lián)網(wǎng)的繁榮發(fā)展與其標(biāo)準(zhǔn)化的基因是分不開(kāi)的，任何想要接入互聯(lián)網(wǎng)的設(shè)備都需要遵循既定的通訊協(xié)議.但也正是這種標(biāo)準(zhǔn)化和通用化導(dǎo)致了其安全性受到威脅.攻擊者通過(guò)標(biāo)準(zhǔn)的協(xié)議與被攻擊對(duì)象交互，實(shí)現(xiàn)其竊取信息或破壞系統(tǒng)等目的.除此以外，網(wǎng)絡(luò)病毒借助電子郵件附件、網(wǎng)頁(yè)文件下載等手段進(jìn)行傳播，不僅會(huì)導(dǎo)致網(wǎng)絡(luò)傳輸效率降低、網(wǎng)絡(luò)中斷，甚至還會(huì)竊取用戶(hù)的核心數(shù)據(jù)，大量的垃圾郵件也會(huì)影響個(gè)人和企業(yè)的正常生活和工作.根據(jù)調(diào)查，87%以上的病毒通過(guò)電子郵件進(jìn)入企業(yè)，危害極其普遍、嚴(yán)重[1].

網(wǎng)絡(luò)數(shù)據(jù)包的實(shí)時(shí)采集和分析，對(duì)于網(wǎng)絡(luò)的服務(wù)商和管理方有十分重要的安全意義.網(wǎng)絡(luò)的服務(wù)商能夠通過(guò)分析當(dāng)前網(wǎng)絡(luò)上的流量來(lái)預(yù)測(cè)網(wǎng)絡(luò)的流量情況，同時(shí)這些數(shù)據(jù)能夠用于優(yōu)化網(wǎng)絡(luò)配置，配置出最優(yōu)的路由路徑和負(fù)載均衡策略[2].對(duì)于網(wǎng)絡(luò)的管理者，能夠通過(guò)采集的數(shù)據(jù)分析出入網(wǎng)絡(luò)的流量的安全態(tài)勢(shì)，及時(shí)發(fā)現(xiàn)可能對(duì)內(nèi)網(wǎng)信息系統(tǒng)造成破壞的攻擊行為以及從內(nèi)向外發(fā)生的數(shù)據(jù)泄露.但網(wǎng)絡(luò)流量的實(shí)時(shí)采集是個(gè)有挑戰(zhàn)性的問(wèn)題，尤其是在網(wǎng)絡(luò)帶寬不斷增長(zhǎng)的背景下，高性能的數(shù)據(jù)包采集系統(tǒng)需要在有限的時(shí)間內(nèi)完整地收集和處理網(wǎng)絡(luò)上產(chǎn)生的大量數(shù)據(jù)，并完成可能的管理或控制，而高速網(wǎng)絡(luò)環(huán)境中流量分析系統(tǒng)的基礎(chǔ)是能夠無(wú)丟失地捕獲網(wǎng)絡(luò)數(shù)據(jù)包[2].

1 傳統(tǒng)的報(bào)文處理

隨著服務(wù)器網(wǎng)卡速率的提升，目前服務(wù)器中通常配有10 Gbps的網(wǎng)卡，因此，數(shù)據(jù)包捕獲系統(tǒng)的實(shí)現(xiàn)不僅有傳統(tǒng)的基于硬件方案，也有基于軟件的方案.使用定制化的硬件設(shè)備進(jìn)行數(shù)據(jù)包捕獲的方案優(yōu)點(diǎn)是，性能相對(duì)較好，能夠支持高帶寬的網(wǎng)絡(luò)；但缺點(diǎn)則是系統(tǒng)的功能模塊相對(duì)固定、擴(kuò)展性差，且硬件成本很高.因此，低成本且擴(kuò)展性好的軟件實(shí)現(xiàn)就成了大多數(shù)網(wǎng)絡(luò)服務(wù)商選擇的解決方案.在高速網(wǎng)絡(luò)環(huán)境下(如大型IDC、云數(shù)據(jù)中心等)，傳輸?shù)臄?shù)據(jù)量比一般傳統(tǒng)的局域網(wǎng)高出幾個(gè)數(shù)量級(jí).這就要求基于軟件的數(shù)據(jù)包捕獲系統(tǒng)能夠達(dá)到高效性和完整性的要求，能及時(shí)處理高速網(wǎng)絡(luò)上的數(shù)據(jù).

Linux網(wǎng)絡(luò)協(xié)議棧是處理網(wǎng)絡(luò)數(shù)據(jù)包的典型系統(tǒng)，它包含了從物理層直到應(yīng)用層的全過(guò)程.其處理流程為：首先驅(qū)動(dòng)向上層模塊發(fā)出請(qǐng)求，通知協(xié)議棧有數(shù)據(jù)到達(dá)；然后協(xié)議棧通過(guò)系統(tǒng)調(diào)用對(duì)數(shù)據(jù)包的網(wǎng)絡(luò)層協(xié)議數(shù)據(jù)進(jìn)行處理，它會(huì)將網(wǎng)卡驅(qū)動(dòng)的接收緩沖隊(duì)列中的數(shù)據(jù)包拷貝到操作系統(tǒng)的接收隊(duì)列中；接著調(diào)用傳輸層的接收函數(shù)進(jìn)行傳輸層的數(shù)據(jù)處理.如果此時(shí)系統(tǒng)接收隊(duì)列中沒(méi)有需要的數(shù)據(jù)包時(shí)，操作系統(tǒng)會(huì)讓當(dāng)前的處理進(jìn)程進(jìn)入休眠狀態(tài)，等待系統(tǒng)接收隊(duì)列中到達(dá)新的數(shù)據(jù)包，當(dāng)休眠的處理進(jìn)程被系統(tǒng)喚醒，它會(huì)從接收隊(duì)列獲得所需的數(shù)據(jù)包，處理完畢以后通過(guò)調(diào)用read函數(shù)，將數(shù)據(jù)包從內(nèi)核緩沖區(qū)拷貝到用戶(hù)態(tài)的應(yīng)用緩沖區(qū)[3].在這個(gè)過(guò)程中，數(shù)據(jù)包首先從網(wǎng)卡驅(qū)動(dòng)的緩沖隊(duì)列拷貝到協(xié)議棧的接收隊(duì)列，再?gòu)膮f(xié)議棧的接收隊(duì)列拷貝到應(yīng)用程序的內(nèi)存空間.數(shù)據(jù)包從下向上的過(guò)程中進(jìn)行了2次拷貝及多層系統(tǒng)調(diào)用處理.

從上述分析可以看出，由于Linux內(nèi)核協(xié)議棧的主要目標(biāo)是實(shí)現(xiàn)通用的網(wǎng)絡(luò)服務(wù)，所以在設(shè)計(jì)上存在固有的缺陷，大量的中斷和數(shù)據(jù)包的多次拷貝都是普遍認(rèn)為的“病因”所在.針對(duì)這些問(wèn)題，研究人員們?cè)O(shè)計(jì)了許多高性能的數(shù)據(jù)包捕獲引擎，這些引擎在技術(shù)上有許多共通之處，如零拷貝、批處理等.但這些引擎的功能較為單一，不能直接用來(lái)開(kāi)發(fā)復(fù)雜的網(wǎng)絡(luò)功能設(shè)備.

1.1 Linux網(wǎng)絡(luò)協(xié)議棧的報(bào)文處理

Linux內(nèi)核協(xié)議棧對(duì)數(shù)據(jù)包處理過(guò)程主要分為3個(gè)步驟[4]：1)DMA傳輸及網(wǎng)卡中斷設(shè)置[5]；2)中斷處理程序拷貝數(shù)據(jù)包；3)netfilter進(jìn)行路由判決，其上的鉤子函數(shù)處理數(shù)據(jù)包，并將數(shù)據(jù)包交給傳輸層的函數(shù)處理.

通過(guò)分析研究者們發(fā)現(xiàn)，Linux內(nèi)核協(xié)議棧在數(shù)據(jù)包的收發(fā)過(guò)程中進(jìn)行了2次數(shù)據(jù)包的內(nèi)存拷貝，這2次拷貝操作的時(shí)間開(kāi)銷(xiāo)占了整個(gè)處理過(guò)程時(shí)間開(kāi)銷(xiāo)的65%，此外層間傳遞的系統(tǒng)調(diào)用時(shí)間也占據(jù)了8%～10%[6].

數(shù)據(jù)拷貝會(huì)造成巨大時(shí)間開(kāi)銷(xiāo)的原因主要有2方面:

1) 數(shù)據(jù)拷貝過(guò)程需要占用總線(xiàn)，而設(shè)備中的總線(xiàn)帶寬資源是有限的，同時(shí)，數(shù)據(jù)的拷貝都是按照一定的位寬度逐字(32位操作系統(tǒng)中字寬為4 B)進(jìn)行的，大量的數(shù)據(jù)拷貝操作將消耗大量的CPU周期；

2) cache命中率和CPU訪(fǎng)問(wèn)cache的效率將會(huì)下降.拷貝操作的過(guò)程中，原cache里緩存的cache行將被待拷貝的數(shù)據(jù)沖掉，而逐字拷貝會(huì)產(chǎn)生頻繁的cache行替換，從而造成cache命中率降低，可以看出協(xié)議棧處理數(shù)據(jù)包時(shí)的拷貝操作是協(xié)議棧性能的主要瓶頸[7].

NAPI(New API)是Linux2.6內(nèi)核之后采用的一種提高數(shù)據(jù)包處理性能的新技術(shù),其核心就是使用中斷和輪詢(xún)組合收包，如圖1所示.NAPI的假設(shè)場(chǎng)景是，一旦網(wǎng)卡開(kāi)始接收到數(shù)據(jù)包，數(shù)據(jù)包就會(huì)以高頻率到達(dá)，換言之，就是針對(duì)一直有數(shù)據(jù)包到達(dá)的網(wǎng)絡(luò)環(huán)境做了優(yōu)化，主要改進(jìn)[8]為：網(wǎng)卡在接收到第1個(gè)數(shù)據(jù)包時(shí)將觸發(fā)硬件中斷，中斷處理函數(shù)會(huì)將該網(wǎng)卡加入到設(shè)備輪詢(xún)表中，同時(shí)，為了防止后續(xù)到達(dá)的數(shù)據(jù)包觸發(fā)頻繁的硬件中斷，需要設(shè)置該中斷使之不再接收中斷請(qǐng)求(Rx IRQ)；隨后，操作系統(tǒng)會(huì)觸發(fā)一個(gè)軟中斷，軟中斷的處理函數(shù)將對(duì)輪詢(xún)表上的設(shè)備進(jìn)行輪詢(xún)，檢查是否有數(shù)據(jù)包到達(dá)并處理；直到本次處理的CPU時(shí)間片用盡或者數(shù)據(jù)包的處理過(guò)程結(jié)束，網(wǎng)卡才重新設(shè)置中斷屏蔽位開(kāi)中斷接收中斷請(qǐng)求.

Fig. 1 Methodology of NAPI圖1 NAPI原理圖

然而，隨著網(wǎng)卡緩存空間和CPU處理能力的增強(qiáng)，在千兆速率的網(wǎng)絡(luò)上使用NAPI技術(shù)己經(jīng)能夠很好地支持各類(lèi)數(shù)據(jù)包的處理.但是隨著萬(wàn)兆網(wǎng)卡的普及和主干網(wǎng)絡(luò)帶寬的提升，數(shù)據(jù)包捕獲及處理能力的瓶頸就轉(zhuǎn)移到網(wǎng)卡驅(qū)動(dòng)以及內(nèi)核協(xié)議棧的處理能力上，頻繁的軟中斷處理和數(shù)據(jù)包拷貝操作會(huì)大量消耗CPU資源，這些資源消耗在萬(wàn)兆網(wǎng)絡(luò)環(huán)境下顯得尤為明顯.如何高效地處理數(shù)據(jù)包內(nèi)容，減少系統(tǒng)不必要的資源開(kāi)銷(xiāo)，優(yōu)化數(shù)據(jù)包處理過(guò)程中的CPU利用率，成為數(shù)據(jù)包捕獲技術(shù)的主要研究方向[8].

1.2 性能瓶頸識(shí)別與分析

由1.1節(jié)的分析可知，僅有NAPI技術(shù)是不足以完成在高速網(wǎng)絡(luò)上的流量捕獲這樣一個(gè)具有挑戰(zhàn)性的任務(wù)，這是因?yàn)長(zhǎng)inux協(xié)議棧體系結(jié)構(gòu)中的固有缺陷降低了性能.經(jīng)過(guò)大量的代碼分析和性能測(cè)試，研究者們已經(jīng)確定協(xié)議棧的5個(gè)主要問(wèn)題[9-12]：

1) 針對(duì)單個(gè)數(shù)據(jù)包級(jí)別的資源分配和釋放.每當(dāng)一個(gè)數(shù)據(jù)包到達(dá)網(wǎng)卡，系統(tǒng)就會(huì)分配一個(gè)分組描述符用于存儲(chǔ)數(shù)據(jù)包的信息和頭部，直到分組傳送到用戶(hù)態(tài)空間，其描述符才被釋放.分配和釋放描述符的過(guò)程在高達(dá)14.88 Mpps的環(huán)境下是一個(gè)顯著的時(shí)間上的開(kāi)銷(xiāo).此外，sk_buff龐大的數(shù)據(jù)結(jié)構(gòu)中的大部分信息對(duì)于大多數(shù)網(wǎng)絡(luò)任務(wù)而言都是無(wú)用的.如文獻(xiàn)[9]中指出，每個(gè)分組的sk_buff的分配消耗近1 200個(gè)CPU周期，而釋放需要1 100個(gè)周期.事實(shí)上，對(duì)于一個(gè)大小為64 B的分組，sk_buff相關(guān)操作消耗了整個(gè)接收處理的CPU利用率的63%[9].

2) 流量的串行訪(fǎng)問(wèn).現(xiàn)代網(wǎng)卡包括多個(gè)硬件的接收端擴(kuò)展(receiver-side scaling, RSS)隊(duì)列可以將分組按照五元組散列函數(shù)分配到不同的接收隊(duì)列.使用這種技術(shù)，分組的捕獲過(guò)程可以被并行化，因?yàn)槊總€(gè)RSS隊(duì)列可以映射到一個(gè)特定的CPU核，并且可以對(duì)應(yīng)相應(yīng)的NAPI線(xiàn)程.這樣整個(gè)捕獲過(guò)程就可以做到并行化.但是問(wèn)題出現(xiàn)在之上的層次，Linux中的協(xié)議棧在網(wǎng)絡(luò)層和傳輸層需要分析合并的所有數(shù)據(jù)包，如圖2所示.由此引起了降低系統(tǒng)性能的2個(gè)問(wèn)題：①所有流量在一個(gè)單一模塊中被處理，產(chǎn)生性能瓶頸；②用戶(hù)進(jìn)程不能夠從一個(gè)單一的RSS隊(duì)列接收消息.這就造成了上層應(yīng)用無(wú)法利用現(xiàn)代硬件的并行化處理能力，這種在用戶(hù)態(tài)分配流量先后序列的過(guò)程降低了系統(tǒng)的性能，丟失了驅(qū)動(dòng)層面所獲得的加速.此外，從不同隊(duì)列合并的流量可能會(huì)產(chǎn)生額外的亂序分組[13].

Fig. 2 Bottleneck in standard Linux network stack when using multi-queue圖2 使用多隊(duì)列的傳統(tǒng)Linux協(xié)議棧中的瓶頸

3) 從驅(qū)動(dòng)到用戶(hù)態(tài)的數(shù)據(jù)拷貝.從網(wǎng)卡收到數(shù)據(jù)包到應(yīng)用取走數(shù)據(jù)的一次DMA過(guò)程中，存在至少2次數(shù)據(jù)包的復(fù)制：從驅(qū)動(dòng)中DMA的訪(fǎng)問(wèn)內(nèi)存到內(nèi)核的數(shù)據(jù)包緩存，以及從內(nèi)核數(shù)據(jù)包緩存到應(yīng)用程序.一次復(fù)制操作的消耗取決于數(shù)據(jù)包長(zhǎng)度，一般為500～2 000個(gè)CPU周期之間[11].上述過(guò)程中更糟糕的是，當(dāng)數(shù)據(jù)包很小時(shí)，逐包復(fù)制的效率更加低下，這是由于每個(gè)操作恒定的開(kāi)銷(xiāo)引起的.

4) 內(nèi)核到用戶(hù)空間的上下文切換.從應(yīng)用程序的視角來(lái)看，它需要執(zhí)行系統(tǒng)調(diào)用來(lái)接收每個(gè)分組.每個(gè)系統(tǒng)調(diào)用包含一次從用戶(hù)態(tài)到內(nèi)核態(tài)的上下文切換，隨之而來(lái)的是大量的CPU時(shí)間消耗.在每個(gè)數(shù)據(jù)包上執(zhí)行系統(tǒng)調(diào)用時(shí)產(chǎn)生的上下文切換可能消耗近1 000個(gè)CPU周期[11].

5) 缺少內(nèi)存本地化.例如，當(dāng)接收一個(gè)64 B分組時(shí)，cache未命中造成了額外13.8%的CPU周期的消耗[12].另外，在一個(gè)基于NUMA的系統(tǒng)中，內(nèi)存訪(fǎng)問(wèn)的時(shí)間取決于訪(fǎng)問(wèn)的存儲(chǔ)節(jié)點(diǎn).因此，cache未命中在跨內(nèi)存塊訪(fǎng)問(wèn)環(huán)境下會(huì)產(chǎn)生更大的內(nèi)存訪(fǎng)問(wèn)延遲，從而導(dǎo)致性能下降.

由于當(dāng)前的協(xié)議棧和應(yīng)用程序中都不能很好地利用網(wǎng)卡和CPU硬件的新特性.我們總結(jié)了目前高性能報(bào)文捕獲引擎中常用的提高捕獲效率的技術(shù)，這些技術(shù)能夠克服之前架構(gòu)的性能限制.

1) 預(yù)分配和重用內(nèi)存資源.這種技術(shù)包括：開(kāi)始分組接收之前，預(yù)先分配好將要到達(dá)的數(shù)據(jù)包所需的內(nèi)存空間用來(lái)存儲(chǔ)數(shù)據(jù)和元數(shù)據(jù)(分組描述符).尤其體現(xiàn)在，在加載網(wǎng)卡驅(qū)動(dòng)程序時(shí)就分配好N個(gè)描述符隊(duì)列(每個(gè)硬件隊(duì)列和設(shè)備一個(gè)).需要注意的是這會(huì)在驅(qū)動(dòng)程序加載時(shí)造成一些額外的時(shí)間開(kāi)銷(xiāo)，但是減少了為每個(gè)數(shù)據(jù)包分配內(nèi)存空間的開(kāi)銷(xiāo).同樣，當(dāng)一個(gè)數(shù)據(jù)包被傳送到用戶(hù)空間，其對(duì)應(yīng)的描述符也不會(huì)被釋放，而是重新用于存儲(chǔ)新到達(dá)的分組.得益于這一策略，在每個(gè)數(shù)據(jù)包分配/釋放所產(chǎn)生的性能瓶頸得到了消除.此外，也可以通過(guò)簡(jiǎn)化sk_buff的數(shù)據(jù)結(jié)構(gòu)來(lái)減少內(nèi)存開(kāi)銷(xiāo).

2) 數(shù)據(jù)包采用并行直接通道傳遞.為了解決序列化的訪(fǎng)問(wèn)流量，需要建立從RSS隊(duì)列到應(yīng)用之間的直接并行數(shù)據(jù)通道.這種技術(shù)通過(guò)特定的RSS隊(duì)列、特定的CPU核和應(yīng)用三者的綁定來(lái)實(shí)現(xiàn)性能的提升.這個(gè)架構(gòu)也增加了性能的可擴(kuò)展性，因?yàn)樾碌牟⑿袛?shù)據(jù)通道可以通過(guò)在驅(qū)動(dòng)層面增加RSS隊(duì)列的數(shù)量和CPU核來(lái)實(shí)現(xiàn).這種技術(shù)也存在一些缺點(diǎn):①數(shù)據(jù)包可能會(huì)亂序地到達(dá)用戶(hù)態(tài)，從而影響某些應(yīng)用的性能[13];②RSS使用Hash函數(shù)在每個(gè)接收隊(duì)列間分配流量[14-15].當(dāng)不同核的數(shù)據(jù)包間沒(méi)有相互關(guān)聯(lián)時(shí)，它們可以被獨(dú)立地分析，但如果同一條流的往返數(shù)據(jù)包被分配到不同的CPU核上時(shí)，就會(huì)造成低效的跨核訪(fǎng)問(wèn).

3) 內(nèi)存映射.使用這種方法，應(yīng)用程序的內(nèi)存區(qū)域可以映射到內(nèi)核態(tài)的內(nèi)存區(qū)域，應(yīng)用能夠在沒(méi)有中間副本的情況下讀寫(xiě)這片內(nèi)存區(qū)域.用這種方式我們可以使應(yīng)用直接訪(fǎng)問(wèn)網(wǎng)卡的DMA內(nèi)存區(qū)域，這種技術(shù)被稱(chēng)為零拷貝.但零拷貝也存在潛在的安全問(wèn)題，向應(yīng)用暴露出網(wǎng)卡環(huán)形隊(duì)列和寄存器會(huì)影響系統(tǒng)的安全性和穩(wěn)定性[11].

Fig. 3 PF RING scheme圖3 PF RING機(jī)制

4) 數(shù)據(jù)包的批處理.為了避免對(duì)每個(gè)數(shù)據(jù)包的重復(fù)操作的開(kāi)銷(xiāo)，可以使用對(duì)數(shù)據(jù)包的批量處理.這個(gè)策略將數(shù)據(jù)包劃分為組，按組分配緩沖區(qū)，將它們一起復(fù)制到內(nèi)核/用戶(hù)內(nèi)存.運(yùn)用這種技術(shù)減少了系統(tǒng)調(diào)用以及隨之而來(lái)的上下文切換的次數(shù);同時(shí)也減少了拷貝的次數(shù)，從而減少了平攤到處理和復(fù)制每個(gè)數(shù)據(jù)包的開(kāi)銷(xiāo).但由于分組必須等到一個(gè)批次已滿(mǎn)或定時(shí)器期滿(mǎn)才會(huì)遞交給上層[16]，批處理技術(shù)的主要問(wèn)題是延遲抖動(dòng)以及接收?qǐng)?bào)文時(shí)間戳誤差的增加.

5) 親和性與預(yù)取.由于程序運(yùn)行的局部性原理，為進(jìn)程分配的內(nèi)存必須與正在執(zhí)行它的處理器操作的內(nèi)存塊一致，這種技術(shù)被稱(chēng)為內(nèi)存的親和性.還有一些其他的考慮因素是CPU的中斷親和性.CPU親和性是一種技術(shù)，它允許進(jìn)程或線(xiàn)程在指定的處理器核心上運(yùn)行.在內(nèi)核與驅(qū)動(dòng)層面，軟件和硬件中斷可以用同樣的方法指定具體的CPU核或處理器來(lái)處理，稱(chēng)為中斷親和力.每當(dāng)一個(gè)線(xiàn)程希望訪(fǎng)問(wèn)所接收的數(shù)據(jù)，如果先前這些數(shù)據(jù)已被分配到相同CPU核的中斷處理程序接收，則它們?cè)诒镜豤ache能夠更容易被訪(fǎng)問(wèn)到.這項(xiàng)策略可以與先前所述的內(nèi)存局部性共同優(yōu)化數(shù)據(jù)的接收過(guò)程，充分利用系統(tǒng)的可用資源.

2 典型高性能收包引擎

本節(jié)中，我們列舉了4個(gè)包捕獲引擎，即PF-RING[17]，PacketShader[9]，Netmap[10]和PFQ[18]，它們?cè)跀?shù)據(jù)包捕獲方面相對(duì)于Linux原生方法取得了顯著的性能提升.對(duì)于每一種收包引擎，我們描述了它的系統(tǒng)架構(gòu)、使用的何種加速技術(shù)、為開(kāi)發(fā)應(yīng)用提供的API，以及提供的附加功能.

1) PF-RING

PF-RING是一個(gè)基于Intel 10 Gbps網(wǎng)卡的數(shù)據(jù)包捕獲引擎框架.這個(gè)引擎實(shí)現(xiàn)了內(nèi)存預(yù)分配，并在其處理數(shù)據(jù)包的整個(gè)過(guò)程中通過(guò)分配RX和PF-RING環(huán)形隊(duì)列實(shí)現(xiàn)重用內(nèi)存.PF-RING也允許建立從硬件到用戶(hù)進(jìn)程并行接收隊(duì)列，即它允許為每個(gè)接收隊(duì)列分配一個(gè)CPU核，可以根據(jù)NUMA節(jié)點(diǎn)進(jìn)行內(nèi)存分配，允許內(nèi)存親和技術(shù)的開(kāi)發(fā).不同于其他方案，PF-RING實(shí)現(xiàn)了完全的零拷貝，它將用戶(hù)內(nèi)存空間映射到驅(qū)動(dòng)的內(nèi)存空間，使用戶(hù)的應(yīng)用可以直接訪(fǎng)問(wèn)網(wǎng)卡的寄存器和數(shù)據(jù).通過(guò)這樣的方式，避免了在內(nèi)核對(duì)數(shù)據(jù)包緩存，減少了數(shù)據(jù)包的拷貝次數(shù).但是，如前面所指出的，這種技術(shù)的代價(jià)是用戶(hù)的應(yīng)用程序可能出現(xiàn)的對(duì)于PF-RING API的不正確使用(其明確地不允許不正確的存儲(chǔ)器存取)，并造成系統(tǒng)的崩潰.在其余的方案中，直接訪(fǎng)問(wèn)網(wǎng)卡是有保護(hù)機(jī)制的.PF-RING的工作過(guò)程如圖3所示.一些NAPI的步驟都被換成了零拷貝技術(shù).

2) PacketShader

PacketShader(PS)是開(kāi)發(fā)能夠線(xiàn)速工作的軟件路由器的基礎(chǔ)，是一套新的高度優(yōu)化流量捕獲的引擎.PS也完全適用于任何涉及采集和處理數(shù)據(jù)包的一般任務(wù).它使用了內(nèi)存預(yù)分配和重用，具體而言，PS分配了2個(gè)內(nèi)存區(qū)域：①用于存儲(chǔ)分組數(shù)據(jù);②用于存儲(chǔ)其元數(shù)據(jù).每個(gè)緩存單元具有對(duì)應(yīng)于一個(gè)包的固定大小的區(qū)域.用于存放分組數(shù)據(jù)的每個(gè)單元的大小對(duì)齊于2 048 B，對(duì)應(yīng)于與標(biāo)準(zhǔn)以太網(wǎng)MTU相鄰的最小2的冪.元數(shù)據(jù)結(jié)構(gòu)除去了對(duì)于許多網(wǎng)絡(luò)任務(wù)不必要的字段，從208 B壓縮至只有8 B(96%).此外，PS實(shí)現(xiàn)了內(nèi)存映射，使應(yīng)用直接訪(fǎng)問(wèn)內(nèi)核數(shù)據(jù)包緩沖區(qū)，避免了不必要的數(shù)據(jù)拷貝.在這方面，PS的作者強(qiáng)調(diào)了其引擎的性能在支持NUMA數(shù)據(jù)放置的優(yōu)勢(shì).同樣，PS在用戶(hù)層面也提供了并行化的分組處理，同時(shí)能夠隨著CPU核的數(shù)目和隊(duì)列數(shù)目實(shí)現(xiàn)擴(kuò)展性.為了減少每個(gè)包的處理開(kāi)銷(xiāo)，PS在用戶(hù)層面實(shí)現(xiàn)了批處理.每次批處理請(qǐng)求都將巨大的數(shù)據(jù)包緩沖區(qū)映射到連續(xù)內(nèi)存區(qū)域，應(yīng)用可以從該區(qū)域訪(fǎng)問(wèn)驅(qū)動(dòng)并復(fù)制數(shù)據(jù).為了減少cache未命中的次數(shù)，改進(jìn)的設(shè)備驅(qū)動(dòng)程序會(huì)預(yù)取當(dāng)前分組的下一個(gè)分組(包括分組數(shù)據(jù)和分組描述符)，如圖4所示:

Fig. 4 PacketShader RX scheme圖4 PacketShader收包機(jī)制

3) Netmap

Netmap和PacketShader體系結(jié)構(gòu)的特征有很多相同之處.即在初始化階段預(yù)分配大小固定的緩存空間(也為2 048 B)，批處理和并行直接數(shù)據(jù)通路.它也實(shí)現(xiàn)了內(nèi)存映射技術(shù)，以允許用戶(hù)的應(yīng)用程序直接訪(fǎng)問(wèn)內(nèi)核包緩存(到NIC直接訪(fǎng)問(wèn)被保護(hù)起來(lái))中簡(jiǎn)化和優(yōu)化過(guò)的元數(shù)據(jù)結(jié)構(gòu)，這種簡(jiǎn)化的元數(shù)據(jù)叫做Netmap ring，其結(jié)構(gòu)體包含環(huán)的大小，一個(gè)指向緩存的指針(當(dāng)前數(shù)據(jù)包)，緩存中收到的包的數(shù)目，或緩存中可用的空槽的數(shù)目.在接收和發(fā)送時(shí)會(huì)分別設(shè)置有關(guān)狀態(tài)位、內(nèi)存中包緩存的偏移值以及元數(shù)據(jù)信息數(shù)組；同時(shí)還包含每個(gè)數(shù)據(jù)包的一個(gè)存儲(chǔ)位置，包括該數(shù)據(jù)包的長(zhǎng)度、在緩存中的索引和一些標(biāo)志位.需要注意的是每個(gè)RSS隊(duì)列，接收和發(fā)送都可以使用Netmap ring實(shí)現(xiàn)并行化的直接數(shù)據(jù)通道.

4) PFQ

PFQ是一種新型的數(shù)據(jù)包捕獲引擎，它允許在應(yīng)用進(jìn)程中進(jìn)行并行化的包捕獲.PFQ的方法與以前的研究不同，區(qū)別于完全繞過(guò)NAPI的中斷方案或使用DMA映射內(nèi)存和內(nèi)核包緩存到用戶(hù)空間等對(duì)驅(qū)動(dòng)進(jìn)行重大修改的方案，PFQ允許同時(shí)使用改進(jìn)的和舊式的體系結(jié)構(gòu).它依照NAPI的方式抓取數(shù)據(jù)包，但實(shí)現(xiàn)了2個(gè)新的修改后的內(nèi)核包緩沖器，使得數(shù)據(jù)包在進(jìn)入?yún)f(xié)議棧之前先進(jìn)入緩存.首先，PFQ使用了額外的用于存放數(shù)據(jù)包副本的緩存以防止內(nèi)核包緩沖器滿(mǎn)了，這些包的拷貝操作是批處理完成的，這樣降低了并發(fā)度并增強(qiáng)了訪(fǎng)問(wèn)內(nèi)存的局部性.這種修改融合了批處理技術(shù)和內(nèi)存親和力技術(shù).第2點(diǎn)修改，PFQ在內(nèi)核層大量地使用了并行化，所有的功能都能夠在多個(gè)系統(tǒng)核心上并行執(zhí)行.PFQ實(shí)現(xiàn)了一個(gè)新的中間層，叫做數(shù)據(jù)包分流塊(packet steering block)，它位于用戶(hù)態(tài)和批處理隊(duì)列之間，向應(yīng)用提供了一些有趣的功能，它在多個(gè)接收的socket間分配流量.這些流量分配由內(nèi)存映射技術(shù)實(shí)現(xiàn)，避免了socket和用戶(hù)空間之間額外的拷貝.PSB允許捕獲線(xiàn)程將數(shù)據(jù)包分發(fā)給多個(gè)socket，從而一個(gè)socket可以從不同的包捕獲線(xiàn)程接收流量.這個(gè)特性避免了使用并行數(shù)據(jù)通道的缺點(diǎn)，即不同的流或會(huì)話(huà)的數(shù)據(jù)包必須由不同的應(yīng)用處理而不能共享.

3 基于DPDK的高速包捕獲系統(tǒng)設(shè)計(jì)

3.1 DPDK數(shù)據(jù)平面開(kāi)發(fā)套件

Intel DPDK是一套可用于開(kāi)發(fā)數(shù)據(jù)平面應(yīng)用庫(kù),定義了控制平面和數(shù)據(jù)平面功能分離的一種方式[19].控制平面的性能要求小于數(shù)據(jù)平面的性能要求，數(shù)據(jù)平面根據(jù)控制平面提供的配置來(lái)轉(zhuǎn)發(fā)流量.Intel DPDK允許用戶(hù)空間的進(jìn)程使用DPDK所提供的庫(kù)直接訪(fǎng)問(wèn)網(wǎng)卡而無(wú)需經(jīng)過(guò)內(nèi)核.從性能提升的角度來(lái)看，有實(shí)驗(yàn)表明在吞吐量方面，相比于Linux內(nèi)核有10～11倍的性能提升.在本文中，我們采用Intel DPDK作為底層庫(kù).

Fig. 7 A rte_mempool with associated rte_ring圖7 rte_mempool及其關(guān)聯(lián)的rte_ring

3.1.1 隊(duì)列管理

為了管理任何類(lèi)型的隊(duì)列，librte ring提供了rte_ring的環(huán)形隊(duì)列結(jié)構(gòu)，如圖5所示.這種結(jié)構(gòu)具有以下性質(zhì)：環(huán)形隊(duì)列的大小固定，遵循先進(jìn)先出的原則實(shí)現(xiàn)無(wú)鎖，支持單/多生產(chǎn)者/消費(fèi)者的排隊(duì)場(chǎng)景.此外，它能夠指定進(jìn)出隊(duì)列的數(shù)據(jù)包的個(gè)數(shù).環(huán)形隊(duì)列被實(shí)現(xiàn)為一張存儲(chǔ)了指向存儲(chǔ)對(duì)象的指針的一張表，每個(gè)消費(fèi)者和生產(chǎn)者各使用一對(duì)指針指向當(dāng)前隊(duì)列的頭部和尾部進(jìn)行訪(fǎng)問(wèn)控制.相比于普通的用長(zhǎng)度不限的雙鏈表實(shí)現(xiàn)的隊(duì)列，rte_ring有2個(gè)很大的優(yōu)勢(shì):1)它是存取時(shí)使用無(wú)鎖定機(jī)制比保護(hù)寫(xiě)這種結(jié)構(gòu)快得多；2)由于在表中保存的是指向數(shù)據(jù)的指針，減少了由于突發(fā)操作和大量數(shù)據(jù)傳輸導(dǎo)致的cache未命中次數(shù).

Fig. 5 The rte_ring structure圖5 rte_ring結(jié)構(gòu)示意圖[14]

3.1.2 內(nèi)存管理

EAL可以提供物理內(nèi)存的映射[14]，它會(huì)創(chuàng)建一個(gè)叫做RTE memseg的描述符的表來(lái)將地址上不連續(xù)的物理內(nèi)存映射為可連續(xù)訪(fǎng)問(wèn)的.然后將這些內(nèi)存分成多個(gè)內(nèi)存區(qū)域，如圖6所示.這些區(qū)域是構(gòu)建于DPDK庫(kù)之上的應(yīng)用進(jìn)一步使用內(nèi)存的基本單元.Librte_mempool提供的對(duì)象之一是rte_mempool.

Fig. 6 Distribution of physical memory into segments and zones for further use圖6 物理的大頁(yè)內(nèi)存被分為更小的單元

這種結(jié)構(gòu)是用rte_ring來(lái)存儲(chǔ)可通過(guò)唯一的名稱(chēng)確定的固定大小的對(duì)象池，如圖7所示.為了提高性能，可以在對(duì)象之間添加一個(gè)特定填充塊，用來(lái)“只裝載在內(nèi)存不同的通道和等級(jí)的每個(gè)對(duì)象的起始部分”[14].例如，在3層轉(zhuǎn)發(fā)和網(wǎng)絡(luò)數(shù)據(jù)包的流分類(lèi)中可以使用這種優(yōu)化，因?yàn)閷?duì)于數(shù)據(jù)包的處理只需要依賴(lài)第1個(gè)64 B即可[14].雖然無(wú)鎖環(huán)狀結(jié)構(gòu)可以被用來(lái)實(shí)現(xiàn)控制訪(fǎng)問(wèn)的目的，但多個(gè)CPU核心訪(fǎng)問(wèn)ring的成本可能很高.為了避免在ring處產(chǎn)生瓶頸，每個(gè)CPU核心都對(duì)rte內(nèi)存池保有本地高速緩存.當(dāng)cache全滿(mǎn)或者全空時(shí)，會(huì)使用批量操作與rte內(nèi)存池的ring自由交換對(duì)象.以此方式，CPU核心可以對(duì)多次使用的對(duì)象進(jìn)行快速訪(fǎng)問(wèn)從而減輕對(duì)ring結(jié)構(gòu)的壓力.

3.1.3 緩存管理

任何能夠傳輸網(wǎng)絡(luò)數(shù)據(jù)的應(yīng)用都可以使用librte mbuf的庫(kù)提供的緩沖區(qū)rte_mbuf.這些緩沖會(huì)在應(yīng)用程序?qū)嶋H運(yùn)行之前就被創(chuàng)建出來(lái)并存放在內(nèi)存池中.在運(yùn)行時(shí)，應(yīng)用現(xiàn)在可以通過(guò)指定mbuf來(lái)指定訪(fǎng)問(wèn)某一個(gè)mempool.釋放一個(gè)rte_mbuf只是將回到它來(lái)自的mempool[14].為了容納更大的數(shù)據(jù)包的元數(shù)據(jù)，可以將多個(gè)rte_mbuf鏈接在一起.如圖8所示，每一個(gè)rte_mbuf都包含元數(shù)據(jù)以及數(shù)據(jù)包的一部分頭部信息.它還包含一個(gè)指向下一個(gè)rte_mbuf的指針以實(shí)現(xiàn)緩沖區(qū)鏈.

需要強(qiáng)調(diào)的是，Intel DPDK通過(guò)創(chuàng)建環(huán)境抽象層(EAL)提供的所有庫(kù)，以及訪(fǎng)問(wèn)包括硬件和存儲(chǔ)器空間的底層資源這些僅僅提供了基本的操作.它不提供類(lèi)似3層轉(zhuǎn)發(fā)等復(fù)雜的功能，使用防火墻或類(lèi)似TCP或UDP協(xié)議,則需要網(wǎng)絡(luò)協(xié)議棧的全面支持.表1將第2節(jié)所述的引擎和DPDK在各種技術(shù)方面進(jìn)行了比較.

Fig. 8 One packet as chain of rte_mbufs圖8 使用多個(gè)rte_mbuf存放一個(gè)數(shù)據(jù)包

Table 1 Comparison of High-Performance Packet Capture Engine表1 多種高性能包捕獲方案的比較

Notes: D stands for Driver; K stands for Kernel; K-U stands for Kernel-User interface; √ stands for support; × stands for unsupport.

3.2 系統(tǒng)總體設(shè)計(jì)

一個(gè)完整的數(shù)據(jù)包捕獲系統(tǒng)不僅僅是包捕獲的引擎，而是涉及具體場(chǎng)景、數(shù)據(jù)包輸入、存儲(chǔ)、處理等多方面的完整的系統(tǒng)框架，在框架之上有多種功能模塊.一個(gè)通用的數(shù)據(jù)包捕獲系統(tǒng)框架，我們首先按照系統(tǒng)的功能需求，確定系統(tǒng)實(shí)現(xiàn)所需的如下目標(biāo):

1) 可維護(hù)性.數(shù)據(jù)包捕獲系統(tǒng)應(yīng)該能夠方便地修改可能存在的bug，補(bǔ)充新的功能模塊以及對(duì)性能進(jìn)行優(yōu)化，維護(hù)的過(guò)程中對(duì)于原有部分的影響要盡可能的小.

2) 可靠性.數(shù)據(jù)包捕獲系統(tǒng)是基于其上的各種安全分析模塊的基礎(chǔ)，捕獲系統(tǒng)需要足夠可靠，能夠應(yīng)對(duì)各種非標(biāo)準(zhǔn)格式的數(shù)據(jù)包.同時(shí)不同的功能模塊的故障要進(jìn)行隔離，不能因?yàn)槟硞€(gè)模塊的失效而影響正常模塊的工作，擴(kuò)大了故障的范圍.

3) 靈活性.數(shù)據(jù)包捕獲系統(tǒng)應(yīng)在不同的網(wǎng)絡(luò)環(huán)境中使用不同的配置模式，具體的運(yùn)行情況依賴(lài)于不同的配置.

4) 可重用性.由于數(shù)據(jù)包捕獲系統(tǒng)中不同部分對(duì)數(shù)據(jù)包格式處理的流程相似性很大，各種業(yè)務(wù)分析流程也有相似之處，所以在設(shè)計(jì)時(shí)需要盡量將常用的功能模塊化.

系統(tǒng)輸入為來(lái)自網(wǎng)絡(luò)的數(shù)據(jù)包，包含各種不同協(xié)議和層次的數(shù)據(jù)包；系統(tǒng)輸出為流量的統(tǒng)計(jì)信息和通過(guò)提取內(nèi)容字段等獲得的信息.除了提取數(shù)據(jù)包的凈荷之外，最原始的通信報(bào)文也需要保存下來(lái).系統(tǒng)各個(gè)部分描述如下3方面:

1) 接收數(shù)據(jù)包模塊.負(fù)責(zé)完成數(shù)據(jù)包的接收和分類(lèi)，然后對(duì)數(shù)據(jù)包的各層頭部進(jìn)行基本的解封裝和提取，剝離頭部后剩下的各層協(xié)議的凈荷傳入下一級(jí)回調(diào)函數(shù).

2) 數(shù)據(jù)包處理模塊.每一種報(bào)文解析的應(yīng)用就是一種數(shù)據(jù)包處理模塊，例如解析HTTP協(xié)議的HTTP模塊、處理DNS的DNS模塊等，各種不同的模塊需要有統(tǒng)一設(shè)計(jì)和接口,內(nèi)部解析邏輯各有區(qū)別.本模塊主要用于不同協(xié)議的內(nèi)容進(jìn)行分析，比如HTTP的請(qǐng)求及響應(yīng)頭部等.

3) 報(bào)文持久化模塊.將原始數(shù)據(jù)包及解析后的協(xié)議相關(guān)的結(jié)果寫(xiě)回?cái)?shù)據(jù)庫(kù)，作為分析結(jié)果供其他組件使用.

Fig. 10 Packet address transfer process in queue圖10 包地址在隊(duì)列中的傳遞流程

3.3 數(shù)據(jù)包接收

數(shù)據(jù)包接收使用了Intel的高性能數(shù)據(jù)包捕獲引擎DPDK.DPDK的應(yīng)用在初始化階段就分配好所需使用的大頁(yè)內(nèi)存，這些大頁(yè)內(nèi)存被組織成內(nèi)存池、環(huán)形緩存等多種操作單元，供應(yīng)用程序使用.除了存放數(shù)據(jù)包的大頁(yè)內(nèi)存，程序初始化時(shí)還需要指定程序運(yùn)行所需的核數(shù)等參數(shù).如圖9所示，由于DPDK中采用輪詢(xún)代替了中斷進(jìn)行收包，所以收包模式為程序主動(dòng)調(diào)用rte_eth_rx_burst()接口去接收一定數(shù)目的數(shù)據(jù)包，這就要求我們封裝收包接口，將其封裝為收到一個(gè)數(shù)據(jù)包作為一個(gè)事件，進(jìn)而觸發(fā)一系列掛于其上的回調(diào)函數(shù)對(duì)數(shù)據(jù)包進(jìn)行處理，從而實(shí)現(xiàn)插件式的數(shù)據(jù)包分析.

由于DPDK是批量接收數(shù)據(jù)包的，所以在調(diào)用一次rx_burst()后，要循環(huán)地對(duì)每一個(gè)接收到的數(shù)據(jù)包進(jìn)行處理.我們創(chuàng)建一個(gè)local_main()函數(shù)作為在每個(gè)核上一直運(yùn)行的主線(xiàn)程，在其中調(diào)用rx_burst()并循環(huán)處理每個(gè)數(shù)據(jù)包的包頭，根據(jù)包頭來(lái)調(diào)用不同的回調(diào)函數(shù)進(jìn)行處理，在處理結(jié)束前是阻塞的.

Fig. 9 Workflow of packet capture using DPDK圖9 使用DPDK捕獲數(shù)據(jù)包的流程

3.4 內(nèi)存管理子模塊

整個(gè)系統(tǒng)中有2個(gè)全局的大頁(yè)內(nèi)存池，分別是TCP流報(bào)文內(nèi)存池和普通報(bào)文內(nèi)存池，這里以普通報(bào)文內(nèi)存池為例詳述其實(shí)現(xiàn).為了減少報(bào)文復(fù)制帶來(lái)的性能開(kāi)銷(xiāo)，我們將報(bào)文體存儲(chǔ)在內(nèi)存池中，而在隊(duì)列間僅傳遞報(bào)文的地址.報(bào)文在接收、處理到銷(xiāo)毀的過(guò)程中涉及3個(gè)隊(duì)列，隊(duì)列傳遞流程如圖10所示:

網(wǎng)卡接收到報(bào)文后，校驗(yàn)和正常的報(bào)文將進(jìn)入內(nèi)存池，其地址將進(jìn)入待解析隊(duì)列，插件調(diào)度模塊將調(diào)用不同的插件對(duì)報(bào)文進(jìn)行解析，解析結(jié)果及屬性將填入報(bào)文的元數(shù)據(jù)結(jié)構(gòu)中，處理結(jié)束后地址統(tǒng)一進(jìn)入刪除隊(duì)列進(jìn)行刪除.每個(gè)隊(duì)列的實(shí)現(xiàn)是一個(gè)環(huán)形緩沖隊(duì)列，使用了DPDK中提供的rte_ring來(lái)存放地址，實(shí)現(xiàn)讀寫(xiě)無(wú)鎖.具體方式如圖11所示:

Fig. 11 Packet buffer queue圖11 報(bào)文緩存隊(duì)列

3.5 插件式數(shù)據(jù)包處理

插件式數(shù)據(jù)包處理是數(shù)據(jù)包捕獲系統(tǒng)實(shí)現(xiàn)擴(kuò)展能力的關(guān)鍵，為了解決報(bào)文格式間的差別以及不同處理邏輯間的差別，數(shù)據(jù)包的上層處理采用插件式設(shè)計(jì).由于目前計(jì)算機(jī)網(wǎng)絡(luò)統(tǒng)一采用TCP/IP協(xié)議，這就使得不同數(shù)據(jù)包的處理和解析有了相同的部分，可以采用相同或近似的方式處理網(wǎng)絡(luò)報(bào)文的每一層協(xié)議封裝.為了解決以上關(guān)鍵問(wèn)題，通用的插件式數(shù)據(jù)包處理設(shè)計(jì)如圖12所示.

插件式的報(bào)文解析模塊，可以很好地解決報(bào)文解析過(guò)程中針對(duì)不同解析目標(biāo)的適配靈活性，同時(shí)分發(fā)機(jī)制可以帶來(lái)很好的可擴(kuò)展性.插件式的數(shù)據(jù)包處理可以實(shí)現(xiàn)報(bào)文處理插件模塊化.將不同的處理功能按照統(tǒng)一的結(jié)構(gòu)化的模板封裝成具有相同接口的插件類(lèi)，這些類(lèi)被編譯為不同的動(dòng)態(tài)鏈接庫(kù)在需要調(diào)用時(shí)加載.增加了系統(tǒng)工作流程的靈活性和可維護(hù)性，程序按照配置文件的不同加載不同的插件模塊,同時(shí)這種方案也可以實(shí)現(xiàn)數(shù)據(jù)包處理管道化.在程序啟動(dòng)時(shí)加載的配置文件中的#route項(xiàng)可以指定每個(gè)插件模塊解析后的結(jié)果的下一級(jí)插件，或者使用#done表示處理當(dāng)前插件已經(jīng)是處理的最后一級(jí)(處理完成).例如網(wǎng)絡(luò)層解析的下一級(jí)處理可能是傳輸層解析，如果傳輸層是TCP協(xié)議則下一級(jí)模塊有可能是HTTP解析，如果是UDP協(xié)議則下一級(jí)有可能是DNS解析.

3.6 基于RSS的數(shù)據(jù)包分發(fā)

RSS是將到達(dá)網(wǎng)卡的數(shù)據(jù)包分配到不同隊(duì)列中的技術(shù)[14].它以可擴(kuò)展的方式允許每個(gè)CPU核獨(dú)立訪(fǎng)問(wèn)不同的網(wǎng)卡隊(duì)列來(lái)接收分組，這樣同時(shí)消除了訪(fǎng)問(wèn)網(wǎng)卡隊(duì)列時(shí)鎖的爭(zhēng)奪，允許多個(gè)不同CPU核的進(jìn)程并發(fā)訪(fǎng)問(wèn)不同的隊(duì)列.然而，現(xiàn)有的RSS機(jī)制中的一個(gè)問(wèn)題是它會(huì)將同一個(gè)TCP連接映射到不同的網(wǎng)卡隊(duì)列，具體而言就是映射的隊(duì)列取決于數(shù)據(jù)包的方向.我們?cè)诖颂岢鲆环N對(duì)稱(chēng)RSS的Hash算法，它會(huì)將同一TCP連接中的數(shù)據(jù)包無(wú)論它們是上行還是下行都會(huì)映射到同一個(gè)網(wǎng)卡隊(duì)列.

我們首先描述原始的RSS算法，它使用Toeplitz散列函數(shù)[15]基于包頭計(jì)算散列值，并通過(guò)取模操作來(lái)決定哪個(gè)接收隊(duì)列來(lái)存儲(chǔ)分組.RSS可以應(yīng)用到IP/TCP/UDP報(bào)頭中的任何字節(jié)范圍，但通常而言，一般會(huì)散列{源IP，目的IP，源端口，目的端口，協(xié)議}組成的五元組.

算法1. RSS Hash值計(jì)算算法(Toeplitz)[15].

輸入: 數(shù)據(jù)包頭部五元組Input[]、隨機(jī)密鑰RSK；

輸出: 數(shù)據(jù)包頭部五元組的Hash值ret.

①ret=0；

② for eachbinInput[] do

③ ifb==1 then

④ret=(left 32 bit ofRSK); /*與RSK高32位異或*/

⑤ end if

⑥ shiftRSKleft 1 bit; /*RSK整體向左滾動(dòng)1位*/

⑦ end for

算法1是RSS散列函數(shù)的偽代碼.INPUT是由網(wǎng)絡(luò)層和傳輸層頭部共同組成的五元組，總共12 B.采用40 B(320 b)的隨機(jī)密鑰(RSK)與輸入值混合的種子值.因?yàn)镽SS算法為了快速處理從而實(shí)現(xiàn)在網(wǎng)卡的硬件中，直接修改RSS算法使其支持對(duì)稱(chēng)映射較為困難.但是，RSK是設(shè)備驅(qū)動(dòng)程序的一部分，并在驅(qū)動(dòng)程序設(shè)置網(wǎng)卡時(shí)先裝入內(nèi)存.我們專(zhuān)注于操縱RSK使得Hash函數(shù)允許對(duì)稱(chēng)映射.對(duì)稱(chēng)流映射需要產(chǎn)生相同的RSS散列值，即使源和目的IP以及端口號(hào)被顛倒.

Hash(srcIP,dstIP,srcPort,dstPort,RSK)=

Hash(dstIP,srcIP,dstPort,srcPort,RSK),

(1)

式(1)是對(duì)稱(chēng)RSS隊(duì)列映射的基本條件.我們需要找到條件滿(mǎn)足式(1).我們觀察到，不是每個(gè)位的RSK都用于獲取散列值.例如給定一個(gè)輸入位，只有32位的RSK用于異或運(yùn)算.也就是說(shuō)，對(duì)于n位INPUT，只有(n-1)+32位RSK用于生成Hash值.如果INPUT大于或等于290位，RSK將循環(huán)到第1位.所以對(duì)于INPUT中的特定位，對(duì)應(yīng)于RSK的范圍是固定的.因此，我們可以導(dǎo)出用于計(jì)算IPv4/TCP(或UDP)數(shù)據(jù)包散列值的RSK的位范圍對(duì)應(yīng)關(guān)系.例如，INPUT的第1個(gè)字節(jié)(前8位)對(duì)應(yīng)RSK的前39位；第2個(gè)輸入字節(jié)(從第9～16位)對(duì)應(yīng)RSK中第9～47位的范圍.通過(guò)這種方式，我們計(jì)算得到了表2中不同INPUT每個(gè)位所對(duì)應(yīng)的RSK的范圍.

設(shè)RSK[A:B]表示RSK中從第A位到第B位間的密鑰值.

Table 2 Associated RSK Range When Computing Packet Header Hash Value

使用表2和式(1)我們可以得出式(2).式(2)需要對(duì)應(yīng)于數(shù)據(jù)包中源和目的IP地址以及源和目標(biāo)端口范圍的RSK位采用相同的值.如果RSK位范圍滿(mǎn)足此條件，對(duì)于2個(gè)方向的TCP數(shù)據(jù)包的RSS Hash值將是相同的.

(2)

進(jìn)一步將式(2)中的重疊區(qū)域拆分后可得到以下3個(gè)等式，即式(3):

1)RSK[1:15]=RSK[17:31]=

RSK[33:47]=RSK[49:63]=

RSK[65:79]=RSK[81:95]=

RSK[97:111]=RSK[113:127];

2)RSK[16]=RSK[48]=

RSK[80]=RSK[96]=RSK[112];

3)RSK[32]=RSK[64].

(3)

我們可以求得一個(gè)滿(mǎn)足式(3)的RSK的一個(gè)示例,如圖13所示：

0xDA650xDB650xDA650xDB650xDA650xDA650xDA650xDA650xDA650xDA650xDA650xDA650xDA650xDA650xDA650xDA650xDA650xDA650xDA650xDA65

Fig. 13 A symmetric Hash satisfied RSK value
圖13 一個(gè)滿(mǎn)足對(duì)稱(chēng)Hash要求的RSK密鑰值

4 實(shí) 驗(yàn)

我們?cè)贚inux上實(shí)現(xiàn)了這個(gè)高性能的包捕獲系統(tǒng)，它由5 000行左右的C語(yǔ)言代碼和300行左右的Python語(yǔ)言代碼組成，使用了DPDK 2.0版本作為包捕獲引擎，使用MySQL 5.6作為存儲(chǔ)持久化結(jié)果的數(shù)據(jù)庫(kù).我們?cè)贑entOS 6.5上部署了整套系統(tǒng)，服務(wù)器采用Dell PowerEdge R720，CPU為Intel Xeon E5-2609，內(nèi)存64 GB(其中大頁(yè)內(nèi)存分配16 GB)，硬盤(pán)1 TB機(jī)械硬盤(pán)，網(wǎng)卡為支持DPDK的e1000和Intel 82599兩種型號(hào).我們將系統(tǒng)部署在一個(gè)局域網(wǎng)的出口處，以旁路模式部署，如圖14所示，我們?cè)趦?nèi)網(wǎng)中部署了10臺(tái)發(fā)送數(shù)據(jù)的服務(wù)器，在網(wǎng)關(guān)的另一側(cè)部署了一臺(tái)接收數(shù)據(jù)的服務(wù)器，路由器會(huì)將出入局域網(wǎng)的雙向流量進(jìn)行鏡像后發(fā)送給分析系統(tǒng)，分析系統(tǒng)在收到數(shù)據(jù)包后存儲(chǔ)在本地.在測(cè)試中，我們使用DPDK-Pktgen[19]發(fā)包工具在10臺(tái)發(fā)送服務(wù)器上向接收服務(wù)器發(fā)送IP報(bào)文，接收端服務(wù)器收到這些報(bào)文后會(huì)直接丟棄.Pktgen能夠產(chǎn)生不同長(zhǎng)度的報(bào)文，也可以調(diào)節(jié)發(fā)送流量的大小，可以滿(mǎn)足實(shí)驗(yàn)的需要.我們還配置了普通Linux系統(tǒng)網(wǎng)卡驅(qū)動(dòng)和PF-RING上基于libpcap的報(bào)文捕獲系統(tǒng)，用來(lái)驗(yàn)證系統(tǒng)在數(shù)據(jù)包捕獲及多核性能擴(kuò)展方面的優(yōu)勢(shì).

Fig. 14 Experiment setting圖14 實(shí)驗(yàn)環(huán)境

我們首先測(cè)試了在不同輸入流量的條件下，不同引擎的捕獲性能及其多核性能擴(kuò)展能力.具體實(shí)驗(yàn)方法是分別使用2個(gè)CPU核和6個(gè)CPU核捕獲報(bào)文，測(cè)試基于原生Linux,PF-RING和DPDK三種平臺(tái)上包捕獲系統(tǒng)的性能.輸入流量的大小從1 Gbps一直增長(zhǎng)到10 Gbps，測(cè)試的數(shù)據(jù)包長(zhǎng)均為250 B.從圖15中我們可以看到，雙核環(huán)境下的原生Linux在輸入流量為1 Gbps左右時(shí)就已經(jīng)有10%左右的丟包，而6核環(huán)境下的原生Linux在輸入流量為2 Gbps時(shí)也開(kāi)始產(chǎn)生丟包.PF-RING平臺(tái)下的捕獲情況略好于原生Linux，但能夠承受的流量負(fù)載也十分有限；而基于DPDK的捕獲系統(tǒng)在雙核環(huán)境下運(yùn)行時(shí)就已經(jīng)取得了不錯(cuò)的性能，直到輸入流量為3 Gbps時(shí)才產(chǎn)生丟包，好于6核環(huán)境下的原生Linux與PF-RING引擎；而運(yùn)行在6核環(huán)境下基于DPDK的包捕獲引擎直到輸入流量為7 Gbps時(shí)才開(kāi)始丟包，事實(shí)上在實(shí)際測(cè)試中，該系統(tǒng)在8核環(huán)境下就可以達(dá)到線(xiàn)速.同時(shí)我們還可以看到，基于DPDK的包捕獲系統(tǒng)在不同CPU核數(shù)環(huán)境下運(yùn)行時(shí)的性能有很大的差異，而原生Linux和PF-RING則不具有這樣的特性，這充分說(shuō)明了系統(tǒng)性能的可擴(kuò)展性.

Fig. 15 Traffic loss rate with the increase of traffic load圖15 隨流量增大的丟包率

Fig. 16 Traffic loss rate with the increase of packet size圖16 隨包長(zhǎng)增大的丟包率

為了驗(yàn)證系統(tǒng)在不同數(shù)據(jù)包長(zhǎng)度下的性能，我們將輸入流量固定為5 Gbps，觀察當(dāng)數(shù)據(jù)包長(zhǎng)度由64 B向1 500 B變化時(shí)的丟包率.如圖16所示，在輸入小數(shù)據(jù)包時(shí)，除6核環(huán)境下的DPDK包捕獲系統(tǒng)外，丟包率都超過(guò)了50%；隨著數(shù)據(jù)包長(zhǎng)度的增大，所有平臺(tái)下的丟包率都開(kāi)始下降，而6核環(huán)境下的包捕獲系統(tǒng)的丟包率一直為0.可見(jiàn)我們的系統(tǒng)在處理小包時(shí)具有明顯的性能優(yōu)勢(shì).

為了驗(yàn)證在使用RSS Hash進(jìn)行數(shù)據(jù)包分發(fā)的有效性，我們統(tǒng)一開(kāi)啟8個(gè)核來(lái)處理流量，在不同流量下監(jiān)控每個(gè)核心的CPU利用率.圖17是在不同流量輸入下CPU每個(gè)核的利用率情況.橫軸代表CPU核的編號(hào)，縱軸代表每個(gè)核的利用率，我們采集流量分別為1 Gbps，3 Gbps，6 Gbps和9 Gbps情況下每個(gè)核的利用情況.很顯然隨著流量的增大，每個(gè)核的利用率也在上升，但不同核間的利用率基本保持齊平.需要注意的是，DPDK采用的是輪詢(xún)模式收包，在此過(guò)程中CPU的利用率始終為100%，為了限制其收包線(xiàn)程占用的CPU資源，我們用Sleep()函數(shù)為收包線(xiàn)程加入了固定的睡眠時(shí)間，Sleep()中參數(shù)越大，進(jìn)程所占用的CPU上界就越低，但過(guò)大的睡眠時(shí)間會(huì)導(dǎo)致丟包.需要注意的是，圖17中的CPU利用率是在不丟包的情況下測(cè)量的臨界值.

Fig. 17 CPU per-core usage under different traffic load圖17 不同流量情況下的每核CPU利用率

5 結(jié) 論

本文圍繞高速網(wǎng)絡(luò)環(huán)境下的數(shù)據(jù)包捕獲問(wèn)題，首先分析了傳統(tǒng)網(wǎng)絡(luò)協(xié)議棧在數(shù)據(jù)包捕獲方面存在的問(wèn)題，其次圍繞目前的多種捕獲引擎分析了各自?xún)?yōu)劣，而后基于DPDK設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)高性能可擴(kuò)展的包捕獲系統(tǒng)，最后對(duì)系統(tǒng)的性能做了實(shí)驗(yàn)驗(yàn)證.數(shù)據(jù)包捕獲只是網(wǎng)絡(luò)流量分析的第1步，要分析網(wǎng)絡(luò)上通信的所有會(huì)話(huà)，必須要對(duì)TCP連接進(jìn)行恢復(fù)，以及對(duì)各種基于TCP的協(xié)議應(yīng)用層協(xié)議進(jìn)行內(nèi)容分析，這將是我們下一步的工作.

[1]China Internet Network Information Center. The 34th China Internet Development Statistics Report[R]. Beijing: China Internet Network Information Center, 2014 (in Chinese)

(中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心. 第34次中國(guó)互聯(lián)網(wǎng)絡(luò)發(fā)展?fàn)顩r統(tǒng)計(jì)報(bào)告[R]. 北京: 中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心, 2014)

[2]Liu Baochen. Research and implementation of a high-performance packet-capture system[D]. Shanghai: Shanghai Jiao Tong University, 2013 (in Chinese)

(劉寶辰. 高性能數(shù)據(jù)包捕獲系統(tǒng)的研究與實(shí)現(xiàn)[D]. 上海: 上海交通大學(xué), 2013)

[3]Risso F, Degioanni L. An architecture for high performance network analysis[C] //Proc of the 6th IEEE Symp on Computers and Communications. Piscataway, NJ: IEEE, 2001: 686-693

[4]McCanne S, Jacobson V. The BSD packet Filter: A new architecture for user-level packet capture[C] //Proc of the 1993 Winter USENIX Technical Conf. Berkeley, CA: USENIX Association, 1993: 120-130

[5]Heberlein L T. A network security monitor[C] //Proc of the IEEE Symp on Research in Security and Privacy. Piscataway, NJ: IEEE, 1990: 296-304

[6]Nie Yuanming, Qiu Ping. Network Information Security Technology[M]. Beijing: Science Press, 2001 (in Chinese)(聶元銘, 丘平. 網(wǎng)絡(luò)信息安全技術(shù)[M]. 北京: 科學(xué)出版社, 2001)

[7]William S. Network Security Element—Application and Standard[M]. Beijing: The People’s Posts and Telecomm-unications Press, 2000

[8]Zhang Nan. Design and implementation of general purpose data collection system based on IP network[D]. Beijing: Beijing University of Posts and Telecommunications, 2014 (in Chinese)

(張楠. 基于IP網(wǎng)絡(luò)的通用數(shù)據(jù)采集系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D]. 北京: 北京郵電大學(xué), 2014)

[9]Han S, Jang K, Park K S, et al. PacketShader: A GPU-accelerated software router[J]. ACM SIGCOMM Computer Communication Review, 2010, 40(4): 195-206

[10]Rizzo L. Netmap: A novel framework for fast packet I/O[C] //Proc of the 21st USENIX Security Symp (USENIX Security’12). Berkeley, CA: USENIX Association, 2012: 101-112

[11]Liao Guangdeng, Znu X, Bnuyan L. A new server I/O architecture for high speed networks[C] //Proc of Symp on High-Performance Computer Architecture. Piscataway, NJ: IEEE, 2011: 255-265

[12]Papadogiannakis A, Vasiliadis G, Antoniades D. Improving the performance of passive network monitoring applications with memory locality enhancements[J]. Computer Communications, 2012, 35(1): 129-140

[13]Wu Wenji, DeMar P, Crawford M. Why can some advanced Ethernet NICs cause packet reordering?[J]. IEEE Communications Letters, 2011, 15(2): 253-255

[14]Intel. Intel DPDK: Programmers Guide[OL]. [2016-08-24]. http://dpdk.org/doc/guides/prog_guide

[15]Mircosoft. Microsoft: Receive side scaling[OL]. [2016-08-24]. http://msdn.microsoft.com/en-us/library/windows/hardware/ff567236(v=vs.85).aspx

[16]Moreno V, Santiago del Rio P M, Ramos J, et al. Batch to the future: Analyzing timestamp accuracy of high-performance packet I/O engines[J]. IEEE Communications Letters, 2012, 16(11): 1888-1891

[17]Rizzo L, Deri L, Cardigliano A. 10 Gbit/s line rate packet processing using? Commodity hardware: Survey and new proposals[OL]. [2016-09-20]. http://luca.ntop.org/10g.pdf?

[18]Bonelli N, Di Pietro A, Giordano S, et al. On multi-gigabit packet capturing with multi-core commodity hardware[C] //Proc of Int Conf on Passive and Active Network Measurement. Berlin: Springer, 2012: 64-73

[19]Intel DPDK. Data Plane Development Kit Project Page[OL]. [2016-09-12]. http://www.dpdk.org,June 2014

Li Junfeng, born in 1992. PhD candidate. Received his bachelor degree from Xian Jiao Tong University in 2015. PhD candidate in Tsinghua University. His main research interests include on network coding and network performance optimization.

Li Dan, born in 1981. Associate professor. Received his MEn degree and PhD degree from Tsinghua University in 2005 and 2007 respectively, both in computer science. His main research interests include cloud computing, datacenter network and SDN.

Realtime Capture of High-Speed Traffic on Multi-Core Platform

Ling Ruilin, Li Junfeng, and Li Dan

(DepartmentofComputerScienceandTechnology,TsinghuaUniversity,Beijing100084)

With the development of Internet application and the increase of network bandwidth, security issues become increasingly serious. In addition to the spread of the virus, spams and DDoS attacks, there have been lots of strongly hidden attack methods. Network probe tools which are deployed as a bypass device at the gateway of the intranet, can collect all the traffic of the current network and analyze them. The most important module of the network probe is packet capture. In Linux network protocol stack, there are many performance bottlenecks in the procedure of packets processing which cannot meet the demand of high speed network environment. In this paper, we introduce several new packet capture engines based on zero-copy and multi-core technology. Further, we design and implement a scalable high performance packet capture framework based on Intel DPDK, which uses RSS (receiver-side scaling) to make packet capture parallelization and customize the packet processing. Additionally, this paper also discusses more effective and fair Hash function by which data packet can be deliveried to different receiving queues. In evaluation, we can see that the system can capture and process the packets in nearly line-speed and balance the load between CPU cores.

packet capture; receiver-side scaling (RSS); multi-core; DPDK platform; Hash function

in, born in 1992.

his bachelor degree in Beijing University of Posts and Telecommunications. Master candidate in Tsinghua University. His main research interests include data center network, cloud computing and high-performance networking.

2016-11-10；

2017-03-09

國(guó)家“八六三”高技術(shù)研究發(fā)展計(jì)劃基金項(xiàng)目(2015AA01A705,2015AA016102)；國(guó)家自然科學(xué)基金優(yōu)秀青年科學(xué)基金項(xiàng)目(61522205) This work was supported by the National High Technology Research and Development Program of China (863 Program) (2015AA01A705, 2015AA016102) and the National Natural Science Foundation of China for Excellent Young Scientists (61522205).

TP391