Browser's strong cache and negotiation cache

Previously, I could only describe the browser cache in general, and the deep-level principles could not be described; I was finally asked to fall down during the two interviews on the front end. In order to vent my hatred, I consulted some materials and finally got a deeper understanding of it. , Not much nonsense, let’s take a look at those things about browser caching, there is something wrong, please feel free to enlighten me.

 This article mainly explains the caching on the browser side. The role of caching is self-evident, which can greatly improve web page performance and improve user experience.

table of Contents

1. Browser cache

2. Strong cache related header fields

3. Negotiate cache related header fields

4. Last-Modified He Sheng Etag

5. The impact of user behavior on cache

6. How to reload cached resources in strong cache

---

1. Browser cache

To cache this thing, you must obtain the resource for the first time, and then tell how to cache the resource according to the returned information. It may use strong caching, or it may tell the client browser to negotiate caching. This needs to be based on the response header content To decide. The following two pictures are used to describe how the browser's cache is played, so that everyone has a general understanding.

When the browser first requests:

When the browser makes a subsequent request:

 

 As can be seen from the above figure, browser cache includes two types, namely strong cache (also called local cache) and negotiation cache. After the first request occurs, when the browser requests again:

• When the browser requests a resource, it will first obtain the header information of the resource cache, and determine whether it hits the strong cache (cache-control and expires information). If it hits, it will directly obtain the resource information from the cache, including the cache header information; this time The request will not communicate with the server at all; you can view the information returned by a strong cache resource under firebug, such as a strong cache js file viewed by local firebug
  
  
   
• If the strong cache is not hit, the browser will send a request to the server, and the request will carry the header field information (Last-Modified/If-Modified-Since and Etag/If-None-Match) returned by the first request. The server compares the result according to the relevant header information in the request to negotiate a cache hit; if it hits, the server returns 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 the cache; otherwise return the latest resource content

The difference between strong caching and negotiation caching can be described in the following table:

	Access to resources	status code	Send request to server
Strong cache	Fetch from cache	200（from cache）	No, fetch directly from the cache
Negotiation cache	Fetch from cache	304（not modified）	Yes, as the name suggests, tell the server whether the cache is available

 

2. Strong cache related header fields

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

1. expires , this is the norm 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 of sending the request is before expires, then the local The cache is always valid, otherwise it will send a request to the server to get the resource
    
2. Cache-control: max-age=number , this is the header information that appears in http1.1, which is mainly used to judge by the max-age value of this field, which is a relative value; the first request time of the resource and the Cache -The validity period set by Control calculates a resource expiration time, and then compares 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; cache-control except this field , And the following more commonly used settings:
    
   • no-cache: Do not use local cache. Need to use cache negotiation, first confirm with the server whether the returned response has been changed. If there is an ETag in the previous response, it will be verified with the server when requesting it. If the resource has not been changed, re-downloading can be avoided.
      
   • no-store: Directly prohibit the browser from caching data. Every time a 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 end users and intermediate proxy servers such as CDN.
      
   • private: It can only be cached by the browser of the end user, and it cannot be cached by relay cache servers such as CDN.

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

3. Negotiate cache related header fields

In negotiation caching, the server determines whether the cache resource is available, so the client and the server must communicate through some kind of identification, so that the server can determine whether the requested resource can be cached and accessed. This mainly involves the following two sets of header fields. These two sets of partners appear in pairs, that is, the response header of the first request carries a field (Last-Modified or Etag), and subsequent requests will carry 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 .

1. 
   The values ​​of Last-Modified/If-Modified-Since are both time strings in GMT format. The specific process:
   • • The browser requests a resource from the server for the first time. When the server returns the resource, it adds a Last-Modified header to the header of the response. This header represents the last modification time of the resource on the server.
        
     • When the browser requests this resource from the server again, add the header of If-Modified-Since to the header of the request. The value of this header is the value of Last-Modified returned in the previous request.
        
     • When the server receives the resource request again, it judges whether the resource has changed according to the If-Modified-Since passed by the browser and the last modification time of the resource on the server. If there is no change, it will return 304 Not Modified, but the resource content will not be returned; if If there is a change, the resource content 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, 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 is 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
        
2. Etag / If-None-Match
   two values are each unique identification string generated by the resource server, as long as there are resources to change this value will change; the process that determines the Last-Modified / If-Modified- Since similar Unlike Last-Modified, when the server returns a 304 Not Modified response, since the ETag has been regenerated, the ETag will be returned in the response header even if the ETag has not changed from the previous one.
    

4. Last-Modified He Sheng Etag

　　You might 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 of the change). At this time, we don't want the client to think that the file has been modified and re-GET;

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

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

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

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

5. The impact of user behavior on cache

Misappropriating a picture on the Internet can basically describe the impact of user behavior on cache

6. How to reload cached resources in strong cache

As mentioned above, when using strong caching, the browser will not send a request to the server. According to the set caching time, the browser will always obtain resources from the cache. During this period, if the resource changes, the browser will be in the cache period. I have been unable to get the latest resources, so how to prevent this from happening?

By updating the resource path referenced in the page, the browser actively abandons the cache and loads new resources.

Similar to the figure below:

In this way, a new query value will be generated every time the file is changed. In this way, the query value is different, that is, the resource path referenced by the page is different. The previously cached resource is ignored by the browser because the resource request path has changed.