即時通訊軟件文件傳輸審計系統(tǒng)的研究與實現(xiàn)

(中南大學 信息科學與工程學院，湖南 長沙，410083)

隨著互聯(lián)網(wǎng)的發(fā)展，即時通訊軟件(IM)以實時性強、反饋速度快、費用低廉等優(yōu)點風靡全球，受到廣大網(wǎng)民的喜歡[1]。即時通信服務(wù)處于開放的網(wǎng)絡(luò)環(huán)境下，是一種公共服務(wù)，在為企業(yè)及個人帶來高效便捷通信的同時，也帶來來自公眾網(wǎng)絡(luò)的信息干擾，存在影響工作效率甚至信息安全的隱患，因此，對 IM進行管理和控制具有重要意義[2]。針對即時通訊軟件的監(jiān)控問題，理論上已有一些研究成果。Lin[3]研究分析IM的特征和行為模式，并基于此提出使用支持向量機阻斷IM的方法。Xiao等[4]在對IM流量特征分析的基礎(chǔ)上提出利用IM的流量特征實現(xiàn)對IM的監(jiān)控。Liu等[5]研究阻斷 IM 垃圾廣告和可能引起的拒絕服務(wù)問題。Kim等[6]首先采用風險分析的方法對 IM 的安全功能需求進行分析，然后制定IM 的安全策略，并設(shè)計和實現(xiàn)一個即時通訊軟件實時監(jiān)控系統(tǒng)Messenger-i。黃紅桃等[7]設(shè)計并實現(xiàn)基于MSN協(xié)議的網(wǎng)絡(luò)行為審計系統(tǒng)，對基于 MSN協(xié)議傳輸?shù)奈募徲嬤€原。付安民等[8]在對IM協(xié)議分析的基礎(chǔ)上，設(shè)計實現(xiàn)即時通監(jiān)控系統(tǒng)。文獻[9]中對IM文件傳輸協(xié)議分析不完備，無法實現(xiàn)對QQ文件傳輸?shù)膶徲?。與此同時，國內(nèi)外市場上均出現(xiàn)對即時通訊軟件監(jiān)控的工具。國外的監(jiān)控產(chǎn)品有 McAfee公司開發(fā)的 McAfee Wireless Protection和Symantec公司開發(fā)的Symantec IM Manager等。國內(nèi)市場上也出現(xiàn)一系列針對即時通訊軟件進行監(jiān)控的軟件，如揚州安達信源網(wǎng)絡(luò)科技有限公司的“第三只眼”、上海百絡(luò)信息技術(shù)有限公司的百絡(luò)網(wǎng)警、同易信息技本有限公司開發(fā)的同易企業(yè)監(jiān)控軟件等。這些軟件可以實現(xiàn)對QQ和MSN等IM聊天內(nèi)容的監(jiān)控，記錄聊天行為。綜上可知，盡管對IM監(jiān)控的研究及產(chǎn)品比較豐富，但目前對即時通訊軟件的監(jiān)控仍然存在以下問題：

(1) 對即時通訊軟件監(jiān)控的研究基本都集中在文本信息(實時聊天信息)方面，而很少研究即時通訊文件傳輸監(jiān)控。

(2) 現(xiàn)有的監(jiān)控系統(tǒng)幾乎只能對ICQ，MSN等少數(shù)國外的即時通訊軟件進行監(jiān)控，而對國內(nèi)廣泛使用的IM如：騰訊QQ、中國移動飛信等無能為力。

(3) 即時通訊軟件更新速度快，因此對其的監(jiān)控還面臨著IM升級和加入新型即時通訊軟件的問題。

因此，深入分析即時通訊軟件文件傳輸?shù)耐ㄐ艆f(xié)議，并能準確高效地對使用即時通訊軟件傳輸?shù)奈募M行審計很有意義。本文作者對多種IM(QQ，F(xiàn)etion，MSN和雅虎通等)文件傳輸協(xié)議進行分析，設(shè)計并實現(xiàn)IM文件傳輸審計系統(tǒng)FAudit，對即時通用戶的文件傳輸行為進行審計，包括用戶信息、文件大小及具體的文件內(nèi)容等信息。該系統(tǒng)具有良好的擴展性、健壯性等性能特性，可以實現(xiàn)對 IM 各類文件(DOC，PDF，TXT和視頻等)傳輸?shù)膶徲嫛?/p>

1 IM文件傳輸協(xié)議分析

雖然互聯(lián)網(wǎng)工作任務(wù)組(IETF)制定的標準即時通信協(xié)議有IMPP[9]，SIMPLE[10]及XMPP[11]3個國際協(xié)議，但目前市場上常用的即時通訊軟件如QQ，F(xiàn)etion，MSN和雅虎通等并未完全遵守這些標準，而是使用自己的私有協(xié)議進行文件傳輸。因此，對各個即時通信協(xié)議進行分析，建立系統(tǒng)特征庫，是FAudit實現(xiàn)的前提，也是重點和難點。

通過搭建協(xié)議分析環(huán)境，根據(jù)主流即時通通信數(shù)據(jù)明文傳輸?shù)奶攸c，在局域網(wǎng)內(nèi)部及網(wǎng)間有目的、大量重復的發(fā)送包含特殊字符(如文件內(nèi)容全為 1)的文件，采用逆推的方法，比較應用層數(shù)據(jù)中固定字節(jié)或者規(guī)律性字節(jié)的含義[12]，總結(jié)出 QQ，F(xiàn)etion，MSN和雅虎通4種主流即時通訊軟件，當前使用的多種版本完整詳細的文件傳輸協(xié)議基本特征信息。表1所示為4種IM文件傳輸協(xié)議的基本特征。從表1可知：目前國內(nèi)廣泛使用的幾個 IM軟件文件傳輸時傳輸層采用TCP或UDP協(xié)議，通信模式采用C/S或P2P的方式。

如前所述，各個 IM使用完全不同的協(xié)議，協(xié)議格式差別很大，因此，不可能總結(jié)出 IM的通用協(xié)議格式。這里，本文只以QQ文件傳輸為例進行分析，其他IM協(xié)議格式分析方法類似。

QQ文件傳輸模式主要有UDP方式，TCP直連及TCP中轉(zhuǎn)。TCP直連常見于臨近網(wǎng)絡(luò)(局域網(wǎng)絡(luò)內(nèi))傳送文件，這種模式傳輸速度快；UDP方式與 TCP中轉(zhuǎn)傳輸方式主要存在于廣域網(wǎng)中。2010SP1版本之后QQ又增加離線文件傳輸功能，可以在接收方離線的情況下，傳輸QQ文件。

表1 幾種主流IM文件傳輸協(xié)議對照表Table 1 Files transfer protocol of mainstream IM

QQ每種傳輸方式的數(shù)據(jù)包格式均不相同，不同版本的數(shù)據(jù)包格式也不相同。根據(jù)應用層協(xié)議特征的不同，可以將QQ傳文件的數(shù)據(jù)包分為4類：初始包(包含有應用識別QQ傳文件的特征和QQ號碼)、文件名包(包含文件名，文件長度等)、文件內(nèi)容中間包(傳輸文件內(nèi)容)以及文件內(nèi)容結(jié)束包(標識文件傳輸結(jié)束)。

(1) 初始包。QQ文件傳輸?shù)某跏紨?shù)據(jù)包包含QQ文件傳輸流識別特征和QQ號碼等信息。圖1所示為使用2009版本、UDP傳輸方式的初始數(shù)據(jù)包，該數(shù)據(jù)包大小為27 B，圖中加下劃線的部分識別特征，其中0x04代表傳輸方式為UDP，最后4字節(jié)為發(fā)送方QQ號。接收方回復數(shù)據(jù)包格式如圖2所示，前4字節(jié)代表應用層識別特征，最后 4字節(jié)為接收方 QQ號碼。

圖1 QQ初始數(shù)據(jù)包協(xié)議特征1Fig.1 Initial packet characteristics of sender

圖2 QQ初始數(shù)據(jù)包協(xié)議特征2Fig.2 Initial packet characteristics of receiver

(2) 文件名包。文件名數(shù)據(jù)包包含文件名、文件長度等信息。QQ文件名使用Unicode或GBK編碼后進行傳輸。圖3所示為QQ2009使用TCP直連進行文件傳輸時文件名數(shù)據(jù)包的格式。該數(shù)據(jù)中 0x12位置處出現(xiàn)的“0x58 0x58”是文件名數(shù)據(jù)包的識別特征。后面4字節(jié)是文件傳輸次數(shù)信息。之后的黑體斜體部分表示文件大小，再之后為文件名(最后一個黑體斜體部分)，這里文件名使用Unicode編碼方式，以0x00結(jié)束。

(3) 文件內(nèi)容包中間包。文件內(nèi)容中間包用于傳輸文件的具體內(nèi)容，包括包識別特征、文件內(nèi)容以及數(shù)據(jù)包序號信息。值得說明的是：在文件傳輸過程中，由于網(wǎng)絡(luò)丟包等各方面的原因，可能導致數(shù)據(jù)包亂序，這里的數(shù)據(jù)包序號信息保證文件內(nèi)容審計的正確性。

圖3 QQ文件名數(shù)據(jù)包協(xié)議特征Fig.3 Characteristics of file name packet

圖4所示為QQ2009使用TCP直連傳輸文件內(nèi)容的數(shù)據(jù)包的格式特征，其中偏移應用程序0x5處的“0x44 0x44”是命令號，表明該數(shù)據(jù)包為傳輸QQ文件內(nèi)容的數(shù)據(jù)包，接下來的4位表示該文件被傳輸?shù)拇螖?shù)，再接下來的 4位為傳輸?shù)膬?nèi)容包的包序號，這里0x00000000表示該包為QQ文件內(nèi)容傳輸?shù)牡?個數(shù)據(jù)包。

圖4 QQ文件內(nèi)容中間包協(xié)議特征Fig.4 Characteristics of file content packet

(4) 文件內(nèi)容結(jié)束包。該包為文件內(nèi)容的最后一個數(shù)據(jù)包。這種數(shù)據(jù)包包含包識別特征及文件剩余長度信息。圖5所示為QQ2009 UDP方式傳輸時文件內(nèi)容結(jié)束包特征，偏移應用程序 0x10位置處的 0x45 0x48是文件內(nèi)容結(jié)束包的命令字段，標識此包結(jié)束后，文件內(nèi)容已經(jīng)傳輸完畢。命令號后面的 4位0x00000080表示當前包中文件內(nèi)容的大小。

此外，QQ 2010SP1版本增加離線文件傳輸功能，QQ離線傳輸基于HTTP協(xié)議實現(xiàn)，以明文方式傳輸。在離線傳輸?shù)某跏及胁粌H包含包識別特征，亦包含文件名信息，傳輸文件大小及當前傳輸?shù)淖止?jié)數(shù)信息。

圖5 QQ文件內(nèi)容結(jié)束包協(xié)議特征Fig.5 Characteristics of last content packet

2 系統(tǒng)設(shè)計

2.1 FAudit網(wǎng)絡(luò)部署

系統(tǒng)詳細的網(wǎng)絡(luò)結(jié)構(gòu)如圖6所示，F(xiàn)Audit部署在被監(jiān)控局域網(wǎng)內(nèi)任何1臺主機上，在交換機上使用端口映射或其他方式使得安裝有FAudit的計算機可以捕獲流入流出局域網(wǎng)或者在局域網(wǎng)內(nèi)傳遞的所有網(wǎng)絡(luò)數(shù)據(jù)包。

圖6 系統(tǒng)網(wǎng)絡(luò)拓撲Fig.6 Network topology of system

2.2 FAudit系統(tǒng)結(jié)構(gòu)

系統(tǒng)總體實現(xiàn)流程如圖7所示，F(xiàn)Audit包括數(shù)據(jù)采集存儲模塊、協(xié)議分析處理模塊及文件重組還原模塊。

2.2.1 數(shù)據(jù)采集處理模塊

數(shù)據(jù)采集處理模塊主要實現(xiàn)網(wǎng)絡(luò)數(shù)據(jù)包的捕獲及保存，系統(tǒng)在Linux平臺下使用Libpcap+PF_RING的方式實現(xiàn)網(wǎng)絡(luò)數(shù)據(jù)包的捕獲。Libpcap是一個與系統(tǒng)無關(guān)的網(wǎng)絡(luò)數(shù)據(jù)捕獲函數(shù)庫，它繞過 TCP層(UDP層)和IP層的處理過程，直接將數(shù)據(jù)包從數(shù)據(jù)鏈路層拷貝到應用程序緩沖區(qū)中，比傳統(tǒng)的Raw socket方式處理效率要高得多，并且避免 SOCKET_PACKET只在基于 Linux的操作系統(tǒng)中有效定義的問題。但對于Libpcap來講，傳統(tǒng)的處理有很多時間都消耗在系統(tǒng)調(diào)用、中斷、PCI總線帶寬以及內(nèi)存拷貝上，而內(nèi)存拷貝是在 LIBPCAP中占用處理時間最長的過程。通常1個數(shù)據(jù)包被用戶空間應用程序處理需要2次內(nèi)存拷貝：一次是從網(wǎng)卡緩沖區(qū)到系統(tǒng)內(nèi)核緩沖區(qū)，另一次

圖7 系統(tǒng)總體實現(xiàn)流程Fig.7 Structure and implementation process of system

是從內(nèi)核緩沖區(qū)到用戶。應用程序每次對1 024 B內(nèi)存的拷貝時問大約為 l μs[13]。為解決這問題，根據(jù)PF_RING對Libpcap接口原理，通過2層封裝實現(xiàn)該接口。PF_RING機制是Luca Deri在零拷貝的基礎(chǔ)上提出的。PF_RING機制不必修改網(wǎng)卡驅(qū)動。在內(nèi)核中，它以一種帶緩存的協(xié)議簇 PF RING為依托，結(jié)合NAPI技術(shù)，改善網(wǎng)卡中斷響應頻率；在用戶空間，應用程序可以通過 MMAP手段，將網(wǎng)絡(luò)數(shù)據(jù)包直接傳送給應用層的用戶程序，提高系統(tǒng)性能。

2.2.2 協(xié)議分析處理模塊

協(xié)議分析模塊的目標是對捕獲的網(wǎng)絡(luò)數(shù)據(jù)包進行解析，層層解析后提取應用層數(shù)據(jù)。

利用 PCAP抓包類，可以在網(wǎng)絡(luò)上抓到符合TCP/IP協(xié)議棧結(jié)構(gòu)的數(shù)據(jù)包，得到指向包頭的指針。通過指針偏移的定位(標準的數(shù)據(jù)包偏移54 B)，對網(wǎng)絡(luò)數(shù)據(jù)包進行解析，剝離以太網(wǎng)頭部、IP頭、TCP頭(UDP頭)得到應用層數(shù)據(jù)。

通過大量重復實驗分析發(fā)現(xiàn)：IM 文件傳輸使用TCP或 UDP協(xié)議實現(xiàn)。換而言之，系統(tǒng)需要的網(wǎng)絡(luò)數(shù)據(jù)包為IP包。系統(tǒng)協(xié)議分析過程為：數(shù)據(jù)鏈路層只分析以太網(wǎng)協(xié)議。根據(jù)以太網(wǎng)協(xié)議內(nèi)容的分析結(jié)果，判斷以太網(wǎng)類型的值：0x0800，表示協(xié)議為IP協(xié)議，對其深入分析。在分析IP協(xié)議時，根據(jù)協(xié)議類型的值判斷傳輸層協(xié)議類型：如果IP協(xié)議類型字段的值為6或17，表示傳輸層協(xié)議為TCP或UDP，根據(jù)傳輸層協(xié)議特征，將指針偏移，提取應用層數(shù)據(jù)，然后，根據(jù)即時通文件傳輸協(xié)議特征匹配應用層數(shù)據(jù)，提取文件信息。

2.2.3 文件重組還原模塊

圖8所示為文件重組還原模塊處理流程。文件重組還原模塊是 FAudit的核心模塊，采用深度包檢測技術(shù)，實現(xiàn)基于TCP協(xié)議、UDP協(xié)議傳輸?shù)奈募傩孕畔?文件名、文件大小)及文件內(nèi)容信息的審計還原[14]。IM文件審計需首先識別標記出IM文件傳輸所在流(源、目的IP，源、目的端口)，在此基礎(chǔ)上通過讀取匹配數(shù)據(jù)庫中的協(xié)議特征，識別文件名包，提取文件屬性信息(文件大小、文件名等信息)，最后提取文件內(nèi)容信息，對文件內(nèi)容重組還原。識別1條文件傳輸流時將該流狀態(tài)設(shè)置為INITED，等待文件名數(shù)據(jù)數(shù)據(jù)包的到來，提取文件名信息后，等文件內(nèi)容數(shù)據(jù)包的到來，對文件內(nèi)容重組還原，審計得到原文件。

圖8 文件重組還原模塊處理流程Fig.8 Process of file reorganization module

3 關(guān)鍵技術(shù)

3.1 數(shù)據(jù)包捕獲

為提高高速復雜網(wǎng)絡(luò)傳輸環(huán)境中的數(shù)據(jù)包捕獲效率，系統(tǒng)使用一種新型的數(shù)據(jù)包捕獲方式，即基于PF_RING套接字的數(shù)據(jù)包捕獲技術(shù)。PF_RING 技術(shù)融合設(shè)備輪詢機制、NAPI技術(shù)和零拷貝技術(shù)，使用環(huán)形緩沖區(qū)，用來實現(xiàn)內(nèi)核空間和用戶空間的內(nèi)存共享。通過PF_RING 技術(shù)，即使1臺常規(guī)PC 機也能在千兆網(wǎng)絡(luò)環(huán)境下捕獲所有數(shù)據(jù)而不產(chǎn)生丟包。PF_RING 以通用性為目標，提供套接口封裝函數(shù)和Libpcap接口。重新編譯安裝PF_RING補丁的Libpcap后，加載 PF_RING內(nèi)核模塊，就可以通過Socket/Libpcap接口使用PF_RING。

3.2 數(shù)據(jù)包解析

在數(shù)據(jù)包解析過程中，為提高驅(qū)動程序的效率，要盡早丟棄非目標數(shù)據(jù)包。對于每一個數(shù)據(jù)包，算法如下：

(1) 檢查是否是IP 協(xié)數(shù)據(jù)包，不是則對此包不做處理；

(2) 進一步檢查是否是TCP或者UDP 數(shù)據(jù)包，不是則對此包不做處理；

(3) 根據(jù)相應的IM協(xié)議，采用深度包檢測技術(shù)匹配應用層數(shù)據(jù)，提取文件信息，審計還原文件。若匹配不成功，則對此包不做處理。

對于具體的IM 包在解析時，將不同的編碼轉(zhuǎn)換為可顯示打印的ASCII 字符。一般IM 包解析后包括的信息有源IP 原地址和端口號、目標IP 地址和端口號、數(shù)據(jù)包長度和消息內(nèi)容等。

3.3 深度包檢測

深度包檢測[15]是相對傳統(tǒng)包檢測技術(shù)而言的。傳統(tǒng)包檢測技術(shù)主要檢測OSI模型中網(wǎng)絡(luò)層及傳輸層的數(shù)據(jù)，通常是傳輸層的TCP頭和網(wǎng)絡(luò)層的IP頭。系統(tǒng)審計的4種IM軟件QQ，F(xiàn)etion，MSN及雅虎通文件傳輸并非采用固定端口實現(xiàn)。因此，要正確高效的審計 IM 傳輸?shù)奈募仨氝M行深度包檢測。FAudit在大量測試分析獲得即時通訊軟件文件傳輸應用特征分析的基礎(chǔ)上，對應用層有效載荷匹配分析，提取文件信息。

采用深度包檢測技術(shù)，可以大幅度提升系統(tǒng)性能，使系統(tǒng)獲得更高效率的同時，能夠滿足復雜的安全策略和高可用性要求。

4 系統(tǒng)測試

為對FAudit的性能進行分析，以QQ2010 SP2為例，測試FAudit使用各種傳輸方式在各種網(wǎng)絡(luò)環(huán)境下文件傳輸性能。測試功能點包括：普通文件傳輸、多文件傳輸、斷點續(xù)傳、離線文件傳輸及網(wǎng)絡(luò)異常情況下文件傳輸性能。

圖9 測試環(huán)境網(wǎng)絡(luò)拓撲圖Fig.9 Network topology of simulation environment

為保證網(wǎng)絡(luò)測試環(huán)境的可控性與可再現(xiàn)性，本文選擇在實驗室搭建的網(wǎng)絡(luò)實驗測試床與實際測試相結(jié)合的方式進行。測試床實驗的網(wǎng)絡(luò)拓撲如圖9所示，2臺計算機部署在不同的子網(wǎng)之間，中間通過專用的廣域網(wǎng)模擬器WANem連接。廣域網(wǎng)模擬器對網(wǎng)絡(luò)參數(shù)如帶寬、網(wǎng)絡(luò)速度、丟包率等進行設(shè)置來模擬真實的廣域網(wǎng)環(huán)境。在實驗中，本文將初始帶寬設(shè)置為 10 Mb/s，往返時延(RTT)設(shè)置為100 ms，來模擬現(xiàn)實中的廣域網(wǎng)網(wǎng)絡(luò)環(huán)境。在測試過程中，對帶寬、丟包率等參數(shù)進行梯度設(shè)置，直至網(wǎng)速限制在6 kB/s左右，丟包率為10%左右。測試過程中，對文件大小及文件類型不予限制，但測試離線文件傳輸方式限制文件大小最大為20 MB(QQ支持的最大的離線傳輸文件的大小)。當在局域網(wǎng)內(nèi)測試 FAudit性能時，使用真實網(wǎng)絡(luò)。局域網(wǎng)環(huán)境中，默認情況丟包0%，延時低于5 ms。

測試的文件類型包括DOC,PDF，RAR，ZIP，EXE，PNG和ISP等22種文件類型，傳輸?shù)奈募畲笾禐?7 566 kB，最小為1 kB。測試結(jié)果如表2所示。在局域網(wǎng)環(huán)境中，QQ使用TCP直連方式進行文件傳輸，廣域網(wǎng)環(huán)境中使用UDP或者TCP中轉(zhuǎn)方式實現(xiàn)。從測試結(jié)果可知：FAudit幾乎可以在任何的網(wǎng)絡(luò)環(huán)境下完全正確的審計文件。但當速度限制到10 kB/S、丟包率為10%時，發(fā)現(xiàn)1個文件基于IP傳輸，并且使用UDP協(xié)議，但沒有 UDP頭，分析發(fā)現(xiàn)是抓包工具LIBPCAP的問題，導致審計出來的內(nèi)容不完整。由于這種現(xiàn)象的不可重復性，系統(tǒng)對此未作處理。

表2 模擬廣域網(wǎng)環(huán)境實驗床測試結(jié)果Table 2 Simulation results based on WANem

5 結(jié)論

(1) 在對即時通訊軟件文件傳輸應用層特征分析的基礎(chǔ)上，對即時通訊文件審計系統(tǒng)提出有效、可行的設(shè)計方案，并基于此，在Linux平臺下實現(xiàn)一個功能完備、性能良好、可擴展的 IM 文件審計系統(tǒng)(FAudit)。

(2) FAudit在各種網(wǎng)絡(luò)環(huán)境下都能夠?qū)M傳輸?shù)母黝愇募?DOC，ODF，TXT和視頻等)進行有效審計。

(3) FAudit具有良好的可擴展性。IM軟件升級頻繁，同時由于 IM市場巨大，依然不斷有新的廠商推出新型IM，對于這種IM的監(jiān)控只需要通過協(xié)議研究和分析，總結(jié)出新型或者升級的IM協(xié)議格式和特征，并生成新的監(jiān)控規(guī)則，然后添加到系統(tǒng)規(guī)則庫中，就能方便地實現(xiàn)對這類IM的監(jiān)控。

[1] 李遠杰, 劉渭鋒, 張玉清, 等. 主流即時通信軟件通信協(xié)議分析[J]. 計算機應用研究, 2005, 22(7): 243?245.LI Yuan-jie, LIU Wei-feng, ZHANG Yu-qing, et al. Analysis of text message transmitting protocol in popular instant messenger software[J]. Application Research of Computers, 2005, 22(7):243?245.

[2] O’Sullivan S. Instant messaging vs. instant compromise[J].Network Security, 2006(7): 4?6.

[3] LIN Chun-kuan. A study of monitoring technologies in instant messenger[EB/OL]. [2011?06?15]. http://thesis.lib.ncu.edu.tw/ETD-db/ETD-search/getfile?URN=93523042&filename=93523042.pdf.

[4] Xiao Z, Guo L, Tracey J. Understanding instant messaging traffic characteristics[C]//Proc of 27th International Conference on Dislfibuted Computing Systems. Toronto: IEEE Press, 2007:51?58.

[5] LIU Zhi-jun, LIN Wei-li, LI na, et al. Detecting and filtering instant messaging sparn-a global and personalized approach[C]//Proc of 1st/EEE ICNP Workshop on Secure Network Protocols.Boston, USA: IEEE Press, 2005: 9?24.

[6] Kim S. Implementation of the security system for instant messengers[J]. Journal of Systems and Software, 2007, 80(10):1590?1593.

[7] 黃紅桃, 彭宏, 吳健培, 等. 基于 MSN 協(xié)議的網(wǎng)絡(luò)行為審計系統(tǒng)的設(shè)計與實現(xiàn)[J]. 計算機工程, 2007, 33(15): 255?257.HUANG Hong-tao, PENG Hong, WU Jian-pei, et al. Design and implementation of network behavior audit system based on MSN protocol[J]. Computer Engineering, 2007, 33(15): 255?257.

[8] 付安民, 張玉清. 即時通實時監(jiān)控系統(tǒng)的設(shè)計與實現(xiàn)[J]. 通信學報, 2008, 29(10): 165?172.FU An-min, ZHANG Yu-qing. Design and realization of the real-time monitoring system for instant messenger[J]. Journal on Communications, 2008, 29(10): 165?172.

[9] Day M, Rosenberg J, Sugano H. RFC2778: A model for presence and instant messaging[S].

[10] 馬嚴. IPV6下基于SIP/SIMPLE協(xié)議IM的研究與實現(xiàn)[D]. 北京: 北京郵電大學計算機學院, 2009: 5?42.MA Yan. SIP/SIMPLE protocol based IM research and implementation under IPV6[D]. Beijing: Beijing University of Posts and Telecommunication. School of Computer Science,2009: 5?42.

[11] RFC 3921, Extensible messaging and presence protocol (XMPP):Instant messaging and presence[S].

[12] Jennings R B, Nahum E M, Olshefski D P, et al. A study of internet instant messaging and chat protocols[J]. IEEE Network,2006, 20(7): 16?21.

[13] 楊建華, 謝高崗, 李忠誠. 基于Linux內(nèi)核的流量分析方法[J].計算機工程, 2006, 32(8): 67?69.YANG Jian-hua, XIE Gao-gang, LI Zhong-cheng. Linux kernel-based traffic analysis method[J]. Computer Engineering,2006, 32(8): 67?69.

[14] Leung K C, V.o.k. L, YANG Dai-qin. An overview of packet reordering in transmission control protocol (TCP): Problems,solutions, and challenges[J]. IEEE Transactions on Parallel and Distributed Systems, 2007, 18(4): 522?535.

[15] Kumar S, Turner J, Williams J. Advanced algorithms for fast and sealable deep packet inspection[C]//Proc of the 2006 ACM/IEEE symposium on Architecture for networking and communications systems. 2006: 81?92.