在解決日常的支持需求中，經(jīng)常會遇到一些用戶反饋一些無法簡單復(fù)現(xiàn)的bug，有很大一部分的bug是由于用戶自身的網(wǎng)絡(luò)環(huán)境波動，或者是本身網(wǎng)絡(luò)環(huán)境就較為惡劣，而服務(wù)在面對這種惡劣的網(wǎng)絡(luò)環(huán)境的健壯性不夠，導(dǎo)致會出現(xiàn)一些意想不到的bug。而在正常的開發(fā)自測過程中很難去營造出這種惡劣的網(wǎng)絡(luò)環(huán)境，使得這些bug較難被提前發(fā)現(xiàn)和修復(fù)。

另外一些服務(wù)在惡劣網(wǎng)絡(luò)環(huán)境下雖然不會出現(xiàn)不可用的情況，但是用戶體檢很差，為了優(yōu)化這個情況下的用戶體驗，也需要去在本地模擬這種環(huán)境來進(jìn)行調(diào)優(yōu)。

所以要去復(fù)現(xiàn)這些bug，甚至是去提前發(fā)現(xiàn)這些bug，就需要能夠在開發(fā)環(huán)境中模擬出惡劣的網(wǎng)絡(luò)環(huán)境，從而看到在這種惡劣的網(wǎng)絡(luò)環(huán)境下的服務(wù)的表現(xiàn)等。

當(dāng)前模擬惡劣網(wǎng)絡(luò)環(huán)境主要可以通過以下這些手段實現(xiàn)：

• 通過應(yīng)用層或者傳輸層的代理服務(wù)器，通過在代理服務(wù)器上設(shè)置一些模擬惡劣網(wǎng)絡(luò)環(huán)境的參數(shù)，使得通過這些代理服務(wù)器的流量都被轉(zhuǎn)化為惡劣網(wǎng)絡(luò)環(huán)境下的流量。如利用Fiddler，Charles等具有代理服務(wù)器功能的網(wǎng)絡(luò)流量分析軟件來實現(xiàn)。
• 通過利用一些更底層的驅(qū)動層面的服務(wù)，通過控制網(wǎng)卡的收包發(fā)包的行為，來模擬惡劣的網(wǎng)絡(luò)環(huán)境。如dummynet的ipfw驅(qū)動等。
• 通過建立一個可控的網(wǎng)關(guān)，在網(wǎng)關(guān)上部署模擬惡劣環(huán)境的相關(guān)程序，所有需要借助該網(wǎng)關(guān)進(jìn)行轉(zhuǎn)發(fā)的流量都會被模擬為惡劣網(wǎng)絡(luò)條件。Linux下的netem就提供了這類支持。

通過應(yīng)用層或者傳輸層的代理服務(wù)器，通過在代理服務(wù)器上設(shè)置一些模擬惡劣網(wǎng)絡(luò)環(huán)境的參數(shù)，使得通過這些代理服務(wù)器的流量都被轉(zhuǎn)化為惡劣網(wǎng)絡(luò)環(huán)境下的流量。

如利用Fiddler，Charles等具有代理服務(wù)器功能的網(wǎng)絡(luò)流量分析軟件來實現(xiàn)。通過利用一些更底層的驅(qū)動層面的服務(wù)，通過控制網(wǎng)卡的收包發(fā)包的行為，來模擬惡劣的網(wǎng)絡(luò)環(huán)境。

如dummynet的ipfw驅(qū)動等。通過建立一個可控的網(wǎng)關(guān)，在網(wǎng)關(guān)上部署模擬惡劣環(huán)境的相關(guān)程序，所有需要借助該網(wǎng)關(guān)進(jìn)行轉(zhuǎn)發(fā)的流量都會被模擬為惡劣網(wǎng)絡(luò)條件。

Linux下的netem就提供了這類支持。

這里主要先講的是第一種手段，即利用Fiddler來模擬惡劣的網(wǎng)絡(luò)環(huán)境，對服務(wù)進(jìn)行測試，這個手段實現(xiàn)簡單，較為直觀，但是缺點(diǎn)是只能支持那些利用HTTP進(jìn)行通信和交互的服務(wù)。在之后的文章中也會進(jìn)一步說一下后兩種手段。

Fiddler是啥

Fiddler的官網(wǎng)上是這樣描述它自己的：The free web debugging proxy for any browser, system or platform，即跨瀏覽器、跨系統(tǒng)、跨平臺的免費(fèi)Web Debug代理服務(wù)器。

當(dāng)你的HTTP瀏覽經(jīng)過Fiddler時，F(xiàn)iddler可以監(jiān)視流量，查看HTTP通訊的各種信息，設(shè)置斷點(diǎn)查看和修改HTTP數(shù)據(jù)，甚至可以構(gòu)造各種測試用的HTTP包以及重放已記錄的包等。

其官網(wǎng)是http://www.fiddler2.com/fiddler2/，上面詳細(xì)地介紹了Fiddler到底是什么。

簡單地利用Fiddler限速模擬惡劣網(wǎng)絡(luò)環(huán)境

Fiddler本身已經(jīng)預(yù)置提供了模擬Modem速度的選項，其位置位于：

Rules – Performances – Simulate Modem Speeds

勾選該選項后，所有通過Fiddler代理的流量都會變得和多年前的56k小貓時上網(wǎng)一般的慢。  

由于Fiddler只是一個HTTP代理，要直觀地看出限速效果，最好是運(yùn)行在瀏覽器中的測速工具，這里選用speedtest.net提供的測速工具進(jìn)行測試。  

首先是開啟該選項之前的速度：

打開了Simulate Modem Speeds后：

速度已經(jīng)回到了當(dāng)年那種無法忍受的低速了，注意到這里PING值也有了顯著的提高，而事實上ping值是ICMP層的控制報文，并不會被Fiddler影響，理論上ping值并不會出現(xiàn)提高的情況，進(jìn)一步分析Fiddler中的報文則可以看出端倪：

事實上網(wǎng)頁插件并不能實現(xiàn)發(fā)送ICMP包并得到ping值的功能，而是用多次較小的HTTP GET請求的響應(yīng)時間來計算PING值，這里實際算出來的是一個平均的HTTP的RTT值，所以受到Fiddler模擬惡劣環(huán)境的影響就是正常的了。

調(diào)整模擬惡劣網(wǎng)絡(luò)環(huán)境的參數(shù)

直接模擬Modem速度實在是慢爆了，事實上就算是在很差信號的情況下，手機(jī)移動網(wǎng)絡(luò)的速度都已經(jīng)超過了當(dāng)年的56k Modem速度了，所以采用默認(rèn)的配置模擬出來的環(huán)境過于惡劣，并不一定符合需求，此時就需要對限速的參數(shù)進(jìn)行調(diào)整。  

Fiddler本身就提供了一個配置文件供調(diào)整這些參數(shù)，點(diǎn)擊：  

Rules – Customize Rules…  

就會用文本編輯器打開CustomRules.js文件，其默認(rèn)位于用戶目錄的文檔目錄下的\Fiddler2\Scripts 位置，后綴名是js，其內(nèi)容實質(zhì)是JScript.NET——微軟對ECMAScript規(guī)范的實現(xiàn)，與日常使用的javascript是屬于同一個規(guī)范下的，但是在擴(kuò)展的細(xì)節(jié)實現(xiàn)存在一定的不同。  

打開該文件后，可以找到一個m_SimulateModem標(biāo)志位：

if (m_SimulateModem) {
    // Delay sends by 300ms per KB uploaded.
    oSession["request-trickle-delay"] = "300";
    // Delay receives by 150ms per KB downloaded.
    oSession["response-trickle-delay"] = "150"
}

該標(biāo)志位控制著oSession的兩個參數(shù)值的設(shè)置，當(dāng)勾選了Simulate Modem Speeds時，request-trickle-delay與response-trickle-delay就會被設(shè)置，其中request-trickle-delay中的值代表每KB的數(shù)據(jù)被上傳時會被延時多少毫秒，response-trickle-delay則對應(yīng)下載時每KB的數(shù)據(jù)會被延時多少毫秒，如果本身網(wǎng)速已經(jīng)相當(dāng)快的話，這里設(shè)置的值就可以近似地推算出開啟模擬后的上傳和下載帶寬了，比如默認(rèn)設(shè)置下下載延時為150ms，上傳延時為300ms，對應(yīng)可以推算出大致的模擬帶寬為：

上傳帶寬=(1*8/1000)/0.300≈0.053Mbps

下載帶寬=(1*8/1000)/0.150≈0.027Mbps

然而實際情況下卻得到了兩倍于這個值的帶寬，推測可能是Fiddler的內(nèi)部實現(xiàn)上有一些和描述上的不同，為何為造成這個現(xiàn)象現(xiàn)在還不是很清楚，所以上述公式最后還需要修正一個2.0的系數(shù)，即：

上傳帶寬=((1*8/1000)/0.300)*2.0≈0.106Mbps

下載帶寬=((1*8/1000)/0.150)*2.0≈0.053Mbps

假設(shè)我們將兩個參數(shù)都設(shè)置為50，則會得到上下載帶寬均為0.32Mbps，測速結(jié)果如下所示：

編寫自定義腳本

進(jìn)一步地，我們可以擴(kuò)展CustomRules.js里的邏輯，參照J(rèn)script的文檔可以在模擬惡劣環(huán)境中加入更多自定義的邏輯，這里實現(xiàn)了一個隨機(jī)延時量設(shè)置，使得網(wǎng)絡(luò)帶寬不是恒定為一個低速的值，而是會在一定范圍內(nèi)隨機(jī)抖動：

static function randInt(min, max) {
    return Math.round(Math.random()*(max-min)+min);
}
if (m_SimulateModem) {
    // Delay sends by 300ms per KB uploaded.
    oSession["request-trickle-delay"] = ""+randInt(1,50);
    // Delay receives by 150ms per KB downloaded.
    oSession["response-trickle-delay"] = ""+randInt(1,50);
}

得到的測試結(jié)果如下：

在測速過程中的瞬時速度的趨勢圖如下：

可以看到整體的網(wǎng)絡(luò)限速存在了一定程度的抖動。

通過進(jìn)一步擴(kuò)展CustionRules.js可以實現(xiàn)很多需要的惡劣環(huán)境模擬場景，如果場景較為復(fù)雜的話，也可以通過編寫Fiddler的插件的方式，編寫C#插件代碼來進(jìn)一步控制Fiddler的行為，在這里就不多做贅述了。

詳細(xì)可以參照：http://docs.telerik.com/fiddler/extend-fiddler/extendwithdotnet

Fiddler模擬惡劣網(wǎng)絡(luò)環(huán)境的局限性

Fiddler進(jìn)行限速較為簡單和靈活，配置也較為方便，但是由于它是一個應(yīng)用層的HTTP的代理，只能模擬該層上的行為，對于一些復(fù)雜的網(wǎng)絡(luò)層的丟包、重傳等惡劣情況就不能很好的模擬出來，而且對于其他協(xié)議的應(yīng)用也不支持，后續(xù)會介紹一些其他的模擬惡劣環(huán)境的方法和軟件來彌補(bǔ)這些缺失。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論