讓你的Fiddler支持HTTP隧道

    某天我想研究一下本身手機上某款軟件的登錄認證流程，使用Fiddler代理抓包是一種經常使用的方法，但我發現當設置了代理以後一直沒法正常登錄，Fiddler上的抓包以下：

而後就沒有而後了，手機APP上顯示沒法登錄。

    這裏咱們先給出解決方案，打開Rules--->Customize Rules，找到OnBeforeResponse函數，一開始它看起來是這樣的：

static function OnBeforeResponse(oSession: Session) {
    if (m_Hide304s && oSession.responseCode == 304) {
        oSession["ui-hide"] = "true";
    }
｝

    在第一個if後面加上下面這段代碼：

if (oSession.oRequest["User-Agent"].IndexOf("MIUI")>-1 && oSession.HTTPMethodIs("CONNECT")){
    oSession.oResponse.headers["Connection"] = "Keep-Alive";
}

    它的含義是，當Fiddler做爲代理對請求進行應答時，若是請求的"User-Agent"中含有「MIUI」字段（緣由見上面的截圖），且使用的是CONNECT方法時，就將應答首部中的"Connection"字段設置爲"Keep-Alive"（經過上面的截圖能夠看到，登錄失敗時回的是"close"）。 

    修改以後果真可以順利登錄了，下面咱們再借助Wireshark把這期間流經網卡的完整數據包都抓下來，分析一下先後兩次處理流程上的區別。

    1）先看登錄失敗時：

    這種狀況下，客戶端APP（192.168.31.29）向Fiddler代理服務器（192.168.31.193）發起CONNECT請求，目標Host是account.xiaomi.com，Fiddler代理在創建了與目標Host的鏈接以後，會向客戶端回一條Connection Established的應答，但其中的Connection被設置爲close，因而客戶端在收到這條應答後關閉了鏈接，也就沒有而後了，致使一直登錄不成功。

    2）登錄成功時的流程：

    此次咱們只過濾出從客戶端到代理服務器的流量，能夠看到當Fiddler代理服務器對CONNECT請求回覆了"Keep-Alive"以後，客戶端會在這條鏈接上發送一些加密的數據，這些加密數據就是用來完成登錄流程的。

    keep-alive是在HTTP1.0中引入的擴展，用於進行鏈接持久化，代表服務器願意爲下一條請求將鏈接保持在打開狀態。HTTP1.1中逐漸中止了對keep-alive鏈接的支持，而是用一種名爲"持久鏈接"的改進型設計取代了它（但實際上keep-alive仍然受到了客戶端和服務器的普遍支持）。HTTP1.1中的這種持久鏈接默認都是激活的，但像咱們在一開始遇到的狀況中，Fiddler做爲代理服務器直接發送了close，致使客戶端直接關閉了鏈接，沒法在該條鏈接上發送更多的請求了。

    這下你應該已經徹底理解了其中的來龍去脈了吧：）

     週末了，祝你們開心！