Two ways to speed up your web application:
1. Reduce the number of round trips for requests and responses
2. Reduce the round-trip bytes of requests and responses
HTTP cache is the best way to reduce the number of round-trips on the client server. Cache provides a mechanism to ensure that the client or proxy can store some things, which will be used in later HTTP responses. (That is, the first request is sent to the client and cached. If you want to retrieve the JS file or CSS file from the server next time, but I still need to go to the server to access it once, because the request needs to compare the etag value. I will introduce the value in the next translation, you don't need to let the file span the entire network again.
Cache-related request headers
To improve performance, Microsoft's IE and other web clients always try their best to maintain the local cache downloaded from the remote server.
When the client needs a resource (HTML, CSS. js ...), They have three possible actions:
1. Send a general HTTP request to the remote server to request this resource.
2. Send a conditional HTTP request to the server, if it is different from the local Cache version.
3. If the cached copy is available, local cache resources are used.
When sending a request, the customer may use the following headers:
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 be contacted for a fresh copy of the resource.
If-modified-since: datetime | the server shocould 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 shocould return the requested resource if the etag of the resource is different than the value provided by the client. an etag is a unique identifier representing a particle version of a file.
1 Pragma: No-Cache indicates that the client is unwilling to accept cache requests. What it needs is the most immediate resource.
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 the latest one to the client.
3 if-None-Match: etagvalue if the etag value of the client resource is inconsistent with that of the server, the server returns the latest resource. Etag is a unique ID used to indicate a specific version of a file.
If these conditional requests, that is, requests containing the IF-modified-since or if-None-matchheader, the server will respond with HTTP/304 not modified, then the client will know that the client cache can be used. Otherwise, the server returns a new response and the client discards the expired cache resources.
You can observe two consistent requests to request the same image. You will find in Fiddler that in the first local Cache version, the server returns a file containing etag, and a file containing the last modification date. In this first request session, a local Cache version is ready for use. In this way, a conditional request is created. When you request this image again, it will respond to a locally cached file, of course, the premise is that the etag value or if-modified-since value of the image cached for the first time matches with that on the server, and the server returns a 304 request to the client.
HTTP/1.1 200 OK
Date: Tue, 08 mar 2006 00:32:46 GMT
Etag: "40c7f76e8d30c31: 2fe20"
Last-modified: Thu, 12 Jun 2003 02:50:50 GMT
If-modified-since: Thu, 12 Jun 2003 02:50:50 GMT
If-None-Match: "40c7f76e8d30c31: 2fe20"
HTTP/1.1 304 not modified
Because an HTTP 304 response only contains a header and has no body, it is much faster than carrying resources when traversing the Internet. However, HTTP/response requires a server round-trip, however, by carefully setting the response header, web programmers can eliminate this factor, or even conditional requests.
Cache Response Headers
The cache mechanism is usually controlled by the response header. The HTTP specification describes the header control cache, the optional cache-control, and expires (expired ).
The Expires header contains an absolute date. When this date is exceeded, it will not be considered to be updated.
Table 2. Common cache-Control headers
Public: The response may be stored in any cache, including caches shared among stored users.
PRIVATE: The response may only be stored in a private cache used by a single user.
No-Cache: The response shocould not be reused to satisfy future requests.
No-store: The response shocould not be reused to satisfy future requests, and shocould not be written to disk. This is primarily used as a security measure for sensitive responses.
Max-age = # seconds: The response may be reused to satisfy future requests within a certain number of seconds.
Must-revalidate: The response may be reused to satisfy future requests, but the origin server shoshould first be contacted to verify that the response is still fresh.
Parameter settings of the cache-control header:
The public response is cached and shared among multiple users.
Private responses can only be used as private caches and cannot be shared between users.
No-Cache response will not be cached
No-store response will not be cached and will not be written to the client disk. This is also used for some sensitive responses based on security considerations.
Max-age = # The seconds response will be cached within a specified number of seconds. Once the time passes, the response will not be cached.
The must-revalidate response will be reused to meet the next request, but it must go to the server side to verify whether it is still up-to-date.
If you find that you often update files on your website, but do not change the file name, you must be very careful to set your cache survival time. For example, if you want a thisyear.gif image file to display the current year on the website, you must ensure that the cache expiration time cannot exceed one day. Otherwise, when a user visits your website on January 1, December 31, the correct date cannot be displayed on January 1, January 1.
For some reason, the server may set: progma: No-Cache header, cache-control: No-Cache
Header parameter: vary is a cache signal. vary: User-Agent indicates that the current response is cached, but only when the same User-Agent header is sent. Command vary: * is equivalent to cache-control: No-cache.
Vary is equivalent to the cache parameter in Asp.net, which means caching based on what it means. If you know how to use the cache in Asp.net, it is easy to understand the meaning of this parameter.
If the response does not contain expires or cache-control, the client is forced to act as 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 the cache service. Wininet allows you to configure the cache size and behavior, and set the cache to perform the following operations:
1 open IE,
2. Select "Internet" as the tool option. In the general sub-options, click "set" in the Temporary Folder.
Currently, popular web servers and browsers support HTTP compression. HTTP compression can significantly reduce the communication between the client and the server. Save more than 50% of HTML, XML, CSS, JS and other files.
A browser sends a signal to the server. It can introduce HTTP Compressed Content and put the compression types supported by the client in the request header,
For example, consider the following request:
Get, HTTP, 1.1
Accept-encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; sv1;. Net CLR 1.1.4322)
This accept-encoding header indicates that IE will be willing to accept compressed responses in gzip and deflate formats.
The response is as follows:
HTTP/1.1 200 OK
Content-Type: text/html; charset = UTF-8
Server: Microsoft-IIS/6.0 -- Microsoft-httpapi/1.0x-powered-by: ASP. NET
Content-encoding: gzipdate: Tue, 15 Feb 2006 09:14:36 GMT
Cache-control: private, Max-age = 3600
Experiments show that HTTP compression can greatly reduce data round-trips, and a common CSS file can even be reduced by 80%! Of course, compression is at the cost of CPU performance. Especially for compressing dynamic files, but the general right is to compress static files such as JS and CSS, because they will be stored on the server after the first compression, to Compress Asp.net dynamic files, you must make a trade-off.