The following figure shows the process of cache reading:
General cache is divided into strong cache and negotiated cache
Strong cache
Can be obtained directly from the local, without any request to the browser. Something like this
- From memory cache: does not access the server. Generally, resources have been loaded and cached in the memory and the cache is directly read from the memory. After the browser is closed, data will not exist and resources will be released
- From Disk cache: Does not access the server, the resource has been loaded at a previous time, directly reads the cache from the disk, closes the browser, the data still exists, the resource will not be released when the page is closed.
Sanctioned disk cache accesses memory cache first, then requests network resources.
Negotiate the cache
If the strong cache is not hit, the browser sends a request to the server with information about the cache header fields returned by the first request (last-modified/if-modified-since and Etag/ if-node-match). If yes, the server returns a new response header to update the corresponding header information in the cache, but does not return the resource content. It tells the browser to obtain the resource directly from the cache. Otherwise, the latest resource content is returned.
Header parameters for strong and negotiated caching
Strong cache
- Expires: Expires. If a time is set, the local cache remains valid until that time, as was the specification in HTTP1.0.
- Cache-control :max-age=number,http1.1 header information, mainly use the max-age value of the field to determine, it is a private value; The first request time of a resource and the cache-control validity period are calculated and compared with the current request time. If the request time is earlier than the expiration time, the Cache will be hit; otherwise, the Cache will not be hit. Cache-control has several other values in addition to this field
- No-cache: local cache is not applicable. To use a negotiated cache, the salty fish server verifies that the returned response has not been changed. If the previous response had an ETag, the request is validated with the server, and if the resource has not changed, a re-download can be avoided
- No-store: disables the browser from caching data. Every time a user requests a resource, the user sends a request to download the complete resource
- Publick: can be cached by all users, including terminals and CDN intermediate proxy servers
- Private: the device can be cached only by the browser of the terminal user and cannot be cached by a trunk cache server such as the CDN
Note: If both cache-control and Expires exist, cache-control takes precedence over Expires
Negotiate the cache
The negotiated cache is used by the server to determine whether the cache resource is available. Therefore, the client and server communicate with each other through some kind of identifier so that the server can determine whether the cache resource is available. There are two sets of values ETag/ if-none-match and last-modified/if-Modified-since. If the response header does not have an ETag/ last-Modified field, the request header does not have a corresponding field.
Last-modified/if-modified-since, both are time strings in GMT format.
- When the browser requests a resource from the server for the first time, the server returns the resource and adds last-modified to the header in response, indicating the time when the resource was Last Modified on the server
- When the browser requests a resource from the server, it adds an if-modified-since header to the header of the request, whose value is the last-modified value of the Last request
- When the server receives a resource request again, it determines whether the resource has changed according to if-Modified-since and the time when the resource was last Modified on the server. If the resource has Not changed, 304 Not Modified is returned, but the resource content is Not returned. If there are changes, the resource content is returned as normal. When 304 is returned, the last-Modified header is also not added to the Response header because the resource has not changed.
- When the browser receives 304, it loads the resource from the cache.
- If the negotiated cache is not hit, the browser loads the resource directly from the server, the last-Modified header is updated when the centroid is loaded, and if-modified-since enables last-modifie returned Last time on the next request
2. Etag/ if-none-match is a unique identifier for each resource generated by the server. The value will change as soon as the resource changes. Since the ETag has been regenerated, the Response Header will return the ETag even if it hasn’t changed
Why ETag when you have Last-Modified?
Mainly to solve the following problems:
- The file changes periodically, but the content does not change, and we do not want the client to think that the file has been modified
- Some files are Modified frequently, and if-modified-since can be checked in the granularity of seconds at the millisecond level, so modification judgment cannot be made
- Some servers can’t pinpoint the last modification time of a file
In this case, the cache can be more accurately controlled using eTAGS, because eTags are the unique identification on the server side of the corresponding resource that is automatically generated by the server or generated by the developer, and the server validates the ETAGS first.
Supplement:
With strong caching, the browser does not send requests to the server. How do I update resources if they change during this time?
The resource path referenced in the page needs to be updated so that the browser will voluntarily abandon the cache and load the new resource
<link rel="stylesheet" href="a.css? V = 1.0.0 "/ >Copy the code