微信對網絡影響的技術試驗及分析（論文全文）

時間 2019-11-12

原文原文鏈接

前言

本文來自論文《微信對網絡影響的技術試驗及分析》，文中研究了微信對現今移動網絡的影響，對於即時通信開發人員來講，文中的某些數據和研究結果，對於實現相似的技術，有必定的參考和借鑑意義。即時通信網(52im.net)現全文收錄之。

摘要

針對業界對微信是否影響移動網絡性能的爭論,進行相關的技術試驗,跟蹤微信在IP層以及在無線網絡信令層的流量,以實際數據分析微信對移動網絡的影響,並提出解決微信問題的建議方法。

引言

2013年2月底,一則關於電信運營商要向微信收費的傳聞引起了行業震盪,據2013年3月31日財新網報道,工業和信息化部(下文稱工信部)部長苗圩當日在參加第二屆「嶺南論壇」時表示,微信有收費可能,但不會大幅度收費,工信部正在協調運營商微信收費一事, 他們會考慮運營商的合理要求。

在此以後的幾個月中,爭論並未中止,騰訊一直經過微信官方微博等各類途徑表示微信不會收費,而且騰訊將和運營商探討互惠互利的長遠合做;工信部則聲明互聯網和移動互聯網等新業務是否收費由市場決定, 工信部將堅持「其經營者依據市場狀況自主決定」的原則;中國計算機學會等社會團體則認爲運營商在未經有關法律程序的狀況下試圖增長收費名目是沒有依據的, 涉嫌雙重收費。

在爭論中,運營商以及通訊行業的專家認爲微信過於頻繁的心跳和短包致使「信令風暴」,由於據數據顯示,微信佔據中國移動60%的信令,卻只產生10%的流量,已經影響到傳統業務的質量;而互聯網人士則站在用戶與道德的制高點上提出異議,認爲微信是合理使用運營商的業務規則。可是不多有人深層次地探究這個問題的技術細節,以數據來分析微信對網絡的影響是否巨大,對網絡的使用是否符合公平使用原則。

本文將從技術角度出發,跟蹤微信的各類操做在IP層產生的數據包收發狀況以及在無線側產生的信令數據,並和語音、短信等傳統業務引起的信令進行對比, 在技術層面客觀分析微信對移動網絡的影響。

一．微信IP層流量分析

微信屬於C/S架構的軟件系統,爲分析微信的流量分佈,須要對微信的通訊過程進行如下分析。

通訊協議: 是使用TCP方式進行通訊,仍是使用UDP方式。
鏈接方式: 若是使用TCP方式,是長鏈接仍是短連接。
心跳方式: 若是使用長鏈接,那麼必然須要進行鏈接有效性檢測,使用的心跳包的頻次是多少。
通知機制: 在微信切入後臺後,服務器端以何種方式通知客戶端。
版本差別: iOS版本和Android版本上的處理方式是否有所不一樣。

本試驗分別在使用iOS 6.x及Android 4.x系統的終端上進行,使用抓包軟件對微信產生的IP流量進行抓取分析。

1微信的通訊過程

通過分析發現,微信的通訊協議採用基於TCP的 HTTP協議,在鏈接方式上採用長鏈接和短鏈接結合的方式。

微信在登陸的時候,採用TCP短鏈接的方式進行認證。微信客戶端首先發起一個TCP鏈接到鑑權服務器, 將加密後的用戶名及密碼用HTTP協議提交給服務器, 服務器返回加密後的認證結果,鑑權完畢後鏈接斷開。一次鑑權過程的數據流量在1K字節左右。在鑑權成功後,微信會向業務服務器從新發起一個TCP鏈接,該鏈接會一直保持,並採用心跳包來定時檢測鏈接的有效性(下文中將此鏈接稱爲業務鏈路),微信客戶端主動發送的消息經過此鏈接傳輸給服務器,服務器通知客戶端的消息也經過此鏈接發送到客戶端。

業務鏈路鏈接成功後,微信客戶端首先經過此鏈接查詢是否有新的更新內容(包括新消息、新好友添加記錄、新朋友圈信息等),以後進入主界面等待用戶進行下一步操做。整個登陸過程以及更新操做產生的流量大約爲3K字節。登陸後在微信客戶端的各個頁籤之間切換不產生任何數據交互。

後續全部涉及到通訊的功能所有在業務鏈路上進行數據交互,如文字信息的收發、圖片的收發、語音信息的收發等,下面對數據包跟蹤記錄進行簡單的分析。

1) 收發文字。當接收一條文字微信時,會跟蹤到4個數據包。

第一、2個數據包長度爲116字節,分別表示對方正在輸入和開始發送信息(第一個包在打字的時候產生, 第二個包在點擊發送按鈕以後產生),能夠認爲,傳遞對方輸入狀態的數據包長度爲116字節。

第3個數據包是發送的具體內容,通過分析發現, 數據包的內容是加密的,若是發送的是全英文字符, 10個字符之內所產生的流量包都是386字節,11~26個字符是402字節,27~42個字符是418字節,43~62個字符是434字節......;發送中文時,1~3個字是386字節, 4~7個字是402字節,8~11個字是418字節,12~15個字是434字節......,大體狀況是內容每增長4個字數據包就要增長16個字節。根據數據量的規律能夠推斷,微信採用了相似於DES或者AES這種以16字節爲分組單位的對稱加密算法。

最後,文字內容發送完畢以後還會產生一個66字節的數據包,標識着本條信息發送完畢。

2) 收發圖片。當發送圖片時,微信會默認只接收和顯示圖片的縮略圖,傳送縮略圖產生的數據包大概3K字節左右。當用戶點擊查看大圖以後纔會下載完整的圖片內容。

3) 收發語音。收發語音信息和文字信息的數據包相似,測試發現,每秒語音大概對應0.9K字節數據,當一段語音的數據量比較大時,微信按照最長1.5K字節一個包進行分割發送,例如3秒語音將產生3K不到的數據,會分紅2~3個1.5K字節數據包發送;7秒語音會產生6K字節左右數據,會分紅4個1.5K字節數據包發送。和發送文字同樣,每次發送完內容以後都還會產生的一個66字節的結束包。

微信在工做過程當中,除了業務連接的長鏈接會一直保持以便用於通訊功能外,還額外使用一些TCP短鏈接來進行臨時性的操做,如好友搜索、頭像下載、漂流瓶等。整體來看,在活動狀態下(即用戶打開微信的主界面進行各類操做的狀態),微信的數據包收發和其餘的互聯網應用沒有多大區別。

2微信的心跳和通知機制

根據TCP協議的特徵能夠知道,在斷開一個TCP鏈接時,須要進行四次握手,首先由主動斷開的一方發送一個FIN消息給另外一方,另外一方回覆ACK消息,而後由另外一方發起一樣FIN/ACK交互流程後,整個鏈接斷開。TCP鏈接在沒有數據收發的狀況下,不會有任何的數據包交互,當鏈接異常斷線時,只有主動發數據包的一方能夠檢測到鏈接斷線,由於這時能夠發現對端無應答; 等待接收的一方是沒法檢測到的,由於主機宕機、網線斷開等異常狀況將致使等待方永遠不會接收到FIN信息。檢測TCP長鏈接有效性的惟一方法是由一方定時發送一個數據包(俗趁心跳包),若是鏈接異常斷線,發送方在發送的時候便可檢測到,而另外一方則設置一個網絡空閒計時器,當超過約定時間未收到心跳包,則認爲連接已異常斷開。

心跳週期(即網絡空閒定時器的超時時間)過長,則服務器端要等比較長的時間才能檢測到鏈接斷線;心跳週期太短時雖然可以很快檢測到鏈接斷線,可是消耗在心跳包上的網絡資源會過大。業界對微信的最大詬病正是在於微信在非活動狀態下的過於頻繁的心跳機制。

因爲操做系統的不一樣特徵,微信在iOS下以及Android操做系統下的心跳機制有着顯著的區別。根據市場研究機構Strategy Analytics發佈的數據代表,2012年第4季度, 在中國大陸市場出貨的智能手機當中,98%採用Android和iOS兩大操做平臺。其中,Android智能手機佔86%,iOS智能手機只佔12%。這就意味着,要分析微信對網絡的影響,主要分析微信在Android系統上的工做特徵便可。

通過分析發現,在iOS系統下微信對網絡的影響並不大,微信在剛開始運行或者剛從後臺切換到前臺時,都會以一個新的Session的方式從新發起登陸,登陸成功後再建立一個TCP長鏈接做爲業務鏈接,該鏈接以2分鐘的頻次發送長度爲86字節的心跳包。當微信被切入後臺後,因爲iOS系統不容許程序在後臺運行,業務連接斷開, 微信轉而採用iOS的PUSH機制來通知客戶端有到達的信息。iOS的PUSH鏈接由操做系統維護,心跳週期爲10分鐘左右,整個系統的全部應用共用一個PUSH鏈接,因此在iOS系統下,微信的業務特徵和大部分互聯網應用區別不大。

而在Android系統下,微信的業務特徵則有顯著的區別,微信自從登陸成功後,建立的業務連接每隔2分鐘即會向服務器發送一個82字節的心跳包。因爲Android系統容許程序在後臺運行,當微信被切入後臺後,微信的業務連接並無斷開,將繼續以此頻次發送心跳包。也就是說,Android版本的微信只要運行並登陸成功後,將24小時不間斷地發送心跳包,這樣, 即便對微信不進行任何操做,微信天天將發送24x30=720個數據包, 數據量爲24x30x82=59K字節,按月計算摺合每個月22 320個數據包或 1.83M字節數據。

二．微信信令流量分析

1微信的信令流量

經過在無線網管系統中掛錶跟蹤發現,微信每發送一個心跳包時在網絡側抓取的信令如圖1所示。圖中體現了微信一次心跳包引起的用於無線資源管理的信令流程,其中,從編號72197到72201的5條信令爲RRC鏈接的創建信令。終端處於空閒模式時,當終端請求創建信令鏈接時,將發起RRC鏈接創建過程,其步驟以下[1]:

From-UE/ RRC_RRC_CONNECT_REQ, 終端發送RRC Connect Request 消息。
To-NodeB/NBAP_RL_ SETUP_REQ,SRNC進行資源分配後,向Node B發送Radio Link Setup Request消息,要求Node B分配RRC鏈接所需的無線鏈路資源。
From-NodeB/NBAP_ RL_SETUP_RSP,Node B分配資源後,應答Radio Link Setup Response消息。
SRNC發起Iub 接口用戶面傳輸承載的創建,並完成RNC與NodeB之間的同步。
To- UE/RRC_RRC_CONN_SETUP, SRNC向終端發送RRC Connection Setup消息。
From-UE / RRC_ RRC_CONNECT_SETUP_CMP, 終端回覆RRC Connection Setup Complete消息。

圖1 微信每次心跳包在無線側產生的信令：
<ignore_js_op>

後續的編號72203到72220的信令爲IP數據包傳輸過程當中的信令,大部分是終端和核心網之間的直傳消息。在此期間,心跳包的IP數據從終端經過無線網絡傳輸到了服務器。

須要重點關注的信令在於編號72221,發自終端的RRC_SIG_ CONNECT_REL_IND信令,該信令在IP包傳送完畢7秒鐘後出現, 表示終端主動要求釋放信令鏈接。後續的8條信令是標準的RRC釋放流程,表示無線資源被釋放的過程。終端主動要求釋放鏈接的緣由是當前大部分智能手機爲了省電, 每次檢測到網絡空閒後,2~10秒內會釋放鏈接。

當2分鐘後終端再次發送心跳包的時候,上述信令流程將重複一遍。這裏須要注意的是,RRC連接以及無線資源的釋放,並不意味着TCP鏈接的斷線,無線資源能夠在TCP層須要收發數據包時才臨時從新分配,雖然從新分配意味着上述RRC鏈接創建和釋放的信令開銷,可是對於無線網絡來講,無實際數據流量時繼續佔用無線資源的成本更加昂貴。

在當前的網絡側配置中,即便終端在2~10秒內不主動釋放鏈接,網絡側也會在網絡空閒15秒後釋放無線資源。因此微信2分鐘的心跳週期,每次心跳包必然會引起一次完整的無線資源申請和釋放的信令開銷,根據統計,每次流程中須要引起30多條信令,其中RNC需處理15條信令消息(圖1中黑色字體而且不帶DIRECT標識的部分,帶 DIRECT標識表示直傳消息,無需 RNC處理)。

2傳統電信業務的信令流量

如今咱們來抓取一下傳統的電信業務對應的信令流程,以便和微信引起的信令進行對比,發送一條短信的信令流程如圖2所示,一次語音被叫的信令流程如圖3所示。

圖2 發送一條短信在無線側產生的信令：
<ignore_js_op>

能夠看到,發送一條短信會引起30條信令,文中未列出接收一條短信的信令流程,實際測試發現接收短信和發送短信產生的信令數量相似。

圖3 接收一次語音呼叫在無線側產生的信令：
<ignore_js_op>

在圖3所示的一次語音被叫信令流程中,信令總數爲40多條。其中編號92的RANAP_PAGING表示尋呼信令,編號93到97的信令爲RRC鏈接的創建,編號118的信令爲被叫振鈴,編號120的信令爲被叫摘機,編號122的信令爲雙方開始通話,編號124的信令爲被叫掛機,編號132到編號135表示RRC 鏈接的釋放。

一次語音主叫產生的信令和語音被叫相似。

三．總結

從以上的信令跟蹤分析能夠發現,微信一次心跳產生的信令,基本等同於發送或接收一條短信的信令,稍少於呼出或接聽一個電話的信令。由第2節對微信IP層心跳數據包的分析可知,在一個月中,微信用戶即便不進行任何操做,也會發送22 320個心跳包,至關於消耗了發送22 320條短信的信令處理能力(或者撥打1萬多個電話的信令處理能力),可是隻產生1.83M字節的流量。考慮到微信用戶正常使用的狀況下,多少會進行一些其餘操做,使其帶來的實際流量消耗達到幾十或者上百M字節,可是其對信令資源的巨大消耗是不爭的事實, 因此中國移動聲稱的「微信佔用了60%的信令資源,卻只產生了10%的流量」是有事實依據的。

微信對信令資源的過多消耗, 的確會影響傳統業務的質量。由於運營商的信道分爲控制信道和業務信道,流量、語音這些數據走的是業務信道,信令等控制信號走的是控制信道。每次發起通話、接收短信首先要發出控制信號也就是信令,而後纔能有數據傳輸,因爲協議和標準的限制,運營商在採購網絡設備時,控制信道與業務信道的分配是成比例的。若是某個業務佔用的業務信道和控制信道的比例嚴重不符,將致使控制信道阻塞,這時即便業務信道再通暢,電話也打不進去,數據也沒法傳輸。

以一個普通用戶每個月平均發送100條短信,打200個電話計算, 一個微信用戶佔用的控制信道資源至關於近100個用戶使用傳統電信業務的控制信道資源, 考慮到微信的高普及率,在忙時徹底可能致使控制信道擁塞,這在國際上也已經有過先例,2012年1月,日本最大的移動運營商NTTDOCOMO在東京地區的網絡發生故障,有252萬用戶受到影響,過後調查發現,某款能夠免費進行語音通訊的安卓應用,每隔3至5分鐘便發送控制信令,正是這款應用致使了運營商信道堵塞。

因爲無線網絡的頻帶資源相比計算機網絡的光纖傳輸帶寬而言稀缺得多,無線信號所受到空中干擾大,信號隨距離的衰減快,要達到一樣的帶寬及一樣的覆蓋範圍,配置密集基站的成本遠比建設光纖傳輸網要高得多,正是由於如此,移動通訊網絡中才須要頻繁地經過釋放和從新申請無線資源來對寶貴的無線資源進行復用。微信用傳統互聯網的方法來設計移動互聯網的應用,實際上是利用了當前運營商只對業務流量進行收費,並不對控制信令流量進行收費的計費體系缺陷, 有違網絡公平使用原則。以銀行的業務做爲類比,本質上至關於每一個用戶都到銀行櫃檯存錢,可是每次只存1分錢,一天存下來銀行的收益也遠沒法收回營業場因此及營業人員的成本支出,個別用戶這樣操做並無什麼問題,可是不少用戶由於某種能夠帶來額外收益的緣由,都到銀行以這種方式存錢,那麼結果必然是銀行要麼關閉營業網點,要麼提升單次服務的門檻,不然這種模式確定難覺得繼。

解決微信問題的方法,要麼運營商經過其餘業務的補貼,來消化網絡擴容的成本;或者騰訊經過下降微信心跳機制的頻次, 減小對移動網絡信令資源的消耗。相信不久的未來,騰訊和運營商之間能夠完美解決微信過多消耗信令資源的問題。