Browser cache type

Browser cache

To cache this stuff, you must get the resource for the first time, and then tell how to cache the resource according to the returned information. It may use a strong cache, or it may tell the client browser to negotiate the cache, which needs to be based on the header content of the response. To decide.

When the browser first requests:

When the browser subsequently makes a request:

As can be seen from the above figure, browser cache contains two types, namely strong cache (also called local cache) and negotiated cache. When the browser requests again after the first request occurs:

• When the browser requests a resource, it will first obtain the header information of the resource cache, and determine whether it hits a strong cache (cache-control and expires information). If the hit directly obtains the resource information from the cache, including the cache header information; this time The request will not communicate with the server at all; under firebug, you can view the information returned by a resource with a strong cache, such as a strong cache js file viewed by local firebug

• If there is no strong cache hit, the browser will send a request to the server, the request will carry the header field information about the cache returned by the first request (Last-Modified / If-Modified-Since and Etag / If-None-Match), by The server compares whether the result is a cache hit according to the relevant header information in the request; if it hits, the server returns a new response header information to update the corresponding header information in the cache, but does not return the resource content, it will inform the browser that it can directly Get from cache; otherwise, return the latest resource content

The difference between strong caching and negotiated caching can be described by the following table:

 

? Strong cache related header fields

 

Strong caching has been introduced above, to obtain resources directly from the cache without going through the server; there are two header fields related to strong caching:

 

1. expires , which is the specification at http1.0; its value is an absolute time GMT format time string, such as Mon, 10 Jun 2015 21:31:12 GMT, if the time to send the request is before expires, then local The cache is always valid, otherwise it will send a request to the server to obtain resources
2. cache-control: max-age = number , this is the header information that appears in http1.1, mainly uses the max-age value of this field to judge, it is a relative value; the first request time of the resource and Cache -The validity period set by Control calculates a resource expiration time, and then compare this expiration time with the current request time. If the request time is before the expiration time, it can hit the cache, otherwise it will not work; , And the following more commonly used settings:
   
   
no-cache: Do not use local cache. You need to use cache negotiation to confirm with the server whether the returned response has been changed. If there is an ETag in the previous response, the request will be verified with the server. If the resource has not been changed, you can avoid re-downloading.

no-store: directly prohibit the browser from caching data. Every time the user requests the resource, a request will be sent to the server, and the complete resource will be downloaded every time.

public: Can be cached by all users, including intermediate proxy servers such as end users and CDNs.

private: Can only be cached by the end user ’s browser, and is not allowed to be cached by relay caching servers such as CDNs.

 

　　Note: If cache-control and expires exist at the same time, the priority of cache-control is higher than expires

? Negotiation cache header field

 

The negotiation cache is determined by the server to determine whether the cache resources are available, so the client and the server must communicate through a certain identifier to allow the server to determine whether the requested resource can be accessed by the cache. This mainly involves the following two header fields. These two sets of partners appear in pairs, that is, the response header of the first request carries a certain field (Last-Modified or Etag), and subsequent requests will bring the corresponding request field (If-Modified-Since or If-None-Match), if the response header does not have a Last-Modified or Etag field, the request header will not have a corresponding field .

Last-Modified/If-Modified-Since

• Both values ​​are time strings in GMT format, the specific process:
• The browser requests a resource from the server for the first time. When the server returns this resource, it adds the Last-Modified header to the header of the respone. This header indicates the last modification time of this resource on the server.
• When the browser requests this resource from the server again, add the If-Modified-Since header to the request header. The value of this header is the Last-Modified value returned during the previous request.
• When the server receives the resource request again, it judges whether the resource has changed according to the If-Modified-Since transmitted by the browser and the last modification time of the resource on the server. If there is no change, it returns 304 Not Modified, but it will not return the resource content; if If there is a change, the content of the resource will be returned normally. When the server returns a 304 Not Modified response, the Last-Modified header will not be added to the response header, because since the resource has not changed, then the Last-Modified will not change, this is the response header when the server returns 304
• After the browser receives the 304 response, it will load the resource from the cache
• If the negotiation cache does not hit, when the browser loads the resource directly from the server, the Last-Modified Header will be updated when it is reloaded. When the next request is made, If-Modified-Since will enable the Last-Modified value returned last time

Etag/If-None-Match

• These two values ​​are the unique identification string of each resource generated by the server. This value will change as long as the resource changes; the judgment process is similar to Last-Modified / If-Modified-Since , not the same as Last-Modified What's more, when the server returns a 304 Not Modified response, because the ETag has been regenerated, the ETag will also be returned in the response header, even if the ETag has not changed from the previous one.

Last-Modified与Etag

 

You may think that using Last-Modified is enough to let the browser know whether the local cached copy is new enough, why do you need Etag? The emergence of Etag in HTTP1.1 is mainly to solve several problems that are difficult to solve in Last-Modified:

 

• Some files may be changed periodically, but their content does not change (only the modification time is changed). At this time, we do not want the client to think that this file has been modified and re-GET;

• Some files are modified very frequently, for example, within a second or less, (for example, N times modified within 1s), If-Modified-Since can check the granularity is s level, this modification cannot be judged (or Said that the UNIX record MTIME can only be accurate to the second);

• Some servers cannot get the last modification time of the file accurately.

 

At this time, using Etag can control the cache more accurately, because Etag is a unique identifier on the server side of the corresponding resource generated automatically by the server or generated by the developer.

 

Last-Modified and ETag can be used together. The server will first verify the ETag . If they are consistent, they will continue to compare Last-Modified and finally decide whether to return 304 .

Impact of user behavior on cache

 

 

References: https://www.cnblogs.com/mq0036/p/7090635.html