陳 旖 張美璟 許發(fā)見

(福建警察學(xué)院計(jì)算機(jī)與信息安全管理系 福建 福州350007)

0 引 言

近年來，移動(dòng)互聯(lián)網(wǎng)發(fā)展迅猛，截至2019年2月，中國手機(jī)網(wǎng)民規(guī)模達(dá)8.17億，網(wǎng)民中使用手機(jī)上網(wǎng)人群的占比為98.6%[1]。相比于傳統(tǒng)的桌面計(jì)算機(jī)，在使用場景上，手機(jī)更貼近生活環(huán)境，使用頻率高，移動(dòng)范圍廣；在信息類型上，手機(jī)蘊(yùn)含更多的個(gè)人信息；在軟件種類上，手機(jī)以移動(dòng)應(yīng)用(App)為主。其中，手機(jī)上安裝的移動(dòng)應(yīng)用App的類型及使用頻率在用戶畫像刻畫[2]、用戶習(xí)慣研究[3]方面具有較高的價(jià)值。例如：頻繁使用購物App的用戶往往被打上購買欲強(qiáng)的標(biāo)簽；反復(fù)開啟同類購物軟件，可能反映出某類用戶存在比價(jià)習(xí)慣等。因此，對手機(jī)上安裝的App類型與使用頻率進(jìn)行識(shí)別和統(tǒng)計(jì)，可以為進(jìn)一步的數(shù)據(jù)挖掘提供數(shù)據(jù)，具有很好的參考價(jià)值。

然而，移動(dòng)互聯(lián)網(wǎng)產(chǎn)生的數(shù)據(jù)量極為龐大，如果采用離線識(shí)別的方式進(jìn)行分析，需占用大量的存儲(chǔ)空間并消耗大量的帶寬進(jìn)行文件傳輸。如果采用在線實(shí)時(shí)分析，則需要在網(wǎng)絡(luò)設(shè)備上直接處理數(shù)據(jù)，而常見的網(wǎng)絡(luò)設(shè)備往往計(jì)算能力受限，因此要求識(shí)別方法應(yīng)避免占用過多的系統(tǒng)資源。

針對移動(dòng)App識(shí)別的問題，文獻(xiàn)[4]提出了一種通過HTTP報(bào)文user-agent字段進(jìn)行識(shí)別的方法，但由于多數(shù)應(yīng)用并未遵循規(guī)范，未使用該字段標(biāo)記自身類型，使得該方法目前可用性較低。文獻(xiàn)[5]提出了一種基于視覺感知特性的應(yīng)用識(shí)別方法，其采用HTTP報(bào)文的頭域和請求信息作為輸入構(gòu)建樣本圖像，再將其輸入二維卷積感知網(wǎng)絡(luò)模型進(jìn)行分類器訓(xùn)練。該方法對流量樣本有較好的適應(yīng)性，但其計(jì)算量大，需采樣后再進(jìn)行離線計(jì)算。文獻(xiàn)[6]提出了一種基于模式匹配的識(shí)別方法，其使用HTTP報(bào)文的Host、URI、cookie等字段構(gòu)建樣本庫，并使用模式匹配算法對未知報(bào)文進(jìn)行分類。該方案需要進(jìn)行深度包檢測來讀取HTTP字段，然而當(dāng)前App開發(fā)已逐步使用加密的HTTPS協(xié)議來取代HTTP協(xié)議，這使得該方案無法讀取到對應(yīng)的HTTP字段，導(dǎo)致其可用性變?nèi)酢?/p>

基于上述研究，本文提出一種適用于資源受限的網(wǎng)絡(luò)設(shè)備的App識(shí)別方法。利用App運(yùn)行時(shí)會(huì)訪問特定域名集合的特性來進(jìn)行識(shí)別，可支持使用HTTPS的App。該方法設(shè)計(jì)了一套輕量級(jí)的轉(zhuǎn)換機(jī)制，可將采集到的報(bào)文數(shù)據(jù)流轉(zhuǎn)換為對應(yīng)的低維度向量，再將向量作為支持向量機(jī)的輸入進(jìn)行訓(xùn)練和識(shí)別。另一方面，為避免占用過多的系統(tǒng)資源，方法使用了布隆過濾器來過濾無關(guān)IP地址，并設(shè)計(jì)了背景流量過濾機(jī)制來減少調(diào)用分類器的次數(shù)。這使得方法對系統(tǒng)資源占用小，可實(shí)現(xiàn)在運(yùn)算能力較弱的接入網(wǎng)關(guān)上直接對手機(jī)App進(jìn)行實(shí)時(shí)在線識(shí)別。此外，由于本方法僅使用臨時(shí)IP標(biāo)識(shí)用戶，可避免App用戶的具體身份信息被泄露。

1 相關(guān)網(wǎng)絡(luò)技術(shù)

隨著移動(dòng)互聯(lián)網(wǎng)技術(shù)的發(fā)展，當(dāng)前的移動(dòng)應(yīng)用開發(fā)行業(yè)已經(jīng)形成了較為通用的開發(fā)范式和框架，App使用的網(wǎng)絡(luò)技術(shù)存在普遍的相似性，其典型的訪問過程如圖1所示。

圖1 App訪問服務(wù)器的典型過程

典型場景下，智能手機(jī)安裝有多款A(yù)pp，App在啟動(dòng)時(shí)會(huì)主動(dòng)與遠(yuǎn)程服務(wù)器通信。App代碼中使用域名標(biāo)識(shí)服務(wù)器，App會(huì)先通過操作系統(tǒng)來訪問DNS服務(wù)器以獲取目標(biāo)服務(wù)器的IP地址，再與其建立TCP連接，最后根據(jù)業(yè)務(wù)邏輯進(jìn)行Web訪問。經(jīng)過對多款主流App報(bào)文的深入分析，可以進(jìn)一步總結(jié)出以下特點(diǎn)。

(1) App普遍使用HTTP/HTTPS協(xié)議與遠(yuǎn)程服務(wù)器通信。其中，HTTP使用明文傳輸，而HTTPS使用SSL/TSL協(xié)議對報(bào)文進(jìn)行加密，可以抵抗深度報(bào)文檢測。隨著安全性需求的提升，目前HTTPS協(xié)議以被廣泛應(yīng)用于App開發(fā)。

(2) App代碼中使用域名來標(biāo)記服務(wù)器，而非IP地址。服務(wù)器使用域名提供服務(wù)地址，可以對外部屏蔽云端服務(wù)器的網(wǎng)絡(luò)IP地址出現(xiàn)變化的情況。例如：服務(wù)器可以提供多個(gè)網(wǎng)絡(luò)運(yùn)營商的IP地址，以優(yōu)化不同網(wǎng)絡(luò)用戶的訪問速度；服務(wù)器也可以主動(dòng)改變域名/IP地址的映射關(guān)系，來實(shí)現(xiàn)對服務(wù)器集群的負(fù)載均衡等。

(3) App依賴操作系統(tǒng)進(jìn)行DNS訪問，可直接使用對應(yīng)API，傳入域名來獲得IP地址，而無須自己維護(hù)域名/IP的映射關(guān)系。操作系統(tǒng)從API收到查詢請求之后，將先在DNS緩存中查找，若存在緩存則直接返回對應(yīng)IP；若未找到，則向DNS服務(wù)器請求目標(biāo)域名的IP地址，再返回給App。DNS服務(wù)器通過DNS響應(yīng)報(bào)文來回復(fù)域名相關(guān)的信息，典型響應(yīng)報(bào)文結(jié)構(gòu)如圖1所示，其報(bào)文中描述了域名“wvcfg.alicdn.com(阿里巴巴緩存服務(wù)器)”的信息，包含該域名的別名、多個(gè)可用的IP地址、管理機(jī)構(gòu)數(shù)據(jù)、附加信息等。系統(tǒng)將這些信息加入DNS緩存中，并根據(jù)網(wǎng)絡(luò)變動(dòng)或超時(shí)等策略更新信息。

(4) App與服務(wù)器域名及服務(wù)器IP之間呈現(xiàn)多對多的關(guān)系。一方面，不同App訪問的服務(wù)器域名存在重疊。這是由于App開發(fā)中往往會(huì)使用到其他廠商的服務(wù)，例如：打車軟件使用地圖廠商提供的定位與導(dǎo)航SDK；部分App使用了微博、微信的第三方登錄接口等。其結(jié)構(gòu)類似于圖1中App1和App2都訪問了共同的域名。另一方面，域名和IP也并非一一對應(yīng)。第一，大多數(shù)域名存在多個(gè)可用的IP地址，如圖1的DNS報(bào)文所示；第二，不同域名的服務(wù)器也可能共用相同的IP地址，例如，高并發(fā)的App普遍使用第三方廠商提供的內(nèi)容分發(fā)網(wǎng)絡(luò)(Content Delivery Network,CDN)來加速數(shù)據(jù)傳輸。CDN緩存服務(wù)器雖對不同App提供了不同的域名，但實(shí)際指向了相同IP地址的緩存服務(wù)器。其結(jié)構(gòu)類似圖1中App1和App2分別訪問了獨(dú)立的域名b和域名c，但實(shí)際上都訪問了IP地址B所對應(yīng)的服務(wù)器集群。

根據(jù)上述分析，由于App間訪問的域名存在重合且域名和IP并非一一對應(yīng)，網(wǎng)關(guān)雖然無法直接通過IP地址識(shí)別到特定App，但可以根據(jù)App訪問指定域名的特性及域名和IP的關(guān)系，從一系列報(bào)文的IP地址中推測出對應(yīng)的App。本文方法基于這一特征進(jìn)行設(shè)計(jì)。

2 方法和模型

2.1 系統(tǒng)建模

2.1.1應(yīng)用場景

本文方法典型的應(yīng)用場景如圖2所示。在典型的中大型企業(yè)網(wǎng)及校園網(wǎng)中，往往存在核心層、匯聚層、接入層三層結(jié)構(gòu)。核心層一般使用高吞吐、高性能和高可用的大型核心交換機(jī)構(gòu)成，用于內(nèi)部主干網(wǎng)之間的通信，以及內(nèi)網(wǎng)與外網(wǎng)間的通信；匯聚層主要用于將眾多的接入層設(shè)備連入核心層；接入層直接面向終端設(shè)備提供網(wǎng)絡(luò)接入服務(wù)。由于終端設(shè)備數(shù)量眾多，因此接入層設(shè)備一般數(shù)量較大，且價(jià)格低廉、功耗低、運(yùn)算能力弱。

圖2 典型應(yīng)用場景

本方法適合部署于接入層設(shè)備，其優(yōu)勢在于：① 可充分利用大量輸入層設(shè)備的剩余算力，無須部署獨(dú)立的運(yùn)算服務(wù)器；② 采用分布式運(yùn)算，避免單點(diǎn)集中式運(yùn)算中出現(xiàn)運(yùn)算性能、網(wǎng)絡(luò)吞吐等瓶頸；③ 核心層、匯聚層對性能、可靠性有較高要求，在接入層增加非關(guān)鍵性的功能對網(wǎng)絡(luò)整體的影響較小。

由于接入層設(shè)備的運(yùn)算和內(nèi)存資源往往受到限制，因此在方法設(shè)計(jì)中需要避免占用過多的系統(tǒng)資源。

2.1.2模型訓(xùn)練與應(yīng)用過程

本文方法分為兩個(gè)步驟進(jìn)行：第一步采集樣本數(shù)據(jù)，并在計(jì)算機(jī)上訓(xùn)練模型并生成參數(shù)；第二步將訓(xùn)練得到的模型及參數(shù)部署到實(shí)際的接入層設(shè)備上，并進(jìn)行相應(yīng)指標(biāo)評(píng)估。

模型訓(xùn)練的過程如圖3所示。首先需要從環(huán)境中采集目標(biāo)App的通信樣本集合，以及其他無關(guān)App的通信樣本作為背景流量樣本。接著，從通信樣本中過濾出DNS報(bào)文，并解析生成域名/IP地址的映射表和域名集合。再根據(jù)樣本報(bào)文的IP地址，將App樣本中所有報(bào)文映射到域名集合中，從而將一個(gè)樣本文件生成一個(gè)對應(yīng)的向量。向量的每個(gè)維度對應(yīng)一個(gè)域名，其大小表示樣本中訪問該域名的次數(shù)。由于生成的向量維度很高，本文方法基于Jaccard包相似度設(shè)計(jì)了一種降維算法，用于對樣本向量進(jìn)行降維。經(jīng)過降維后的樣本向量集合再作為訓(xùn)練集輸入支持向量機(jī)(Support vector machine,SVM)進(jìn)行分類訓(xùn)練。另外，本文還設(shè)計(jì)了一種背景報(bào)文過濾器，以降低方法對系統(tǒng)計(jì)算資源的占用。在訓(xùn)練過程結(jié)束之后，將輸出域名/IP映射表、降維算法參數(shù)、背景報(bào)文過濾器參數(shù)、SVM分類器模型參數(shù)，供識(shí)別過程使用。

圖3 模型訓(xùn)練流程

識(shí)別的過程如圖4所示。在接入設(shè)備上，識(shí)別程序循環(huán)抓取報(bào)文，如果抓取到DNS報(bào)文，則解析報(bào)文并更新域名/IP映射表。如果抓取到通信報(bào)文，則將其IP地址使用布隆過濾器檢查，如果其IP地址屬于某個(gè)域名，則將其加入到滑動(dòng)窗口隊(duì)列中。識(shí)別程序周期性地將滑動(dòng)窗口中的報(bào)文映射到域名集合，并進(jìn)行降維，得到待檢測的向量。再將向量使用背景報(bào)文過濾器進(jìn)行檢查，如果檢查通過再使用SVM分類器進(jìn)行分類，得到分類結(jié)果。

圖4 運(yùn)行中識(shí)別流程

2.2 樣本采集和數(shù)據(jù)變換

2.2.1報(bào)文樣本采集

在樣本采集環(huán)境中，存在一臺(tái)運(yùn)行嵌入式Linux系統(tǒng)的無線網(wǎng)關(guān)、一臺(tái)安卓智能手機(jī)、一臺(tái)通用計(jì)算機(jī)。其中，安卓智能手機(jī)通過Wi-Fi連接無線網(wǎng)關(guān)，使用USB線連接計(jì)算機(jī)，并開啟USB調(diào)試模式，且禁止后臺(tái)App運(yùn)行；計(jì)算機(jī)通過網(wǎng)線連接網(wǎng)關(guān)，可使用SSH協(xié)議登錄網(wǎng)關(guān)的控制臺(tái)，并可通過安卓調(diào)試橋(Android Debug Bridge tools，ADB)連接上安卓手機(jī)的開發(fā)調(diào)試服務(wù)。

對App采樣時(shí)，計(jì)算機(jī)先通過控制臺(tái)命令，在網(wǎng)關(guān)上使用抓包工具TCPDUMP對無線接口進(jìn)行抓包，再通過ADB命令觸發(fā)待采樣的App運(yùn)行。待抓包結(jié)束之后，計(jì)算機(jī)通過命令控制TCPDUMP工具停止抓包并生成cap格式的抓包文件，再使用ADB命令控制手機(jī)關(guān)閉App進(jìn)程。對該App的采樣到此結(jié)束，計(jì)算機(jī)在進(jìn)行延時(shí)等待后，將對下一App進(jìn)行采樣。在對所有App完成報(bào)文采樣后，計(jì)算機(jī)將把抓包文件下載到本地。

本文針對安卓市場上不同類別且下載量較大的50款A(yù)pp進(jìn)行采樣，在不同的時(shí)間點(diǎn)，共采樣40輪。將其中30輪作為訓(xùn)練樣本，其他10輪作為測試樣本。

2.2.2數(shù)據(jù)探索與預(yù)處理

使用分析工具Wireshark對采集的樣本文件進(jìn)行數(shù)據(jù)探索，可以發(fā)現(xiàn)App通信樣本中存在共性。本方法根據(jù)這些共性，制定出如下幾項(xiàng)樣本預(yù)處理的規(guī)則：

(1) 以握手報(bào)文數(shù)量作為訪問服務(wù)器頻繁程度的度量。App每次啟動(dòng)時(shí)，TCP的握手報(bào)文數(shù)量一般大致相同。這是因?yàn)锳pp會(huì)與哪些服務(wù)器通信、將創(chuàng)建幾個(gè)TCP連接通信，都是程序中固化的。而App的通信報(bào)文數(shù)量不穩(wěn)定，這是因?yàn)锳pp的緩存更新功能往往是周期性執(zhí)行的，更新周期及數(shù)據(jù)大小差異等原因，都導(dǎo)致通信數(shù)據(jù)量并不穩(wěn)定。

因此，本文方法在統(tǒng)計(jì)App與某個(gè)服務(wù)器之間的通信報(bào)文數(shù)量時(shí)，僅統(tǒng)計(jì)其中TCP握手報(bào)文個(gè)數(shù)。

(2) 統(tǒng)計(jì)握手報(bào)文的時(shí)間范圍為10秒。啟動(dòng)過程中，App往往先顯示啟動(dòng)圖片，同時(shí)與服務(wù)器進(jìn)行頻繁的通信。大部分的TCP握手報(bào)文都集中在首個(gè)握手報(bào)文發(fā)出后的10秒內(nèi)發(fā)出。因此，本方法選取App啟動(dòng)后，首個(gè)握手報(bào)文發(fā)出后的10秒內(nèi)的握手報(bào)文進(jìn)行統(tǒng)計(jì)。

(3) App以一組10個(gè)為單位進(jìn)行分組識(shí)別?，F(xiàn)實(shí)環(huán)境中，App類型繁多。若把所有待測App一起進(jìn)行分類訓(xùn)練，將大大增加訓(xùn)練的難度，影響模型分類質(zhì)量。

為解決上述問題，本文方法將App進(jìn)行分組訓(xùn)練。首先將待分類的App按10個(gè)一組進(jìn)行分組，得到數(shù)據(jù)集F={F1,F2,…,FI},共I組數(shù)據(jù)組，若出現(xiàn)App數(shù)量不足一組時(shí)，則填充全0的樣本。若使用F1數(shù)據(jù)來訓(xùn)練模型時(shí)，則待檢測App組成的數(shù)據(jù)集為FApp={F1}，而其他App樣本則作為無關(guān)的背景報(bào)文組成數(shù)據(jù)集FBG={F2,F3，…,FI}。在訓(xùn)練過程中，F(xiàn)1-FI將迭代作為FApp訓(xùn)練模型，最終生成多組模型參數(shù)。在檢測階段，待分類的數(shù)據(jù)可被多組不同參數(shù)的模型進(jìn)行分類，進(jìn)而得到分類結(jié)果。

按上述分組策略，本文方法以組為單位處理數(shù)據(jù)。故可將采集的50款A(yù)pp樣本分為F1-F5共5組。其中F1包含A0-A9共10款應(yīng)用，分別為淘寶、支付寶等常用App。在后續(xù)內(nèi)容中，以F1為例展示一組數(shù)據(jù)的處理效果。即以F1作為FApp，以F2-F5作為FBG。

2.2.3樣本數(shù)據(jù)變換

處理報(bào)文樣本時(shí)，首先遍歷集合FApp中所有樣本文件，從DNS報(bào)文中解析所有域名，再剔除未被訪問域名，從而生成域名集合N={n1,n2,…,nx}，以及域名/IP的映射表。之后，再獨(dú)立解析FApp中每個(gè)樣本文件，先將文件中首個(gè)握手報(bào)文出現(xiàn)的10秒內(nèi)的所有握手報(bào)文過濾出來，再將握手報(bào)文訪問的IP地址輸入域名/IP映射表，得到報(bào)文訪問的域名，并將對應(yīng)域名的統(tǒng)計(jì)值加1。處理結(jié)束后，每個(gè)文件都會(huì)生成一個(gè)數(shù)據(jù)記錄。定義向量d=(Cn1,Cn2,…,Cnx)來表示該數(shù)據(jù)記錄。其中，Cnx表示該樣本中App向域名nx發(fā)出的握手報(bào)文個(gè)數(shù)。如果將每個(gè)域名nx看作一個(gè)軸，則Cn1-Cnx可以看作樣本在各個(gè)軸上投影的值。故可以將樣本文件生成的記錄用向量d來表示，其維度等于域名集合N的元素個(gè)數(shù)。

由于FApp中包含十類不同App，可將App按類別使用A0-A9進(jìn)行編號(hào)，并使用DA0來表示A0類樣本生成的向量d組成的集合。則FApp中所有文件處理完成之后，最終將生成集合DApp={DA0,DA1,…,DA9}。

圖5直觀地展示了DApp中數(shù)據(jù)的分布特點(diǎn)，其數(shù)據(jù)來源于淘寶、支付寶等10款常見的App。其中，橫軸上的每個(gè)點(diǎn)分別對應(yīng)集合N中的一個(gè)域名nx；縱軸上的一個(gè)點(diǎn)分別對應(yīng)DA0-DA9中的一個(gè)向量d；橫軸與縱軸交匯點(diǎn)的灰度值表示樣本向量d在域名nx上的映射值Cnx，也反映出該樣本對域名nx訪問的頻繁程度。

圖5 App訪問域名的分布特點(diǎn)

可以看出，同類型App生成的向量d相似度高，而不同類型App生成的向量d差異較大。不同類型App訪問的域名存在少量重合。

2.3 降維與過濾背景流量

2.3.1降 維

從數(shù)據(jù)探索中可以看出，App樣本生成的向量d的維度較高，其數(shù)值約在100～200之間。向量d的維度過高將導(dǎo)致運(yùn)算量大且內(nèi)存占用多。因此，需要對d做降維。

常見的降維方法有主成分分析(PCA)等。PCA技術(shù)可用于對高維空間下的點(diǎn)進(jìn)行分析，得到新的若干條最關(guān)鍵的坐標(biāo)軸。原始的高維數(shù)據(jù)可以投影到這些關(guān)鍵的坐標(biāo)軸上得到新的數(shù)據(jù)。這些新的數(shù)據(jù)的維度較小，并能較好地體現(xiàn)原有數(shù)據(jù)的特征[7]。

以圖5中的A0-A9進(jìn)行實(shí)驗(yàn)，將集合DApp中所有的向量d組成矩陣M。其中，矩陣M的行數(shù)等于樣本數(shù)量，由于存在10個(gè)App，每個(gè)App有30個(gè)樣本，故共有300行；矩陣列數(shù)為向量d的維度，為157。使用PCA對M進(jìn)行降維，保留90%的信息，得到降維后的矩陣M的列數(shù)為26。若再繼續(xù)降低保留的信息量，則出現(xiàn)降維效果增加緩慢，而特征損失增加較快的情況。這將導(dǎo)致樣本信息損失較多?？紤]到網(wǎng)絡(luò)設(shè)備的內(nèi)存和運(yùn)算能力較弱，使用分類器對26維的數(shù)據(jù)進(jìn)行運(yùn)算對系統(tǒng)性能影響依舊較大。因此，由于應(yīng)用環(huán)境的限制，PCA技術(shù)不是本文方法最佳的降維方案。

在考慮了設(shè)備運(yùn)算能力和實(shí)際數(shù)據(jù)特征的基礎(chǔ)上，本文設(shè)計(jì)了一種基于Jaccard包相似度的降維算法。在PCA技術(shù)中，算法會(huì)從數(shù)據(jù)中尋找最佳的數(shù)據(jù)軸。而在本環(huán)境的數(shù)據(jù)中，已知矩陣M中存在10類App樣本，且同類App樣本之間相似度高。因此，本算法新建立一個(gè)10維的空間，空間中的軸分別代表A0-A9十類App，各軸之間相互正交。原數(shù)據(jù)向量d轉(zhuǎn)換到新空間上的向量j的轉(zhuǎn)換過程可分為兩步處理：

(1) 由樣本報(bào)文變換得到的樣本向量集合DApp={DA0,DA1,…,DA9}來計(jì)算各App的樣本向量均值集合Dmeans=(dA0-means,dA1-means,…,dA9-means)。計(jì)算過程即將同類App的樣本向量進(jìn)行向量加法運(yùn)算后，除以樣本數(shù)量。設(shè)某個(gè)編號(hào)為Ay的App存在樣本集合DAy，集合中包含d0-dk共k個(gè)樣本向量，則該App的樣本向量的均值dAy-means=(d0+d1+…+dk)/k。

(2) 使用Jaccard包算法計(jì)算待測向量dx與Dmeans中每一類App的樣本向量均值的相似度Sy。該算法以兩個(gè)集合的交集除以并集來計(jì)算其相似度。其中，以某個(gè)元素在兩個(gè)集合出現(xiàn)的最小次數(shù)作為其在交集中的個(gè)數(shù)；以某個(gè)元素在兩個(gè)集合中出現(xiàn)的最大次數(shù)作為其在并集中的個(gè)數(shù)。運(yùn)算時(shí)，可將向量的一個(gè)維度視作集合中的一種元素，將該維度的數(shù)值視作對應(yīng)集合元素出現(xiàn)的次數(shù)?？啥x函數(shù)INTER和UNION用于計(jì)算兩個(gè)向量的交集與并集，則dx與dAy-means的相似度Sy=INTER(dx,dAy-means)/UNION(dx,dAy-means)。將dx分別與dA0-means-dA9-means進(jìn)行計(jì)算后，即可得到降維后的向量j=(S0,S1,…,S9)。

轉(zhuǎn)換前的dx和dAy-means的維度均等于域名集合N的元素個(gè)數(shù)，轉(zhuǎn)換后的向量j的維度固定為10。該降維算法的可解釋性也較好。其轉(zhuǎn)換過程可視為計(jì)算待測點(diǎn)到樣本均值之間的相似度，其數(shù)值范圍在[0，1]之間，同時(shí)完成了數(shù)據(jù)歸一化的操作。

圖6直觀展示轉(zhuǎn)換后的數(shù)據(jù)，其中：橫軸表示新空間中A0-A9十類App對應(yīng)的數(shù)據(jù)軸；縱軸表示樣本點(diǎn)與對應(yīng)軸的相似度。圖中每條線表示某一類App的樣本點(diǎn)在某個(gè)軸上映射出的相似度數(shù)值。

圖6 樣本降維效果

可以看出，一類App的樣本在代表自身類別的軸上的映射的數(shù)據(jù)值較大，在其他軸上的映射的數(shù)值較小。同類樣本點(diǎn)在特定軸上映射的數(shù)值分布在一定區(qū)間內(nèi)，該特征可被分類器用于識(shí)別App類型。

2.3.2過濾背景流量

在移動(dòng)互聯(lián)網(wǎng)環(huán)境中，數(shù)量龐大的App時(shí)時(shí)刻刻都在生成通信報(bào)文，這些報(bào)文中僅有少量屬于待識(shí)別App生成的報(bào)文。相對于待識(shí)別的App生成的報(bào)文，其他App的生成的報(bào)文構(gòu)成了背景流量。背景流量的報(bào)文數(shù)量龐大，如果都輸入到分類器進(jìn)行判斷，將占用大量的運(yùn)算資源來處理無關(guān)數(shù)據(jù)流量。因此，本文設(shè)計(jì)了一種背景報(bào)文過濾機(jī)制來降低背景報(bào)文造成的運(yùn)算資源消耗。

為探索目標(biāo)App報(bào)文和背景流量報(bào)文的分布特點(diǎn)，可構(gòu)造出圖7進(jìn)行分析，其中：橫軸表示A0-A9對應(yīng)的數(shù)據(jù)軸；縱軸表示樣本點(diǎn)與對應(yīng)軸的相似度。圖中深色點(diǎn)為待檢測的樣本點(diǎn)，淺色點(diǎn)為背景報(bào)文樣本在對應(yīng)軸上映射出的相似度數(shù)值。背景報(bào)文樣本的生成過程，即從背景報(bào)文數(shù)據(jù)集FBG中隨機(jī)選取200個(gè)樣本，再將樣本進(jìn)行數(shù)據(jù)轉(zhuǎn)換并降維，降維后的向量值即樣本點(diǎn)映射到各軸上的相似度數(shù)值。

圖7 目標(biāo)App報(bào)文和背景流量報(bào)文的分布情況

可以看出，某類App的報(bào)文樣本在代表自身類型的軸上的映射的數(shù)據(jù)值較大，而背景流量映射出的值較小。過濾機(jī)制將利用這一特性計(jì)算出一組閾值，如果樣本在某個(gè)維度上的數(shù)值大于閾值，才使用分類器對樣本進(jìn)行分類，否則直接按背景報(bào)文處理。本文方法以軸上背景報(bào)文樣本的上五分位為閾值，即過濾掉后80%的背景報(bào)文。各軸對應(yīng)的閾值如圖7中的虛線所示，可以看出，僅20%的背景流量和屬于目標(biāo)App的樣本能通過閾值過濾。

2.4 SVM訓(xùn)練

支持向量機(jī)SVM的基本思想是尋找一個(gè)最優(yōu)分類超平面將訓(xùn)練樣本分開[8]。本文方法使用SVM作為分類器對樣本進(jìn)行多分類。在數(shù)據(jù)變化階段中，App和背景流量的樣本已經(jīng)被轉(zhuǎn)換為10維的向量。訓(xùn)練時(shí)，將向量的每個(gè)維度的數(shù)值按序組成數(shù)組，作為訓(xùn)練輸入；而向量對應(yīng)的樣本類型作為訓(xùn)練輸出，將App樣本按類別使用數(shù)字0至9進(jìn)行標(biāo)識(shí)。實(shí)驗(yàn)中發(fā)現(xiàn)，若所有背景樣本共用單一類別時(shí)，分類準(zhǔn)確率較低；而每5～6種背景樣本共用一種類別時(shí)，準(zhǔn)確率較高。故采用經(jīng)驗(yàn)值，將每6類背景樣本共用一個(gè)大于9的數(shù)值標(biāo)識(shí)。數(shù)據(jù)集中存在500個(gè)樣本，其中含10類App作為識(shí)別目標(biāo)，共300個(gè)；含40類App作為背景流量，共200個(gè)。

訓(xùn)練時(shí)，將數(shù)據(jù)集使用十折交叉驗(yàn)證法來劃分訓(xùn)練集和測試集，采用C_SVC類型的SVM分類器，使用一對一法(One-versus-one,OVO)來實(shí)現(xiàn)多分類。相比于一對多法(One-versus-rest,OVR)，在App版本更新時(shí)，OVO可避免對所有的分類器進(jìn)行重新訓(xùn)練。

2.5 使用模型進(jìn)行識(shí)別

相比于樣本采集及訓(xùn)練的過程，使用模型識(shí)別的過程還需要增加以下工作：

(1) 使用滑動(dòng)窗口生成待測樣本。在樣本采集中，App啟動(dòng)和抓包時(shí)間是人為控制的，而在實(shí)際的環(huán)境中，App啟動(dòng)時(shí)間是未知的。為了從環(huán)境中動(dòng)態(tài)地生成待測樣本，本文方法設(shè)計(jì)了一個(gè)滑動(dòng)窗口?；瑒?dòng)窗口內(nèi)存在一個(gè)隊(duì)列，用于保存當(dāng)前時(shí)間點(diǎn)至前10秒范圍內(nèi)的握手報(bào)文。當(dāng)有新報(bào)文到達(dá)時(shí)，加入隊(duì)列頭。窗口存在一個(gè)以1秒為周期的定時(shí)器，定時(shí)器到時(shí)時(shí)，先刪除隊(duì)尾超時(shí)的節(jié)點(diǎn)，再遍歷滑動(dòng)窗口隊(duì)列中所有報(bào)文，將報(bào)文進(jìn)行樣本數(shù)據(jù)轉(zhuǎn)換，得到一個(gè)待識(shí)別的向量dx。進(jìn)而可對dx進(jìn)行降維、過濾和識(shí)別等操作。

(2) 使用布隆過濾器過濾無關(guān)IP。在數(shù)據(jù)探索中發(fā)現(xiàn)，域名/IP映射表中的IP地址數(shù)量約為1 500至2 000個(gè)。為避免大量使用無關(guān)IP的報(bào)文被加入隊(duì)列，本文方法使用布隆過濾器來快速檢查報(bào)文的IP是否存在于域名/IP映射表中。布隆過濾器由多個(gè)哈希函數(shù)和一個(gè)很長的二進(jìn)制數(shù)組組成，可用于快速檢查某個(gè)元素是否存在于一個(gè)很大的集合中。本文方法的過濾器使用了JSHash、RSHash、SDBMHash、PJWHash四種哈希函數(shù)，二進(jìn)制數(shù)組占用1 250字節(jié)。根據(jù)布隆過濾器的性質(zhì)，假設(shè)哈希函數(shù)能均勻地散列數(shù)據(jù)，有效IP為2 000個(gè)的情況下，則有約90.8%的無關(guān)IP可被過濾。

(3) 實(shí)時(shí)更新域名/IP映射表。根據(jù)對網(wǎng)絡(luò)技術(shù)的分析，域名與IP地址的對應(yīng)關(guān)系是隨著環(huán)境而變化的。從樣本中生成的域名/IP映射表需要根據(jù)運(yùn)行環(huán)境的變化而更新。因此，本文方法在識(shí)別環(huán)境中也需要實(shí)時(shí)抓取DNS報(bào)文，并根據(jù)DNS解析的數(shù)據(jù)來更新映射表。

3 實(shí) 驗(yàn)

3.1 實(shí)驗(yàn)環(huán)境與算法實(shí)現(xiàn)

實(shí)驗(yàn)使用一臺(tái)基于Mediatek-MT7620芯片方案的無線接入網(wǎng)關(guān)進(jìn)行驗(yàn)證，其主頻為580 MHz的MIPS架構(gòu)處理器，內(nèi)存為123 MB，支持兩個(gè)百兆以太網(wǎng)口，以及2.4 GHz頻段Wi-Fi接入。設(shè)備運(yùn)行OpenWrt系統(tǒng),該系統(tǒng)是一種適用于嵌入式網(wǎng)絡(luò)設(shè)備的Linux發(fā)行版，具有強(qiáng)大的擴(kuò)展性[9]。

本文方法的代碼實(shí)現(xiàn)主要分為兩個(gè)部分，第一部分是運(yùn)行在計(jì)算機(jī)端的模型訓(xùn)練程序，使用Python實(shí)現(xiàn)；第二部分是運(yùn)行在無線網(wǎng)關(guān)平臺(tái)上的識(shí)別程序。由于網(wǎng)關(guān)只能支持C/C++語言編程，故使用C語言實(shí)現(xiàn)了識(shí)別程序，經(jīng)交叉編譯后部署到設(shè)備上。其中，實(shí)時(shí)抓包使用了LIBCAP庫[10]，SVM分類器使用了LIBSVM庫[11]的實(shí)現(xiàn)。另外，實(shí)驗(yàn)中使用LIBCAP庫編寫了一個(gè)報(bào)文重放工具，可解析cap格式的抓包文件，并將其中抓取的報(bào)文重放到網(wǎng)絡(luò)接口中。

3.2 識(shí)別效果評(píng)估

為評(píng)估模型識(shí)別的效果，實(shí)驗(yàn)使用重放工具將測試集對應(yīng)的抓包文件重放到網(wǎng)絡(luò)中，由識(shí)別程序進(jìn)行在線識(shí)別。因使用十折交叉驗(yàn)證法測試，故識(shí)別程序需分別使用10個(gè)SVM模型進(jìn)行識(shí)別，重放工具則分別重放10組測試集對應(yīng)的抓包文件。10組交叉驗(yàn)證共生成500個(gè)識(shí)別結(jié)果。

識(shí)別程序在實(shí)驗(yàn)中的識(shí)別效果如圖8所示。可以看出，程序?qū)δ繕?biāo)App報(bào)文的識(shí)別效果較好，并可以正確識(shí)別出大部分的背景流量，但部分特征和目標(biāo)App相似的背景流量可能會(huì)被誤識(shí)別為目標(biāo)App?？墒褂脺?zhǔn)確率P來評(píng)估識(shí)別效果，準(zhǔn)確率P=TP/(TP+FP)，其中TP為分類正確的樣本數(shù)，F(xiàn)P為分類錯(cuò)誤的樣本數(shù)。則在當(dāng)前的測試集條件下，分類器的識(shí)別準(zhǔn)確率約為94.4%。

圖8 識(shí)別結(jié)果的混淆矩陣

3.3 資源占用情況評(píng)估

為評(píng)估本方法對系統(tǒng)資源占用情況，實(shí)驗(yàn)中使用top命令以1秒為周期定時(shí)采集識(shí)別程序所在進(jìn)程的CPU及內(nèi)存利用率，其結(jié)果如圖9所示?？梢钥闯?，CPU利用率在0～2%之間波動(dòng)，呈現(xiàn)周期性變化，這和程序?qū)瑒?dòng)窗口進(jìn)行周期性處理的特性相吻合。程序占用約1 025 KB內(nèi)存，占用率約為0.8%。

圖9 CPU與內(nèi)存占用率

對于網(wǎng)絡(luò)設(shè)備而言，吞吐量指設(shè)備在單位時(shí)間內(nèi)發(fā)送的數(shù)據(jù)量，體現(xiàn)了設(shè)備轉(zhuǎn)發(fā)報(bào)文的能力，是評(píng)估設(shè)備性能的重要指標(biāo)。為評(píng)估本方法對設(shè)備轉(zhuǎn)發(fā)性能的影響，設(shè)計(jì)了一種壓力測試實(shí)驗(yàn)，該實(shí)驗(yàn)中存在兩臺(tái)計(jì)算機(jī)分別通過以太網(wǎng)連接實(shí)驗(yàn)網(wǎng)關(guān)，使用網(wǎng)絡(luò)吞吐量測試工具iperf[12]，從一臺(tái)計(jì)算機(jī)向另外一臺(tái)計(jì)算機(jī)以TCP連接的最大帶寬發(fā)送數(shù)據(jù)。在以下三個(gè)場景中觀察吞吐量的變化：① 識(shí)別程序未運(yùn)行；② 識(shí)別程序運(yùn)行，但環(huán)境中未運(yùn)行目標(biāo)App；③ 識(shí)別程序運(yùn)行，且環(huán)境中存在待識(shí)別App周期性啟動(dòng)。

實(shí)驗(yàn)結(jié)果如圖10所示，在場景1和場景2中，設(shè)備吞吐量都較為平穩(wěn)，其均值分別為94.06 Mbit/s和93.96 Mbit/s；在場景3中，設(shè)備吞吐量存在小范圍波動(dòng)，其均值為91.64 Mbit/s，較場景1僅略微降低。

圖10 系統(tǒng)轉(zhuǎn)發(fā)吞吐量

4 結(jié) 語

本文針對當(dāng)前App識(shí)別方法運(yùn)算量較大，難以進(jìn)行在線識(shí)別的問題，提出了一種基于域名訪問范圍特征的App實(shí)時(shí)識(shí)別方法。該方法的優(yōu)勢一方面在于其處理速度快，可以做到在線識(shí)別，避免了離線識(shí)別中抓包文件的存儲(chǔ)和傳輸消耗；另一方面，對系統(tǒng)資源占用較小，可以直接在資源受限的嵌入式網(wǎng)關(guān)中運(yùn)行。但本文方法也存在不足之處：(1) 部分App進(jìn)行大版本升級(jí)后，訪問的域名集合會(huì)出現(xiàn)明顯變化，導(dǎo)致識(shí)別失??；(2) 同一公司開發(fā)的App訪問的域名較為相似，易產(chǎn)生誤判。這些都是可進(jìn)一步優(yōu)化的問題。除了本文方法收集的信息外，用戶App使用特征還有很多，如用戶年齡段、就職行業(yè)與手機(jī)平臺(tái)等，對這些特征的挖掘與分析可作為進(jìn)一步研究的方向。