摘 要: 通過引入流特征統計和深度數據包檢測相結合的思想，設計了一種可擴展的10Gb/s線速P2P流量識別引擎" title="識別引擎">識別引擎，給出了該引擎的硬件實現方案，詳細介紹了方案中已知流過濾、傳輸層特征統計、凈荷關鍵詞匹配等核心部分的實現。測試表明，該引擎可完全實現10Gb/s速率下的P2P流量線速識別，識別準確率大于95%。
關鍵詞: 識別引擎； P2P流量； 流特征識別；深度數據包檢測
?
??? 近來，P2P流量成為一個流行的問題，這種無序的流量占用網絡中50%～90%的帶寬[1]，造成網絡擁塞，致使服務質量下降。通過在網絡中主動識別標識P2P流量，并在此基礎上實現對P2P流量的管理與控制，是目前被業內認可的一種解決方案。
有一些工具使用深層數據包檢測技術" title="檢測技術">檢測技術[2] DPI(Deep Packet Inspection)通過軟件（如P2P終結者）的方式在小型局域網中識別處理P2P流量，其能力有限； 華為、Cisco等公司也推出了相關產品，基于DPI技術對流量的應用層協議分類,標識出P2P流量，其最大吞吐率" title="吞吐率">吞吐率為4Gb/s。韓國的JamesWon-KiHong等人研發的流量監控系統NG-MON是基于流量特征的檢測技術[3](Transport Layer Identification)，但其性能參數未知。DPI技術的缺點是對新P2P應用檢測具有滯后性，難以檢測加密P2P應用，性能與載荷檢測的復雜度相關。基于流量特征的檢測技術[4]能夠克服這些缺點，但它不能指示P2P應用協議具體類型，當其他應用的流量與P2P流量特征類似時容易誤判。
針對目前已經成為主流鏈路" title="鏈路">鏈路傳輸速率的10Gb/s速率，筆者設計了一種高效的P2P流量識別引擎，把深層數據包檢測技術和基于流量特征的檢測技術結合，兼顧效率和精度。該引擎能夠對10Gb/s鏈路的P2P流量線速識別。
1 P2P識別引擎設計
本設計的P2P識別引擎采用流水作業方式，如圖1所示。
?
當一個IP數據包（設為flow：由源IP地址SrcIP、目的IP地址DstIP、源端口SrcPort、目的端口DstPort和協議域Protocol組成）進入該引擎時，它首先通過已知流比較，未知的流量數據包送到端口匹配識別引擎進行端口匹配，接著不匹配的數據包由傳輸層特征識別引擎處理，將未知類型P2P數據包送至凈荷檢測識別引擎，做具體類型判斷。對于每個模塊識別出的非P2P流量直接輸出到引擎對外接口；對于識別出的P2P數據包，則添加類型指示并送到輸出FIFO，類型指示包括P2P具體類型和P2P未知類型。最后，數據包由FIFO輸出。
1．1 已知流過濾
對于P2P流量而言，具有數據量大，在線時間長的特點。數據包（flow）和儲存在TCAM中的已知P2P流直接比較，快速區分出是否為已知P2P流；同時有很多知名Web等服務器的IP地址固定，通過IP地址判斷不是P2P流量。
1．2 端口匹配識別引擎
許多P2P應用軟件有默認的使用端口，一些用戶沒有修改軟件默認端口的習慣，通過端口可以識別一部分P2P流量。
1．3 傳輸層特征識別引擎
傳輸層識別引擎通過對主機傳輸層特征的統計識別P2P流量。根據已有研究成果[4]，目前P2P流量在傳輸層特征上存在以下兩個特征：
(1)許多P2P應用在一對主機之間同時采用TCP 和UDP連接；
(2)某一主機與多個目的主機通信，并且對于不同目的主機通常采用不同的目的端口。
上述特征也存在一些例外情況，如DNS、NETBIOS、IRC、游戲和多媒體業務流量有(1）的特征， 有時Mail、DNS、Game也具備上述(2）的特征。本設計采用參考文獻[4]的方法可以區分這些應用。考慮到骨干網鏈路上主機數目眾多，無法測量所有主機的傳輸層特征；但是由于網絡流量大小服從Zipf分布的特性，10%的主機的流量占據了鏈路總流量的90%[5]，因此，采用抽樣的方式，僅僅測量流量大的主機的傳輸層特征。抽樣算法采用參考文獻[6]中提出的sample-and-hold算法。
1．4 凈荷檢測識別引擎
不同的P2P協議凈荷具有不同的特征，采用特征字符串來匹配凈荷的方式可以精確識別P2P具體應用的具體類型。
2 P2P識別引擎的實現
P2P識別引擎可以識別10Gb/s網絡中P2P流量。它包括已知流過濾、端口匹配識別、傳輸層特征識別、凈荷檢測識別四個部分，并隨著發展可以擴展新的功能模塊。這在Xilinx Virtex-4 LX160 FPGA上得到了實現。
2．1 已知流過濾的實現
要線速地對10Gb/s數據流進行處理，需兼顧處理速度和存儲容量要求，所以筆者使用TCAM1實現對數據包的過濾。在一條鏈路中，識別引擎的工作時間越長， 識別出來的P2P流量越多，把識別出來的P2P流量用流標識符(SrcIP、DstIP、SrcPort、DstPort和Protocol經過Bloom filter運算壓縮[7]成20bit流標識符)存儲在FPGA片外的TCAM1中。許多知名網站服務器(如sina、 hotmail等)的訪問量很大，其IP地址固定，把這些IP地址也儲存在TCAM1中。如果SrcIP或者DstIP在表中，則可以直接判為非P2P流量。在TCAM1中，如圖2所示，劃分出多塊空間，分別對應存儲已知具體類型和未知類型的P2P流量標識符、知名網站服務器IP地址。通過TCAM掩碼可以選擇每一行中的比特哪些必須匹配，哪些可以忽略。如果所有的值在沒有掩碼的比特位置都匹配了，根據返回的空間地址可以知道數據包的類型。通過發送控制包到 P2P識別引擎可以改變TCAM掩碼、TCAM值和TCAM空間分配。對于識別出具體類型的P2P流量，把數據包添加類型指示直接送到輸出FIFO中，對未知類型的P2P流量數據包添加類型指示送到凈荷檢測模塊處理，對知名網站服務器的數據包直接送到引擎對外接口；如果沒有匹配，則認為是未知流量，對其添加未知類型指示送到端口匹配識別模塊作處理。對已知流的快速標識，可以提高判別效率，節省FPGA資源。
?
2．2 端口匹配的實現
目前很多的P2P應用軟件中都有默認的使用端口，例如eMule使用端口4662/4672/4673等。據統計，目前P2P默認端口數量在100以下，使用FPGA的BLOCK RAM實現的CAM可以高效地完成端口匹配工作。在這個CAM中，對不同類型端口同樣分配不同空間位置，由返回地址獲得P2P類型。對于端口匹配識別出的具體類型P2P流量，把流標識符寫入TCAM1相應的位置，同時把數據包添加類型指示直接送到輸出FIFO中；對沒有識別出流量類型的數據包，送到傳輸層特征識別引擎處理。
2．3 傳輸層特征識別引擎的實現
傳輸層特征識別引擎的實現框圖如圖3所示。
?
首先，對于到達的每個數據包，按照概率p對其進行抽樣。如果數據包被抽樣到，則以“SrcIP +DstIP”作為流標志，將該數據包所屬的流（設為F）送往TCP/UDP對判別模塊。如果檢測到F中同時存在活動的TCP和UDP連接（活動時間取64s[7]），并且端口不是表1中列出的端口，則判定F為P2P流量，并輸出到凈荷檢測識別模塊；如果是表1中端口，則根據參考文獻[4]中方法進一步處理；否則，將F送入(IP，PORT)檢測模塊。(IP，PORT)檢測模塊分別統計與各個SrcIP通信的DstIP和DstPort的數量，如果兩者數量接近，且均遠大于1，則認為該源IP地址所對應的流量為P2P流量。
?
筆者參考了文獻[7]的算法思想，基于d-left Hash函數實現了TCP/UDP連接對檢測模塊。采用4個獨立的Hash函數，Hash結果空間大小為210，每個Hash單元存放8個（源）IP地址及2bit的狀態標志。IP地址并不直接存放，而是首先對其進行壓縮運算，得到一個長14bit" title="14bit">14bit的地址標號，再將地址標號存放在Hash單元中。這樣，實現TCP/UDP連接對檢測模塊共需要的存儲容量為：
4×8×210×(14+2)=524 288bit
對于所選用的FPGA而言，采用片內SRAM即可滿足這一需求。
(IP，PORT)檢測模塊基于Bloom Filter的思想實現。如圖4所示，(IP，PORT)檢測模塊共維護10K條統計表項，每條表項在FPGA片外SRAM中對應一個96bit的存儲區域。其中有92bit用于Bloom Filter的Hash向量，4bit作為統計計數器。每到達一個數據包，通過查找其源IP地址統計項的Hash向量，判斷目的IP地址是否是一個新地址，如果是則將對應的計數器加1。否則更新Bloom Filter的Hash向量。與實現TCP/UDP連接對檢測模塊類似，不直接存儲源IP地址，而是存儲其14bit的壓縮標號。這樣，實現(IP，PORT)檢測模塊共需要140KB的FPGA片內存儲空間以及(960×2)=1 920KB的片外SRAM存儲空間。比較容易就可以實現。
?
2．4? 凈荷檢測識別的實現
凈荷復雜就會造成檢測性能下降，10Gb/s的數據難以完全實現線速檢測。但是通過上述三個模塊的處理，送到凈荷檢測的數據包速率大大降低(10％)，就可以實現線速檢測。
不同的P2P協議具有不同的特征[8]，表2給出了幾種典型應用協議數據區的判別特征。從不同應用協議的凈荷特征可以看出，絕大部分協議的報文特征體現在凈荷開頭的前20字節，少數協議的報文特征還會體現在凈荷結尾處的某些字段。用上述固定位置字段的特征信息可以進行數據包的識別。
?
凈荷檢測識別引擎如圖5所示，使用FPGA外的TCAM2可以高效地實現凈荷關鍵詞的匹配。對不同凈荷特征分配不同空間，當一個IP包到達，凈荷的匹配比特與TCAM中的表項值比較，如果沒有掩碼的值都匹配了，根據返回的空間地址可以確定P2P的類型，把未知類型更改為具體類型指示并送到輸出FIFO中，同時把流標識符寫入TCAM1相應的位置；如果沒有匹配成功，則認為是未知類型的P2P數據包送到輸出FIFO中。
?
采用多個凈荷檢測識別引擎并行工作的方式，可以提高處理能力。
3 性能分析與測試
在Xilinx Virtex-4 LX160 FPGA上綜合P2P識別引擎在布局布線后的結果列在表3中。核心邏輯占用了69％的邏輯資源和88％的block RAM。
3．1 吞吐率
本文設計的P2P識別引擎器件采用Xilinx Virtex-4 LX160 FPGA、IDT 71T75602 SRAM、IDT 75K72100 TCAM。
對于實現在FPGA內部的模塊，FPGA的工作時鐘在125MHz，同時處理128bit的數據，這樣可以得出P2P識別引擎的吞吐率：128bit×125MHz＝16Gb/s。完全能夠實現10Gb/s的線速處理。
對于查表匹配模塊，TCAM工作時鐘在100MHz，按照每個最短數據包64字節計算，查表速率：64×8×100＝51.2Gb/s；更新一個TCAM表項的內容需要4個時鐘周期，更新速率：51.2/4＝12.8Gb/s。可以實現對10Gb/s數據的線速處理。
對于SRAM模塊，設鏈路數據率為10Gb/s，最小包長為64字節，則每個數據包的傳輸時間為51.2ns。SRAM的讀寫周期為4ns，接口位寬32bit。每收到一個數據包，需要讀寫SRAM各三次，共需24ns。那么，還剩余27.2ns用于判斷Bloom Filter的Hash向量的四個對應位是否為1，并更新計數器。滿足本設計所選用的FPGA要求，同樣能夠實現10Gb/s的線速處理。
按照流水處理的方式，本文設計的引擎可以實現對P2P數據的線速識別。
3．2 測試
如圖6所示，在測試時使用Spirent AX4000測試儀發送鏈路速率為10Gb/s包含各種類型流量的數據包，識別引擎對其中的P2P流量識別，把識別的結果用FPGA中實現的統計模塊記錄下來，通過PC觀察結果。
?
測試結果表明，該引擎可以在10Gb/s速率下完成對P2P數據包的識別，且準確率大于95％。但該引擎還有待實際網絡流量的測試。
本文設計的 P2P識別引擎實現在高性能路由器中(國家863計劃信息技術領域重大專項，大規模接入匯聚路由器系統性能及關鍵技術研究)，滿足對10Gb/s鏈路數據中的P2P流量線速識別。FPGA所具有的大規模并行處理能力和可編程的靈活性使得該引擎能獲得極高的處理性能，并且通過重新下載配置信息來改變功能，能夠適應P2P應用的日益變化和性能需求，具有良好的可擴展性。
參考文獻
[1] 鄔賀銓. 2007年寬帶世界論壇亞洲會議.演講稿.
[2] ?SEN S, SPATSCHECK O, WANG D.? Accurate, scalable?in-network identification of P2P traffic using application?signatures. In www, 2004.
[3] ?HAN S H， JAMES W K H. The architecture of NGMON： A passive network monitoring system for high-speed IP networks. Lecture Notes In Computer Science；Vol. 2506，2002.
[4] ?KARARGIANNIS T, BROIDO A, FALOUTSOS M, et al.?Transport layer identification of P2P traffic. In Proceedings ?of ACM SIGCOMM, 2004.
[5] ?ESTAN C, VARGHESE G. New directions in traffic measurement and accounting. SIGCOMM '02, August 19－23,2002, Pittsburgh, Pennsylvania, USA.
[6] ?CLAFFY K, BRAUN H W, POLYZOS G. A parametrizable?methodology for internet traffic flow profiling. In IEEE?JSAC, 1995.
[7] ?BONOMI F, MITZENMACHER M, PANIGRAHY R.?Beyond bloom filters: from approximate membership checks ?to approximate state machines. SIGCOMM’06, September?11–15, 2006, Pisa, Italy.
[8] ?White paper-netflow services and applications http://www.cisco.com/warp/public/cc/pd/iosw/ioft/neflct/tech/napps_wp.%htm.