Fiddler – Analyze HTTP Traffic

Posted: January 4, 2011 in Performance, Web Development
Tags: ,
0
  1. Fiddler is an HTTP debugging proxy which logs all HTTP traffic between your computer and the Internet. It enables us to inspect all HTTP traffic, set breakpoints, and “fiddle” with incoming or outgoing data. Using fiddler we can check reason for performance bottleneck of a web page, which cookies are being sent to server or what downloaded content is marked as cacheable … etc
  2. NetMon, Fiddler, YSlow, net tab in IE 9, net tab in firebug add-on of firefox browser… etc are same category of tools used for network debugging.
  3. Fiddler requireds MS W2k and above, .NET Framework 1.1 or above
  4. When you start Fiddler, the program registers itself as the system proxy for Microsoft Windows Internet Services (WinInet), the HTTP layer used by Internet Explorer, Microsoft Office, and many other products.
  5. When you close Fiddler, it unregisters itself as the system proxy before shutting down.
  6. Most used tabs in fiddler
    • Statistics – statistics about selected session
    • Filters – Filter out the http traffic logging
    • Inspectors (Debugging) – view/modify request/responses for security testing or general functionality testing
    • Request Builder – create/build http request using existing previous requests
    • Timeline – Time map of all requests of a page (Buffering Mode – buffers response to give to user for edit, Streaming Mode – can’t debug used during performance testing)
    • Auto Responder – replay previously captured or generated traffic when network connectin is down during demo .. etc (also useful to change response in place of actual response) or want to see prior version of our site
  7. Best Practices
    • Use FiddlerCap (available in few other localized versions) – to take a snapshot of (end user/Client’s) Web Traffic, and send that snapshot to a debugging buddy who can troubleshoot the bug. – http://www.fiddlercap.com/FiddlerCap/
    • Use Net tab in IE9 Developer Tool, import option
    • Filter traffic – images, https connects,app type/process filter using – QuickExec/Find
    • Use export (SAZ – session archive zip format) facility for future use when demoing without internet connection
    • Use Viewer mode
  8. Advanced usage
    • Scripting – thru Custom Rules, Inspectors – modify request/response, break on requests remove caching headers … etc
    • Extensibility – (Ex: Watcher – security auditor & neXpert – following performance bestpractices or not) extend the fiddler using any .net lang
    • FiddlerCore – core proxy engine of fiddler inside .net application to integrate it have our own small simple screen for specific purpose 
  9. HTTP Status codes on Filters Tab
    • Hide success status codes
      • 200 – The request has succeeded
      • 204 – The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation
      • 206 – The server has fulfilled the partial GET request for the resource and response MUST include the header fields like Content-Range header field, Date, ETag (version of a file, ETAG of the resource is different than the value provided by the client.)/Content Location, Expires/cache-Control/Vary
    • Hide redirects status codes
      • 300 –
      • 301 – Moved Permanently
      • 302 – Found, The requested resource resides temporarily under a different URI
      • 303 – The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource
      • 307 – The requested resource resides temporarily under a different URI
        Hide not modified
      • 304 – If the client has performed a conditional GET request (If-Modified-Since, If-None-Match) and access is allowed, but the document has not been modified, the server SHOULD respond with this status code
    • Hide Authentication Demand
      • 401 – The request requires user authentication
  10. Two key factors in improving the speed of your Web applications
    • Reducing the number of request/response roundtrips
    • Reducing the number of bytes transferred between the server and the client
  11. HTTP caching is of the best ways to reduce roundtrips and bytes transferred. To enhance performance, Microsoft Internet Explorer and other Web clients maintain a local cache of resources downloaded from remote Web servers. When a resource is needed by the client, there are three possible actions
    • Send a plain HTTP request to the remote Web server asking for a resource
    • Send a conditional HTTP request to the origin server asking for the resource only if it differs from the locally cached version
    • Use a locally cached version of the resource, if a cached copy is available
  12. Control request/response cache headers for better performance
    • Cache-Related Request Headers – Pragma: no-cache, If-Modified-Since: datetime, If-None-Match: etagvalue
    • Cache-Related Response Headers – Generally, the cacheability of an HTTP response is controlled by headers sent in the response. The optional Cache-Control  and Expires headers are the primary mechanisms for a Web server to indicate to a proxy or a client how content may be cached. Expires header contains date or 0 or -1. Cache-Control Header contains public, private, no-cache, no-store, max-age:#seconds, must-revalidate
  13. HTTP Compression – All popular Web servers and browsers offer support for HTTP Compression. HTTP Compression can dramatically decrease the number of bytes that are transmitted between the server and the client; savings of over 50 percent for HTML, XML, CSS, and JS are common.

References – 

Older posts but useful for beginners –

Leave a comment