網路效能評價的實現

網路的優劣會影響網路互動的延遲時間、穩定性和速度，從使用者體驗上集中表現為開啟頁面的速度緩慢。比如在較差的網路併發的請求數會被降低，以避免網路效能因為阻塞而進一步惡化。

針對不同網路品質的優化的前提就是要有一種方法來度量網路的品質。

目前度量網路的品質的方法如果僅以網路連線型別來區分,比如2G, 3G, Wifi等，無法有效感知到當時的網路狀態。在同一網路連線型別下，網路的品質仍有大幅波動，可能會因為阻塞以及線路上問題導致延遲上抖動(jitter)、丟失資料包、資料包損壞等情況。在現實場景中，比如繁忙時段，或者處在訊號不好的區域時(如交通工具上)，使用網路型別來判斷當時的網路品質會有很大偏差。

本文基於對一段時間的網路資料的記錄，進行演算法處理，可以測出一個衡量當時網路狀態的指標(MI: Measurement Index)。具體應用到移動裝置上時，考慮到計算量的問題，可以使用近似演算法減小計算的複雜度。

目前的使用的演算法是結合歷史資料進行統計，即執行指數平滑演算法。這樣理論上因為同時使用了本次及之前的歷史的資料進行計算，可以將單次統計的資料量減少。

網路資料的定義是通過模擬測試環境錄製得來。其中包括兩個主要內容:
1. 定義網路評測的引數
2. 定義網路狀態區間範圍

在實際應用時，還需要考慮資料採集的區間和資料量，以及資料的平滑處理。

網路評測的引數

經過對比評估以下六個引數對應於latency和bandwidth的設定，得到資料如下:
1. Speed, 傳輸速率：由收完資料的時間除去所收取的資料大小。
2. Header Received: 收到響應頭的時間 （即TTFB)。
3. Connected: 連線到主機的時間。
4. Sent: 在Java層完成呼叫完成傳送請求的時間。
5. DNS Resolved: DNS解析的時間。
6. Finished: 整個請求完成的時間。

對比分析各引數中位數與網路狀態(rate)後，發現以下引數與網路狀態的關聯關係，其中Header Received的關聯關係為正相關。

所以定義由Header Received時間定為網路衡量指標

定義網路狀態區間範圍

關於網路狀態範圍，由於網路的波動性，不能限定在具體的一個值的區分。這裡使用K中值分類法(R Script: compareData.R)。

將資料分為四個簇，依次取出其設定範圍。再以目前測試發現最大值分佈在12000左右(約為6000延遲)，　所以使用13000，即最大延遲數，進行歸一化處理。

下圖表示的為分為四個簇的情況(每一項資料為一個URL測試５次所得結果)：

其中cluster 4最佳，cluster 1為最差的區間, 為保守起見，在目前的實現將cluster 1與cluster 2合併來看。

定義資料分析的時間段

依次採集分析2x1URL, 5x1URL,5x2URLs, 5x4URLs及3x1URL資料。對比各種情況下資料聚合的情況。其中2x1URL 表現資料不足，四個簇不能很好的分隔:

這時的每一項值的資料量為50條左右。

當3x1URL時，每一項值的資料量為80條上下，四個簇重合部分已經有很好的改善:

由上面可知，如果使用獨立樣本進行計算，50筆資料較難獲得有效的樣本資料，至少需要８０筆資料，才能得出較合適的統計。而行動網路下，特別是2G網路下，８０個請求會耗時太久，不利於及時體現當前網路資料。

目前的使用的演算法是結合歷史資料進行統計，即執行指數平滑演算法。這樣理論上因為同時使用了本次及之前的歷史的資料進行計算，可以將單次統計的資料量減少。

定義資料的樣本大小及採集週期

目前選定最小採集樣本為15筆請求,包含失敗的請求,其中失敗的請求視為一次最大延遲記錄(取值見上面的討論)。 最小採集週期為30秒，最大采集週期為4分鐘。

考慮到網路的變化特性，一是不能太快跳變，二是及時逼近。另外在行動網路下，資料量可能達不到採集的要求，必須有效地利用歷史資料。所以係數的選擇需要考慮到兩個方面:一是收斂速度，二是兼顧歷史資料(利用歷史資料進行計算，並避免資料不準導致的誤判。)。

這裡存在三個變數: 採集的週期(t)，採集的樣本數(n)及平滑係數(a)。
採集樣本數是指最小可以用於統計運算的資料數量。根據模擬測試(R指令碼為simulatorPhase.R), 判斷資料集的大小的波動性可以在平滑係數的輔助下達到一定的穩定性（平滑係數越小，資料分佈越穩定，但收斂速度越慢.）。 比如下圖中使用樣本數15、平滑係數0.3的組合可以達到樣本數20、平滑係數0.4組合的標準差範圍。(平滑係數越大標準差越大!)

採集樣本為20，平滑係數為0.4(總資料量4000)，結果的標準差為579.87(非定值):

採集樣本為15，平滑係數為0.4(總資料量4000)，結果的標準差為589.16(非定值):

採集樣本為15，平滑係數為0.3(總資料量4000)，結果的標準差為576.41(非定值):

採集樣本為15，平滑係數為0.6(總資料量4000)，結果的標準差為872.23(非定值):

採集週期是指最小的資料採集時間，在此時間內只負責收集資料，不進行計算。在採集週期內可能並不會收集到足夠的資料，就會延長到一個最大采集週期。
採集的週期的大小取決於最小採集樣本的大小。目前設定為30秒。

最大采集週期的選定，取值於行動網路下，以無圖模式一分鐘瀏覽一個新浪新聞頁面，達到採集樣本數量的時間，即4分鐘。

下圖為上述引數在實際測試過程中觀察到的Measurement Index分佈的情況, 在資料演化將近6次(約3分鐘)後維持到6385上下。

定義資料的平滑係數

不同的平滑係數會一個處理波動時的浮動範圍，表示無法明確判別的區域，歸為較好的網路處理。由此定義了實現時使用的模糊區間。

測試對比了多個候選的係數。以0.3及0.65為例說明如下。

平滑係數:0.3

指數0.3是假設網路環境相對穩定，但受網路抖動的影響會有波動。

在計算時選擇經過多樣本獲得的歷史資料的比重大於新取得的單樣本資料。缺點是會造成逼近速度變緩, 近8次逼近到目標值(相差200以內)。

再模擬兩次資料統計的波動。單次統計資料約為2000，若分成兩次統計，可能會遇到一次3500，後一次500的大幅波動。應用係數0.3後統計結果保持在平均值2000的上下200的範圍, 對應於指數上下浮動0.03。
以下為其示意圖:

8次逼近所需時間視最小採集週期而定，一般情況下約為4分鐘時間。

考慮大幅波動時的標準差，以3000~1500的波動為例，其標準差為:447.56。

係數0.3最大的優勢在於適應小樣本資料的情況。詳細之前的討論。為了彌補主要的缺點，將在一個網路下第一次計算時，先使用係數0.5, 再調整為0.3。效果如下:

以下為實際測試結果(latency:2000,bandwidth 80kbps, standard MI:~2500):

平滑係數:0.65

當選取0.65作為係數時，當前值所佔的比重更高。需要3次運算逼近到設定值(130以內，佔比小於1%)。

如上模擬兩次資料統計的波動。這時統計結果保持在平均值2000的上下約800(逼近於777)的範圍。即設定的界定值前後800對應於效能指數上下浮動0.06。

考慮大幅波動時的標準差，以3000~1500的波動為例，其標準差為:381.9。較係數取０.５時並沒引入太多的誤差，卻將收斂所用的次數降低了２次。

與實際場景的對應

與現實場景的對應關係如下（收集的現場資料）：

Scenario	Latency	Index
包含地鐵繁忙時間的資料(2G)	500~6000	19~100
地鐵一般場景(2G)	100~400	5~64
公司座位	200~500	32~52
3G&Wifi	50~80	0~4

下面為其分佈示意圖(橫軸依次代表上表中的五項，請忽略第3項資料):

參考

• 網路效能評價