關(guān)卿，秦宏偉，張文超

（解放軍63886 部隊(duì)，河南洛陽471003）

1 引言

現(xiàn)在因特網(wǎng)上出現(xiàn)了許多新型的網(wǎng)絡(luò)應(yīng)用程序，這些應(yīng)用程序具有比傳統(tǒng)應(yīng)用程序更加復(fù)雜的交互結(jié)構(gòu)和流量模式。當(dāng)前流量分析領(lǐng)域的一個(gè)困難是傳統(tǒng)的方法無法分析這些新興的應(yīng)用所產(chǎn)生的流量，需要一個(gè)新的方法來分析這些新興的應(yīng)用流量。本文在對當(dāng)前的流量識別算法進(jìn)行深入探究的基礎(chǔ)上結(jié)合網(wǎng)絡(luò)應(yīng)用交互特征，提出了一種基于流親戚關(guān)系分組的面向應(yīng)用的流量識別算法(FRRG 算法)。該算法的核心思想是根據(jù)各流之間的外在特性對流進(jìn)行分組，同一個(gè)組中的各流可以認(rèn)為是同一個(gè)應(yīng)用所產(chǎn)生的。該算法并不對網(wǎng)絡(luò)數(shù)據(jù)包的有效載荷[1]進(jìn)行檢測，而是關(guān)注于其外在特性，即其五元組信息。因此該算法獨(dú)立于應(yīng)用層所使用的具體協(xié)議，也與應(yīng)用層的數(shù)據(jù)是否加密無關(guān)，從而克服了有效載荷檢測算法的弊端。

2 相關(guān)研究

當(dāng)前的流量識別算法主要有2 種：有效載荷和非有效載荷[1]流量識別方法。

有效載荷檢測算法的基本思想是在包的有效載荷中識別特征位串，這些特征位串含有具體應(yīng)用層協(xié)議的獨(dú)特特征。網(wǎng)絡(luò) 上 流 行 的9個(gè)P2P 協(xié) 議(eDonkey，F(xiàn)astTrack，BitTorrent，OpenNap，W inM x，Gnutella，MP2P，Soulseek，Areas，Direct Connect)都是運(yùn)行在非標(biāo)準(zhǔn)、用戶自定義的私有協(xié)議之上，所有對它們進(jìn)行P2P 流量的有效載荷識別就需要按照每一個(gè)特定包格式進(jìn)行識別。這種方法能夠高精度的識別流媒體和P2P所產(chǎn)生的流量，但是，利用該算法進(jìn)行流量識別存在一些與數(shù)據(jù)相關(guān)或者來自P2P 協(xié)議本質(zhì)特性方面的限制。因?yàn)橐獙τ行лd荷進(jìn)行檢查，系統(tǒng)的有效載荷正比于被捕獲的數(shù)據(jù)包數(shù)量和大小，這就造成了一定量的系統(tǒng)額外開銷。另外，當(dāng)控制會(huì)話的端口號變化[2][3]時(shí)，這種方法也就不再有效。當(dāng)控制會(huì)話的數(shù)據(jù)被加密后，比如P2P 的KaZaA[4][5]應(yīng)用程序，有效載荷檢查的方法也沒用了。用這種方法來識別因特網(wǎng)流量，需要知道所有應(yīng)用層協(xié)議的所有細(xì)節(jié)，很明顯這是不可能的。

非有效載荷流量識別算法僅僅檢測包頭信息來識別P2P流，而根本不檢測用戶的有效載荷，它是基于觀察源IP 和目標(biāo)IP 的連接模式來識別網(wǎng)絡(luò)流量。該算法使用TCP/UDP 啟發(fā)式和{IP，port}啟發(fā)式來進(jìn)行流量識別。該算法存在有以下的局限性：識別結(jié)果粒度太粗，僅能將流量識別為P2P 流和非P2P流，不能提供更加精確的識別，比如識別為具體某個(gè)應(yīng)用所產(chǎn)生的流量；使用的方法太細(xì)粒度，僅僅關(guān)注于一些P2P 協(xié)議中交互的細(xì)微特征來進(jìn)行識別，一旦將來P2P 協(xié)議關(guān)于這些細(xì)微特征有了改變，該算法將毫無用處；利用P2PIP 列表會(huì)造成誤判，可擴(kuò)展性較差。

3 基于流親戚關(guān)系分組的流量識別算法

3.1 算法主要思想

流親戚關(guān)系分組 (Flow Relative Relation Group，簡寫FRRG)的應(yīng)用層流量識別方法，它的主要思想就是仔細(xì)探究同一個(gè)應(yīng)用程序所產(chǎn)生各流的相關(guān)依賴性，然后根據(jù)所屬應(yīng)用程序?qū)⒘鞣纸M，同一組中的流可以認(rèn)為是同一個(gè)應(yīng)用程序產(chǎn)生的。該方法包括3個(gè)部分，如圖1 所示。在此方法中，并沒有對每個(gè)包進(jìn)行有效載荷檢測，這是因?yàn)橛行лd荷檢測會(huì)使性能嚴(yán)重下降，而且在許多情況下還不適用。我們僅僅使用包頭信息，并將這些信息聚合成流。

圖1 流量識別方法示意圖

第1 步是構(gòu)建應(yīng)用程序特征表(Application Characteristic Table，簡寫ACT)，這可以通過離線使用多種包分析工具來完成。該表包括應(yīng)用程序名稱、除去動(dòng)態(tài)分配的端口外經(jīng)常使用的端口、傳輸層的協(xié)議號、以及該應(yīng)用程序的交互方式等。這些信息在第3 步流親戚關(guān)系計(jì)量中用來決定應(yīng)用程序的名字。

第2 步是決定關(guān)鍵端口(Decide Key Port，簡寫DKP)。DKP的輸入是原始包或流數(shù)據(jù)，輸出流信息和關(guān)鍵端口信息。在這一步中，流信息是根據(jù)捕獲包的五元組信息得到的，這五元組分別是源IP 地址、源端口、目標(biāo)IP 地址、目標(biāo)端口、傳輸協(xié)議。從TCP 流信息中選擇出關(guān)鍵端口號，由于許多流的源端口和目的端口都超過1024，這一步并非很簡單。因此很有必要分清哪個(gè)是關(guān)鍵端口，這樣才能準(zhǔn)確的定出相應(yīng)的應(yīng)用程序名字。

第3 步就是對DKP 輸出的流數(shù)據(jù)進(jìn)行分析、整合，流親戚關(guān)系計(jì)量(Flow Relative Relation Computing，簡寫FRRC)根據(jù)各流之間的關(guān)系對流進(jìn)行分組，并用相應(yīng)的應(yīng)用程序名字標(biāo)識該流。絕大多數(shù)新興的網(wǎng)絡(luò)程序都使用多個(gè)會(huì)話與一個(gè)或多個(gè)節(jié)點(diǎn)進(jìn)行交互，所以完全有可能揭示出同一個(gè)應(yīng)用程序所產(chǎn)生的各流的關(guān)系。根據(jù)這種流與流間的依賴關(guān)系，可以將流分成一些組。比如說MSN messenger 所產(chǎn)生的流被FRRC分在同一個(gè)組中。分組之后，F(xiàn)RRC 就可以根據(jù)應(yīng)用程序特征表ACT 來決定每個(gè)組的應(yīng)用程序名字。

3.2 應(yīng)用程序特征表

為了從捕獲的流信息中決定應(yīng)用程序的名字，需要對廣泛使用的應(yīng)用程序之間的交互行為進(jìn)行研究，并給出這些應(yīng)用程序的名稱、使用的缺省端口號、傳輸協(xié)議以及交互類型。使用tcpdump 和ethereal 對這些應(yīng)用程序所產(chǎn)生的流量進(jìn)行分析，然后據(jù)此來構(gòu)建ACT。這個(gè)ACT 實(shí)際上可看作是IANA端口列表的一個(gè)擴(kuò)展，里面包含了更多的內(nèi)容。對多個(gè)網(wǎng)絡(luò)上最流行的應(yīng)用程序做上述實(shí)驗(yàn)，即可構(gòu)建一個(gè)ACT，表1 示意了其中的一小部分。

表1 應(yīng)用程序特征表（部分）

3.3 決定關(guān)鍵端口

所謂關(guān)鍵端口是指在流量識別中起決定作用的端口號。一個(gè)正常TCP 的交互使用3 次握手機(jī)制在一個(gè)服務(wù)器和一個(gè)客戶端之間建立連接，互相發(fā)送FIN 數(shù)據(jù)包來結(jié)束這個(gè)連接。在TCP 會(huì)話中，服務(wù)器打開一個(gè)端口等待客戶發(fā)來連接請求。對于流量識別來說，服務(wù)器的監(jiān)聽端口是個(gè)很重要的端口。那么如何從被捕獲的包中得到服務(wù)端的監(jiān)聽端口呢？首先，利用3 次握手中使用的SYN 包和SYN- ACK 包。SYN 包的目標(biāo)端口和SYN- ACK 包的源端口就是服務(wù)器的監(jiān)聽端口，利用這個(gè)結(jié)論可以從所有的TCP 流中決定關(guān)鍵端口號。然而在實(shí)際的互聯(lián)網(wǎng)環(huán)境中，經(jīng)常捕獲到SYN 包而沒有SYN- ACK 包，所以需要同時(shí)檢查SYN 包和SYN- ACK 包。在DKP 中一個(gè)很基本的步驟就是要檢查一個(gè)流是否有與之對應(yīng)的相反流，因此可在決定關(guān)鍵端口時(shí)排除沒有對應(yīng)相反流的流。為了提高DKP 算法的性能，可利用這樣一個(gè)事實(shí)：沒有系統(tǒng)使用低于1024 的端口號作為客戶端隨機(jī)端口號，系統(tǒng)隨機(jī)產(chǎn)生的端口號都大于1024。因此可在應(yīng)用SYN/SYN- ACK 方法之前，通過檢查是否有小于1024 的端口號來決定關(guān)鍵端口。

在實(shí)際的環(huán)境中，還需考慮幾種情況。第一，在高速鏈路上可能無法捕獲DKP 所需的所有包，有時(shí)這是因?yàn)槭褂昧瞬蓸訖C(jī)制而有意的丟失一些包，有時(shí)則是因?yàn)椴粚ΨQ路由和捕獲系統(tǒng)性能的限制而丟失一些包。第二，在那些維持時(shí)間很長的TCP 會(huì)話中，比如流媒體服務(wù)、Vo IP 服務(wù)、網(wǎng)絡(luò)游戲等，SYN 包和SYN- ACK 包僅出現(xiàn)在TCP 連接的開始，如果從這些連接的中間開始捕獲數(shù)據(jù)包，則很有可能無法得到這些流的關(guān)鍵端口。第三，還要考慮一些比如Cisco NetFlow 的流數(shù)據(jù)，它們作為DKP 模塊的輸入可以將該方法擴(kuò)展到多個(gè)不同的環(huán)境中，在這種情況下，流信息可能不包括作為識別關(guān)鍵端口線索的TCP 標(biāo)志信息(比如Cisco NetFlow V5 不包括這種信息)。為了在DKP 方法中解決這個(gè)問題，特提出公理集1 的5 條公理：

公理集1：

前三條公理是顯而易見的，后兩條公理在普通網(wǎng)絡(luò)上也都成立。利用DKP 算法和公理集1 的組合，可以識別因特網(wǎng)上幾乎所有的TCP 流，剩下的TCP 流可以看作是DoS/DDoS或蠕蟲病毒所產(chǎn)生的異常流量。對于UDP 流，因?yàn)樗幌馮CP 流那樣使用3 次握手機(jī)制，所以不能使用這種方法，但是可以用FRRC 算法直接組合UDP 流。

3.4 流親戚關(guān)系計(jì)量

FRRC 算法是基于這樣的一個(gè)事實(shí)：同一個(gè)應(yīng)用程序所產(chǎn)生的各流之間存在相關(guān)依賴性，根據(jù)這種依賴性FRRC 將每個(gè)流歸入不同的集合中，屬于同一個(gè)集合的流是同一個(gè)應(yīng)用程序所產(chǎn)生的。FRRC 算法包括2個(gè)連續(xù)的過程：外表關(guān)系分組 (Facet Relation Group，簡寫FRG) 和地理關(guān)系分組(Geography Relation Group，簡寫GRG)。

（1）外表關(guān)系分組

該算法根據(jù)每個(gè)流的屬性相關(guān)性對其進(jìn)行分類。外表關(guān)系可定義為同一個(gè)應(yīng)用程序所產(chǎn)生的2 條流在協(xié)議、端口號、IP 地址等方面的關(guān)系。公理集2 適用于TCP 流和UDP 流，可以用來進(jìn)行外表關(guān)系分組。

公理集2：

FRG 算法的流程如下：第一在被捕獲的流中選擇一條流，第二再選擇該流所對應(yīng)的相反流，第三選擇與已選擇的流在屬性源IP 地址、源端口、協(xié)議相同的流，第四選擇與已選擇的流在屬性目標(biāo)IP 地址、目標(biāo)端口、協(xié)議相同的流，第五對在第三步和第四步選擇的流重復(fù)從第二步到第四步的過程，這個(gè)遞歸的過程一直持續(xù)直到?jīng)]有新的流被選進(jìn)來。結(jié)束了選擇的第一條流的組合過程，再從剩下的流中選擇另外一條流，繼續(xù)上述步驟直到?jīng)]有剩余的流。

可以將FRG 算法毫無修改的應(yīng)用于UDP 流；然而對于TCP 流，還需要對FRG 算法進(jìn)行些許修改，這是因?yàn)樵赥CP連接中，客戶端不能使用單個(gè)端口號建立多個(gè)連接，而服務(wù)器端卻可以使用單個(gè)端口號建立多個(gè)連接。為了提高FRG 算法的性能，可將該算法應(yīng)用于DKP 算法的輸出流上，當(dāng)然這些輸出流的關(guān)鍵端口已被確定。

（2）地理關(guān)系分組

利用FRG 算法，可以將TCP 流和UDP 流分在一些FRG組中，屬于同一組中的流可以認(rèn)為是同一個(gè)應(yīng)用程序所產(chǎn)生。但是，還不能保證同一個(gè)應(yīng)用程序所產(chǎn)生的流被分在同一個(gè)FRG 組中。為了解決FRG 算法無法克服的問題，提出一種稱為地理關(guān)系分組(GRG)的算法。GRG 算法是在FRG 算法的基礎(chǔ)上，給出一種定量描述來衡量FRG 各組間的關(guān)系：求出每一對FRG 組之間的關(guān)系權(quán)重，如果這個(gè)權(quán)重超過一個(gè)指定的閾值，便可以將這2個(gè)FRG 組合并為一個(gè)單一的組。

4 實(shí)驗(yàn)及算法對比

4.1 分析標(biāo)準(zhǔn)P2P 協(xié)議流量時(shí)，PE 算法和FRRG 算法的對比

關(guān)閉所有主機(jī)上的所有網(wǎng)絡(luò)軟件；運(yùn)行Ethereal，設(shè)置混合模式，并開始捕獲包；然后同時(shí)在每臺(tái)主機(jī)上運(yùn)行BitTorren 軟件，下載同一個(gè)文件；確保所采集到的流量都是BitTorent 軟件下載該文件的相關(guān)流量。文件下載完畢后，Ethereal 停止捕獲報(bào)文。將Ethereal 捕獲的流量蹤跡分別用基于流親戚關(guān)系的流量識別算法和有效載荷檢測算法進(jìn)行分析，所得的結(jié)果如圖2 所示：

圖2 BitTorrent 流量的兩種識別算法對比

4.2 分析包括非標(biāo)準(zhǔn)P2P 協(xié)議流量時(shí)，PE 算法和FRRG 算法的對比

圖3 BitTorrent 和ppLive 流量的2 種識別算法對比

運(yùn)行Ethereal，并開始捕獲包；同時(shí)在每臺(tái)主機(jī)上運(yùn)行BitTorren 軟件，下載同一個(gè)文件；然后同時(shí)在每臺(tái)主機(jī)上運(yùn)行ppLive 軟件，觀看同一部電影。所有主機(jī)的文件都下載完畢后，Ethereal 停止捕獲報(bào)文。將Ethereal 捕獲的流量蹤跡分別用基于流親戚關(guān)系的流量識別算法和有效載荷檢測算法進(jìn)行分析，所得的結(jié)果如圖3 所示.

5 結(jié)束語

本文提出的FRRG 算法克服了有效載荷檢測算法的弊端，實(shí)驗(yàn)結(jié)果表明該算法運(yùn)行良好，在一定的條件下，進(jìn)行流量識別的準(zhǔn)確率較高，并且具有較強(qiáng)的可擴(kuò)展性。FRRG 算法僅對IP 數(shù)據(jù)包的三層信息進(jìn)行分析，由于特征信息較少，因此不可避免造成些許誤判，下一步將考慮如何從其它層中抽取特征信息，以及自動(dòng)構(gòu)建應(yīng)用程序特征表等問題，來增強(qiáng)FRRG 算法效率和適用性。

[1]Remco Poortinga,Remco van de Meent,and Aiko Pras.Analysing Campus Traffic Using the meter- M IB[C].Proc.of the Passive and Active Measurement W orkshop(PAM 2002),Mar.25- 27,2002.

[2]Hun- Jeong Kang,Myung- Sup Kim,and James Won- Ki Hong.A Method on Multimedia Service Traffic Monitoring and Analysis[C].Lecture Notes in Computer Science 2867,Edited by Marcus Brunner,Alexander Keller,14th IFIP/IEEE Int’l W orkshop on Distributed Systems:Operations and Management(DSOM 2003), Heidelberg,Germany,Oct.2003:93- 105.

[3]Hun- Jeong Kang,Hong- Taek Ju,M yung- Sup Kim,and James W.Hong.Towards Stream ing Media Traffic Monitoring and Analysis[C].Proc.of 2002 Asia- Pacific Network Operations and Management Symp.(APNOMS 2002),Jeju,Korea,Sept.25- 27,2002:503- 504.

[4]Nathaniel Leibow itz,Matei Ripeanu,and Adam W ierzbicki.Deconstructing the KaZaA Network[C].3rd IEEE W orkshop on Internet Applications(W IAPP'03),June 2003.

[5]Nathaniel Leibow itz,Aviv Bergman,Roy Ben- Shaul,and Aviv Shavit.Are File Swapping Networks Cacheable[C].7th Int’l W orkshop on WebContent Caching and Distribution(WCW),Boulder,Colorado,Aug.14- 4,2002.