本發(fā)明涉及一種基于用戶真實流量數據來對App的Host/Url特征集進行補全的方法。具體來說，涉及一種當給定某個App的初始Host/Url特征集后，直接從多個用戶的真實流量數據中挖掘出歸屬于該App的Host/Url特征，從而對初始特征集進行補全的方法。

背景技術：

進入了后PC時代，運行于各種智能終端的移動App已成為互聯網流量的主要提供者。截止2015年11月，在全球二大主要的App市場中，Google Play中已有120萬+個App，而Apple Store中的數量也已達到112萬+。這些App在為人們提供豐富多彩的網絡服務的同時，也貢獻了海量的互聯網流量。然而，與App市場繁榮發(fā)展極不相稱的是，運營商及網絡安全部門對這些來自App的流量的解析能力卻大大的滯后。

這些運行于智能終端的App，主要通過HTTP和HTTPS協(xié)議與各自的服務器進行通訊。從數據包的外在表征看，這些來自App的HTTP和HTTPS通信數據與其他使用同樣協(xié)議的通信數據沒有任何本質的差別，再加上待識別App的數量極為龐大，造成了這一問題解決的不易。

已有學者開展了從網絡數據中提取App指紋方法的研究，按照所采用特征的不同，可將其歸為以下幾類：

(1)利用HTTP頭(HTTP header)中的User-Agent(UA)信息:HTTP header是HTTP協(xié)議的一部分，是通過HTTP協(xié)議在發(fā)出請求(request)或者應答(response)時封裝在其頭部用來定義HTTP傳輸參數的一些字段。

在HTTP header中包含多個域，其中User-Agent(UA)部分是HTTP客戶端向訪問網站提供的所使用瀏覽器類型、操作系統(tǒng)、瀏覽器內核等信息的標識。蘋果公司在其iOS開發(fā)者指南中建議在UA中加入有關App的標識信息。直接從UA中讀取App標識看來是一個非?？旖萦行У姆椒?，因此有很多方法直接依據UA中的信息進行識別。然而，盡管iOS做了這樣的建議，但由于并非是強制要求，因而并不是所有開發(fā)者都會遵循這一建議。安卓則更是連這樣的建議都沒有。我們在實際測試中也發(fā)現，有些App在運行時會發(fā)出多個不同UA的HTTP請求，有些甚至將其偽裝成一個瀏覽器的訪問，有些則是填入一些關于安卓系統(tǒng)版本等操作系統(tǒng)的信息。因此，基于UA特征的方法在實際應用中具有局限性。

(2)利用Ads或analytics(A&A)輔助服務提供的App標識：有很多App，尤其是那些免費的App，常常會在提供本身服務之外加入一些輔助服務，比如ads或analytics(簡稱：A&A)。A&A服務在向服務器發(fā)送HTTP請求時，通常會帶有宿主App的標識。然而，A&A服務的數據流量通常十分稀少，而且可能被用戶所屏蔽(如安裝Adblock等工具)，造成能實際被檢測到的概率較低。此外，我們在測試中還發(fā)現，有些App的A&A服務發(fā)送的宿主App標識并非是App的名稱，而只一個ID，無法做到直接對應。

(3)利用Host/Url信息：不同的App總是會和各自的服務器進行聯系，因而通過用戶流量數據中App所訪問的Host/Url信息也能夠對其進行有效識別。

獲得App的Host/Url特征集是在用戶流量數據中對App進行識別的前提，目前大多采用對App進行自動測試的方法。然而，對App進行的自動測試無法窮盡所有可能的執(zhí)行路徑，因而不能獲得全量的Host/Url特征集。本發(fā)明針對利用Host/Url特征對流量數據中的App進行識別的問題，如何對App不完備的Host/Url特征集進行補全，提出了一種基于用戶真實流量數據的補全方案。

技術實現要素：

本發(fā)明的目的在于針對現有技術的不足，提出了一種基于用戶真實流量數據補全App的Host/Url特征集的方法。

本發(fā)明的目的是通過以下技術方案來實現的：一種基于用戶真實流量數據補全App的Host/Url特征集的方法，該方法包括以下步驟：

(1)從某個App的初始Host/Url特征集中選取種子特征集，記為{url_seed}。

(2)對種子特征集{url_seed}中的每個成員，都在多用戶的真實流量數據中進行特征補全。

(3)從補全后的特征集中選取新的種子，構成新的種子特征集，迭代地進行特征補全，直到不再得到新的種子為止。

進一步地，所述的步驟(1)中從某個App的初始Host/Url特征集中選取種子特征集，具體包括以下步驟：

(1)統(tǒng)計該App初始特征集中的每個Host/Url特征出現在不同App的Host/Url特征集中的次數。只出現在該App中則次數為1，出現在2個不同的App中則次數為2，以此類推。

(2)種子特征集{url_seed}中的成員，將優(yōu)先選取所有出現在不同App的特征集中次數只有1次的Host/Url特征。如果在初始特征集中沒有出現次數只有1次的Host/Url特征，則選取出現次數最少的幾個Host/Url特征，將其作為種子特征集的唯一成員。

進一步地，所述的步驟(2)中對種子特征集{url_seed}中的每個種子url_i，都在多用戶的真實流量數據中進行特征補全，具體包括以下步驟：

(1)從多個用戶各自的流量數據中提取種子url_i訪問時刻前后一段時間范圍內的Host/Url特征，構成{url_cand}。

(2)對來自N個用戶的候選特征集{url_cand}_k(k＝1,2,...,N)進行關聯分析，得到若干個頻繁項集。

(3)將得到的頻繁項集中不屬于初始Host/Url特征集的新Host/Url特征提取出來，對初始特征集進行補全。

本發(fā)明的有益效果是：給定App不完備的初始特征集，只需在初始特征集中提取種子，利用種子在多用戶的真實流量數據中將屬于該App的其他Host/Url特征提取出來，從而對初始特征集進行了補全。由于補全特征直接來源于用戶的流量數據，本發(fā)明提出的方法不僅實現較為便捷，還更能貼近用戶的對App的真實使用。

附圖說明

圖1為本發(fā)明方法中上位機控制多臺安卓終端進行批量測試的示意圖；

圖2為本發(fā)明方法中對App進行批量測試中具體執(zhí)行進程的流程圖；

圖3為本發(fā)明方法中對HTTPS通信用DNS反向解析獲取App訪問服務器的域名示意圖；

圖4為本發(fā)明方法中對某款App的Host/Url初始特征集進行補全的方法流程圖；

圖5為本發(fā)明方法中以url_i為種子的特征補全流程圖；

圖6為被發(fā)明方法中由種子url_i在多個用戶的流量數據中得到候選特征集的示意圖。

具體實施方式

下面結合附圖和具體實施方式對本發(fā)明作進一步詳細描述，本發(fā)明的目的和效果將變得更加明顯。

運行于各種智能終端的應用(以下簡稱App)，主要通過HTTP協(xié)議和HTTPS協(xié)議與各自的服務器進行通訊聯系。這些服務器的地址通常用域名或IP地址來表示，這里簡稱為Host。如果在Host基礎上，加上具體的HTTP請求路徑，那就稱之為Url。用Url可以刻畫在同一個服務器上的不同類型的訪問。我們把Host和Url統(tǒng)稱為Host/Url特征。一般情況下，一個App會向多個服務器請求不同類型的網絡服務，因而就有多個Host/Url特征，這些Host/Url特征構成了該App的特征集。

另一方面，App所請求的Host/Url會在網絡運營商端用戶的通信日志(以下簡稱流量數據)中會被記錄下來。如果獲得了某款App的Host/Url特征集，我們就可以在網絡運營商端的用戶流量數據中進行匹配搜索，以確認流量數據中是否包含了該款App產生的數據流量。

為了采用Host/URL特征進行App的識別，首先要采集App的通信流量數據，構建一個Host/URL與App的匹配關系表。與已有文獻中采用在安卓模擬器中自動運行安卓App不同的是，本發(fā)明提出了更為高效批處理的方法，如圖1所示。

由一臺上位機控制一批安卓智能終端，上位機和安卓智能終端的連接方式可以是以太網、Wifi或者USB接口。然后當接收測試任務時，由上位機將待測試的安卓App安裝文件(apk文件)以多進程并發(fā)的方式分發(fā)到這些安卓智能終端，每個進程負責控制一個安卓智能終端。每個進程的處理流程如圖2所示，即通過adb命令控制其安裝、運行、停止和卸載。并在同時，在安卓智能終端上啟動tcpdump程序開啟對DNS、HTTP和HTTPS協(xié)議的通信數據進行捕獲并保存為pcap格式的文件。每個App測試完成后，由上位機將tcpdump程序保存的pcap文件傳回進行分析。

有關adb命令的詳情，參見：https://developer.android.com/studio/command-line/adb.html。

有關tcpdump程序的詳情，參見：http://www.androidtcpdump.com/。

有關pcap文件格式的詳情，參見：https://wiki.wireshark.org/Development/LibpcapFileFormat。

由于近年來HTTPS通信量呈逐漸上升趨勢，而HTTPS是一種加密傳輸的通信協(xié)議。當一個App試圖與其服務器建立一個HTTPS連接時，它首先會根據Host向本地DNS服務器請求解析，當收到DNS回應的IP地址后，再去和服務器建立加密的握手消息并驗證成功后，以后所有的請求和應答都通過SSL加密通信進行，因此無法捕獲到諸如GET、REQUEST以及RESPONSE的任何內容，即使是包括具體請求的URL也無法獲得。

由于域名相對于IP地址來說要穩(wěn)定很多，同一個域名可由不同的DNS服務器可以被解析成不同的IP地址。因而，獲得域名而不是IP地址對于構建Host/Url特征十分重要。對于使用HTTPS協(xié)議的App服務器而言，用tcpdump程序只能捕獲到服務器的IP地址，為了獲得它們的域名，我們采用了DNS反向解析的方法，如圖3所示。在對App進行測試時，開啟tcpdump時會同時保存此次測試過程中所有的與DNS服務器的請求和應答記錄，當發(fā)現某個App與其服務器進行HTTPS協(xié)議的通信，我們會根據其服務器的IP地址在DNS記錄尋找其請求的域名，并將此反向解析得到的域名代替IP地址作為該App中基于HTTPS協(xié)議的Host/Url特征。

通過上述對App進行自動測試、用tcpdump進行通信數據捕獲和對得到的pcap文件進行解析，我們可以獲得App的初始Host/Url特征集{url_init}。

然而，由于App測試無法窮舉所有可能的執(zhí)行路徑，尤其是那些需要登錄、甚至手機驗證后才能使用的App，所測得的初始Host/Url特征集是不完備的。

為了對初始Host/Url特征集進行補全，本發(fā)明提出一種基于用戶真實流量數據進行補全的方法。具體步驟如下：

如圖4所示，在步驟101中，在某個App的初始Host/Url特征集{url_init}進行篩選，選擇出種子特征集，即有篩選的過程是：

首先統(tǒng)計初始特征集{url_init}中的每個特征url_i在不同App的Host/Url特征集中出現的次數。如果出現次數只有1次，說明該Host/Url特征只被該App所訪問；而如果在不同App的Host/Url特征集中出現的次數多，則表明該url_i被多個不同的App所共同訪問。在種子特征集{url_seed}的成員的篩選過程中，將優(yōu)先選取那些只被該App所訪問的Host/Url，即出現次數只有1次的特征。

有時，可能在初始特征集{url_init}找不到出現次數只有1次的特征。這時，將選取出現次數最少的幾個Host/Url特征，將其的組合作為種子特征集{url_seed}的唯一成員。一般選次數最少的2個Host/Url特征即可。

構建好種子特征集后，如圖4所示，在步驟102中，對種子特征集{url_seed}中的每個成員，都在多用戶的真實流量數據中進行特征補全。

假設url_i是種子特征集中的一員，即url_i∈{url_seed}，則當在某個用戶的真實流量數據中如果在t_p時刻檢測到有對url_i的訪問，則在t_p前后一段時間范圍[t_p-Δt,t_p+Δt]內，屬于該App的其他Host/Url特征被訪問到可能性也很大。假設這段時間范圍內該用戶所訪問的Host/Url集為{url_cand}，則可從中提取出一個或多個url_comp，有url_comp∈{url_cand}且如果經過判別是屬于該App，則將它們作為補全數據加入到該App的Host/Url特征集。

由于目前手機操作系統(tǒng)基本都工作在多任務模式，同一時刻有多個App處于運行狀態(tài)，在{url_cand}中很容易混入不同App的Host/Url特征?？紤]到不同用戶所使用的App存在差異性，這樣當考察從不同用戶得到的{url_cand}構成的集合時，屬于待補全App的Host/Url特征就會構成了頻繁項；而不屬于待補全App的Host/Url特征則由于不同用戶所使用App的差異性，無法構成頻繁項；這樣，通過關聯分析提取頻繁項的方法就可以有效地將屬于待補全App的Host/Url特征提取出來。具體由種子url_i從提取{url_comp}的過程如下：

如圖5所示，在步驟201中，提取多個用戶在訪問種子url_i時刻前后一段時間范圍內所訪問的Host/Url，分別構成各自的候選特征集{url_cand}。

假設某個用戶的流量數據中在t_p時刻有對種子url_i的訪問，則將t_p時刻前后一段時間范圍[t_p-Δt,t_p+Δt]內該用戶訪問的Host/Url提取出來，構成候選特征集{url_cand}。通過這種方式，如果在用戶流量數據中檢測到有N個用戶對種子url_i的訪問，就可以提取出N個候選集{url_cand}_k(k＝1,2,...,N)。如圖6所示，提取到這N個用戶各自對url_i訪問的時刻是不必相同的。

如圖5所示，在步驟202中，對來自N個用戶的候選集{url_cand}_k(k＝1,2,...,N)進行關聯分析，得到若干個頻繁項集：Fp₁＝{url_A,url_B,...}、Fp₂＝{url_C,url_B,...}，…。

有關關聯分析算法的詳情，可參見：Han J,Pei J,Yin Y,et al.Mining frequent patterns without candidate generation:A frequent-pattern tree approach[J].Data mining and knowledge discovery,2004,8(1):53-87.

如圖5所示，在步驟203中，將提取的頻繁項集中不屬于初始特征集{url_init}的新Host/Url特征都提取出來，對初始特征集進行補全。

經過上述過程，完成了以url_i為種子對某款App的Host/Url特征集進行擴充過程。對種子特征集{url_init}中所有成員實施上述過程，即完成了一次對初始特征集的補全的全過程，即完成了從初始特征集提取種子特征集和基于種子特征集的特征集補全的過程。

為了挖掘出更多的屬于該款App的Host/Url特征，我們在對初始特征集進行一次補全后，如圖4所示，在步驟103中，從補全后的特征集中選取新的種子，構成新的種子特征集，迭代地進行特征補全，即重復步驟101～103的過程，直到不再得到新的種子為止。

上述實施方式用來解釋說明本發(fā)明，而不是對本發(fā)明進行限制，在本發(fā)明的精神和權利要求的保護范圍內，對本發(fā)明做出的任何修改和改變，都落入本發(fā)明的保護范圍。