Fiddler can help you record, debug Microsoft Internet Explorer interactions with Web applications, find bottlenecks in the performance of Web programs, and look at the content of sending cookies to a Web server and the size of the content you download.
To say more, fiddler stands in the middle of a user and Web server, forwarding requests and responses, so fiddler as an viewable, customizable tool that allows you to understand the details of interactive processes and help resolve Web program interaction issues. such as the following schematic diagram:
Internet Explorer <-> WinINET? (Automatically registered by Fiddler Runtime) <-> Fiddler <-> Web Server
Fiddler can be used to:
Performance testing. such as viewing the size of a page
Debugging. In session options, you can pause and edit HTTP traffic
Fiddler is available not only for Microsoft Internet Explorer, but also for other browsers, such as Mozilla Firefox,opera. The software interface is friendly, proficient in HTTP, and may be more usable than Netmon. NET to expand. The official site, there are video teaching.
This tool I have been used for a long time, and for my help is also very large, today I translated the Microsoft article, so that more friends to understand this good tool, but also my first translation of articles, inappropriate place please everyone to correct.
Introduced:
Have you ever wondered how your Web app and IE interact with each other? Have you encountered some strange performance bottlenecks that you can't solve? Are you curious about the cookies that are sent to the server and those that you have downloaded that are marked as cacheable?
Fiddler official website and download address: http://www.fiddlertool.com/Fiddler/dev/
Microsoft's Fiddler can help you answer the above questions, not only that, it is an HTTP debugging agent, it can record all the HTTP communication between your computer and the Internet, Fiddler can also let you check all HTTP traffic, set breakpoints, and fiddle all the " In and Out "data (refers to cookie,html,js,css and other documents, which can make you arbitrarily modify the meaning). Fiddler is simpler than other network debuggers because it exposes only HTTP traffic and provides a user-friendly format.
Fiddler contains a simple yet powerful, JScript. NET Event Script subsystem, and he is very flexible and can support numerous HTTP debugging tasks. Fiddler is written in C #.
。。。。。 Next is a big piece of crap about how to install, just go all the way to next. I'll skip the passage and cut to the chase.
Running Fiddler
When you start Fiddler, the program will take you as a System agent for Microsoft Internet Service. You can verify that the fiddler is properly intercepting the Web request by checking the Proxy Settings dialog box. The operation is this: Click IE settings, tools, LAN settings, and finally click Advanced.
As a System agent, all HTTP requests from Microsoft Internet Service (WinInet) will go through fiddle before reaching the target Web server, and all HTTP responses will flow through fiddler before returning to the client. In this way, you can understand fiddler a lot of role.
When you close the fiddler, it is automatically removed from the system registry, in other words, when you shut down the fiddler, you don't take a dump in the manger.
Below, is a Fillder user interface, you can refer to its function.
Use Fiddler to do performance test HTTP statistics view by displaying all HTTP traffic, Fiddler can easily demonstrate which pages are used to generate a page, through the statistics page (that is, the big box on the left of fiddler) users can easily use multiple selections to get a Web page of " Total weight "(paging file and related JS,CSS etc.) you can also easily see a page of your request, how many times it has been requested, and how many bytes have been converted.
In addition, by exposing the HTTP headers, users can see which pages are allowed to be cached on the client or proxy side. If a response does not contain a Cache-control header, then he is not cached on the client.
Use Fiddler to debug
Fiddler supports breakpoint debugging concepts when you select Beforerequest in the menu-rules-automatic breakpoints option of the software, or when these request or response attributes can match the target's criteria, Fiddler is able to suspend HTTP traffic, allowing for modification of requests and responses. This functionality is useful for security testing and, of course, can be used for general functional testing because all code paths can be used to drill.
Session checking the user can create an HTTP request in the Builderpage item by hand (that is, the third, requestbuilder, tab on the right of fiddler), Alternatively, you can use a drag-and-drop operation to move an existing request from the session list to builder page to execute the request again ...
The Fiddler extension Fiddler can be extended using the. NET Framework. There are 2 basic mechanisms for fiddler extension preparation:
Custom rules, and rule checking.
Using scripted rules to extend fiddler
Fiddler supports JScript. NET engine, which enables users to automatically modify HTTP requests and responses. The engine is able to modify the session in the Fiddlerui in the visual interface to extract from the list the errors you are interested in, or to remove the session that you are not interested in.
The following sample code shows that the interface becomes purple when the cookie is loaded.
static function Onbeforerequest (oSession:Fiddler.Session) {if (OSession.oRequest.headers.Exists ("Cookie")) { osession["Ui-color"] = "purple"; osession["Ui-bold"] = "Cookie"; }}
By adding inspectors to extend fiddler users can join a Inspector plug-in object to write fiddler extensions using any language in. Net. Requestinspectors and Responseinspectors provide a format specification, or a specified (user-defined) HTTP request and Response view.
In the default installation, Fiddler added the Inspectors:
Request inspectors
[RW] Headers-shows request Headers and status.
[RW] Textview-shows the request body in a text box. (Original request body view)
[RW] Hexview-shows the request body in a hexadecimal view. (Body's 16-in view)
[RO] Xml-shows the request body as an XML DOM in a tree view. (Presentation of requests in 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 in view)
[RO] Imageview-shows the response body as a 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. (If you have a description of the privacy policy in the response header, show it)
Learn how to build a faster web site through fiddler. In this article, we'll use Fiddler to explore HTTP performance, caching, and compression.
If you have not installed and configured Fiddler, please start with the first article.
HTTP Performance Overview There is no doubt that users like to visit fast Web sites. The user is very impatient, unless your site is not a competitor, in other words is in a monopolistic position. If your visitors are from all over the world, you have to make sure that your site is very efficient and even more standard in its execution. As an internationalized network connection point, it is usually subject to pressure from two aspects: high traffic and low bandwidth.
In the first critical visit, users must download every piece of content to generate pages, including js,css,images,html, if your page is too difficult to load (including IIS receiving requests to execute and return to the client HTML), the visitor may leave your page.
By exposing all HTTP traffic, it's easy for Fiddler to show you which files are often used to generate a page,
Shift+click can calculate the total page weight of those selected sessions by selecting more than one session in the conversation list in the Fiddler left border. The number of those that are converted into bytes.
If you want your client to be impressed on the first visit, the best and only way to get back to the client is to return fewer files.
1 Use fewer pictures
2 condense all the CSS into a CSS file
3 condensed all the scripts into a JS file
4 Simplify your Page time
5 Using HTTP Compression
If you've optimized the performance of your first visit, you can use the advantages of HTTP caching to make your site visit faster.
Introduction to HTTP Caching
2 ways to increase the speed of your Web application:
Reduce the number of round-trip requests and responses
Reduce the round-trip byte size of requests and responses.
HTTP caching is the best way to reduce the number of round-trip trips to the client server. Caching provides a mechanism to ensure that a client or agent can store something that will be used in a later HTTP response. (That is, the first request, to the client, cached, the next time if the page also want this JS file or CSS file, do not go to the server to take down, but still want to go to the server to visit once, because the request to compare ETag value, about this value, I will be in the next translation to introduce its role) so , you don't have to let the file cross the entire network again.
Cache-Related Request headers
To improve performance, Microsoft's IE and other Web clients always try to maintain a local cache that is downloaded from the remote server.
When the client needs a resource (html,css.js ...). ), they have 3 possible actions:
1 sends a general HTTP request to the remote server side, requesting this resource.
2 sends a conditional HTTP request to the server, provided that it is different from the local cached version.
3 If the cached copy is available, the local cache resource is used.
When a request is sent, the customer may use several headers as follows
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 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 was different than the value provided by the CL Ient. A ETAG is a unique identifier representing a particular version of a file. |
1 Pragma:no-cache indicates that the client is unwilling to accept a cache request, and it needs the most immediate resources.
2 If-modified-since:datetime indicates that if the resource has been modified since it was last requested by the client, the server will return to the client for the latest.
3 If-none-match:etagvalue If the ETag value of the client resource is inconsistent with the server side, then the server side returns the most recent resource. ETag is a unique ID used to represent a specific version of a file.
If these conditional requests, that is, the request containing the if-modified-since or If-none-matchheader headers, the server will respond with a http/304 not Modified. Then the client knows that it can use the client's cache. Otherwise, the server will return a new response and the client discards the expired cache resource.
You can observe 2 consecutive requests, to request the same picture, you will find in Fiddler: In the first local cache version, the server returns a file containing ETag, and a file containing the last modified date, in this first request session, a local cached version already available. As a result, a conditional request is created. Then you request the picture again, he will respond to a locally cached file, of course, if the first cached picture of the ETag value or If-modified-since value to match the server, the server responds to a 304 to the client.
Session #1
Get/images/banner.jpg http/1.1
Host:www.bayden.com
http/1.1 OK
Date:tue, Mar 2006 00:32:46 GMT
content-length:6171
Content-type:image/jpeg
ETag: "40c7f76e8d30c31:2fe20"
Last-modified:thu, June 2003 02:50:50 GMT
Session #2
Get/images/banner.jpg http/1.1
If-modified-since:thu, June 2003 02:50:50 GMT
If-none-match: "40c7f76e8d30c31:2fe20"
Host:www.bayden.com
http/1.1 304 Not Modified
Because a HTTP304 response consists of only a head, no body, and all of it travels faster than the resources it carries when it crosses the Internet, the http/304 response requires a round-trip of the server, but the Web programmer can eliminate this by carefully setting the response header, Even a conditional request.
Cache-Related Response headers
Usually the caching mechanism is controlled by the response header. The HTTP specification describes the header control cache, the optional cache-control,expires (expired).
The Expires header contains an absolute date, and when this date is exceeded, it will not be considered for updating.
Table 2. Common Cache-control Headers
Value |
Meaning |
Public |
The response may is stored in any cache, including caches shared among many users. |
Private |
The response may is stored in a private cache used by a single user. |
No-cache |
The response should is reused to satisfy future requests. |
No-store |
The response should not is reused to satisfy future requests, and should to disk. This is primarily used as a security measure for sensitive responses. |
Max-age= #seconds |
The response may is reused to satisfy future requests within a certain number of seconds. |
Must-revalidate |
The response may is reused to satisfy future requests, but the origin server should the I-contacted to verify Response is still fresh. |
Parameter settings for Cache-control headers:
The public response is cached and shared among multiple users.
Private responses can only be used as a private cache and cannot be shared among users.
No-cache responses are not cached
No-store responses are not cached and are not written to the client's disk, which is also a sensitive response based on security considerations that is used.
Max-age= #seconds response will be cached for a specified number of seconds, and will not be cached once time has passed.
The must-revalidate response is reused to satisfy the next request, but it must go to the server side to verify that it is still up to date.
Attention:
If you want to configure caching in IIS, refer to the soft technical article:
· How to Modify the Cache-control HTTP Header if you use IIS. You can learn more about the use of caching in asp.net articles:
· How to Cache in asp.net by Using Visual C #. NET. If you find that you often update files on your site, but do not change the file name, then you have to be very careful about setting your cache lifetime. For example: If you want a thisyear.gif picture file to display the current year on the site, you need to make sure that the cache expires in no more than one day, otherwise a user will not be able to display the correct date on January 1 when they visit your site on December 31.
For some reason, the server may be set: Progma:no-cache headers, Cache-control:no-cache
Parameters in header: Vary is a cache signal, vary:user-agent indicates that the current response is cached, but only when sending the same user-agent header. Instruction vary:* is equivalent to Cache-control:no-cache.
Vary is equivalent to the cached parameter in asp.net, which means caching according to what, if you know how the asp.net cache is used, it is easy to understand the meaning of this parameter.
Using the HTTP session list, Fiddler users can see the HTTP cache headers included in the page.
Fiddler session list If the response does not contain expires or Cache-control, the client is forced to make a conditional request to ensure that all resources are up to date.
Conditional requests and Wininetcache
IE uses Microsoft Windows Internet Services to maximize the use of caching services. WinInet allows the user to configure the size and behavior of the cache, and set the cache to do the following:
1 Open IE,
2 tool options, select the Inrernet option, in the General sub option, in the temporary folder, click Set
The following figure is the four kinds of settings for the village selection:
Tag Performance issues:
You can use fiddler custom rules to mark something you need, such as if a response is greater than 25KB, you can mark the current session as red and be more visible. The following code is in the Onbeforeresponse event:
Flag files over 25KB if (OSession.responseBodyBytes.length > 25000) {osession["ui-color"] = "red"; osession["Ui-bold" "] =" true "; osession["Ui-customcolumn"] = "Large file"; Similarly, you can also mark the response without indicating the cached information. Mark files which do not have caching informationif (!osession.oresponse.headers.exists ("Expires") &&!osession . OResponse.headers.Exists ("Cache-control")) {osess
