fiddler怎麼用?http調試工具fiddler不知道大家是否會用到呢?不過有些朋友可能還不知道怎麼用,下面幫客之家小編為大家分享下http調試工具fiddler使用教程吧!
Fiddler可以幫您記錄,調試Microsoft Internet Explorer與Web應用程式的互動,找到Web程式運行效能的瓶頸,還有如查看向Web伺服器發送cookies的內容,下載內容的大小等功能。
說多一點是,Fiddler站在使用者與Web伺服器的中間,由它轉寄請求與響應,因此Fiddler作為一個可檢視,可定製的工具,能讓您瞭解互動過程細節,有利於解決Web程式的互動問題。如下列:
Internet Explorer <-> WinINET? (由Fiddler運行時自動註冊) <-> Fiddler <-> Web Server
Fiddler可以用於:
效能測試。如查看頁面的大小調試。在會話選項中,可暫停,編輯HTTP通訊 。
Fiddler不僅可用於Microsoft Internet Explorer,其它瀏覽器,如Mozilla Firefox,Opera等也適用。軟體介面友好,精於HTTP,可能比NetMon易用,還可用.NET進行擴充。官方網站上,還有視頻教學。
這個工具我已經使用比較長時間了,對我的協助也挺大,今天我翻譯的微軟的文章,讓更多的朋友都來瞭解這個不錯的工具,也是我第一次翻譯文章,不恰當之處請大家大家多多指正。
介紹:
你是不是曾經疑惑過你的web程式和IE是如何互動的?你是不是遇到過一些奇怪的而你又無法解決的效能瓶頸?你是不是對那些發送給伺服器端的cookie 和那些你下載下來的被標記為可快取的內容感到好奇?
微軟的Fiddler能夠協助你回答以上的問題,不但如此,它還是一個http調試代理,它能 夠記錄所有的你電腦和互連網之間的http通訊,Fiddler 可以也可以讓你檢查所有的http通訊,設定斷點,以及Fiddle 所有的“進出”的資料(指cookie,html,js,css等檔案,這些都可以讓你胡亂修改的意思)。 Fiddler 要比其他的網路調試器要更加簡單,因為它僅僅暴露http通訊還有提供一個方便使用的格式。
Fiddler 包含一個簡單卻功能強大的基於JScript .NET 事件指令碼子系統,他非常靈活性非常棒,可以支援眾多的http調試任務。Fiddler 是用C#寫出來的。
接下來是一大段廢話,關於如何安裝的,只要一路next,就可以了。這段話我就跳過,直接切入正題了。
Running Fiddler
當你啟動了Fiddler,程式將會把自己作為一個微軟互連網服務的系統代理程式中去。你可以通過檢查代理設定對話方塊來驗證Fiddler是被正確地截取了web請求。操作是這樣的:點擊IE設定,工具,區域網路設定,最後點擊進階。
作為系統代理程式,所有的來自微軟互連網服務(WinInet)的http請求再到達目標Web伺服器的之前都會經過Fiddle,同樣的,所有的Http響應都會在返回用戶端之前流經Fiddler。這樣,就能明白Fiddler很多作用了吧!
當你關閉Fiddler的時候,它就會自動從系統註冊表中移出,換句話說,當你關閉了Fiddler後,不會佔著茅坑不拉屎。
下面,是一個Fillder的使用者介面,大家可以參考參考其功能。
用Fiddler來做效能測試 HTTP統計視圖通 過顯示所有的Http通訊,Fiddler可以輕鬆的示範哪些用來產生一個頁面,通過統計頁 面(就是Fiddler左邊的那個大框)使用者可以很輕鬆的使用多選,來得到一個WEB頁面的“總重量”(分頁檔以及相關js,css等)你也可以很輕鬆 得看到你請求的某個頁面,總共請求了多少次,以及多少位元組被轉化了。
另外,通過暴露HTTP頭,使用者可以看見哪些頁面被允許在用戶端或者是代理端進行緩衝。如果要是一個響應沒有包含Cache-Control 頭,那麼他就不會被緩衝在用戶端。
用Fiddler來調試
Fiddler支援斷點調試概念,當你在軟體的菜單—rules—automatic breakpoints選項選擇beforerequest,或者當這些請求或響應屬效能夠跟目標的標準相匹配,Fiddler就能夠暫停Http通訊, 情切允許修改請求和響應。這種功能對於安全性測試是非常有用的,當然也可以用來做一般的功能測試,因為所有的代碼路徑都可以用來演習。
Session檢查用 戶可以在BuilderPage項種來以手工的方式來建立一個HTTP請求(即在 Fiddler右側的tab的第三個,RequestBUILDER),或者可以使用拖拽操作從Session列表中來移動一個已經存在的請求到 builder page 來再次執行這個請求。。。
Fiddler 擴充Fiddler可以使用 .net framework來對它進行擴充。有2種為Fiddler擴充準備的基本機制:
自訂規則,和規則檢查。
使用指令碼化的規則來擴充Fiddler
Fiddler支援JScript .NET引擎,它可以允許使用者自動地修改Http請求和響應。這個引擎能夠在可視化介面修改在FiddlerUI中的Session,可以從列表中提取你感興趣的錯誤,也可以移除你不感興趣的Session。
以下的範例程式碼示範當cookie被載入的時候把介面變成紫色。
static function OnBeforeRequest(oSession:Fiddler.Session){ if (oSession.oRequest.headers.Exists("Cookie")){ oSession["ui-color"] = "purple"; oSession["ui-bold"] = "cookie"; }}
通過加入Inspectors來擴充Fiddler使用者可以加入一個Inspector外掛程式對象,來使用.net下的任何語言來編寫Fiddler擴充。RequestInspectors 和 ResponseInspectors提供一個格式規範的,或者是被指定的(使用者自訂)Http請求和響應視圖。
預設安裝中,Fiddler加入了一下的Inspectors:
Request Inspectors
[RW] Headers—Shows request headers and status.
[RW] TextView—Shows the request body in a text box. (原始的請求body視圖)
[RW] HexView—Shows the request body in a hexadecimal view. (body的16進位視圖)
[RO] XML—Shows the request body as an XML DOM in a tree view.(以XML方式展示請求)
Response Inspectors
[RW] Transformer—Removes GZip, DEFLATE, and CHUNKED encodings for easier debugging.
[RW] Headers—Shows response headers and status.
[RW] TextView—Shows the response body in a text box.
[RW] HexView—Shows the response body in a hexadecimal view. (16進位視圖)
[RO] ImageView—Shows the response body as an Image. Supports all .NET image formats.
[RO] XML—Shows the response body as an XML DOM in a tree view.
[RO] Privacy—Explains the P3P statement in the response headers, if present.(如果在回應標頭中有關於隱私權原則的說明就展示出來)
學習如何通過Fiddler建立一個速度更快的網站。在這篇文章中,我們將使用Fiddler去探究HTTP的效能,緩衝,以及壓縮。
如果你要是沒有安裝和配置過Fiddler, 請從文章的第一篇開始。
HTTP效能總覽毫 無疑問使用者都喜歡訪問速度快的網站。使用者是非常的不耐煩,除非你的網站是沒有競爭者,換句 話就是處於壟斷地位的。如果你的訪問者來自世界各地,那你就必須要保證你的網站在執行效率方面要非常好,甚至要更加標準。作為一個國際化的網路連接點,通 常要受到來自兩個方面的壓力:高訪問量以及低頻寬。
在第一次至關重要的訪問中,使用者必須要下載每一個內容片斷,來產生頁面,包括JS,CSS,Images,HTML,如果你的頁面太難載入(包括IIS接到請求執行並返回給用戶端HTML),訪問者也許就會離開你的頁面!
通過暴露所有的HTTP通訊,Fiddler很容易得向你展示哪些檔案經常被用於產生一個頁面,
Shift+click 可以在Fiddler左邊框的會話列表中多選會話,來計算那些被選會話的“頁面總重量”。那些被轉換成位元組的數量。
如果你想讓你的客戶在第一次訪問的時候就留下深刻的印象 ,那麼最好的,也是唯一的途徑就是返回給客戶更少的檔案。
1 使用更少的圖畫
2 將所有的CSS濃縮到一個CSS檔案中
3 將所有的指令碼濃縮到一個JS檔案中
4 簡化你的頁面時間
5 使用HTTP壓縮
如果要是你已經對使用者的第一次來訪的效能進行了最佳化,那麼你可以通過Http 緩衝的優勢來使得你的網站訪問速度更快!
HTTP 緩衝介紹
2種方式來提升你的web 應用程式的速度:
減少請求和響應的往返次數
減少請求和響應的往返位元組大小。
HTTP 緩衝是最好的減少用戶端伺服器端往返次數的辦法。緩衝提供了提供一種機制來保證用戶端 或者代理能夠儲存一些東西,而這些東西將會在稍後的HTTP 響應中用到的。(即第一次請求了,到了用戶端,緩衝起來,下次如果頁面還要這個JS檔案或者CSS檔案啥的,就不要到伺服器端去取下來了,但是還是要去服 務器上去訪問一次,因為請求要對比ETAG值,關於這個值,我將會在下次翻譯中介紹其作用)這樣,就不用讓檔案再次跨越整個網路了。
緩衝相關的要求標頭
為了提高效能,微軟的IE和其他的web用戶端總是想盡辦法來維持從遠程伺服器上下載下來的本地的緩衝。
當用戶端需要一個資源(html,css.js…),他們有3種可能的動作:
1 發送一個一般的HTTP請求到遠程伺服器端,請求這個資源。
2 發送一個有條件的HTTP請求到伺服器,條件就是如果它不同於本地的緩衝版本。
3 如果緩衝的拷貝可用,就使用本地的緩衝資源。
當發送一個請求,客戶也許會使用如下的幾個HEADER
Table 1. Client Cache Headers
Pragma: no-cache
The client is unwilling to accept any cached responses from caches along the route and the origin server must be contacted for a fresh copy of the resource.
If-Modified-Since: datetime
The server should return the requested resource only if the resource has been modified since the date-time provided by the client.
If-None-Match: etagvalue
The server should return the requested resource if the ETAG of the resource is different than the value provided by the client. An ETAG is a unique identifier representing a particular version of a file.
1 Pragma:no-cache 表明用戶端不願意接受緩衝請求,它需要的是最即時的資源。
2 If-Modified-Since: datetime 表明如果這個資源自從上次被用戶端請求,就已經修改了,那麼伺服器就會返回給用戶端最新的。
3 If-None-Match: etagvalue 如果用戶端資源的ETAG值跟伺服器端不一致了,那麼伺服器端返回最新的資源。ETAG就是一個唯一的ID,用來表示一個檔案的一個特定的版本。
如 果要是這些有條件的請求,也就是含有If-Modified-Since 或者 If-None-MatchHeader頭的請求,伺服器將會以HTTP/304 Not Modified 來作為響應,那麼用戶端就知道可以使用用戶端的緩衝了。否則,伺服器將會返回一個新的響應並且用戶端就會拋棄到期的緩衝資源。
你 可以觀察2個連貫的請求,來請求同一個圖片,你會在Fiddler中發現:在第一個本機快取 版本中,伺服器返回一個含有ETAG的檔案,和一個含有最後修改日期的檔案,在這個第一次的請求會話中,一個本地的緩衝版本已經可以使用了。這樣一來,一 個有條件的請求就被建立出來。然後你再次請求這個圖片的時候,他就就會響應一個本機快取的檔案,當然前提是第一次緩衝的圖片的ETAG值或者If- Modified-Since 值跟伺服器上匹配的話,伺服器就響應一個304給用戶端。
Session #1
GET /images/banner.jpg HTTP/1.1
Host: www.bayden.com
HTTP/1.1 200 OK
Date: Tue, 08 Mar 2006 00:32:46 GMT
Content-Length: 6171
Content-Type: image/jpeg
ETag: "40c7f76e8d30c31:2fe20"
Last-Modified: Thu, 12 Jun 2003 02:50:50 GMT
Session #2
GET /images/banner.jpg HTTP/1.1
If-Modified-Since: Thu, 12 Jun 2003 02:50:50 GMT
If-None-Match: "40c7f76e8d30c31:2fe20"
Host: www.bayden.com
HTTP/1.1 304 Not Modified
因為一個HTTP304響應僅僅包含頭,沒有body,所有它在穿越互連網的時候要比攜帶了資源的快很多,儘管如此,HTTP/304響應需要一個伺服器的往返,但是通過細心的設定回應標頭,web程式員可以消除這種因素,甚至是有條件的請求。
緩衝相關回應標頭
通常緩衝機制是由回應標頭來控制的。HTTP規範描述了Header控制緩衝,The optional Cache-Control,Expires(到期)。
Expires頭包含一個絕對的日期,當超過此日期,它將不會被考慮更新了。
Table 2. Common Cache-Control Headers
Value
Meaning
public
The response may be stored in any cache, including caches shared among many users.
private
The response may only be stored in a private cache used by a single user.
no-cache
The response should not be reused to satisfy future requests.
no-store
The response should not be reused to satisfy future requests, and should not be written to disk. This is primarily used as a security measure for sensitive responses.
max-age=#seconds
The response may be reused to satisfy future requests within a certain number of seconds.
must-revalidate
The response may be reused to satisfy future requests, but the origin server should first be contacted to verify that the response is still fresh.
Cache-Control頭的參數設定:
Public 響應會被緩衝,並且在多使用者間共用。
Private 響應只能夠作為私人的緩衝,不能再使用者間共用。
No-cache 響應不會被緩衝
No-store 響應不會被緩衝,並且不會被寫入到用戶端的磁碟裡,這也是基於安全考慮的某些敏感的響應才會使用這個。
Max-age=#seconds 響應將會某個指定的秒數內緩衝,一旦時間過了,就不會被緩衝。
Must-revalidate 響應會被重用來滿足接下來的請求,但是它必須到伺服器端去驗證它是不是仍然是最新的。
注意:
如果你要想在iis中配置緩衝,請參閱溫軟的知識技術文章:
你可以學習