基于多空間內(nèi)存共享的高速網(wǎng)絡(luò)鏈路數(shù)據(jù)包捕獲方法

摘要：結(jié)合共享內(nèi)存和NAPI技術(shù)提出了一種基于通用硬件平臺和開源軟件實現(xiàn)的高速網(wǎng)絡(luò)鏈路數(shù)據(jù)包捕獲方案，能夠?qū)?shù)據(jù)包的捕獲能力和捕獲效率提升到一個新水平。通過實驗表明，在通用PC服務(wù)器上實現(xiàn)該方案完全能夠滿足千兆鏈路的監(jiān)測需求，數(shù)據(jù)包處理能力可達(dá)到線速148.8萬pps。

關(guān)鍵詞：數(shù)據(jù)包捕獲；共享內(nèi)存；新的應(yīng)用編程接口

中圖分類號：TP393．06文獻(xiàn)標(biāo)志碼：A

文章編號：1001－3695(2008)03－0807－04

網(wǎng)絡(luò)測試是了解網(wǎng)絡(luò)流量、分析業(yè)務(wù)性能的重要手段。如何實現(xiàn)高速鏈路流量捕獲分析是目前人們非常關(guān)注的問題[1]。數(shù)據(jù)包捕獲是被動測量的基本過程，一般有三種辦法：a)基于專用硬件的采集方法，如HP/Agilent Advisor[2]、InMon sFlow Probe[3]、Endace DAG[4]等。由于專用硬件可編程性差、價格通常比較昂貴，其性價比往往難以滿足用戶的要求。b)基于網(wǎng)絡(luò)處理器的數(shù)據(jù)包捕獲方法。網(wǎng)絡(luò)處理器（network processor，NP）[5]是專門為數(shù)據(jù)包處理而設(shè)計的可編程處理器，專門針對數(shù)據(jù)包處理部件進行優(yōu)化，因此數(shù)據(jù)包的處理能力可以得到大幅度的提升。但是網(wǎng)絡(luò)處理器通常價格比較昂貴，而且針對特定硬件進行開發(fā)的特點易造成開發(fā)難度加大、可移植性差等問題。c)基于通用PC架構(gòu)，通過普通的網(wǎng)絡(luò)接口卡捕獲數(shù)據(jù)包的方法，如Ethereal[6]、Wireshark[7]等工具。該方法采用通用硬件平臺的實現(xiàn)方式大大節(jié)約了成本，但是從網(wǎng)絡(luò)鏈路上捕獲數(shù)據(jù)包，再將捕獲到的數(shù)據(jù)包從操作系統(tǒng)內(nèi)核空間拷貝到用戶空間需要占用大量的CPU資源。目前基于該方法實現(xiàn)的工具均不能提供監(jiān)測百兆以上鏈路線速處理能力。

1研究背景

Libpcap[8]是由美國加州大學(xué)勞侖斯實驗室開發(fā)的開源數(shù)據(jù)包捕獲工具，對多種網(wǎng)絡(luò)媒介提供良好的支持，并具有可跨平臺移植的優(yōu)勢，使其自1994年正式發(fā)布以來就成為UNIX、類UNIX平臺下開發(fā)流量監(jiān)測分析程序首選的一款數(shù)據(jù)包捕獲工具。依賴于操作系統(tǒng)，Libpcap為流量監(jiān)測分析程序提供虛擬的數(shù)據(jù)包捕獲平臺。通過該平臺流量監(jiān)測分析程序能夠直接訪問網(wǎng)卡捕獲的數(shù)據(jù)包，從而簡化程序開發(fā)。Libpcap的工作流程可簡要概括如下：a)接收來自操作系統(tǒng)內(nèi)核空間緩存的數(shù)據(jù)包。b)對接收到的所有數(shù)據(jù)包進行過濾規(guī)則匹配。如果匹配成功就將數(shù)據(jù)包拷貝到用戶空間緩存；否則直接丟棄數(shù)據(jù)包。c)運行在用戶空間的流量監(jiān)測分析程序調(diào)用Libpcap提供的API接口讀取數(shù)據(jù)包信息。然而，隨著網(wǎng)絡(luò)技術(shù)的發(fā)展和高速網(wǎng)絡(luò)鏈路的普及，Libpcap在數(shù)據(jù)包捕獲性能方面的缺陷也逐漸暴露。探究其原因主要是數(shù)據(jù)包接收時產(chǎn)生的中斷開銷，將數(shù)據(jù)包從內(nèi)核空間拷貝到用戶空間的系統(tǒng)調(diào)用和內(nèi)存拷貝需要消耗大量的CPU資源[8，15]，這就使得基于Libpcap實現(xiàn)的流量監(jiān)測分析程序很難適用于百兆以上鏈路環(huán)境中。

隨著千兆網(wǎng)卡和千兆交換機等高速網(wǎng)絡(luò)設(shè)備逐步進入主流市場，小區(qū)寬帶接入網(wǎng)的出口帶寬也紛紛升級到千兆速率，對千兆甚至更高速率鏈路的監(jiān)測需求已經(jīng)迫在眉睫。因此，有人提出了基于Linux NetFilter[9]機制實現(xiàn)的動態(tài)可掛載內(nèi)核模塊技術(shù)[10]。其基本思想是將數(shù)據(jù)包的解碼和統(tǒng)計分析等功能實現(xiàn)為一個內(nèi)核模塊，轉(zhuǎn)移到操作系統(tǒng)內(nèi)核中運行，以達(dá)到數(shù)據(jù)包內(nèi)存零拷貝和減少系統(tǒng)調(diào)用開銷的目的。實驗表明此方法與NAPI（new API）技術(shù)[11]相結(jié)合可以獲得較高的性能，同時也存在諸多缺陷：a)在內(nèi)核模塊中不能調(diào)用C標(biāo)準(zhǔn)函數(shù)庫，只能使用內(nèi)核導(dǎo)出的少量系統(tǒng)調(diào)用，這就給監(jiān)測和分析功能的開發(fā)實現(xiàn)帶來了很大的麻煩；b)在內(nèi)核中開發(fā)代碼不僅容易出錯而且不易調(diào)試，在程序中隱藏的BUG極有可能會導(dǎo)致系統(tǒng)崩潰，給用戶造成無法估量的嚴(yán)重后果；c)出于安全方面的考慮，一般來說用戶會拒絕在某些關(guān)鍵機器上運行內(nèi)核程序。

NAPI技術(shù)是為解決中斷活鎖問題(interrupt livelock)[12]而引入的。高速外圍設(shè)備的出現(xiàn)給操作系統(tǒng)引入了中斷活鎖問題，主要目的是降低設(shè)備對CPU的中斷請求次數(shù)。目前在Linux、FreeBSD和Windows等主流操作系統(tǒng)中都采用了一種降低中斷頻率的技術(shù)——設(shè)備輪詢[13]。采用輪詢技術(shù)可以提高系統(tǒng)在重負(fù)載時的效率，但在輕負(fù)載時會增加系統(tǒng)對設(shè)備的響應(yīng)延遲。中斷技術(shù)在輕負(fù)載時可減小響應(yīng)延遲，但在重負(fù)載時會引起中斷活鎖。NAPI則是一種中斷與輪詢相結(jié)合的技術(shù)，在輕負(fù)載時系統(tǒng)采用中斷方式處理數(shù)據(jù)包；在重負(fù)載時只中斷一次，隨后采用輪詢的方式處理多個數(shù)據(jù)包，從而減少中斷次數(shù)。實驗表明，在千兆鏈路監(jiān)測應(yīng)用中即使采用了NAPI技術(shù)，基于Libpcap的數(shù)據(jù)包捕獲應(yīng)用其數(shù)據(jù)包深度分析能力最高只能達(dá)到18.5萬pps，丟包率約為87.5％，遠(yuǎn)遠(yuǎn)不能滿足千兆鏈路的監(jiān)測需求；基于內(nèi)核模塊的數(shù)據(jù)包捕獲應(yīng)用其數(shù)據(jù)包深度分析能力達(dá)到110萬pps，丟包率約為25％，還不能滿足線速監(jiān)測的需求。

綜上所述，可在通用硬件平臺上實現(xiàn)的且能夠達(dá)到更高性能的、可滿足高速網(wǎng)絡(luò)鏈路監(jiān)測需要的數(shù)據(jù)包捕獲方法仍舊是迫切需要的。

2基于多空間內(nèi)存共享高速網(wǎng)絡(luò)鏈路數(shù)據(jù)包捕獲方法

2．1結(jié)構(gòu)

本文所提出的基于多空間內(nèi)存共享的高速網(wǎng)絡(luò)鏈路數(shù)據(jù)包捕獲方法采用內(nèi)存映射技術(shù)，其關(guān)鍵在于采用了可跨越內(nèi)核空間和用戶空間界限的共享內(nèi)存作為數(shù)據(jù)包緩存，減少系統(tǒng)調(diào)用次數(shù)，實現(xiàn)數(shù)據(jù)包內(nèi)存零拷貝，從而縮短了數(shù)據(jù)包從網(wǎng)卡到流量監(jiān)測分析程序的傳輸路徑。

如圖1所示，基于多空間內(nèi)存共享的高速網(wǎng)絡(luò)鏈路數(shù)據(jù)包捕獲方法由三個部分組成，即底層數(shù)據(jù)包獲取驅(qū)動模塊、共享內(nèi)存管理模塊和上層應(yīng)用API接口。

系統(tǒng)中實現(xiàn)的數(shù)據(jù)包處理流程如下：a)底層數(shù)據(jù)包獲取驅(qū)動模塊捕獲數(shù)據(jù)包；b)通過共享內(nèi)存管理模塊檢查數(shù)據(jù)包緩存空間，如果尚有可用的緩存空間，則將數(shù)據(jù)包通過DMA（directly memory access）通道寫入到共享內(nèi)存并返回，否則直接丟棄數(shù)據(jù)包；c)流量監(jiān)測分析程序調(diào)用上層應(yīng)用API接口訪問共享內(nèi)存中緩存的數(shù)據(jù)包，完成數(shù)據(jù)包處理和分析工作后釋放數(shù)據(jù)包緩存。

2．2設(shè)計與實現(xiàn)

如上所述，基于多空間內(nèi)存共享的高速網(wǎng)絡(luò)鏈路數(shù)據(jù)包捕獲方法的實現(xiàn)主要包括以下三個部分。

2．2．1底層數(shù)據(jù)包獲取驅(qū)動模塊

底層驅(qū)動模塊通過增加驅(qū)動程序的部分功能，實現(xiàn)數(shù)據(jù)包在共享內(nèi)存中的存儲和管理。新增的功能主要包括：

a)在底層數(shù)據(jù)包獲取驅(qū)動模塊初始化過程中加載共享內(nèi)存管理模塊，初始化共享內(nèi)存。

b)區(qū)分監(jiān)測接口和控制接口接收到的數(shù)據(jù)包。監(jiān)測接口數(shù)據(jù)包送到共享內(nèi)存數(shù)據(jù)信息域中緩存；控制接口數(shù)據(jù)包按照正常的數(shù)據(jù)包處理流程，送入操作系統(tǒng)內(nèi)核協(xié)議棧中接受處理。

c)創(chuàng)建一個字符設(shè)備用于共享內(nèi)存的管理，在字符設(shè)備中實現(xiàn)mmap內(nèi)存映射系統(tǒng)調(diào)用的具體方法，mmap系統(tǒng)調(diào)用封裝在上層應(yīng)用API接口中提供給流量監(jiān)測分析程序調(diào)用。

需要補充的是，為了不影響主機的正常通信，這里引入了監(jiān)測接口和控制接口的概念。其中：監(jiān)測接口用于被監(jiān)測鏈路的數(shù)據(jù)包捕獲；控制接口用于主機的正常通信（如可用于監(jiān)測系統(tǒng)的配置和管理）。在監(jiān)測接口上接收從被監(jiān)測鏈路上偵聽到的數(shù)據(jù)包并存儲到網(wǎng)卡的板載緩存；底層數(shù)據(jù)包獲取驅(qū)動模塊讀取全局索引數(shù)組信息，檢查共享內(nèi)存管理信息域，判斷數(shù)據(jù)包是否能夠安全寫入數(shù)據(jù)信息域中（判斷方法是：如果當(dāng)前需要被寫入的數(shù)據(jù)包緩存單元的全局引用計數(shù)器skb_cnt_index[i]值為0，說明該緩存單元可以安全覆蓋）；如果數(shù)據(jù)包可以被寫入到共享內(nèi)存中，底層驅(qū)動模塊將數(shù)據(jù)包通過DMA通道從網(wǎng)卡板載緩存搬運到共享內(nèi)存數(shù)據(jù)信息域中存放，并初始化管理信息域中與數(shù)據(jù)包緩存單元對應(yīng)的管理單元（對共享內(nèi)存中的數(shù)據(jù)信息域和管理信息域的說明詳見2.2.2節(jié)）。底層數(shù)據(jù)包獲取驅(qū)動模塊需要初始化的內(nèi)容包括：a)根據(jù)當(dāng)前系統(tǒng)中已注冊的上層流量監(jiān)測分析應(yīng)用的個數(shù)初始化全局引用計數(shù)器數(shù)組中的對應(yīng)元素，形式化表達(dá)式為skb_cnt_index[i] = app_counter；b)將訪問標(biāo)志字段數(shù)組中的對應(yīng)元素重新置位，形式化表達(dá)式為skb_label_index[i] = 0x00。否則，數(shù)據(jù)包不能夠被寫入到共享內(nèi)存中，說明共享內(nèi)存數(shù)據(jù)信息域產(chǎn)生溢出，底層驅(qū)動模塊則直接丟棄收到的數(shù)據(jù)包。在本實現(xiàn)中修改開源的Intel e10006.3.9[14]網(wǎng)卡驅(qū)動程序完成本模塊。

2．2．2共享內(nèi)存管理模塊

共享內(nèi)存管理模塊負(fù)責(zé)向操作系統(tǒng)申請一塊連續(xù)的物理內(nèi)存作為內(nèi)核空間和用戶空間共享的內(nèi)存，將申請得到的物理內(nèi)存劃分為數(shù)據(jù)信息域和管理信息域。數(shù)據(jù)信息域用于緩存接收到的數(shù)據(jù)包，管理信息域則被用于管理數(shù)據(jù)信息域。該模塊在底層數(shù)據(jù)包獲取驅(qū)動模塊的初始化過程中被加載，在加載過程中會分別對數(shù)據(jù)信息域和管理信息域進行初始化。此外，流量監(jiān)測分析程序通過管理信息域中的數(shù)據(jù)結(jié)構(gòu)向底層數(shù)據(jù)包獲取驅(qū)動模塊注冊自身信息并下達(dá)數(shù)據(jù)包查看請求。

共享內(nèi)存管理模塊實現(xiàn)從操作系統(tǒng)頁表中查找連續(xù)的空閑內(nèi)存頁面，在查找到的多段連續(xù)空閑內(nèi)存中選擇一個內(nèi)存段，選擇策略可以按操作系統(tǒng)的內(nèi)存分配方法實現(xiàn)為最佳匹配、最大匹配和最快匹配，在選出的某一空閑內(nèi)存段中再劃分出用戶指定數(shù)量的頁面并將頁面標(biāo)記為reserved，操作系統(tǒng)內(nèi)存調(diào)度程序不能將標(biāo)記頁面交換出物理內(nèi)存。這就保證了共享內(nèi)存的專用性。圖2給出共享內(nèi)存管理模塊的邏輯結(jié)構(gòu)。

定義共享內(nèi)存大小為MEM_SHARE MB、數(shù)據(jù)信息域DATA_AREA MB、管理信息域CTRL_AREA MB。這三者滿足MEM_SHARE= DATA_AREA +CTRL_AREA。數(shù)據(jù)信息域被分割成定長的數(shù)據(jù)包緩存單元，每單元緩存一個數(shù)據(jù)包，定義數(shù)據(jù)包緩存單元長度為PKT_UNIT字節(jié)。數(shù)據(jù)信息域在邏輯上形成一個環(huán)形緩沖區(qū)循環(huán)存放接收到的數(shù)據(jù)包；管理信息域用來存放數(shù)據(jù)信息域中的數(shù)據(jù)包所對應(yīng)的全局索引數(shù)組信息和流量監(jiān)測分析程序的注冊信息。如表1所示，共包含有四個數(shù)據(jù)成員信息。其中：skb_cnt_index和skb_label_index數(shù)組合稱為全局索引數(shù)組信息；app_counter和appname合稱為流量監(jiān)測分析程序的注冊信息。app_counter最多可支持MAX_APP個應(yīng)用程序同時注冊運行；appname[MAX_APP][NAME_LEN]應(yīng)用程序的注冊名稱不允許超過NAME_LEN個字節(jié)。skb_cnt_index [DATA_AREA/PKT_UNIT]該計數(shù)器初始化為app_counter中的值，此后由流量監(jiān)測分析程序遞減該計數(shù)器到0。skb_label_index [DATA_AREA/PKT_UNIT]該字段初始化為0，此后由流量監(jiān)測分析程序?qū)⒃撟侄蔚膶?yīng)標(biāo)志位置1。

共享內(nèi)存空間的建立是實現(xiàn)高速網(wǎng)絡(luò)鏈路數(shù)據(jù)包捕獲方法的關(guān)鍵。如圖1所示，底層數(shù)據(jù)包獲取驅(qū)動模塊負(fù)責(zé)寫入數(shù)據(jù)包到共享內(nèi)存，流量監(jiān)測分析程序調(diào)用上層應(yīng)用API接口讀取數(shù)據(jù)包進行統(tǒng)計和分析，這種情況可視為簡單的單生產(chǎn)者多消費者問題。為避免引入鎖機制帶來的額外開銷，系統(tǒng)實現(xiàn)了免鎖算法，簡言之其通過讀寫指針的協(xié)調(diào)管理來實現(xiàn)，底層數(shù)據(jù)包獲取驅(qū)動模塊移動寫指針，流量監(jiān)測分析程序移動讀指針。每當(dāng)讀指針試圖超越寫指針時就停止讀取動作，掛起讀取進程；反之亦然。通過底層數(shù)據(jù)包獲取驅(qū)動模塊直接向共享內(nèi)存數(shù)據(jù)信息域順序循環(huán)寫入數(shù)據(jù)，而位于用戶空間的應(yīng)用程序調(diào)用上層應(yīng)用API接口訪問共享內(nèi)存，達(dá)到數(shù)據(jù)包內(nèi)存零拷貝和消除系統(tǒng)調(diào)用開銷的目的。

2．2．3上層應(yīng)用API接口

類似Libpcap所提供的API接口，上層應(yīng)用API接口提供了一系列基本功能接口函數(shù)。支持的功能主要包括：a)流量監(jiān)測分析程序向底層數(shù)據(jù)包獲取驅(qū)動模塊注冊信息；b)打開高速網(wǎng)絡(luò)數(shù)據(jù)包捕獲設(shè)備；c）設(shè)置數(shù)據(jù)包捕獲設(shè)備的默認(rèn)訪問參數(shù)，將共享內(nèi)存映射到流量監(jiān)測分析程序；d）用戶可配置數(shù)據(jù)包捕獲設(shè)備的訪問參數(shù)，包括數(shù)據(jù)包讀取的輪詢時間、最大等待時間和最低可返回數(shù)據(jù)量；e）獲取數(shù)據(jù)包捕獲設(shè)備的訪問參數(shù)信息；f）獲取共享內(nèi)存大小和實時利用率信息；g）從數(shù)據(jù)包捕獲設(shè)備中讀取數(shù)據(jù)包并返回當(dāng)前數(shù)據(jù)包指針；h）標(biāo)志數(shù)據(jù)包為已處理狀態(tài)，移動當(dāng)前指針到下一數(shù)據(jù)包；i）取消共享內(nèi)存到流量監(jiān)測分析程序的內(nèi)存映射；j）關(guān)閉數(shù)據(jù)包捕獲設(shè)備；k）流量監(jiān)測分析程序向底層數(shù)據(jù)包獲取驅(qū)動模塊注銷信息。

利用上述API接口提供的功能，可以實現(xiàn)在用戶空間開發(fā)高性能的流量監(jiān)測分析程序。在滿足高性能和便捷性的同時，相比基于內(nèi)核模塊的實現(xiàn)方法，應(yīng)用此方法在用戶空間實現(xiàn)流量監(jiān)測程序可大大降低對程序開發(fā)人員的技能要求，使得開發(fā)人員可集中更多的精力在數(shù)據(jù)的統(tǒng)計分析和顯示部分，有利于縮短軟件開發(fā)時間，降低開發(fā)成本。

3實驗結(jié)果分析

為了驗證本文所提出方法，在本章中對比了Libpcap工具、基于內(nèi)核模塊的數(shù)據(jù)包捕獲方法和基于多空間內(nèi)存共享的數(shù)據(jù)包捕獲方法的性能。具體配置如表2所示。

需要特別強調(diào)的是，按照上述配置在高速鏈路環(huán)境下接收數(shù)據(jù)包，PCI總線等硬件因素不會成為性能瓶頸所在。實驗中使用的PC服務(wù)器為x86體系結(jié)構(gòu)，支持64位PCIX總線，主頻133 MHz，計算可得PCIX總線帶寬為133 MHz×64 bit =8 925 478 912 bps＝8.312 5 Gbps。由于在實驗過程中PCIX總線上未安裝除千兆網(wǎng)卡以外的任何設(shè)備，可以確定PCIX總線帶寬不可能成為數(shù)據(jù)包捕獲的性能瓶頸。同時，采用的Linux版本支持NAPI并在實驗過程中開啟對NAPI的支持。

3．1數(shù)據(jù)包捕獲能力測試

實驗1對比Libpcap工具、基于內(nèi)核模塊的數(shù)據(jù)包捕獲方法和基于多空間內(nèi)存共享的數(shù)據(jù)包捕獲方法的數(shù)據(jù)包捕獲能力。

數(shù)據(jù)包處理部分僅實現(xiàn)對捕獲到的每一個數(shù)據(jù)包遞增包計數(shù)器，計算數(shù)據(jù)包捕獲速率；流量發(fā)生器SmartBits 2000的千兆端口發(fā)送64 Byte大小的單播MAC幀，產(chǎn)生不同速率的測試流量。

圖3顯示了隨數(shù)據(jù)包發(fā)送速率的增加三種捕獲方法的數(shù)據(jù)包捕獲能力變化曲線。由此可知，基于多空間內(nèi)存共享的數(shù)據(jù)包捕獲方法性能最優(yōu)，其在千兆鏈路環(huán)境下能夠線速捕獲所有數(shù)據(jù)包；基于內(nèi)核模塊的數(shù)據(jù)包捕獲方法性能稍差，最高數(shù)據(jù)包捕獲速率接近千兆線速達(dá)到148.4萬pps，丟包率約為0．27％；Libpcap工具的性能最低，最高數(shù)據(jù)包捕獲速率僅為18.5萬pps，丟包率約為87.5％。Libpcap工具的性能與另外兩種捕獲方法相比有如此大的差距，分析其原因主要在于Libpcap工具沒有實現(xiàn)數(shù)據(jù)包內(nèi)存零拷貝，大部分系統(tǒng)資源都浪費在中斷開銷、將數(shù)據(jù)包從內(nèi)核空間移動到用戶空間的系統(tǒng)調(diào)用和內(nèi)存拷貝過程中。

3．2數(shù)據(jù)包深度分析能力測試

實驗2對比基于Libpcap工具、基于內(nèi)核模塊的數(shù)據(jù)包捕獲方法和基于多空間內(nèi)存共享的數(shù)據(jù)包捕獲方法的數(shù)據(jù)包深度分析能力。在實驗1中僅比較了三種方法的數(shù)據(jù)包捕獲能力，而沒有考慮到不同捕獲方法的數(shù)據(jù)包捕獲效率。數(shù)據(jù)包捕獲只是實現(xiàn)流量監(jiān)測分析的前提步驟，在捕獲完成后還必須對捕獲得到的數(shù)據(jù)包作大量的分析處理和相關(guān)統(tǒng)計等，這些都會消耗大量的計算資源。若數(shù)據(jù)包捕獲工具在執(zhí)行數(shù)據(jù)包捕獲的過程中消耗了大部分系統(tǒng)資源，而僅剩余小部分的系統(tǒng)資源用于對捕獲到的數(shù)據(jù)包的分析處理和相關(guān)統(tǒng)計，結(jié)果可想而知，這就會造成一方面是系統(tǒng)花費了大量的開銷用于數(shù)據(jù)包捕獲；另一方面是底層捕獲到的數(shù)據(jù)包由于上層處理程序的處理能力不足而被丟棄，導(dǎo)致系統(tǒng)浪費大量的資源作無用功，無法真正提高流量監(jiān)測分析程序的性能。因此，在比較數(shù)據(jù)包捕獲工具的性能時必須考慮到數(shù)據(jù)包捕獲效率指標(biāo)。實驗2修改了實驗1中的數(shù)據(jù)包處理部分，增加處理每個數(shù)據(jù)包的計算量，模擬實際流量監(jiān)測分析程序中復(fù)雜的數(shù)據(jù)包統(tǒng)計和分析處理運算。由于不同流量監(jiān)測分析程序的數(shù)據(jù)包處理計算復(fù)雜度不盡相同，為了使實驗結(jié)果更易于比較，采用查看數(shù)據(jù)包的前20 Byte；并將每個字節(jié)視為一無符號整形數(shù)，依次執(zhí)行連加、連減和連乘運算（連乘運算中忽略零值），模擬流量監(jiān)測分析程序的數(shù)據(jù)包處理運算。

使用修改后的程序重新測試對比了基于三種捕獲方法的數(shù)據(jù)包深度分析能力，流量發(fā)生器所發(fā)送的數(shù)據(jù)包同實驗1。圖 4顯示了隨數(shù)據(jù)包發(fā)送速率的增加三種捕獲方法的數(shù)據(jù)包深度分析能力變化曲線。在三種捕獲方法中依然是基于多空間內(nèi)存共享的數(shù)據(jù)包捕獲方法的數(shù)據(jù)包處理能力最優(yōu)，能夠線速捕獲并處理全部數(shù)據(jù)包；基于內(nèi)核模塊的數(shù)據(jù)包捕獲方法的性能居中，最高數(shù)據(jù)包捕獲速率達(dá)到110.7萬pps，丟包率約為25％；Libpcap 工具性能最低，最高數(shù)據(jù)包捕獲速率僅為18.5萬pps，丟包率約為87.5％。

基于多空間內(nèi)存共享的數(shù)據(jù)包捕獲方法與基于內(nèi)核模塊的數(shù)據(jù)包捕獲方法相比，在性能上提升了約34.4％。分析其原因在于前者必須在內(nèi)核空間中為接收到的每一個數(shù)據(jù)包動態(tài)分配、釋放臨時緩存，產(chǎn)生大量的內(nèi)存管理相關(guān)的系統(tǒng)調(diào)用開銷。由于所有的數(shù)據(jù)包都進入位于操作系統(tǒng)內(nèi)核的TCP/IP協(xié)議棧，為所有待處理的數(shù)據(jù)包排隊、維護數(shù)據(jù)包處理隊列的開銷也是相當(dāng)可觀的。

圖5比較了實驗1和2中基于內(nèi)核模塊的數(shù)據(jù)包捕獲方法的處理能力。從圖中發(fā)現(xiàn)處理能力下降較大，原因在于高速網(wǎng)絡(luò)鏈路環(huán)境下基于內(nèi)核模塊的數(shù)據(jù)包捕獲方法會占用較多的系統(tǒng)資源，造成與上層數(shù)據(jù)包處理程序相互競爭資源，從而影響數(shù)據(jù)包的深度分析能力。

綜上所述，采用共享內(nèi)存與NAPI技術(shù)相結(jié)合的方式，基于多空間內(nèi)存共享的數(shù)據(jù)包捕獲方法能夠?qū)?shù)據(jù)包深度分析能力提升約34.4％，其完全能夠滿足千兆鏈路的監(jiān)測需求，在千兆最小包情況下的處理能力也可以達(dá)到線速148.8萬pps。

4結(jié)束語

本文針對高速網(wǎng)絡(luò)鏈路的監(jiān)測需求，提出了一種基于多空間內(nèi)存共享的數(shù)據(jù)包捕獲方法。與已有方法相比其具有如下優(yōu)勢：a）共享內(nèi)存的實現(xiàn)消除了為每個數(shù)據(jù)包臨時分配、釋放緩存的系統(tǒng)調(diào)用開銷，實現(xiàn)數(shù)據(jù)包內(nèi)存零拷貝；b）提供可以在用戶空間調(diào)用的高性能數(shù)據(jù)包訪問接口，使得在用戶空間開發(fā)高性能的流量監(jiān)測分析程序成為可能；c）基于通用硬件平臺和開源軟件的實現(xiàn)方式可以大大降低開發(fā)成本，有利于開拓市場。從實驗結(jié)果上看，該方法能夠大幅提高數(shù)據(jù)包捕獲性能，達(dá)到千兆甚至更高速率下網(wǎng)絡(luò)鏈路的監(jiān)測需求。

參考文獻(xiàn)：

［1］DEGIOANNI L， BALDI M， RISSO F，et al.Profiling and optimization of softwarebased networkanalysis applications[C]//Proc of the 15th Symposium on Computer Architecture and High Performance Computing.Sao Paulo:[s.n.]，2003.

[2]Agilent Corporation[EB/OL].[2007－0312].http://www.home.agilent.com.

[3]InMon Corporation[EB/OL].[2007－0312].http://www.inmon.com.

[4]University of Waikato.The DAG project[EB/OL]. [2007－0312]. http://www.endace.com/.

[5]SHAH N.Understanding network processor[D].Berkeley: University of California， 2001.

[6]Ethereal Inc[EB/OL].(2007－03－01).[2007－0312]. http://www.ethereal.com.

[7]Wireshark Inc[EB/OL].(2007－01－28).[2007－0312]. http://www.wireshark.org.

[8]The Tcpdump Group[EB/OL]. (2006－0919).[2007－0312].http://www.tcpdump.org.

[9]WELTE H.The netfilter framework in Linux 2.4[C]//Proc of Linux Kongress 2000.Erlanger:[s.n.]，2000. [10]DERI L.Improving passive packet capture:beyond device polling[C]//Proc of SANE 2004.Amsterdam，Netherlands:[s.n.]，2004.

[11]ALEXEY K.NAPIhowto.txt[EB/OL].(2002－0216).[2007－0312].http://lwn.net/2002/0321/a/napihowto.php3.

[12]MOGUL J C，REMAKRISHNAN K K.Eliminating receive livelock in an interruptdriven kernel[J].ACM Transactions on Computer System，1997，15(3):217－252.

[13]RIZZO L.Device polling support for FreeBSD[C]//Proc of BSDCon Europe Conference.Brighton:[s.n.]，2001.

[14]Open Source Technology Group [EB/OL]. [2007－0312].http://sourceforge.net/projects/e1000/.

[15]DERI L.Passively monitoring networks at gigabit speeds using commodity hardware and open source software[C]//Proc of PAM. San Diego， California:[s.n.]，2003.

[16]DEGIOANNI L，VARENNI G.Introducing scalability in network measurement:toward 10Gbps with commodity hardware[C]//Proc of IMC’04.Silicy:[s.n.]，2004:25－27.

“本文中所涉及到的圖表、注解、公式等內(nèi)容請以PDF格式閱讀原文”