摘  要： Winpcap有一系列創(chuàng)新（如數據包監(jiān)視和數據包注入）的特點，這在以前的操作系統(tǒng)中是見不到的。介紹了Winpcap的系統(tǒng)結構及其功能。
關鍵詞： Winpcap；數據包監(jiān)測；數據包注入

    網絡分析軟件通常依賴底層調用抓取數據包，進行數據包監(jiān)視或流量分析等。大多數的Unix系統(tǒng)都提供這些功能（至少是數據包抓取），而Windows提供的這些功能卻不令人滿意。Windows提供了一些與各種內核組件相關的API，但這些API存在嚴重的缺陷，如并不是所有的Netmon API都可用，而且其擴展存在很多限制。IP過濾驅動程序（IP filter driver）只存在Windows 2000及以上系統(tǒng)中，而且它只支持IP協(xié)議，雖然它能夠控制和丟棄數據包但卻不能監(jiān)測和構造數據包。PCAUSA提供了一個商業(yè)產品，該產品含有數據包捕獲和BPF兼容的過濾器，然而它的用戶接口處于底層且沒有提供過濾器構造這樣的抽象方法。隨著原本在Unix系統(tǒng)上的應用不斷轉向Windows系統(tǒng)，這些特性的缺失成了不可忽視的問題。
本文主要介紹一個強大可擴展的Win32平臺的網絡監(jiān)聽框架系統(tǒng)Winpcap的結構及其功能。該體系結構填補了Unix和Windows間網絡監(jiān)聽能力的間隔，使得Unix應用到Windows的移植更簡單，而且Winpcap把性能放在最首位，使其能滿足更苛刻的需求。
1 Winpcap的體系結構
　Winpcap的基本結構如圖1所示，由1個過濾引擎、2個緩沖區(qū)（內核層與用戶層）以及一系列供開發(fā)人員使用的組件庫組成。盡管Libpcap具有穩(wěn)固的結構并且功能強大，但Winpcap在結構和數據捕獲上仍然有自己獨到的地方，而且甚至可以認為是對Libpcap的創(chuàng)新。

　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)這些目的，內核模塊必須能夠執(zhí)行指令，因此需要一個“虛擬BPF”用來在每個接收的數據包執(zhí)行這些虛擬代碼。其中內核層的過濾引擎是獲得高性能的關鍵。
　NPF與BPF在體系上最大的不同是對循環(huán)緩沖區(qū)的使用選擇[1]。Winpcap每次復制一部分數據包，Winpcap的緩沖區(qū)不再是固定大?。↙ibpcap的內核緩沖區(qū)與用戶緩沖區(qū)都是32 KB），而且在將數據包從內核緩沖區(qū)復制到用戶緩沖區(qū)的過程中對數據包進行更新，而不是復制完后更新。在復制過程中，將已經傳送的數據包所占用的空間立即釋放，因為盡管Winpcap工作在較高的優(yōu)先級并且可能一直壟斷CPU，但內核層的捕獲程序可能會中斷復制過程。只要交換緩沖區(qū)允許占用一般的內存，Winpcap的緩沖區(qū)就可以存放大量的數據包。
　內核緩沖區(qū)僅通過一個read函數就可以完全復制，這可以減少大量的系統(tǒng)調用并且避免程序在內核層與用戶層之間頻繁切換。因為環(huán)境的切換之前必須保存任務狀態(tài)（CPU描述符與任務狀態(tài)大約有幾百個字節(jié)），頻繁切換會導致CPU使用率下降。
　Winpcap的內核緩沖區(qū)比BPF的要大（為1 MB），因為較小的內核緩存也會帶來一些問題，特別是當程序無法與捕獲數據包的驅動程序的速度保持一致情況下，這種情況在將數據發(fā)往硬盤或網絡數據量激增的情況下很常見。相反，用戶緩沖區(qū)需要小一些，通常情況下為256  KB。內核緩沖區(qū)與用戶緩沖區(qū)都可以在運行時調整。
　用戶緩沖區(qū)的大小至關重要，因為它決定了僅通過一個調用最多可以從內核讀多少數據，同時，一次從內核中至少應該讀多少數據也很重要。如果給出一個較大的值，則內核可以在數據送往用戶緩沖區(qū)之前等待足夠多的數據包到達，這可以減少一些系統(tǒng)調用。如果給出一個較小的值，則意味著內核可以將數據包盡快送往用戶緩存。這對那些實時性要求比較高的應用來說很重要，一個好的捕獲引擎會在兩者之間做出好的平衡。NPF是可配置的，讓用戶選擇程序具有好的執(zhí)行效率或快速的反應。而Winpcap提供了一組函數可以設置數據包讀延時和數據包拷貝的最小值。當讀延時或內核緩沖區(qū)獲得的數據包數據量滿足了最小值，數據都會被送往用戶緩沖區(qū)。延時默認設置為1 s，最小數據量設置為16 KB，這種功能被稱之為“延遲寫入”。
1.1 統(tǒng)計模式
　包捕獲與網絡分析會過多占用CPU，因為有大量的數據需要處理和拷貝。提高執(zhí)行速度最常用的方法是提高過濾引擎的速度與一次拷貝結構，這種方法是通過將內核緩沖區(qū)映射到程序內存來實現(xiàn)。一次拷貝的操作會減少數據的拷貝，但并不會減少內核層與用戶層之間的系統(tǒng)調用。如果用戶一次讀一個數據包，環(huán)境切換的代價會抵消一次拷貝所帶來的好處。
　一種新的方法是監(jiān)視時并不將數據包送往用戶層，而是Winpcap將監(jiān)視的功能放在內核層，這樣就可以避免數據送往用戶層。Winpcap提供了一種嵌入在NPF過濾引擎中的可編程的統(tǒng)計模式，可以使過濾器成為強大的分類器而不僅僅是過濾器。應用程序可以使用這個模塊監(jiān)視任意的網絡行為（如網絡下載、兩臺主機間的網絡流量、每秒鐘的網頁訪問數量），并且可以在預先設定的時間間隔獲得這些結果。
統(tǒng)計模式避免了數據拷貝，并且實行0拷貝模式（統(tǒng)計行為在數據包到達網卡驅動的存儲區(qū)時執(zhí)行，之后數據包被丟棄），所以不需要緩沖區(qū)。統(tǒng)計模式是監(jiān)視網絡的一種極為有效的方法，且能在高速網絡中表現(xiàn)出良好的性能。
　Winpcap為開發(fā)人員提供了一組高層調用可以很容易地使用統(tǒng)計模式，對那些習慣了Libpcap的開發(fā)人員來說很容易掌握。
1.2 數據包注入
　BPF與NPF都提供了直接發(fā)送原始包的功能，可以將數據包直接發(fā)送到網絡中。但是Libpcap并沒有使用這些調用，而BPF也并不是用于此目的。大多數Unix系統(tǒng)都提供了直接發(fā)送原始包的功能，而Windows只有2000才提供了此功能，且功能受限。因此，Winpcap是Win32平臺上第一標準的而且可靠的發(fā)送原始包的類庫。NPF提供了許多新的函數可以發(fā)送多個數據包而只在內核層與用戶層之間切換一次。
Winpcap雖然提供了很多函數可以去開發(fā)這些新的功能（但并沒有直接提供這些功能），它需要開發(fā)人員手工構造數據包或利用已有的工具。而用戶可以使用Libnet Packet Assembly Library（即在Winpcap上加了一層功能），就可以構造數據包并發(fā)送到網絡中。
2 性能分析
　主要是對Winpcap的性能進行測試，用Winpcap在Windows98與Windows2000下的表現(xiàn)與Libpcap/BPF在FreeBSD下的表現(xiàn)進行比較。
　圖2為兩臺主機直接相連，以排除外部數據包的干擾，使實驗結果更精確。一臺主機是Windows2000操作系統(tǒng)，使用基于Winpcap的工具產生大量的數據包發(fā)送到網絡中，并保證高速率。數據包的大小選擇，是以保證每秒所產生的數據包都能夠達到一個極限值。

　操作系統(tǒng)安裝在同一臺主機上的不同硬盤分區(qū)上，以避免由于硬件原因帶來的差異。數據包被發(fā)送到不同的主機上，這樣可以使兩臺主機之間不用進行交互。接收端的主機網卡設置為混雜模式，根據測試主題的不同而用不同的工具捕獲數據包。根據測試需要，數據包收到后或丟棄、或傳送給應用程序、或存儲在硬盤中。
　FreeBSD的CPU負載可以在TOP PROGRAM查看，Windows2000可以通過任務管理器查看，Windows98則可以用CPUMETER查看（可以從網上獲得）。
　被測試的軟件都是最新的發(fā)行版，Winpcap的內核緩沖區(qū)為1 MB，Libpcap的緩沖區(qū)被設置為2個512 KB大小的空間（默認為32 KB）。
　這些實驗將努力避免其他軟件對實驗結果的影響，但是結果并不能準確地表現(xiàn)出單獨組件的性能，因為不同的組件不交互基本上是不可能的。
2.1 發(fā)送實驗
　發(fā)送實驗是測試發(fā)送性能，只在Windows2000下進行（95/98沒有對這個功能做優(yōu)化）。圖3顯示了當每個包都為88 B的情況下達到每秒發(fā)送的最大值（原認為在每個包為64 B的情況下會達到最大值），這出乎意料。因為測試并不依賴NPF，CPU的負載始終沒有達到100%，這也說明了NPF并不是瓶頸所在。當數據包為400 B時網絡達到全速。

　經實驗發(fā)現(xiàn)發(fā)送能力更多依賴于網卡，當更換網卡、并在相同情況下進行測試時，發(fā)送速度只能達到每秒30 000個包。
2.2 接收與過濾實驗
　接收與過濾能力實驗測試：數據包被網絡接口接收并被過濾器檢查，如果所有的包都不會滿足過濾條件，它們將在檢查后被丟棄（不會被拷貝）。
　測試在兩種情況下進行：第一種使用3條BPF虛擬指令；第二種使用13條復雜的BPF虛擬指令。
　圖4為網絡分離和過濾性能，幾乎所有的包都被接受并沒有被過濾器檢查。Windows98的CPU負載明顯高于Windows2000（但是也在可以接受的范圍內）FreeBSD表現(xiàn)很差，只捕獲大約一半的數據包，而且CPU負載始終較高。

2.3 向應用程序傳送數據包的測試

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

　無論在Windows2000還是FreeBSD中，CPU的負載都隨著數據包容量的增大而降低，Windows98因為沒有延遲寫入的能力而表現(xiàn)一般。
2.4 程序性能實驗
　實驗將使用基于Winpcap的工具將獲得的數據包轉存在文件中，結果如圖6所示。程序將每個數據包的68 B的內容存到文件中。所有的系統(tǒng)在高數據率的情況下都會丟失一些數據包：一部分是因為恪守CPU時間（當一個數據包到達時，程序卻還在處理前面的包）；另一部分則因為內核緩沖區(qū)沒有足夠的空間去存放數據包。圖7為整個數據包被寫入文件時的結果。

2.5 監(jiān)視實驗
　監(jiān)視實驗在AD-HOC網絡上進行。實驗結果表明CPU負載一直維持在較低的水平，而且結果與圖4相類似。圖5顯示了在用戶層監(jiān)視的代價遠高于內核層，這些多余的代價會給用戶層監(jiān)視的性能帶來折扣。另外，用戶層的監(jiān)視需要大容量的緩沖區(qū)。
3 Winpcap的改進意見
　根據實驗結果與體系結構的特點，采取了如下相應的改進措施：
3.1 過濾引擎改進
　因為采用動態(tài)代碼生成技術對BPF進行改進，使BPF性能取得明顯效果，因此對NPF也進行了類似的改進，采用JIT（Just In Time）技術，將過濾代碼翻譯成X86的二進制代碼，這項改進使整體的捕獲性能提高了約8%。
3.2 內存拷貝
　因數據包從網卡到程序需要進行兩次拷貝過程，而第一次拷貝（從網卡到內核緩沖區(qū)）的代價明顯高于第二次拷貝，一個重要的原因是NdisTransferData（）函數進行了額外的操作。但是同時，在研究過程中也注意到一些網絡控制器（尤其是一些大型的網絡適配器）是在通知網卡驅動之前將數據包拷貝到內存中的，因此NPF驅動可以在同一內存區(qū)接收數據包。在這種情況下，可以使用C標準庫的函數來實現(xiàn)這個功能。
3.3 時間戳
　用于產生微妙級精確度時間戳的KeQueryPerformanceCounter函數可以被Inter處理器中集成的TSC（Time Stamp Counter）取代，TSC的精度與CPU頻率相同。X86的指令集提供了一條指令來取得時間戳（rdtsc），這項改進可以使整體性能提升27%左右。但是標準的NPF發(fā)現(xiàn)版并沒有使用這項改進，因為這項指令需要硬件支持（只在Inter處理器或與Inter處理器兼容的處理器上才能運行）[2]。
3.4 Tap函數優(yōu)化
　Tap函數中同樣用到了NdisTransferData（）函數，而該函數運行時要求分配一塊存儲區(qū)去使某個數據結構可以用來存放要傳送的數據包，這個操作在數據包傳送完畢時可能會導致回調函數的調用中斷。同樣也可以用C標準庫的函數替代它。這項改進可以使整體性能提升5%左右。
3.5 硬件優(yōu)化
　由于很多開銷是在捕獲過程之外產生的，這就存在硬件優(yōu)化的可能性，如NEW ZEALAND BASED公司推出有專用于網絡捕獲的芯片。該芯片避免了過多地與操作系統(tǒng)的交互，它可以產生時間戳，而且直接將數據包傳送到系統(tǒng)內存，用硬件來管理緩沖區(qū)。這樣應用程序可以直接取得數據而不需要同其他層次打交道。因此，硬件的優(yōu)化可以使基于軟件的捕獲程序性能得到較大的提升。
　本文主要針對Winpcap的體系結構及其性能進行研究，并對可能的優(yōu)化措施進行探討。文中的實驗主要是對Winpcap的各個部分的性能進行測試，與一般的看法不同，過濾和緩沖區(qū)并不是影響整體性能的最重要的部分。對這兩部分的優(yōu)化，引起了很多的關注，但是針對它們的改進相對整體的性能提升并沒有明顯的幫助，特別是在數據包比較小的情況下。經一系列實驗說明，真正的瓶頸在那些隱藏的地方，如設備驅動程序、應用程序與操作系統(tǒng)的交互、操作系統(tǒng)與硬件之間的交互。
　數據捕獲是由很多組件配合完成的工作。所以，在對其性能進行優(yōu)化這個問題上，要從全局考慮，而不應該僅僅局限在某個組件。實驗說明了一些大量優(yōu)化操作都集中在沒什么提升潛力的地方（如過濾引擎和緩沖區(qū)優(yōu)化），而真正值得關注的地方卻并沒有引起足夠的重視。同時，即使所有涉及到的技術都很成熟，但性能提升還是有很大的空間，希望本文能給同行提供一些新的視角。
參考文獻
[1] DEGIOANNI L， BALDI M， RISSO F， et al. Profiling and optimization of software-based network-analysis applications proceedings[C].  The 15th IEEE Symposium on Computer Architecture and High Performance Computing （SBAC-PAD 2003） Sao Paulo， Brazil， November 2003：3-5.