李 莉

（河南科技學(xué)院，河南 新鄉(xiāng) 453003）

國內(nèi)對(duì)于 P2P技術(shù)的研究和應(yīng)用都進(jìn)行得火熱，但是對(duì)于P2P流量監(jiān)控技術(shù)的研究卻很少，很難在各大論文庫中檢索到P2P流量檢測(cè)方面的中文文章，而高水平的論文更是少之又少。但是國內(nèi)部分網(wǎng)絡(luò)設(shè)備生產(chǎn)商已經(jīng)推出了P2P流量監(jiān)控的相關(guān)產(chǎn)品，如華為的SecPath 1800防火墻[14]和Euenmon。防火墻以及CAPTECH的網(wǎng)絡(luò)管理軟件——網(wǎng)絡(luò)慧眼。這些產(chǎn)品采用的都是深層數(shù)據(jù)包檢測(cè)技術(shù)。

1 P2P流量檢測(cè)

國外P2P流量檢測(cè)方面的研究工作和產(chǎn)品化工作都做得很好，特別是深層數(shù)據(jù)包檢測(cè)技術(shù)已經(jīng)發(fā)展得非常成熟。Subhabrata Sen等人于2004年初提出基于應(yīng)用簽名的P2P流量檢測(cè)方法，實(shí)際上是深層數(shù)據(jù)包檢測(cè)方法的一種，該方法把payload特征分為固定偏移量（fixed offset）特征和變化偏移量（variable offset）特征，第一步檢查固定偏移量，第二步檢查變化偏移量，在性能和精度上都取得了令人滿意的效果。韓國的 James Won Ki Hong等人于2003年提出基于傳輸層特征的P2P流量檢測(cè)方法，該方法先通過離線統(tǒng)計(jì)的方式找到各種P2P應(yīng)用的常用端口，然后把這些常用端口信息用到流量檢測(cè)中作為應(yīng)用分類的依據(jù)。試用該方法針對(duì)韓國當(dāng)時(shí)流行的P2P軟件進(jìn)行了測(cè)試，但是沒有給出性能參數(shù)。Thomas Karagiannis等人在仔細(xì)研究了P2P流量的傳輸層特征后于2004年提出一種基于傳輸層特征的P2P流量檢測(cè)方法，該方法以P2P流量的傳輸層所表現(xiàn)出來的兩種一般性特征為依據(jù)，結(jié)合傳統(tǒng)的端口檢測(cè)技術(shù)，能夠有效地檢測(cè)到新的P2P應(yīng)用的加密和P2P應(yīng)用，但是改方法過于復(fù)雜且不能對(duì)P2P應(yīng)用進(jìn)行分類，另外他們還沒有考慮對(duì)該方法的性能優(yōu)化。國外網(wǎng)絡(luò)設(shè)備生產(chǎn)商和網(wǎng)絡(luò)服務(wù)提供商都推出了相關(guān)的產(chǎn)品和技術(shù)，如Cisco公司的Neflow技術(shù)，Allot的故障恢復(fù)流量管理方案（fail safetrafficm anagementsolutions）,CacheLogic公司的CacheLogic P2P管理方案，VersoTechnologies的NetSpective系列產(chǎn)品等，其中NetSpectiv系類產(chǎn)品已經(jīng)擁有了攔截加密 P2P應(yīng)用Skype的能力?？v觀這些產(chǎn)品，全部都使用了自行研發(fā)的深層數(shù)據(jù)包檢測(cè)技術(shù)，除了性能的識(shí)別精度商存在差別外，其技術(shù)的本質(zhì)是相同的。目前為止唯一有據(jù)可查的使用基于流量特征的檢測(cè)方法的產(chǎn)品是流量監(jiān)控系統(tǒng)NG-MON,韓國的JamesWonKiHong等人在該系統(tǒng)商使用了他們自主研發(fā)的基于流量特征的P2P檢測(cè)技術(shù)，但是沒有給出具體的性能參數(shù)。

據(jù)包分類就是根據(jù)數(shù)據(jù)包本身攜帶的信息或與數(shù)據(jù)包有關(guān)的信息（主要指IP包頭和傳輸層頭部攜帶的信息）索引預(yù)先設(shè)置的分類器，查找匹配的規(guī)則來達(dá)到區(qū)分?jǐn)?shù)據(jù)包的目的（圖1）。數(shù)據(jù)包分類的結(jié)果決定了這個(gè)數(shù)據(jù)包屬于哪一數(shù)據(jù)流以及此數(shù)據(jù)包應(yīng)達(dá)到什么樣的服務(wù)等級(jí)，然后轉(zhuǎn)發(fā)引擎根據(jù)分類的結(jié)果采用相應(yīng)的處理來滿足用戶的需求。這些處理可能包括丟棄未授權(quán)的分組、進(jìn)行特殊的排隊(duì)和調(diào)度處理或者作為路由選擇的依據(jù)等。許多網(wǎng)絡(luò)服務(wù)需要進(jìn)行數(shù)據(jù)包分類，如尋路、防火墻訪問控制、策略路由和業(yè)務(wù)帳單等。

圖1 數(shù)據(jù)包分類示意圖

類器是分類規(guī)則和分類策略的集合。一般情況下，分類器中的一條規(guī)則代表一種業(yè)務(wù)流，在數(shù)據(jù)包轉(zhuǎn)發(fā)過程中接受相同的服務(wù)。分類規(guī)則是分類算法處理數(shù)據(jù)包的依據(jù)。一條分類規(guī)則可以看成是一個(gè)過濾器(Filter)和一種處理行為(Action)的組合。通常分類規(guī)則過濾器(Filter)涉及到數(shù)據(jù)包包頭（包括IP頭和傳輸層頭部等）的一個(gè)或多個(gè)字段，如ToS(8bits)、源IP地址(32bits)、目的IP地址(32bits)、協(xié)議(8bits)、源端口(16bits)和目的端口(16bits)。分類后的處理行為(Action)包括數(shù)據(jù)包的丟棄優(yōu)先級(jí)、調(diào)度策略、緩存區(qū)和帶寬管理策略和路由選擇策略等。此外處理行為中還必須包括一個(gè)優(yōu)先級(jí)標(biāo)識(shí)符來解決一個(gè)數(shù)據(jù)包符合多個(gè)分類規(guī)則的情況，即分類規(guī)則相互重疊的情況。

2 系統(tǒng)功能模塊設(shè)計(jì)

針對(duì)目前城域網(wǎng)100G以上的流量，在設(shè)計(jì)系統(tǒng)的架構(gòu)時(shí)就需要特別考慮。選擇一種最適合的架構(gòu)來滿足城域網(wǎng)上對(duì)100G流量性能的要求。由于P2P應(yīng)用協(xié)議類型、實(shí)現(xiàn)機(jī)理的多樣性，為了徹底監(jiān)管和控制P2P流，只能采取綜合性解決方案，在綜合考察了最新P2P流量控制技術(shù)及設(shè)備的前提下，設(shè)計(jì)了P2P流量綜合控制系統(tǒng),如圖2所示。

該系統(tǒng)采用分布的架構(gòu)設(shè)計(jì)恐想。系統(tǒng)主要由五大功能模塊組成，包括P2P檢測(cè)模塊、管理模塊以及執(zhí)行模塊，每個(gè)模塊又含有若干部件。映射到具體網(wǎng)絡(luò)設(shè)備中，各設(shè)備的P2P控制功能就是由這些部件組合而實(shí)現(xiàn)的。由于設(shè)備性能的限制，要處理100G以上的大流量,只能考慮采用分布式部署的方案。這樣將分布式部署多個(gè)業(yè)務(wù)識(shí)別模塊和業(yè)務(wù)執(zhí)行模塊。各個(gè)業(yè)務(wù)識(shí)別模塊的識(shí)別、統(tǒng)計(jì)業(yè)務(wù)數(shù)據(jù)信息都統(tǒng)一上報(bào)給業(yè)務(wù)管理模塊，由該模塊匯總所有的流量信息，然后根據(jù)管理員設(shè)置的各種控制策略，有效地限制和阻斷P2P流量數(shù)據(jù),保障網(wǎng)絡(luò)和業(yè)務(wù)的安全性。

圖2 P2P流量監(jiān)控系統(tǒng)框架

3 結(jié)論

P2P流量的控制與反控制是一個(gè)不斷發(fā)展變法的過程。最初的P2P流量是可以通過其固定服務(wù)器IP地址及端口號(hào)加以識(shí)別的，很快便大量出現(xiàn)了采用隨機(jī)動(dòng)態(tài)端口、偽裝端口的分布式P2P應(yīng)用軟件，并且已出現(xiàn)了加密的P2P流，甚至出現(xiàn)了在安全的套階層SSL通道上傳輸?shù)腜2P流，越來越不易被識(shí)別。

[1]劉強(qiáng).P2P流量監(jiān)控技術(shù)研究與實(shí)現(xiàn)[D].北京：北京郵電大學(xué)，2008.

[2]徐烙.P2P流量的監(jiān)控與管理[J].中國教育網(wǎng)絡(luò),2006.

[3]Peer-to-PeerComputingDejanS.Milojicic,VanaKalogeraki,RajanLu Kiran Nagaraja,Jim Pruyne,Bruno Richard,Sami Rollions,Zhichen Xu,HP Laboratiories Palo Alto HPL-2002-57 March 8 th,2002.

[4]BRADEN R,CLARK D,SHENKER S.Integrated Services in the Internet Architecture.An Overview,IETF RFC 1633[S],1994.