利用Fiddler模擬惡劣網絡環境

在解決日常的支持需求中，經常會遇到一些用戶反饋一些無法簡單復現的bug，有很大一部分的bug是由於用戶自身的網絡環境波動，或者是本身網絡環境就較爲惡劣，而服務在面對這種惡劣的網絡環境的健壯性不夠，導致會出現一些意想不到的bug。而在正常的開發自測過程中很難去營造出這種惡劣的網絡環境，使得這些bug較難被提前發現和修復。另外一些服務在惡劣網絡環境下雖然不會出現不可用的情況，但是用戶體檢很差，爲了優化這個情況下的用戶體驗，也需要去在本地模擬這種環境來進行調優。 
所以要去復現這些bug，甚至是去提前發現這些bug，就需要能夠在開發環境中模擬出惡劣的網絡環境，從而看到在這種惡劣的網絡環境下的服務的表現等。當前模擬惡劣網絡環境主要可以通過以下這些手段實現：

1. 通過應用層或者傳輸層的代理服務器，通過在代理服務器上設置一些模擬惡劣網絡環境的參數，使得通過這些代理服務器的流量都被轉化爲惡劣網絡環境下的流量。如利用Fiddler，Charles等具有代理服務器功能的網絡流量分析軟件來實現。
2. 通過利用一些更底層的驅動層面的服務，通過控制網卡的收包發包的行爲，來模擬惡劣的網絡環境。如dummynet的ipfw驅動等。
3. 通過建立一個可控的網關，在網關上部署模擬惡劣環境的相關程序，所有需要藉助該網關進行轉發的流量都會被模擬爲惡劣網絡條件。Linux下的netem就提供了這類支持。

  這裏主要先講的是第一種手段，即利用Fiddler來模擬惡劣的網絡環境，對服務進行測試，這個手段實現簡單，較爲直觀，但是缺點是隻能支持那些利用HTTP進行通信和交互的服務。在之後的文章中也會進一步說一下後兩種手段。

【Fiddler是啥】

  Fiddler的官網上是這樣描述它自己的：The free web debugging proxy for any browser, system or platform，即跨瀏覽器、跨系統、跨平臺的免費Web Debug代理服務器。當你的HTTP瀏覽經過Fiddler時，Fiddler可以監視流量，查看HTTP通訊的各種信息，設置斷點查看和修改HTTP數據，甚至可以構造各種測試用的HTTP包以及重放已記錄的包等。其官網是http://www.fiddler2.com/fiddler2/，上面詳細地介紹了Fiddler到底是什麼。

【簡單地利用Fiddler限速模擬惡劣網絡環境】

  Fiddler本身已經預置提供了模擬Modem速度的選項，其位置位於： 
  Rules – Performances – Simulate Modem Speeds 
 
  勾選該選項後，所有通過Fiddler代理的流量都會變得和多年前的56k小貓時上網一般的慢。 
  由於Fiddler只是一個HTTP代理，要直觀地看出限速效果，最好是運行在瀏覽器中的測速工具，這裏選用speedtest.net提供的測速工具進行測試。 
  首先是開啓該選項之前的速度： 
 
  打開了Simulate Modem Speeds後： 
 
  速度已經回到了當年那種無法忍受的低速了，注意到這裏PING值也有了顯著的提高，而事實上ping值是ICMP層的控制報文，並不會被Fiddler影響，理論上ping值並不會出現提高的情況，進一步分析Fiddler中的報文則可以看出端倪： 
 
  事實上網頁插件並不能實現發送ICMP包並得到ping值的功能，而是用多次較小的HTTP GET請求的響應時間來計算PING值，這裏實際算出來的是一個平均的HTTP的RTT值，所以受到Fiddler模擬惡劣環境的影響就是正常的了。

【調整模擬惡劣網絡環境的參數】

  直接模擬Modem速度實在是慢爆了，事實上就算是在很差信號的情況下，手機移動網絡的速度都已經超過了當年的56k Modem速度了，所以採用默認的配置模擬出來的環境過於惡劣，並不一定符合需求，此時就需要對限速的參數進行調整。 
  Fiddler本身就提供了一個配置文件供調整這些參數，點擊： 
  Rules – Customize Rules… 
  就會用文本編輯器打開CustomRules.js文件，其默認位於用戶目錄的文檔目錄下的\Fiddler2\Scripts 位置，後綴名是js，其內容實質是JScript.NET——微軟對ECMAScript規範的實現，與日常使用的javascript是屬於同一個規範下的，但是在擴展的細節實現存在一定的不同。 
  打開該文件後，可以找到一個m_SimulateModem標誌位：

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"
}

• 1
• 2
• 3
• 4
• 5
• 6

  該標誌位控制着oSession的兩個參數值的設置，當勾選了Simulate Modem Speeds時，request-trickle-delay與response-trickle-delay就會被設置，其中request-trickle-delay中的值代表每KB的數據被上傳時會被延時多少毫秒，response-trickle-delay則對應下載時每KB的數據會被延時多少毫秒，如果本身網速已經相當快的話，這裏設置的值就可以近似地推算出開啓模擬後的上傳和下載帶寬了，比如默認設置下下載延時爲150ms，上傳延時爲300ms，對應可以推算出大致的模擬帶寬爲：

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

  然而實際情況下卻得到了兩倍於這個值的帶寬，推測可能是Fiddler的內部實現上有一些和描述上的不同，爲何爲造成這個現象現在還不是很清楚，所以上述公式最後還需要修正一個2.0的係數，即：

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

  假設我們將兩個參數都設置爲50，則會得到上下載帶寬均爲0.32Mbps，測速結果如下所示： 

【編寫自定義腳本】

  進一步地，我們可以擴展CustomRules.js裏的邏輯，參照Jscript的文檔可以在模擬惡劣環境中加入更多自定義的邏輯，這裏實現了一個隨機延時量設置，使得網絡帶寬不是恆定爲一個低速的值，而是會在一定範圍內隨機抖動：

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);
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

  得到的測試結果如下： 
 
  在測速過程中的瞬時速度的趨勢圖如下： 
 
  可以看到整體的網絡限速存在了一定程度的抖動。 
  通過進一步擴展CustionRules.js可以實現很多需要的惡劣環境模擬場景，如果場景較爲複雜的話，也可以通過編寫Fiddler的插件的方式，編寫C#插件代碼來進一步控制Fiddler的行爲，在這裏就不多做贅述了。詳細可以參照：http://docs.telerik.com/fiddler/extend-fiddler/extendwithdotnet

【Fiddler模擬惡劣網絡環境的侷限性】

  Fiddler進行限速較爲簡單和靈活，配置也較爲方便，但是由於它是一個應用層的HTTP的代理，只能模擬該層上的行爲，對於一些複雜的網絡層的丟包、重傳等惡劣情況就不能很好的模擬出來，而且對於其他協議的應用也不支持，後續會介紹一些其他的模擬惡劣環境的方法和軟件來彌補這些缺失。

轉自：https://www.cnblogs.com/lgqboke/p/6728085.html