適用于資源受限設備的移動應用類別實時識別方法

陳 旖 張美璟 許發見

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

0 引 言

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

然而，移動互聯網產生的數據量極為龐大，如果采用離線識別的方式進行分析，需占用大量的存儲空間并消耗大量的帶寬進行文件傳輸。如果采用在線實時分析，則需要在網絡設備上直接處理數據，而常見的網絡設備往往計算能力受限，因此要求識別方法應避免占用過多的系統資源。

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

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

1 相關網絡技術

隨著移動互聯網技術的發展，當前的移動應用開發行業已經形成了較為通用的開發范式和框架，App使用的網絡技術存在普遍的相似性，其典型的訪問過程如圖1所示。

圖1 App訪問服務器的典型過程

典型場景下，智能手機安裝有多款App，App在啟動時會主動與遠程服務器通信。App代碼中使用域名標識服務器，App會先通過操作系統來訪問DNS服務器以獲取目標服務器的IP地址，再與其建立TCP連接，最后根據業務邏輯進行Web訪問。經過對多款主流App報文的深入分析，可以進一步總結出以下特點。

(1) App普遍使用HTTP/HTTPS協議與遠程服務器通信。其中，HTTP使用明文傳輸，而HTTPS使用SSL/TSL協議對報文進行加密，可以抵抗深度報文檢測。隨著安全性需求的提升，目前HTTPS協議以被廣泛應用于App開發。

(2) App代碼中使用域名來標記服務器，而非IP地址。服務器使用域名提供服務地址，可以對外部屏蔽云端服務器的網絡IP地址出現變化的情況。例如：服務器可以提供多個網絡運營商的IP地址，以優化不同網絡用戶的訪問速度；服務器也可以主動改變域名/IP地址的映射關系，來實現對服務器集群的負載均衡等。

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

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

根據上述分析，由于App間訪問的域名存在重合且域名和IP并非一一對應，網關雖然無法直接通過IP地址識別到特定App，但可以根據App訪問指定域名的特性及域名和IP的關系，從一系列報文的IP地址中推測出對應的App。本文方法基于這一特征進行設計。

2 方法和模型

2.1 系統建模

2.1.1應用場景

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

圖2 典型應用場景

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

由于接入層設備的運算和內存資源往往受到限制，因此在方法設計中需要避免占用過多的系統資源。

2.1.2模型訓練與應用過程

本文方法分為兩個步驟進行：第一步采集樣本數據，并在計算機上訓練模型并生成參數；第二步將訓練得到的模型及參數部署到實際的接入層設備上，并進行相應指標評估。

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

圖3 模型訓練流程

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

圖4 運行中識別流程

2.2 樣本采集和數據變換

2.2.1報文樣本采集

在樣本采集環境中，存在一臺運行嵌入式Linux系統的無線網關、一臺安卓智能手機、一臺通用計算機。其中，安卓智能手機通過Wi-Fi連接無線網關，使用USB線連接計算機，并開啟USB調試模式，且禁止后臺App運行；計算機通過網線連接網關，可使用SSH協議登錄網關的控制臺，并可通過安卓調試橋(Android Debug Bridge tools，ADB)連接上安卓手機的開發調試服務。

對App采樣時，計算機先通過控制臺命令，在網關上使用抓包工具TCPDUMP對無線接口進行抓包，再通過ADB命令觸發待采樣的App運行。待抓包結束之后，計算機通過命令控制TCPDUMP工具停止抓包并生成cap格式的抓包文件，再使用ADB命令控制手機關閉App進程。對該App的采樣到此結束，計算機在進行延時等待后，將對下一App進行采樣。在對所有App完成報文采樣后，計算機將把抓包文件下載到本地。

本文針對安卓市場上不同類別且下載量較大的50款App進行采樣，在不同的時間點，共采樣40輪。將其中30輪作為訓練樣本，其他10輪作為測試樣本。

2.2.2數據探索與預處理

使用分析工具Wireshark對采集的樣本文件進行數據探索，可以發現App通信樣本中存在共性。本方法根據這些共性，制定出如下幾項樣本預處理的規則：

(1) 以握手報文數量作為訪問服務器頻繁程度的度量。App每次啟動時，TCP的握手報文數量一般大致相同。這是因為App會與哪些服務器通信、將創建幾個TCP連接通信，都是程序中固化的。而App的通信報文數量不穩定，這是因為App的緩存更新功能往往是周期性執行的，更新周期及數據大小差異等原因，都導致通信數據量并不穩定。

因此，本文方法在統計App與某個服務器之間的通信報文數量時，僅統計其中TCP握手報文個數。

(2) 統計握手報文的時間范圍為10秒。啟動過程中，App往往先顯示啟動圖片，同時與服務器進行頻繁的通信。大部分的TCP握手報文都集中在首個握手報文發出后的10秒內發出。因此，本方法選取App啟動后，首個握手報文發出后的10秒內的握手報文進行統計。

(3) App以一組10個為單位進行分組識別?，F實環境中，App類型繁多。若把所有待測App一起進行分類訓練，將大大增加訓練的難度，影響模型分類質量。

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

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

2.2.3樣本數據變換

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

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

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

圖5 App訪問域名的分布特點

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

2.3 降維與過濾背景流量

2.3.1降 維

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

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

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

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

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

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

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

圖6直觀展示轉換后的數據，其中：橫軸表示新空間中A0-A9十類App對應的數據軸；縱軸表示樣本點與對應軸的相似度。圖中每條線表示某一類App的樣本點在某個軸上映射出的相似度數值。

圖6 樣本降維效果

可以看出，一類App的樣本在代表自身類別的軸上的映射的數據值較大，在其他軸上的映射的數值較小。同類樣本點在特定軸上映射的數值分布在一定區間內，該特征可被分類器用于識別App類型。

2.3.2過濾背景流量

在移動互聯網環境中，數量龐大的App時時刻刻都在生成通信報文，這些報文中僅有少量屬于待識別App生成的報文。相對于待識別的App生成的報文，其他App的生成的報文構成了背景流量。背景流量的報文數量龐大，如果都輸入到分類器進行判斷，將占用大量的運算資源來處理無關數據流量。因此，本文設計了一種背景報文過濾機制來降低背景報文造成的運算資源消耗。

為探索目標App報文和背景流量報文的分布特點，可構造出圖7進行分析，其中：橫軸表示A0-A9對應的數據軸；縱軸表示樣本點與對應軸的相似度。圖中深色點為待檢測的樣本點，淺色點為背景報文樣本在對應軸上映射出的相似度數值。背景報文樣本的生成過程，即從背景報文數據集FBG中隨機選取200個樣本，再將樣本進行數據轉換并降維，降維后的向量值即樣本點映射到各軸上的相似度數值。

圖7 目標App報文和背景流量報文的分布情況

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

2.4 SVM訓練

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

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

2.5 使用模型進行識別

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

(1) 使用滑動窗口生成待測樣本。在樣本采集中，App啟動和抓包時間是人為控制的，而在實際的環境中，App啟動時間是未知的。為了從環境中動態地生成待測樣本，本文方法設計了一個滑動窗口?；瑒哟翱趦却嬖谝粋€隊列，用于保存當前時間點至前10秒范圍內的握手報文。當有新報文到達時，加入隊列頭。窗口存在一個以1秒為周期的定時器，定時器到時時，先刪除隊尾超時的節點，再遍歷滑動窗口隊列中所有報文，將報文進行樣本數據轉換，得到一個待識別的向量dx。進而可對dx進行降維、過濾和識別等操作。

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

(3) 實時更新域名/IP映射表。根據對網絡技術的分析，域名與IP地址的對應關系是隨著環境而變化的。從樣本中生成的域名/IP映射表需要根據運行環境的變化而更新。因此，本文方法在識別環境中也需要實時抓取DNS報文，并根據DNS解析的數據來更新映射表。

3 實 驗

3.1 實驗環境與算法實現

實驗使用一臺基于Mediatek-MT7620芯片方案的無線接入網關進行驗證，其主頻為580 MHz的MIPS架構處理器，內存為123 MB，支持兩個百兆以太網口，以及2.4 GHz頻段Wi-Fi接入。設備運行OpenWrt系統,該系統是一種適用于嵌入式網絡設備的Linux發行版，具有強大的擴展性[9]。

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

3.2 識別效果評估

為評估模型識別的效果，實驗使用重放工具將測試集對應的抓包文件重放到網絡中，由識別程序進行在線識別。因使用十折交叉驗證法測試，故識別程序需分別使用10個SVM模型進行識別，重放工具則分別重放10組測試集對應的抓包文件。10組交叉驗證共生成500個識別結果。

識別程序在實驗中的識別效果如圖8所示?？梢钥闯?，程序對目標App報文的識別效果較好，并可以正確識別出大部分的背景流量，但部分特征和目標App相似的背景流量可能會被誤識別為目標App?？墒褂脺蚀_率P來評估識別效果，準確率P=TP/(TP+FP)，其中TP為分類正確的樣本數，FP為分類錯誤的樣本數。則在當前的測試集條件下，分類器的識別準確率約為94.4%。

圖8 識別結果的混淆矩陣

3.3 資源占用情況評估

為評估本方法對系統資源占用情況，實驗中使用top命令以1秒為周期定時采集識別程序所在進程的CPU及內存利用率，其結果如圖9所示?？梢钥闯?，CPU利用率在0～2%之間波動，呈現周期性變化，這和程序對滑動窗口進行周期性處理的特性相吻合。程序占用約1 025 KB內存，占用率約為0.8%。

圖9 CPU與內存占用率

對于網絡設備而言，吞吐量指設備在單位時間內發送的數據量，體現了設備轉發報文的能力，是評估設備性能的重要指標。為評估本方法對設備轉發性能的影響，設計了一種壓力測試實驗，該實驗中存在兩臺計算機分別通過以太網連接實驗網關，使用網絡吞吐量測試工具iperf[12]，從一臺計算機向另外一臺計算機以TCP連接的最大帶寬發送數據。在以下三個場景中觀察吞吐量的變化：① 識別程序未運行；② 識別程序運行，但環境中未運行目標App；③ 識別程序運行，且環境中存在待識別App周期性啟動。

實驗結果如圖10所示，在場景1和場景2中，設備吞吐量都較為平穩，其均值分別為94.06 Mbit/s和93.96 Mbit/s；在場景3中，設備吞吐量存在小范圍波動，其均值為91.64 Mbit/s，較場景1僅略微降低。

圖10 系統轉發吞吐量

4 結 語

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