ControlFreak
LANGUAGES: JavaScript | HTML
Fiddler
Free Microsoft Tool Can Help You Analyze Your Web Site s Network Traffic
By Steve C. Orr
It s no secret that Web sites consume network bandwidth. And because network bandwidth is a finite resource, it pays to use it efficiently. There are many techniques Web developers employ for minimizing bandwidth usage: caching, compression, eliminating unnecessary postbacks, etc. But how do you really know how efficient your Web site is with its bandwidth? You could employ every best practice in existence and still end up surprised about your application s bandwidth usage when you use a network analyzer, such as Fiddler, to see what s really going on behind the scenes.
Bandwidth can inadvertently be consumed in a variety of ways, and it can all add up to significant amounts. For example, third-party controls can sometimes use bandwidth in mysterious and unexpected ways. Embedded advertisements and other components can contain logic that make network calls you may not have anticipated. AJAX does wonders for usability, but it too can eat large amounts of bandwidth if not used with care. Caching can be complex to configure; if you re not careful, you could end up with content not being cached as efficiently as you d thought.
Inefficient network usage can cascade into bottlenecks that limit the scalability of a Web site, and it can interfere with other important network activity, as well. And, of course, on one end of that network are one or more Web servers that also have a limited capacity for dealing with incoming requests so such requests should not be tossed around gratuitously.
These are all excellent reasons for analyzing the traffic between your clients and server using a tool such as Fiddler. However, you re not the only one who can analyze details of traffic traveling between a client and server. Hackers love to look for security holes in content traveling across open networks, so you should analyze your traffic to find potential problems before they do.
What Does Fiddler Do?
Fiddler gets installed on a client computer to help analyze exactly which HTTP content is (and isn t) being submitted from that client across the network (see Figure 1). It captures details about every page request, postback, AJAX request, and any other HTTP-related traffic. Using Fiddler you can see every piece of content being requested from the server. It may be intuitive to think of a page request as a single call across the network, but, in reality, it usually consists of many small requests. First, the page s HTML is retrieved from the server, then many individual requests tend to follow for each external piece of content the HTML references, such as images, JavaScript files, CSS files, etc. Each of these items might be cached in various ways, and Fiddler can help identify the details about how each item is (or isn t) cached so you can optimize your application s network requests.
Figure 1: The Fiddler user interface
may not impress your graphic designer friends, but it is highly functional and
provides a plethora of information about every HTTP network request detail.
Fiddler also captures AJAX requests. Because AJAX requests are usually designed to be invisible to the user, without a tool such as Fiddler it can be virtually impossible to detect from the client exactly when these requests are being sent or what data they contain.
Fiddler also times each request and provides analytical features to help scrutinize such details. These features are helpful when it comes time for performance tuning. We ll get into more details about this shortly.
Fiddler can also be used as a handy debugging and security analysis tool. Configurable breakpoints can be set so network requests may be analyzed, and even altered, before being sent across the network. This is useful for trying out various kinds of what-if scenarios, including tests to see how hacker-resistant your site is.
Your First Time Fiddling
The download and installation of Fiddler is routine. Once installed, a toolbar button will be available in Internet Explorer s command bar, as shown in Figure 2. (In some cases you may need to configure your command bar to get it to appear immediately.) It also can be launched from the Start menu, just like any other program.
Figure 2: Fiddler can be launched
with a single click from this toolbar button within Internet Explorer.
When you launch Fiddler, you ll see its powerful (and somewhat unsightly) interface, as shown in Figure 1. It will immediately start logging network traffic. When you navigate to a new page in Internet Explorer (or Firefox), you ll see the Session List in Fiddler start to log related events. The Session List fills the left side of the Fiddler application window by default, although its interface is fairly configurable via the View dropdown menu. There is also a handy Stay on top View menu command that can keep Fiddler visible at all times even while clicking around in the browser.
Clicking on an item in the Session List will display performance statistics for that item, as shown at the right side of Figure 3. You can select multiple items in the Session List to see the aggregated performance statistics for a group of requests, such as all the items associated with a particular page request. The Performance Statistics tab details how many bytes were sent and received and how long it took. Fiddler goes a step further by estimating how long that same request would likely take from other parts of the world and at various connection speeds, such as dial-up modem, DSL, etc. The Show Chart link at the bottom of the window will display an amenable pie chart.
Figure 3: Fiddler provides an array
of useful performance metrics to help identify exactly which content is
consuming the most bandwidth.
When one or more items in the Session List are selected, you ll notice a variety of useful options become available in the context menu (or the Edit dropdown menu) for saving or copying the selected items in various levels of detail. You can even mark interesting items with various colors to make them stand out. To clear the Session List, simply click the Remove | All Sessions context menu item. Alternatively, you can choose to clear only individual items in the list.
Double clicking on an item in the Session List will display the Session Inspector tab (shown at the right side of Figure 1), which displays a lot of information. By clicking through the resulting sub tabs you can peruse a cornucopia of details about the selected request, such as the request header, which often contains valuable and otherwise hard to obtain information (like cookie data and compression settings). You can also see other views of the selected request, such as text, forms, hexadecimal, authorization, raw, and XML. The lower information pane displays similar information, except relating to the server s response rather than the client s request. It also provides such additional views as privacy, caching, and image view (which is relevant only when the selected response contains an image).
Analyze Events
Let s go into a bit more detail about how to analyze the requests captured in the Session List. The Session List contains nine columns of data for every request. These columns can be dragged around into whichever order is most relevant to you. The Host and URL columns contain details about the server, path, and filename of the requested item.
The Result column shows the result code that the server returned for that request. For example, code 200 indicates a normal and successful response, while 404 is an error code indicating the server could not find the requested item. You may want to sort by this column sometimes (by clicking on the column header) so you can more easily isolate problematic content requests.
The Body column contains the number of bytes that were returned for the requested item. This value may be zero if the item was pre-cached by the browser, indicating that the item didn t need to be sent to the client because it was already there.
The Caching column contains details about the type of caching applied to the item, if any. Typically, you ll see expiration dates, max age counters, or no-cache values in this column.
The Content Type column shows what kind of content is associated with this request, such as text/html , image/jpeg , or application/x-javascript . The Protocol column will generally contain HTTP , although Fiddler version 2 (in beta as of this writing) supports HTTPS request analysis, as well.
Super Debugging
At the top right of the Fiddler application you ll see the Request Builder tab. This tab allows you to construct custom-page HTTP requests on the fly, including querystring parameters for get requests and form items for post requests. You can define the entire body of the request any way you d like, just to see how the server responds. Of course, typing the entire body by hand would be rather tedious; luckily, there s a shortcut. You can drag an existing request from the Session List onto the Request Builder tab and use that request as a starting point, modifying it as needed. Alternatively, you can paste in request details from any other source.
Once you ve customized your request the way you want, simply click the Execute! button and the request will be posted to the server and the results will be logged in the Session List (where they can be analyzed just like any other request).
Under the Rules dropdown menu there is an Automatic Breakpoints menu item that allows breakpoints to be set just before requests are sent to the server, or just after the response is received. This gives you an opportunity to analyze network traffic as it is happening. Furthermore, this information is editable (in version 2 of Fiddler), so you can modify a request after it is generated but before it goes to the server. This can be useful for testing security, as well as more general application features.
Fiddling with Fiddler
Clearly, Fiddler was designed with extensibility in mind. For starters, the Customize Rules item under the Rules dropdown menu will open a script that Fiddler uses to manage various business rules. This JavaScript-based file can be modified to extend Fiddler with customized rules and features.
For example, by adding the following code snippet to the OnBeforeRequest event, every request item that has a cookie associated with it will be colored cyan in the Session List:
if (oSession.oRequest.headers.Exists("Cookie")){
oSession["ui-color"] = "cyan";
}
The next example flags all large response items to visually identify potential targets for bandwidth optimization; this code should be added to the OnBeforeResponse event:
if (oSession.responseBodyBytes.length > 30000){
oSession["ui-color"] = "red";
oSession["ui-bold"] = "true";
}
Each response item larger than 30K will display in bold in the Session List and be colored red.
While these scripts are edited in Notepad by default, if you re going to be doing much script editing you might prefer to download the free FiddlerScript Editor as it provides a friendlier and more intuitive interface. You may also want to peruse the script examples listed on the Fiddler Web site.
Other ways to extend Fiddler include adding new menu items (by adding a key to the registry) that launch custom applications, extending Fiddler s pipeline with .NET code (using the IAutoFiddle interface), and adding custom inspectors to supplement the built-in request and response inspectors. All these techniques are covered in detail on the Fiddler Web site.
Online Resources
The Fiddler Web site (http://www.fiddler2.com) has a surprising variety of useful tools and resources listed. Here are just a few:
- Fiddler Demonstration Videos: http://www.fiddlertool.com/fiddler/help/video/default.asp
- FiddlerScript Editor: http://www.fiddlertool.com/fiddler/fse.asp
- FiddlerScript Cookbook (script examples): http://www.fiddlertool.com/fiddler/dev/scriptsamples.asp
- Extending Fiddler with custom code: http://www.fiddlertool.com/fiddler/dev/
- Fiddler FAQ: http://www.fiddler2.com/fiddler2/faq.asp
The Fiddler Web site also lists some links to external Web sites that provide useful Fiddler information:
- Fiddler overview on MSDN: http://msdn.microsoft.com/library/en-us/IETechCol/dnwebgen/IE_Fiddler2.asp
- Fiddler Blog: http://insidehttp.blogspot.com
- Fiddler Forum: http://groups.msn.com/HTTPFiddler/
Conclusion
Fiddler is a valuable software tool that every Web developer should have in their arsenal. I applaud Microsoft for releasing this free and useful tool. Even though Microsoft doesn t officially support Fiddler, it s clear from all the previously mentioned resources that there is a lot of support in the developer community.
Remember that Fiddler is a client-side tool that analyzes network HTTP traffic. Therefore, it will not be able to analyze a Web application when running on that application s Web server (because everything is local in such a case, and there is no HTTP network traffic). This also means that if you re developing and running your Web application locally on your development machine, you won t be able to run Fiddler from that same machine to analyze the application. Of course, Fiddler will work great from any client computer once the target Web application is deployed to a separate network server.
Scalability and bandwidth are important topics in software development today, and every top-tier developer needs to be familiar with the metrics involved. Now that you ve gained some knowledge in this arena, and made yourself a more valuable software developer as a result, I encourage you to keep the momentum going by downloading Fiddler and getting to know it even better. Download Fiddler for free (http://www.fiddler2.com) and start fiddling around.
Steve C. Orr is an ASPInsider, MCSD, Certified ScrumMaster, Microsoft MVP in ASP.NET, and author of the book Beginning ASP.NET 2.0 AJAX by Wrox. He s been developing software solutions for leading companies in the Seattle area for more than a decade. When he s not busy designing software systems or writing about them, he can often be found loitering at local user groups and habitually lurking in the ASP.NET newsgroup. Find out more about him at http://SteveOrr.net or e-mail him at mailto:[email protected].
