網絡抖動下移動應用性能測試仿真

何美玲 李佩雅

（1.浙江中醫藥大學信息技術中心 浙江省杭州市 310000 2.暨南大學網絡空間安全學院 廣東省廣州市 510632）

1 引言

隨著手機的普及和深度使用，移動應用的使用達到了空前的熱度。移動應用的特點在于網絡狀態不穩定，網絡模式不固定。移動終端隨著用戶發生地理位置變更，其網絡模式相應發生切換、網絡信號強弱發生變化，就是所謂的網絡抖動。網絡抖動會影響應用的使用體驗，若應用研發過程中未做好高可用性保護容易導致應用出現弱網絡條件下的慢響應、無響應設置崩潰。因此，研究網絡抖動下的應用性能仿真測試具有深遠意義。

2 研究依據及可行性

統計表明，全球超過70%的應用部署都是失敗的，因為幾乎所有應用的研發和質量保障都是在網絡性能較好的局域網實驗室完成的，技術人員重點關注的是上層應用實現，而忽略了下層數據連接。

利用技術手段盡可能對網絡條件進行抖動模擬仿真，使其產生網絡損傷，即生成較弱性能的網絡條件，在低于或接近現實中弱網絡模型的狀態下進行移動應用的功能和性能校驗確保其在現實生產環境中也能達到使用標準。

另外，網絡抖動仿真的意義還可以對應用健壯性進行檢驗。在抖動網絡條件下，應用的容錯機制開啟，應用終端和服務器的響應時間拉長，如研發人員會預設一些容錯控制，類似加載等待UI 等。正是檢驗應用的高可用性的一種手段。

網絡仿真模擬是否存在可行性，取決于網絡性能的核心指標以及如何通過模擬變更這些指標數據來控制不同網絡模式的強弱。網絡的主要性能指標有帶寬、時延和帶寬時延積。三者關系如下公式：

帶寬Band width：在一個固定的時間內（1 秒），網絡中能通過的最大位數據。就像高速公路的車道一樣，帶寬越大，車道越多。即數據傳輸率。它的主要影響因素是網絡設備。

時延Delay：一個數據包從用戶的計算機發送到網站服務器，再從網站服務器返回用戶計算機的來回時間。即數據從電腦這邊傳到那邊所用的時間。時延包括發送時延、傳播時延和處理時延。帶寬是影響時延的其中一個因素，因帶寬小會導致交換機和路由器等待。另外硬件性能如路由器跳數等也會影響時延。網絡中各個傳輸和處理節點的延時都會增加總的網絡時延。網絡時延越高，網速越慢。通常使用PING(Packet Internet Grope)來測量網絡延時。由于互聯網絡的復雜性、網絡流量的動態變化和網絡路由的動態選擇，網絡延時隨時都在不停的變化(稱為抖動)。網絡延時和網絡延時的抖動越小，網絡的質量就越好。

帶寬時延積Bandwidth-Delay Product：帶寬乘以傳播時延，即鏈路上的最大比特數。也就是信道中正在傳輸的數據總量。這個指標雖然是評測網絡性能的指標，但其很大程度上依賴前兩個指標，前兩個指標在一定程度上足夠反應，故此處不作考慮。

網絡丟包率：丟包指源端在t 時刻發送分組P 到宿端，若宿端接收到該分組，則t 時刻從源端到宿端的丟包為0，否則為1。丟包率指在兩臺主機的交互過程中，宿端沒有成功接收的分組占源端所發送分組總數的比例[1]。正常傳輸時網絡丟包率應該控制在一定范圍內。丟包率受帶寬和時延的影響，帶寬小或時延高造成數據包發送遇到阻礙，當達到處理不過來的情況該包就會被丟棄。該參數不是主要的評估依據，但能較直觀地反應網絡的整體性能。丟包率也可以用PING 來檢測。

表1：不同類型網絡損傷模擬工具

圖1：NEWT 界面解析

圖2：某網站使用WCDMA 限流前后響應對比

帶寬、時延和丟包率是我們進行仿真測試首要考慮的三個參數，我們通過最優變更這些參數的方式來達到模擬不同網絡狀態的目的。從上面對幾個參數的分析來看，最直接的方式是修改網絡設備，比如傳輸介質，或者更換不同性能的路由器。然而這種方式成本過高，幾乎不存在可行性，促成了我們對網絡抖動模擬的以下探索[2-3]。

圖3：Android APP 在不同網絡模式下響應對比

圖5：Edge 網絡基準下不同延時下的響應對比

3 模擬方法和工具

目前已知的具備可行性的網絡環境控制方式主要有兩種。一種是使用網絡損傷儀。這種方式需要購買設備，成本較高，對于有限的測試目標——比如單個應用的請求——投入產出比太高，一般作為備選。另一種是使用軟件進行網絡損傷配置。使用軟件也分為兩種情況，其一是應用層的代理軟件，如Fiddler,提供編碼接口供測試人員調用，直接對請求進行過濾、限流以及限速，但無法做到丟包，也沒有真實網絡的參考值可供參考。其二是作用在網卡層面的一類軟件。這類軟件不止一種，但原理類同。Windows 上可以使用Network Emulator for Windows Toolkit(NEWT)。這類軟件可以做到對以上所說的參數進行隨心所欲的配置，模擬不同的網速、延時、丟包等。另外，軟件本身預置了2G、3G 等常用網絡制式的參數配置。[4-5]

如表1 所示，顯然是NEWT 更符合需求。NEWT 是通過監控相應的網卡，通過目標網卡提供的接口對以目標網卡為出口的請求按照各種過濾器規則進行過濾，從配置文件中讀取配置，進行丟包、設置請求等待時間、限制帶寬等操作。圖1 是Network Emulator for Windows Toolkit 的操作界面。

NEWT 對帶寬、時延已經丟包等參數的設置是通過配置文件來讀取的，用戶通過圖形界面來設置實際上也會生成一份對應的配置文件。以下是不使用和使用WCDMA 這種配置時PING 某網站的響應對比情況如圖2。

當然，我們可以自定義其他的參數配置，模擬抖動，NEWT 提供各個參數的各種變化模型，比如Gilbert 丟包模型，設置最好情況和最糟糕的情況等等。具體的配置情況需要測試人員對網絡屬性和原理有更加深刻的認識，高階用法設置可以提供網絡更底層的測試服務。

圖4：Edge 網絡基準下不同帶寬下的響應對比

圖6：Edge 網絡基準不同丟包率下的響應對比

4 工程實踐仿真

4.1 實驗環境優化改造

4.1.1 Mock 服務使網絡更單一純粹

為了盡可能地減少服務請求需要耗費的路由轉換和多個網絡之間的訪問隔離，我們使用mock 服務的方式將移動應用的后端服務架設再本地服務器上，排除了辦公網和機房網絡之間尋址的時間耗費和這部分網絡耗時，使實驗采集到的數據更單一。

4.1.2 腳本自動統計響應時間

由于人腦人眼存在思考等待時間且UI 返回有延時，數據不夠精準，我們采用在每個接口調用處插入腳本統計接口請求到響應返回的耗時，并通過圖表繪制展示。這種方式使采集數據更方便且精確。

4.1.3 循環多次采樣

為了提高數據的可參考性，我們對每組數據采樣超過30 次，這是平衡了實驗成本和準確度的一個結果。并且采樣數據必須排除因為設備卡頓等個例導致的偏離較大的值。

4.2 單因子試驗

以Android 端應用為例介紹網絡抖動下的性能測試仿真思路和解決方案[6]。通過標準為在正常網絡條件下20s 內成功返回，在較差網絡條件下無論請求成功與否，必須在60s 內作出超時返回。實驗時我們通過單因子和多因子角度對接口響應做出評測，嘗試找出臨界值并給出測試建議。

表2：復合因子網絡參數變化下的響應情況

圖7：多因子網絡參數變化下的響應情況

怎樣的網絡情況算是正常，蘋果官方給出的參考值如下：

（1）3G（330kbit 的上行速率，780kbit 的下行速率，100ms的延遲和0%的丟包率）

（2）Edge（200kbit的上行速率，2400kbit的下行速率，400ms 的延遲和0%的丟包率）

（3）Wi-Fi（33000kbit 的上行速率，40000kbit 的下行速率，1ms 的延遲和0%的丟包率）

這樣的網絡狀況下，以Android 端APP 為對象，分別進行多組測試后得出如圖3 的結果（響應時間以毫秒記）。

可以看到這樣的網絡情況下幾乎沒有任何的性能問題，全部相應成功且幾乎無等待。由于Edge 網絡條件相對較苛刻，更具有參考意義，因此我們選取Edge 的正常值作為基準參考，進行單因子試驗，繪制如圖4。

圖4 中可以看到將帶寬限制到30kb/s 時請求仍然成功，但響應時間拉長，但當帶寬調整到10kb/s 時，請求失敗且等待時間達到60s。可見臨界值在10-30kb/s 之間。單獨做了一組20kb/s 的試驗，發現大部分請求成功且響應時間達到將近50s。結論是：160kb/s 即20KB/s，算是Edge 網絡正常情況，延時在2s 多可以接受，較差的情況下如30kb/s，請求仍然能響應但超時較為嚴重。

同樣的，如圖5 所示，在時延高達2000ms 時目標在15s 左右響應成功，5000ms 時請求失敗且響應時間拉大到60s 且大部分請求失敗。客戶端認為在20s 內響應成功算是可接受，延時達到2000ms 仍然能響應可以接受，因此是符合生產標準的。

另外，如圖6 所示，相對于前兩個指標，實驗表明丟包率顯得不那么具有數值參考意義。采集到的數據跨度較大，原因是隨機丟包導致部分請求響應較快部分較慢，響應時間似乎不那么具有參考意義。實驗表明，在丟包率達到10%的情況下，請求成功率仍然在90%以上，當丟包率達到20%，請求成功率50%，我們認為其符合質量標準。

4.3 復合因子試驗

單因子的質量評估已經給出，多因子的就更為復雜一些。表2是多組參數組合取值獲得的采樣表格。

我們選擇多組數據實驗并繪制圖7。從圖7 中可以看出，當參數維持在時延100ms、帶寬100kb/s 和5%丟包（略差于2G 網絡）時接口幾乎無性能問題，保持無察覺延時請求成功。當網絡時延加大，帶寬進一步放低，丟包率提升，則請求的響應時間越來越長，但請求仍然能保持成功，用戶體驗越來越差。當時延達到1000ms以上且帶寬為2G 較為糟糕的狀況時請求開始大量失敗，響應時間也進一步提高，達到一個峰值（小于60s）后再降下來，這之后的請求幾乎是100%失敗丟棄了。當然，我們的取值是從2G 網絡較為正常的一個配置開始，4000ms 和20kb/s 的一個配置幾乎是2G網絡最為糟糕的參數配比，在該條件下，SDK 能在規定時間內做出響應我們認為其符合上線標準。

4.4 繼續研究與展望

此研究仍處于初期階段，需要挖掘和改進的點很多，如：

4.4.1 尋求更穩定的網絡提供方式

網絡抖動下移動端測試我們采用的是在PC 上模擬環境，讓手機連接PC 虛擬出網絡熱點，達到同時限制手機網絡的目的。由于PC 虛擬出的網絡存在不穩定性，需要尋求一種更穩定的網絡提供方式。

4.4.2 尋求服務的可視化

目前數據統計和分析門檻較高，想要獲得更精確的響應數據需要通過腳本或變更源碼來控制。服務可視化將使得數據統計更方便，且反饋方式更直接，縮小測試成本并提高測試體驗。

5 總結

本文為測試移動應用在網絡抖動下的性能表現進行網絡仿真模擬，從網絡基本性能的參數原理角度探討，實驗模擬弱網條件，對網絡帶寬、延時和丟包率參數采用單因子與符合因子變更比較法進行數據對比分析，是計算機應用網絡仿真條件下的創新型研究方法。經過優化實驗環境改善統計方法，使實驗結果更具說服力，得出結論：實驗用移動應用軟件在網絡仿真條件下的測試結論和生產環境匹配。但實驗處于初級階段，未來需要需求更穩定的仿真防落生成方式，并在數據分析角度做進一步探索，實現平臺化的數據可視化方案。