面向移動應用識別的結構化特征提取方法

沈 亮，王 鑫，陳曙暉

（國防科技大學計算機學院，長沙410073）

（?通信作者電子郵箱shchen@nudt.edu.cn）

0 引言

隨著移動互聯網基礎設施建設不斷優化升級以及智能手機的快速普及，我國形成了全球最大的移動互聯網應用市場。中國互聯網絡信息中心（China Internet Network Information Center，CNNIC）發布的第43 次《中國互聯網絡發展狀況統計報告》顯示，截至2018年12月，我國市場上監測到的移動應用程序在架數量為449萬款［1］。面對數量龐大的移動應用，如何高效、準確地識別這些應用的流量，對于網絡運營和管理機構具有重要的意義，這是研究差異性服務、流量控制、惡意應用識別以及用戶行為分析的前提和基礎。

網絡流量識別是指通過對網絡流量的分析，確定網絡流量對應的應用協議，并基于此對網絡流量進行分類。在傳統的互聯網平臺上，主要通過端口識別［2］、深度包檢測（Deep Packet Inspection，DPI）［3-4］、基于主機行為或流量行為的識別技術［5-6］、協議逆向［7］和機器學習［8-10］等技術來實現。傳統網絡識別大多只能進行粗粒度的流量識別，如網絡流對應的應用層協議、惡意流量識別、異常流量檢測等。

在傳統網絡流量識別技術的基礎上，很多研究工作專門針對移動應用的特點提出了相應的識別方法。當前的主要研究方向是對應用超文本傳輸協議（Hyper Text Transfer Protocol，HTTP）流的識別。這是因為絕大部分移動應用都是通過HTTP 和超文本傳輸安全協議（Hyper Text Transfer Protocol over Secure socket layer，HTTPS）與服務器進行通信［11］，而這兩種協議的實現機制不同，需要分開研究。Xu等［12］通過提取移動應用網絡流量中的應用標識符（唯一標識應用的數字或字符串，如Youku、taobao_android 等）來識別應用流量。他們根據互聯網服務提供商提供的網絡流量，對移動應用特征進行了大規模研究，提出使用HTTP 報文中的User-Agent字段來識別應用程序。但是，Tongaonkar 等［13］在對超過10 萬個Android 和iOS 應用程序研究后發現，iOS 系統的許多應用程序都遵循在User-Agent 字段放置應用標識符的規則，但Android系統的應用程序并沒有強制遵循這一規則。因此，該方法并不適用于識別Android應用。

Dai 等［11］構建了一個應用特征生成系統NetworkProfiler。應用特征有兩個組成部分:第一部分由主機名Host 組成；第二個部分是將HTTP請求行中的請求方法（Get/Post/Head 等）、請求路徑名和查詢關鍵字及其值域中的固定不變內容轉換為狀態機。NetworkProfiler 只是獲取HTTP報文請求行中的固定字符串和Host 作為應用的特征，存在以下兩個問題:1）當前主流應用朝著體系化、平臺化方向發展，應用相互集成，如手機QQ 中集成了QQ 空間、微視、QQ 音樂、京東購物等。當多個關聯應用從同一個服務器獲取數據時，產生的報文在Host、請求行等位置可能完全一致，NetworkProfiler 忽略了其他位置可能存在的有用信息，難以有效識別關聯應用的流量。2）為了對抗網絡監聽和爬蟲，應用開發人員引入可變路徑技術，對請求行中的關鍵路徑段和參數值進行編碼或加密，NetworkProfiler難以有效識別這類流量。

Ranjan 等［14］將應用安裝包進行反編譯，從配置文件中獲取指定HTTP 消息報頭的值作為特征。這種方法不需要采集應用流量，直接從應用市場下載應用安裝包即可獲得研究數據。但是也存在兩個比較突出的問題:1）不同應用在開發時所遵循的規范不統一，面對數量龐大的應用，難以形成有效的自動化方法將應用配置文件中的全部有用信息結合起來；2）需要人工設計應用特征的構成，可能會忽略應用自定義的HTTP報頭及其內容，而這些信息是識別應用流量的關鍵。

也有研究者［15-16］嘗試利用卷積神經網絡（Convolutional Neural Network，CNN）進行準確的移動應用流量識別。將數據包轉換為固定長度的向量，利用CNN 提取HTTP 中的抽象統計特征，并為每個應用程序建立了一個檢測模型。這種做法的好處是實現了應用HTTP 特征無關化，存在的主要問題有:1）需要較大的樣本集才能實現較好的效果；2）模型比較復雜，難以在網絡上進行在線實時檢測，更適合做離線處理；3）背景流量對分類器的性能影響較大。

移動應用流量識別存在比較突出的難點，就是沒有可用的移動應用網絡流量集。有研究者［17］使用移動平臺上的虛擬專用網絡（Virtual Private Network，VPN）應用程序編程接口（Application Programming Interface，API）來獲取應用程序生成的網絡流量。這種方法能夠將應用程序與網絡流相關聯，可用于構建移動應用的流量數據集。

從以上研究可以看出，對移動應用流量識別主要采用兩種技術:DPI 和機器學習。以上研究都能夠解決一定的問題，但是都存在局限性:1）DPI 和傳統的機器學習算法如支持向量機、隨機森林等，都需要預先設計特征，這樣會丟失應用流量中廣泛存在的個性化信息，可能導致識別效果不理想；2）深度學習雖然實現了特征無關化，但是模型復雜，難以進行在線實時檢測，用于處理加密的HTTPS流量可能更加合適。

由于HTTP 流中的字符可見，其中有足夠多的可用信息，關鍵是如何獲取這些信息來構建有效的應用流量特征。本文針對移動應用HTTP流量，提出了一種基于傳統DPI技術的移動應用HTTP 流結構化特征提取方法。與現有工作的不同之處在于:1）不需要預先設計特征，對數據不作特殊處理，可以保留報文中的全部特征片段，直接采用HTTP 報文結構作為聚類標簽，適用于所有HTTP 流；2）在提取應用特征前先進行一次聚類，避免了對毫無關聯的流進行操作，既便于保留報文中的共同點，也便于發現不同點；3）實驗數據全部來自現實環境，結果更加可靠，通過開發一款基于Android 的流量采集工具，在設備端捕獲流量的同時精確地為每條數據流產生標簽，此標簽可以確定每一條流的歸屬，避免了其他流量獲取方法帶來的不確定性。

1 結構化特征提取系統框架

本文構建了一個基于DPI 的移動應用特征提取系統，由流量采集、預處理、特征提取、特征篩選4 個模塊組成，如圖1所示。

圖1 移動應用特征提取系統基本框架Fig.1 Basic framework of mobile application signature extraction system

1）采集流量。從流量入手開展移動應用特征提取研究，首先要獲取移動應用的網絡流量。由于沒有標準的移動應用流量數據集可供使用，研究者要獨立采集移動應用的流量。采集流量必須要解決網絡流的實際歸屬問題，即采用一定的技術手段來準確判定每條網絡流是由哪個應用的產生的；否者，從不純凈的應用流量中提取的特征將存在很大的誤差。本文將在2.1節介紹標簽化的流量采集方法。

2）預處理階段。根據報文的五元組信息將采集的混合網絡流量進行重組，形成獨立的網絡流。在完成流重組后剔除非正常流以及利用HTTP 報文進行DNS 查詢的數據流。正常的HTTP 流必須具有完整的TCP 連接建立過程，且服務器返回的狀態碼為“2XX”系列。最后獲取HTTP 請求報文的載荷信息，存入對應的應用程序流量庫中，每條載荷信息代表一條網絡流。

3）特征提取階段。將每個應用的流聚類成具有相同結構的集合，并分別提取每個集合內所有流的最長公共子序列（Longest Common Sequence，LCS），最后替換掉LCS 中的可變字段和無關信息，就形成了每一類流的字符串特征。

4）特征篩選階段。將多個關聯應用的相同特征進行篩選，根據該特征代表的網絡流在不同應用中出現的頻率來判定特征最后的歸屬。

2 關鍵技術實現

2.1 標簽化流量采集

標簽化流量采集就是通過一定的技術手段確定每一條網絡流的歸屬。由于不同的手機操作系統原理不同，目前我們開發了一款基于Android的免Root流量采集工具NetLog，通過Android4.0+提供的VPN Service 模塊監聽設備上所有應用的接口。NetLog 在開啟后會自動記錄設備產生的網絡流量，每隔一定時間生成一個pcap 文件及相應的網絡流標簽文本，并壓縮上傳至服務器。流量標簽如圖2 所示，包括開始的時間、應用名稱、協議類型（TCP/UDP）、源IP地址、源端口號、目的IP地址、目的端口號。通過該標簽，可以在后續的預處理階段對pcap 文件中的混合流量進行精確的區分，從而得到純凈的應用流量。

圖2 Netlog流量標簽Fig.2 Traffic labels of Netlog

2.2 結構化特征提取

移動應用操作界面很多，功能十分豐富，為了實現每一個界面的每一種功能，應用需要向對應的服務器請求數據。針對這些功能，開發人員會在應用中制定對應的數據獲取計劃，在應用運行過程中觸發時就形成了不同類型的網絡流。網絡數據獲取計劃的內容包括采取的數據傳輸協議（HTTP、HTTPS等）、請求路徑、各種參數名及參數值、各個字段的先后順序、不同字段之間的分隔符等。網絡數據獲取計劃相當于構建了一個流量框架，當觸發時各個字段填充上相應的數據就構成了現實中的網絡流量。由于不同公司的應用開發規范不同、不同開發人員的個人習慣不同，應用每一種功能所對應的網絡數據獲取計劃可能存在差異，這些差異最終會體現在報文中，而這正是流量特征。

本節將介紹如何提取應用HTTP流的結構化特征。

2.2.1 流聚類

在對應用流量進行分析后發現，應用在獲取不同的數據時產生的HTTP 請求報文存在較大的差異。當請求方法、報文結構、服務器域名有任意一處不同時，報文可能完全不同。本文期望在提取應用流量特征時保留報文的結構，為此，需要將每個應用的HTTP 流進行聚類，使每一類流趨向于相同的數據獲取行為。在進行多次聚類實驗及效果評估后，制定了流聚類標簽，聚類標簽由HTTP 請求報文的請求方法、消息報頭及其先后順序、Host或路徑中的域名組成，這個標簽適用于任何移動應用HTTP 流，當兩條流的標簽一致時則認為是同一類流，具體流程如圖3所示。

圖3 流聚類流程Fig.3 Traffic clustering process

經過聚類，每一類的數據流已經高度相似。圖4 為兩臺不同設備上的愛奇藝產生的HTTP 請求報文，根據本文的聚類原則，這兩條數據流屬于一類。從圖4 可以觀察到這兩條請求報文的結構完全一致，只有部分字段的值不同，可以在后續處理中提取出其中的報文結構和固定字符串作為特征。

2.2.2 特征生成

應用產生的HTTP 流經過聚類后，得到了多個高度相似的集合。在提取特征時，要將每一類流中的固定不變信息保留下來。本文提出的特征生成算法是:在應用流聚類的基礎上，使用LCS 算法分別提取應用的每一類HTTP 流的LCS。由于每一類HTTP 流具有相同的結構，為了減少不必要的計算，將HTTP 報文分成不同的行，即請求行、報文頭行、報文體行，再分別提取每一行的子LCS后并組合成最終的結果。

圖4 愛奇藝HTTP流Fig.4 HTTP traffic of iQiYi

LCS 算法實現簡單，但存在結果碎片化的問題。為此，本文引入閾值Length_min 來解決碎片化問題。具體思路為:在生成兩個字符串的LCS狀態矩陣時，當前位置字符相同，且其前后共Length_min 個字符也相同時才計入結果。由于HTTP報文有明顯的結構，不同意義的字段由一定的間隔符分隔，最短的關鍵字可以是1 個字符，如“pt=0&t=6&tl=7&”中的關鍵字“t”加上前后兩個分隔符“&”“=”，所以Length_min取值最小應為3。Length_min值越大，最后的結果越精簡。詳細描述如算法1所示。

根據本文的特征生成算法，提取圖4 中兩條愛奇藝HTTP流的LCS，其結果如圖5 所示。可以看出，結果保留了圖4 兩條HTTP 請求報文中符合本文要求的公共字符串序列，且保留了報文的結構，由于非連續處插入了特殊間隔符，可以在后續處理中剔除可變化的字段。

圖5 圖4的LCS結果示例Fig.5 Result example of LCS for Fig.4

2.2.3 字符替換

將應用的每一特征中存在的可變字段和無關項進行替換，最后添加轉義符將特征轉化為正則表達式形式，可直接用正則匹配來識別應用流量。

1）替換可變字段。如前所述，在提取了每一組數據流的LCS 后，會在每一個不連續處插入特殊間隔符，而HTTP 報文具有明顯的結構，可依據常用間隔符如空格、換行，以及“/”“，”“=”“&”“；”等劃分成不同的字段，如果某一字段中存在特殊間隔符，則將當前字段替換為“（.*）”。

2）替換無關項。應用程序的流中通常具有某些與應用程序無關的字段，如“WIFI”“4G”“G4”“LTE”“NONE”“NULL”等，將這些字段替換為“（.*）”。

3）轉義字符替換。最后保留“（.*）”不變，將各個轉義字符前添加轉義符“”，需要轉義的字符包括“.”“*”“？”“（”“）”等。

圖6為圖5所示的LCS經過字符替換后的結果，其中存在變化的字段和無關項已替換為正則表達式中代表任意字符的“（.*）”。當網絡流量來源比較廣泛時，就可以排除出所有的可變換字段，剩下的固定不變字段即為該類網絡流的特征。

2.3 特征篩選

由于移動應用的開放性，不同應用可以從相同的服務器獲取數據，所以可能存在不同應用產生完全相同的HTTP 請求報文，即提取的特征無法有效識別數據流的源頭。這類完全相同的流，主要涉及一些系統功能相關的數據，包括獲取服務器時間、網絡測試、上傳日志等。如圖7 所示，飛豬、閑魚、手機淘寶、手機天貓和優酷視頻都能提取到這樣一條特征。對于這種不能明確地區分數據流歸屬的特征，依據其在應用數據流中出現的頻率來判定，如果在某一應用中出現的頻率明顯高于其他應用，則將此特征歸為出現頻率較高的應用；如果在各個應用中出現的頻率沒有明顯的差異，則將此特征刪除。

本文設置臨界頻率倍數閾值P，P代表了對提取的應用特征誤報率的容忍度。P=0 表明完全接受應用特征產生的誤識別；P 值越大，則本文方法提取的特征在實際流量識別中的誤報率越低。本文將P設置為5，現實意義為如果特征A代表的流在應用1中所占比率高于其他應用5倍，則特征A歸屬于應用1，其他應用中的特征A 刪除。5 是一個經驗值，在實驗中已經可以達到較好的效果。

圖6 愛奇藝特征示例Fig.6 Signature example of iQiYi

圖7 多種應用的共同特征Fig.7 Common signature of multiple applications

3 實驗及結果分析

3.1 實驗數據采集

為了評估本文的特征提取方法，在多臺設備上安裝采集工具NetLog，并收集2019 年5 月20 日—6 月30 日產生的流量。其中6 月15 日前的流量作為樣本集，用于提取應用的特征；6月16日—30日的數據作為測試集，用于測試實驗提取的特征的識別效果。為了排除設備型號對應用特征的影響，挑選出其中至少出現在兩臺不同設備上的42 種應用所產生的HTTP流作為實驗數據。樣本集共含有117 772條HTTP流，其詳細分布見表1；測試集共含有50 387 條HTTP 流，其詳細分布見表2。

表1 樣本集應用及HTTP流分布Tab. 1 Applications and HTTP traffic distribution in sample dataset

3.2 評價標準

表2 測試集應用及HTTP流分布Tab. 2 Applications and HTTP traffic distribution in test dataset

表3 混淆矩陣Tab. 3 Confusion matrix

3.3 實驗結果

為驗證本文提出的應用特征提取方法的有效性，使用該方法提取樣本集中42 種應用的HTTP 流特征，并使用這些特征去識別測試集中的應用流量，得出每個應用特征的TP、FP、FN、TN 值，并計算每個應用的特征在測試集上的查全率、準確率和誤報率。由于提取的特征是正則表達式形式的字符串，識別時直接使用正則匹配的方法將每一個特征同應用的HTTP 請求報文進行匹配即可。評估結果見表4。由表4 可見，本文提出的應用特征提取方法具有良好的識別效果，其中平均準確率ACC 達99%以上，單個應用最大誤報率為QQ 空間的0.52%，查全率最低為71%、最高為99%，平均查全率為90.63%。

由表4 也可得出，本文方法可以有效區分具有關聯性的同一體系的應用。如騰訊公司的QQ 空間、QQ 瀏覽器、手機QQ、企鵝電競、騰訊視頻、微視、微信，阿里巴巴旗下的淘寶、天貓、淘票票、口碑、飛豬、餓了么、聚劃算、閑魚，字節跳動公司的今日頭條、抖音短視頻、火山小視頻、西瓜視頻等。同一公司開發的應用具有明顯的關聯性，功能相互集成，本文方法可以以極低的誤報率取得較高的查全率。

表4 應用特征在測試集上的評估Tab. 4 Evaluation of application signatures on test dataset

3.4 對比實驗

本節進行兩組對比實驗:第一組，通過改變特征篩選階段的閾值P，觀察它對識別結果的影響；第二組，選取其他已發表文獻的應用特征提取技術與本文方法進行對比。

3.4.1 對比實驗1

本文在特征篩選階段設置了閾值P=5，即將多個應用出現的相同特征歸屬于流占比高于其他應用5 倍的應用，該閾值可以較低的誤報率獲得較高的查全率。在對比實驗1 中，將閾值P設置為無窮大，其現實意義為:如果多個應用具有一個相同的特征，則排除此特征，從而使得在樣本集上獲取的特征可以唯一指向某一個應用。對比實驗同樣使用樣本集提取特征，用測試集來驗證識別效果，對比結果見表5。從表5 可見，能夠容忍一定程度誤報率的P 取值為5，與完全不容忍誤報率的P 取值為無窮大相比，平均查全率由88.21%提高到90.63%，但平均誤報率僅由0.01%提高為0.05%。表6 列出了三種結果差異較大的應用，查全率有較大幅度的提升，但誤報率最高僅為0.52%。由此可見，在容忍一定誤報率的前提下，可以大幅提高部分應用流量的查全率。

表5 對比實驗1結果 單位：%Tab. 5 Result of comparative experiment 1 unit:%

表6 對比實驗1詳細結果 單位：%Tab. 6 Details of comparative experiment 1 unit:%

3.4.2 對比實驗2

本節選取其他三種特征提取技術來評估本文方法:1）基于HTTP 頭 字 段 中 的 顯 式 應 用 標 識 符［12］；2）基 于NetworkProfiler 方法［11］的URL 狀態機及Host 組合；3）應用逆向的方法［14］。前兩種方法與本文方法都是從應用流量入手，根據原文的思路進行復現，從樣本集中提取特征，并測試所提取的特征在測試集中的識別效果；第三種應用逆向的方法，由于不具備復現的能力，本文根據文獻［14］的實現機制和實驗數據進行對比分析。

由表7 可見，本文方法與應用標識符的方法相比，平均查全率提高了47%，平均誤報率僅為0.05%。與NetworkProfiler的方法相比，平均查全率提高了22%，平均誤報率不足NetworkProfiler 方法的1/25。由此可見，本文方法與其他從應用流量入手的方法相比，具有較高的查全率和較低的誤報率。

表7 對比實驗2結果 單位：%Tab. 7 Result of comparative experiment 2 unit:%

最后，對應用逆向的方法進行對比分析。文獻［14］對應用安裝包進行反編譯，從配置文件中獲取特定的字符串（例如服務器域名、User-Agent 等）填充到統一構建的特征框架中，從而形成應用流量特征。此方法無須采集應用流量，直接利用應用安裝包構建應用流量特征，其優勢是便于開展大規模的應用特征提取，缺點是統一的特征框架難以充分利用配置文件中的關鍵信息，造成特征不夠精細，難以有效區分同體系的應用流量。文獻［14］的實驗結果表明，安卓應用的整體流覆蓋率為40.76%，引入“Application Families”概念（將具有一定關聯性的應用作為一個整體）后整體流覆蓋率提升為81%。由此可見，本文提出的方法對于識別具有關聯性的應用流量具有明顯的優勢。

4 結語

本文提出了一種提取移動應用HTTP 流結構化特征的方法，避免了預先設計特征帶來的識別精度底、適用性差的問題，能夠有效識別存在數據關聯性的應用的流量。本文方法不需要對數據做特殊處理，適合開展大規模、高吞吐量的實時在線檢測。

本文方法存在兩點不足:1）采集流量需要人工運行應用程序完成；2）流聚類還不夠精細，造成聚類后的類別較多。下一步的主要工作包括:1）優化聚類算法，在不影響特征精度的前提下，盡可能減少特征的數量；2）與應用自動化運行工具相結合，構建一個全自動的移動應用HTTP特征提取系統。