LANGUAGES: HTML | JavaScript
Fiddler
This
Free Microsoft Tool Can Help You Analyze Your Web Site’s Network Traffic
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 has a surprising
variety of useful tools and resources listed. Here are just a few:
The Fiddler Web site also lists some links to external Web sites that provide
useful Fiddler information:
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 and start fiddling around.
The original version of this article was published in
the August 2007 issue of
ASP.NET Pro Magazine.