摘 要： 提出一種針對高速光網絡環境的數據包捕獲平臺的設計方案。采用軟硬件結合" title="軟硬件結合">軟硬件結合的設計思想，由系統硬件完成數據包的解析和過濾，軟件根據硬件解析結果將數據直接向應用進程分發。驅動部分借鑒了零拷貝和循環緩沖區技術，并進行了中斷優化以降低數據采集的CPU占用率。
關鍵詞： 軟硬件結合 規則? 包捕獲? 64位PCI? OC48接口
?
隨著網絡的普及,安全問題正威脅著每個網絡用戶。因此對計算機的網絡監控十分必要,而其中對網絡數據包的捕獲和分析尤為重要。隨著網絡帶寬不斷增加,監控高速網絡數據流的需求越來越明顯,各種數據包捕獲技術在大規模寬帶網絡的入侵檢測系統[1]、大流量網絡數據情況下的網絡協議分析、寬帶網絡防火墻和高性能路由器等領域中,都具有廣泛的應用前景。
1 傳統方案
傳統的數據包捕獲方案一般是基于普通的網卡,通過應用程序和支持庫把網卡設置成混雜模式[2],從而繞開網卡通常的工作程序,使之能夠接受目標地址而不是自己MAC地址的數據包,再經過過濾、解析實現監控。
目前實現包捕獲功能的軟件有很多。支持Linux操作系統的Libpcap[3]庫就是基于BPF模型一個典型數據包捕獲平臺。Libpcap 實質上是一個系統獨立的 API 函數接口,用于用戶層次的數據包截獲工作。它為底層網絡監控編程提供了易于移植的應用框架。利用Libpcap庫開發的網絡監控的工具如Tcpdump[3]等,大多有效地利用了庫中的接口實現了按需捕獲功能。但是總體上來看,這些工具由于設計上的限制,即使工作在非常強大的硬件平臺上,在面對現代高速網絡時也越來越難以應付,特別是在快于千兆的光網絡環境中,常常因為來不及處理導致丟包相當嚴重。
2 改進方案概述
這是一種采用軟硬件結合的高速數據包捕獲實現方案。為了能適用于高速光網絡環境,硬件部分完成了對實時性要求高的數據包的預處理工作,軟件部分在后期能夠對數據包進行再次的深度處理。整個系統硬件的關鍵在包解析處理模塊" title="處理模塊">處理模塊和規則管理模塊。包解析處理模塊實現了數據包的預處理;規則管理模塊則用于規則存儲和查找,包解析處理模塊對數據包的過濾有賴于查找的結果。基于硬件配置的靈活性,可以在前期就將未匹配成功、校驗出錯、太短或太長等不符合要求的數據包丟棄,后期處理階段可以專注于對有處理需求的數據包進行解析,極大地提高了整個系統的性能。另外,由于目前大部分寬帶IP網的地市級出口基本上都是由2.5Gbps POS(Packet Over SONET)鏈路組成,每個設備采用了兩路2.5Gbps OC48 POS接口作為數據輸入;而輸出端采用了64 bit 66MHz的PCI總線設計,從而在主機一側保證帶寬。為了適應更高的采樣需求,驅動在設計上支持多設備協同工作。
系統軟件部分基于Linux操作系統平臺,由驅動程序和自定義的庫函數組成。驅動程序實現了系統各芯片的初始化,響應上層對規則和硬件配置的要求和維護數據緩沖區等功能。庫函數介于應用程序與驅動程序之間,起到一個橋梁中介作用,主要向上層提供類似Libpcap的API,從而把復雜的處理函數封裝起來,給用戶一個簡潔通用的接口。
考慮到傳統方案主要在網卡中斷、內存操作、用戶態和內核態間的拷貝等方面存在瓶頸,軟件中做了幾項改進:(1)改進了中斷方式,以數據塊" title="數據塊">數據塊而不是以單個數據包觸發中斷,減少了中斷的頻率;(2)借鑒零拷貝的思想,避免了不必要的內存拷貝;(3)利用循環緩沖區(ring buffer)存儲用戶數據, 提高了內存利用率。
3 系統設計及實現
3.1 系統硬件實現
系統利用硬件代替Linux內核實現了數據包的差錯校驗和協議棧的初步解析。一定格式的過濾規則按照優先級存儲于規則管理模塊中,規則管理模塊將包解析模塊從數據包的一些控制字段中抽取出關鍵字同預設的所有規則進行比較,選出優先級最高的匹配規則,匹配的結果反饋給包處理模塊,而沒有匹配到任何規則的數據包會被丟棄。符合要求的數據包被加上一個叫做internal head的自定義頭部。這個自定義頭部包含了這個數據包的長度、協議類型、時間戳和cookie等信息,這里cookie字段是數據包分發的依據。此后驅動程序惟一需要解析的包頭只有自定義頭部,從而降低了軟件處理部分的復雜度。
經過過濾后,符合要求的數據包會被暫存在硬件外部高速存儲器中,同時包處理模塊以中斷的方式通知驅動新數據的到來。為避免頻繁中斷帶來的額外的系統開銷,在設計上采用了以數據塊而不是以數據包的方式來觸發中斷:暫存在硬件外部高速存儲器中的數據達到規定大小時觸發中斷, 數據借助這次中斷通過DMA方式送往主機側。當然,為防止收取不到規定大小的數據塊而造成的死鎖,也就是如果收取的數據在一定時間仍沒有辦法達到這個大小,則采用超時機制強行發出中斷請求,送出剩余的數據。
系統硬件數據處理的整個過程如圖1所示。
3.2 系統軟件實現
本系統在Linux操作系統中被注冊為一個字符設備并共用一個設備號。為了提供對多設備的支持,這里設計了一個全局的私有結構來區分它們,每個結構被用一個單向鏈表管理起來:每當驅動程序找到一個新設備,就給它分配一個新的結構并掛在鏈表上。另外這個結構的另一個用途是作為中斷處理" title="中斷處理">中斷處理函數的dev_id參數,在中斷來時中斷處理函數能夠以此區分不同的設備。
從驅動程序代理用戶進程設置過濾規則到硬件觸發中斷通知驅動程序收取數據包,驅動程序代表整個系統進行一些必要的工作。
整個系統的軟件結構如圖2所示。
3.2.1 用戶規則設置
每個用戶進程在創建初期會在內核中獲取一塊或多塊連續內存塊用來存儲自己所需的數據。考慮到用戶進程可能在數量上會很多,系統初始化時就已經申請好一定數量固定大小的內存塊,并打上id標記等待進程來申請。為了提高內存的利用率,這里利用了循環緩沖區結構來管理每個內存塊。循環緩沖區可以讓驅動程序專心進行數據接收而不用考慮讀進程,同時內存也不會被浪費。為避免頻繁的數據拷貝,借鑒了零拷貝[4](zero-copy)的思想。零拷貝基本思想是:數據包從網絡設備到用戶程序空間傳遞的過程中,減少數據拷貝次數,減少系統調用,在一定程度上實現CPU的零參與。實現零拷貝采用的最主要技術是DMA數據傳輸技術和內存區域映射技術。傳統的網絡數據包過濾處理,需要進行多次數據拷貝,整個過程需要用戶進程向系統發出的系統調用,其中涉及到操作系統大量的上下文切換和CPU的始終參與。零拷貝技術首先利用DMA技術將網絡數據包通過DMA通道直接推入系統內核中一個公共緩沖區,其過程可與主機并行操作,然后由公共緩沖區分發給相應用戶緩沖區。由于位于內核空間的用戶緩沖區是受保護的,應用進程在用戶態無法直接訪問。排除低效率的系統調用方法,這里采用了Linux的一種高效的內存映射機制mmap將內核空間映射到虛地址空間,用戶通過這個空間內的虛地址就能訪問到相應的用戶緩沖區了。
創建用戶進程的同時,過濾規則也按一定語法被設置。規則通過庫函數和系統調用被按一定優先級(這里稱規則索引)存儲于規則管理模塊中,此時該規則開始生效。為了方便驅動管理規則,同樣的規則以鏈表的方式保存于系統內存中。軟件中的規則是硬件中的規則的抽象,兩者每時每刻都保持著同步。
用戶的緩沖區和用戶設置的規則被前文所述的內存塊id標記聯系起來。這個標記的值會賦予以規則索引為下標的數組從而完成關聯。
一個進程添加新規則的過程如圖3所示。虛線箭頭表示控制流。用戶進程發出系統調用在內存中創建新規則及其規則索引,驅動程序代替它查詢用戶緩沖區得到一個空閑內存塊的id標記號,然后這個id號關聯到新規則,也從而使用戶緩沖區的內存塊、規則和用戶進程三者對應起來,最后規則被添加進入硬件。值得注意的是,如果驅動程序發現內存中已存在同樣的規則,它僅會把這個進程申請到的id號放在舊規則索引的數組最后。
在做好其他相應的設置以后,應用進程會到自己的用戶緩沖區中查看是否有新的數據到來。這里沒有采用常用的輪詢方法來檢查緩沖區。雖然輪詢不需要硬件特別的支持,但隨之帶來的問題也是明顯的。頻率過高的輪詢會大量地消耗CPU的時鐘周期;時間間隔過大則會帶來數據包時間戳不準確,錯過收取數據的時機導致丟包等問題。取而代之采用了一種中斷驅動的方法:用戶進程察看自己的緩沖區內有沒有新數據的到來,如沒有則把自己掛到等待隊列開始睡眠;中斷來時,中斷處理函數收取數據包并發信號喚醒睡眠進程做讀操作。
3.2.2 中斷處理過程
中斷的處理流程如圖4所示。中斷來時,中斷處理函數首先根據內核傳入的私有結構dev_id[5]判斷到底是哪個設備產生中斷,然后檢查相應設備的中斷狀態寄存器,根據寄存器判斷中斷發生的不同原因決定是否進行DMA操作。DMA操作會在無需操作系統干預的情況下把數據塊從硬件外部高速存儲器搬到內核公共緩沖區。公共緩沖區數據包自定義包頭經過解析后得到cookie值,它對應著前文所述的規則索引。驅動程序會根據規則索引把數據從公共緩沖區分發到相應進程的用戶緩沖區并喚醒等待隊列上的進程做讀取包和深度解析的工作。
在中斷處理過程中對于非搶占的Linux內核涉及系統同步的問題。為保護共享數據可能被非同步操作,整個中斷處理過程通過關中斷的方式來保護。但對于擁有對稱多處理器(SMP)或加入搶占機制的系統,需要做一些額外的處理:為了不影響其他處理器上的中斷處理,避免使用全局關中斷函數,只禁用當前處理器的中斷,并利用不會睡眠的鎖如自旋鎖對所有可能引發同步問題的臨界區進行保護。在多設備的環境下,系統中的每個設備DMA操作前都必須擁有自己的鎖;為了避免數據混亂,每個設備都擁有各自的公共緩沖區,而且從各自的公共緩沖區向用戶緩沖區寫數據前必須獲得一個全局鎖,從而實現寫操作的串行化。
4 性能測試
實驗使用SmartBits測試儀模擬真實的網絡環境對本系統進行了測試。測試硬件平臺為Intel P4 2.4GHz的處理器,1GB內存,64位PCI總線;軟件平臺為Fedra core3。測試結果" title="測試結果">測試結果顯示傳統的Libpcap在400Mbps左右就已經出現嚴重的丟包現象,而且受包長影響很大。而本系統在單設備雙輸入的情況下,當包速率超過1 800Mbps才出現丟包現象,并基本不受包長變化影響。另外測試結果表明本系統在Linux操作系統平臺下有較低的系統占用,如圖5所示本系統在不同包長的情況下處理器占用率均比Intel 光網卡 PRO/1000F要低得多。
本文在參考傳統網絡數據包捕獲方法的同時,針對傳統方法的一些弱點,提出一種軟硬件結合的包捕獲方案。該方案由硬件完成數據包過濾的任務,并對軟件部分作了優化,測試結果表明,該方案能滿足大多數高速網絡數據包捕獲任務的需要,具有廣泛的應用前景。
參考文獻
1 White G B，Pooch U W.Cooperating security managers：Distributed intrusion detection systems.Computers & Security，1996；15(5)：441～450
2 唐正軍，劉代志.網絡嗅探器Sniffer軟件源代碼淺3：采用Labpcap庫的通用設計.計算機工程，2002；28(2)
3 Jacobson V，Leres C，McCanne S.The tcpdump manual page. Lawrence Berkeley Laboratory，Berkeley，CA，1997
4 Kurmann C，Rauch F，Stricker T.Speculative defragmentation-leading gigabit ethernet to true Zero-Copy communication. Cluster Computing，2001；4(1)：7～18
5 Rubini A，Corbet J著，魏永明，駱 剛，姜 君譯.Linux設備驅動程序(第二版).北京：中國電力出版社，2004：275～276