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:
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 (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:Steve@Orr.net.