Winpcap的體系結(jié)構(gòu)與性能研究*

楊 虹，陳 威

（重慶郵電大學(xué)，重慶 400065）

網(wǎng)絡(luò)分析軟件通常依賴底層調(diào)用抓取數(shù)據(jù)包，進行數(shù)據(jù)包監(jiān)視或流量分析等。大多數(shù)的Unix系統(tǒng)都提供這些功能（至少是數(shù)據(jù)包抓取），而Windows提供的這些功能卻不令人滿意。Windows提供了一些與各種內(nèi)核組件相關(guān)的API，但這些API存在嚴重的缺陷，如并不是所有的Netmon API都可用，而且其擴展存在很多限制。IP過濾驅(qū)動程序（IP filterdriver）只存在 Windows 2000及以上系統(tǒng)中，而且它只支持IP協(xié)議，雖然它能夠控制和丟棄數(shù)據(jù)包但卻不能監(jiān)測和構(gòu)造數(shù)據(jù)包。PCAUSA提供了一個商業(yè)產(chǎn)品，該產(chǎn)品含有數(shù)據(jù)包捕獲和BPF兼容的過濾器，然而它的用戶接口處于底層且沒有提供過濾器構(gòu)造這樣的抽象方法。隨著原本在Unix系統(tǒng)上的應(yīng)用不斷轉(zhuǎn)向Windows系統(tǒng)，這些特性的缺失成了不可忽視的問題。

本文主要介紹一個強大可擴展的Win32平臺的網(wǎng)絡(luò)監(jiān)聽框架系統(tǒng)Winpcap的結(jié)構(gòu)及其功能。該體系結(jié)構(gòu)填補了Unix和Windows間網(wǎng)絡(luò)監(jiān)聽能力的間隔，使得Unix應(yīng)用到Windows的移植更簡單，而且Winpcap把性能放在最首位，使其能滿足更苛刻的需求。

1 Winpcap的體系結(jié)構(gòu)

Winpcap的基本結(jié)構(gòu)如圖1所示，由1個過濾引擎、2個緩沖區(qū)（內(nèi)核層與用戶層）以及一系列供開發(fā)人員使用的組件庫組成。盡管Libpcap具有穩(wěn)固的結(jié)構(gòu)并且功能強大，但Winpcap在結(jié)構(gòu)和數(shù)據(jù)捕獲上仍然有自己獨到的地方，而且甚至可以認為是對Libpcap的創(chuàng)新。

圖1 Winpacp的體系結(jié)構(gòu)

Winpcap的過濾可從用戶層開始（與Libpcap兼容），開發(fā)人員可以自定義包過濾條件 （如picks up all udp packets）；Winpcap會把它們編譯成一些虛擬指令 （如 if the packet is ip and the protocol type field is equal to 17，then return true），同時把這些虛擬指令發(fā)送到過濾引擎，并且激活這些功能。要實現(xiàn)這些目的，內(nèi)核模塊必須能夠執(zhí)行指令，因此需要一個“虛擬BPF”用來在每個接收的數(shù)據(jù)包執(zhí)行這些虛擬代碼。其中內(nèi)核層的過濾引擎是獲得高性能的關(guān)鍵。

NPF與BPF在體系上最大的不同是對循環(huán)緩沖區(qū)的使用選擇[1]。Winpcap每次復(fù)制一部分數(shù)據(jù)包，Winpcap的緩沖區(qū)不再是固定大小 （Libpcap的內(nèi)核緩沖區(qū)與用戶緩沖區(qū)都是32 KB），而且在將數(shù)據(jù)包從內(nèi)核緩沖區(qū)復(fù)制到用戶緩沖區(qū)的過程中對數(shù)據(jù)包進行更新，而不是復(fù)制完后更新。在復(fù)制過程中，將已經(jīng)傳送的數(shù)據(jù)包所占用的空間立即釋放，因為盡管Winpcap工作在較高的優(yōu)先級并且可能一直壟斷CPU，但內(nèi)核層的捕獲程序可能會中斷復(fù)制過程。只要交換緩沖區(qū)允許占用一般的內(nèi)存，Winpcap的緩沖區(qū)就可以存放大量的數(shù)據(jù)包。

內(nèi)核緩沖區(qū)僅通過一個read函數(shù)就可以完全復(fù)制，這可以減少大量的系統(tǒng)調(diào)用并且避免程序在內(nèi)核層與用戶層之間頻繁切換。因為環(huán)境的切換之前必須保存任務(wù)狀態(tài)（CPU描述符與任務(wù)狀態(tài)大約有幾百個字節(jié)），頻繁切換會導(dǎo)致CPU使用率下降。

Winpcap的內(nèi)核緩沖區(qū)比 BPF的要大（為 1 MB），因為較小的內(nèi)核緩存也會帶來一些問題，特別是當程序無法與捕獲數(shù)據(jù)包的驅(qū)動程序的速度保持一致情況下，這種情況在將數(shù)據(jù)發(fā)往硬盤或網(wǎng)絡(luò)數(shù)據(jù)量激增的情況下很常見。相反，用戶緩沖區(qū)需要小一些，通常情況下為256 KB。內(nèi)核緩沖區(qū)與用戶緩沖區(qū)都可以在運行時調(diào)整。

用戶緩沖區(qū)的大小至關(guān)重要，因為它決定了僅通過一個調(diào)用最多可以從內(nèi)核讀多少數(shù)據(jù)，同時，一次從內(nèi)核中至少應(yīng)該讀多少數(shù)據(jù)也很重要。如果給出一個較大的值，則內(nèi)核可以在數(shù)據(jù)送往用戶緩沖區(qū)之前等待足夠多的數(shù)據(jù)包到達，這可以減少一些系統(tǒng)調(diào)用。如果給出一個較小的值，則意味著內(nèi)核可以將數(shù)據(jù)包盡快送往用戶緩存。這對那些實時性要求比較高的應(yīng)用來說很重要，一個好的捕獲引擎會在兩者之間做出好的平衡。NPF是可配置的，讓用戶選擇程序具有好的執(zhí)行效率或快速的反應(yīng)。而Winpcap提供了一組函數(shù)可以設(shè)置數(shù)據(jù)包讀延時和數(shù)據(jù)包拷貝的最小值。當讀延時或內(nèi)核緩沖區(qū)獲得的數(shù)據(jù)包數(shù)據(jù)量滿足了最小值，數(shù)據(jù)都會被送往用戶緩沖區(qū)。延時默認設(shè)置為1 s，最小數(shù)據(jù)量設(shè)置為16 KB，這種功能被稱之為“延遲寫入”。

1.1 統(tǒng)計模式

包捕獲與網(wǎng)絡(luò)分析會過多占用CPU，因為有大量的數(shù)據(jù)需要處理和拷貝。提高執(zhí)行速度最常用的方法是提高過濾引擎的速度與一次拷貝結(jié)構(gòu)，這種方法是通過將內(nèi)核緩沖區(qū)映射到程序內(nèi)存來實現(xiàn)。一次拷貝的操作會減少數(shù)據(jù)的拷貝，但并不會減少內(nèi)核層與用戶層之間的系統(tǒng)調(diào)用。如果用戶一次讀一個數(shù)據(jù)包，環(huán)境切換的代價會抵消一次拷貝所帶來的好處。

一種新的方法是監(jiān)視時并不將數(shù)據(jù)包送往用戶層，而是Winpcap將監(jiān)視的功能放在內(nèi)核層，這樣就可以避免數(shù)據(jù)送往用戶層。Winpcap提供了一種嵌入在NPF過濾引擎中的可編程的統(tǒng)計模式，可以使過濾器成為強大的分類器而不僅僅是過濾器。應(yīng)用程序可以使用這個模塊監(jiān)視任意的網(wǎng)絡(luò)行為（如網(wǎng)絡(luò)下載、兩臺主機間的網(wǎng)絡(luò)流量、每秒鐘的網(wǎng)頁訪問數(shù)量），并且可以在預(yù)先設(shè)定的時間間隔獲得這些結(jié)果。

統(tǒng)計模式避免了數(shù)據(jù)拷貝，并且實行0拷貝模式（統(tǒng)計行為在數(shù)據(jù)包到達網(wǎng)卡驅(qū)動的存儲區(qū)時執(zhí)行，之后數(shù)據(jù)包被丟棄），所以不需要緩沖區(qū)。統(tǒng)計模式是監(jiān)視網(wǎng)絡(luò)的一種極為有效的方法，且能在高速網(wǎng)絡(luò)中表現(xiàn)出良好的性能。

Winpcap為開發(fā)人員提供了一組高層調(diào)用可以很容易地使用統(tǒng)計模式，對那些習(xí)慣了Libpcap的開發(fā)人員來說很容易掌握。

1.2 數(shù)據(jù)包注入

BPF與NPF都提供了直接發(fā)送原始包的功能，可以將數(shù)據(jù)包直接發(fā)送到網(wǎng)絡(luò)中。但是Libpcap并沒有使用這些調(diào)用，而BPF也并不是用于此目的。大多數(shù)Unix系統(tǒng)都提供了直接發(fā)送原始包的功能，而Windows只有2000才提供了此功能，且功能受限。因此，Winpcap是Win32平臺上第一標準的而且可靠的發(fā)送原始包的類庫。NPF提供了許多新的函數(shù)可以發(fā)送多個數(shù)據(jù)包而只在內(nèi)核層與用戶層之間切換一次。

Winpcap雖然提供了很多函數(shù)可以去開發(fā)這些新的功能（但并沒有直接提供這些功能），它需要開發(fā)人員手工構(gòu)造數(shù)據(jù)包或利用已有的工具。而用戶可以使用Libnet Packet Assembly Library（即在 Winpcap上加了一層功能），就可以構(gòu)造數(shù)據(jù)包并發(fā)送到網(wǎng)絡(luò)中。

2 性能分析

主要是對Winpcap的性能進行測試，用Winpcap在Windows98與Windows2000下的表現(xiàn)與Libpcap/BPF在FreeBSD下的表現(xiàn)進行比較。

圖2為兩臺主機直接相連，以排除外部數(shù)據(jù)包的干擾，使實驗結(jié)果更精確。一臺主機是Windows2000操作系統(tǒng)，使用基于Winpcap的工具產(chǎn)生大量的數(shù)據(jù)包發(fā)送到網(wǎng)絡(luò)中，并保證高速率。數(shù)據(jù)包的大小選擇，是以保證每秒所產(chǎn)生的數(shù)據(jù)包都能夠達到一個極限值。

圖2 測試中使用測試平臺

操作系統(tǒng)安裝在同一臺主機上的不同硬盤分區(qū)上，以避免由于硬件原因帶來的差異。數(shù)據(jù)包被發(fā)送到不同的主機上，這樣可以使兩臺主機之間不用進行交互。接收端的主機網(wǎng)卡設(shè)置為混雜模式，根據(jù)測試主題的不同而用不同的工具捕獲數(shù)據(jù)包。根據(jù)測試需要，數(shù)據(jù)包收到后或丟棄、或傳送給應(yīng)用程序、或存儲在硬盤中。

FreeBSD的CPU負載可以在TOP PROGRAM查看，Windows2000可以通過任務(wù)管理器查看，Windows98則可以用CPUMETER查看（可以從網(wǎng)上獲得）。

被測試的軟件都是最新的發(fā)行版，Winpcap的內(nèi)核緩沖區(qū)為1 MB，Libpcap的緩沖區(qū)被設(shè)置為2個512 KB大小的空間（默認為32 KB）。

這些實驗將努力避免其他軟件對實驗結(jié)果的影響，但是結(jié)果并不能準確地表現(xiàn)出單獨組件的性能，因為不同的組件不交互基本上是不可能的。

2.1 發(fā)送實驗

發(fā)送實驗是測試發(fā)送性能，只在Windows2000下進行（95/98沒有對這個功能做優(yōu)化）。圖3顯示了當每個包都為88 B的情況下達到每秒發(fā)送的最大值 （原認為在每個包為64 B的情況下會達到最大值），這出乎意料。因為測試并不依賴NPF，CPU的負載始終沒有達到100%，這也說明了NPF并不是瓶頸所在。當數(shù)據(jù)包為400 B時網(wǎng)絡(luò)達到全速。

經(jīng)實驗發(fā)現(xiàn)發(fā)送能力更多依賴于網(wǎng)卡，當更換網(wǎng)卡、并在相同情況下進行測試時，發(fā)送速度只能達到每秒30 000個包。

2.2 接收與過濾實驗

接收與過濾能力實驗測試：數(shù)據(jù)包被網(wǎng)絡(luò)接口接收并被過濾器檢查，如果所有的包都不會滿足過濾條件，它們將在檢查后被丟棄（不會被拷貝）。

測試在兩種情況下進行：第一種使用3條BPF虛擬指令；第二種使用13條復(fù)雜的BPF虛擬指令。

圖4為網(wǎng)絡(luò)分離和過濾性能，幾乎所有的包都被接受并沒有被過濾器檢查。Windows98的CPU負載明顯高于Windows2000（但是也在可以接受的范圍內(nèi)）FreeBSD表現(xiàn)很差，只捕獲大約一半的數(shù)據(jù)包，而且CPU負載始終較高。

2.3 向應(yīng)用程序傳送數(shù)據(jù)包的測試

測試應(yīng)用程序從Winpcap接收數(shù)據(jù)包的能力 （收到后直接丟棄，并不做進一步的處理），檢驗整個Winpcap體系的功能，包括數(shù)據(jù)從網(wǎng)卡復(fù)制到內(nèi)核緩沖區(qū)再到用戶緩沖區(qū)，而且將不使用過濾功能。圖5為測試結(jié)果，Winpcap幾乎可以將所有從網(wǎng)絡(luò)接口獲得的數(shù)據(jù)全部送至應(yīng)用程序，沒有數(shù)據(jù)包在內(nèi)核緩沖區(qū)被丟棄。而FreeBSD并不能做到這些，特別是在高數(shù)據(jù)率的情況下，大部分的數(shù)據(jù)包在沒有到達過濾器之前已被丟棄。

無論在Windows2000還是FreeBSD中，CPU的負載都隨著數(shù)據(jù)包容量的增大而降低，Windows98因為沒有延遲寫入的能力而表現(xiàn)一般。

2.4 程序性能實驗

實驗將使用基于Winpcap的工具將獲得的數(shù)據(jù)包轉(zhuǎn)存在文件中，結(jié)果如圖6所示。程序?qū)⒚總€數(shù)據(jù)包的68 B的內(nèi)容存到文件中。所有的系統(tǒng)在高數(shù)據(jù)率的情況下都會丟失一些數(shù)據(jù)包：一部分是因為恪守CPU時間（當一個數(shù)據(jù)包到達時，程序卻還在處理前面的包）；另一部分則因為內(nèi)核緩沖區(qū)沒有足夠的空間去存放數(shù)據(jù)包。圖7為整個數(shù)據(jù)包被寫入文件時的結(jié)果。

監(jiān)視實驗在AD-HOC網(wǎng)絡(luò)上進行。實驗結(jié)果表明CPU負載一直維持在較低的水平，而且結(jié)果與圖4相類似。圖5顯示了在用戶層監(jiān)視的代價遠高于內(nèi)核層，這些多余的代價會給用戶層監(jiān)視的性能帶來折扣。另外，用戶層的監(jiān)視需要大容量的緩沖區(qū)。

3 Winpcap的改進意見

根據(jù)實驗結(jié)果與體系結(jié)構(gòu)的特點，采取了如下相應(yīng)的改進措施：

3.1 過濾引擎改進

因為采用動態(tài)代碼生成技術(shù)對BPF進行改進，使BPF性能取得明顯效果，因此對NPF也進行了類似的改進，采用 JIT（Just In Time）技術(shù)，將過濾代碼翻譯成X86的二進制代碼，這項改進使整體的捕獲性能提高了約8%。

3.2 內(nèi)存拷貝

因數(shù)據(jù)包從網(wǎng)卡到程序需要進行兩次拷貝過程，而第一次拷貝（從網(wǎng)卡到內(nèi)核緩沖區(qū)）的代價明顯高于第二次拷貝，一個重要的原因是 NdisTransferData（）函數(shù)進行了額外的操作。但是同時，在研究過程中也注意到一些網(wǎng)絡(luò)控制器（尤其是一些大型的網(wǎng)絡(luò)適配器）是在通知網(wǎng)卡驅(qū)動之前將數(shù)據(jù)包拷貝到內(nèi)存中的，因此NPF驅(qū)動可以在同一內(nèi)存區(qū)接收數(shù)據(jù)包。在這種情況下，可以使用C標準庫的函數(shù)來實現(xiàn)這個功能。

3.3 時間戳

用于產(chǎn)生微妙級精確度時間戳的KeQueryPerformanceCounter函數(shù)可以被Inter處理器中集成的 TSC（Time Stamp Counter）取代，TSC的精度與 CPU頻率相同。X86的指令集提供了一條指令來取得時間戳（rdtsc），這項改進可以使整體性能提升27%左右。但是標準的NPF發(fā)現(xiàn)版并沒有使用這項改進，因為這項指令需要硬件支持 （只在Inter處理器或與Inter處理器兼容的處理器上才能運行）[2]。

3.4 Tap函數(shù)優(yōu)化

Tap函數(shù)中同樣用到了 NdisTransferData（）函數(shù)，而該函數(shù)運行時要求分配一塊存儲區(qū)去使某個數(shù)據(jù)結(jié)構(gòu)可以用來存放要傳送的數(shù)據(jù)包，這個操作在數(shù)據(jù)包傳送完畢時可能會導(dǎo)致回調(diào)函數(shù)的調(diào)用中斷。同樣也可以用C標準庫的函數(shù)替代它。這項改進可以使整體性能提升5%左右。

3.5 硬件優(yōu)化

由于很多開銷是在捕獲過程之外產(chǎn)生的，這就存在硬件優(yōu)化的可能性，如NEW ZEALAND BASED公司推出有專用于網(wǎng)絡(luò)捕獲的芯片。該芯片避免了過多地與操作系統(tǒng)的交互，它可以產(chǎn)生時間戳，而且直接將數(shù)據(jù)包傳送到系統(tǒng)內(nèi)存，用硬件來管理緩沖區(qū)。這樣應(yīng)用程序可以直接取得數(shù)據(jù)而不需要同其他層次打交道。因此，硬件的優(yōu)化可以使基于軟件的捕獲程序性能得到較大的提升。

本文主要針對Winpcap的體系結(jié)構(gòu)及其性能進行研究，并對可能的優(yōu)化措施進行探討。文中的實驗主要是對Winpcap的各個部分的性能進行測試，與一般的看法不同，過濾和緩沖區(qū)并不是影響整體性能的最重要的部分。對這兩部分的優(yōu)化，引起了很多的關(guān)注，但是針對它們的改進相對整體的性能提升并沒有明顯的幫助，特別是在數(shù)據(jù)包比較小的情況下。經(jīng)一系列實驗說明，真正的瓶頸在那些隱藏的地方，如設(shè)備驅(qū)動程序、應(yīng)用程序與操作系統(tǒng)的交互、操作系統(tǒng)與硬件之間的交互。

數(shù)據(jù)捕獲是由很多組件配合完成的工作。所以，在對其性能進行優(yōu)化這個問題上，要從全局考慮，而不應(yīng)該僅僅局限在某個組件。實驗說明了一些大量優(yōu)化操作都集中在沒什么提升潛力的地方（如過濾引擎和緩沖區(qū)優(yōu)化），而真正值得關(guān)注的地方卻并沒有引起足夠的重視。同時，即使所有涉及到的技術(shù)都很成熟，但性能提升還是有很大的空間，希望本文能給同行提供一些新的視角。

[1]DEGIOANNI L， BALDI M， RISSO F， et al.Profiling and optimization of software-based network-analysis applications proceedings[C]. The 15thIEEE Symposium on Computer Architecture and High Performance Computing （SBAC-PAD 2003） Sao Paulo， Brazil， November 2003：3-5.

[2]RISSO F，DEGIOANNI L.An architecture for high performance network analysis[C].Proceedings of the 6th IEEE Symposium on Computers and Communications （ISCC 2001）， Hammamet，Tunisia， July 2001：2-7.