浏览器缓存(Brower Caching)
It is the browser that stores the document that the user has recently requested on the local disk. When the visitor visits the same page again, the browser can directly load the document from the local disk.
The advantages of browser caching are:
- Reduce redundant data transmission and save network charges
- Reduce the burden on the server and greatly improve the performance of the website
- Faster loading of web pages on the client side
Browser cache is divided into strong cache and negotiation cache
When the browser requests again after the first request:- The browser will first obtain the header information of the resource cache,
expiresandcahe-controljudge whether it is a hit according to the sum强缓存）. If it hits, it will directly obtain the resource from the cache, including the cached header information, and this request will not communicate with the server; - If the strong cache is not hit, the browser will send a request to the server, and the request will carry the cached header field information (Last-Modified/IF-Modified-Since, Etag/IF-None-Match) returned by the first request, The server compares whether the result hits the negotiation cache according to the relevant header information in the request. If it hits, the server returns the 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
Strong cache
ExpiresStrong caching is controlled by one or Cache-Controltwo fields in the HTTP return header, which is used to indicate the cache time of resources. ·
Expires
This field is the specification of http1.0, and its value is a time string in GMT format of absolute time, such as Expires:Mon,18 Oct 2066 23:59:59GMT. This time represents the invalidation time of the resource. Before this time, the cache is hit. This method has an obvious disadvantage. Since the invalidation time is an absolute time, when the time difference between the server and the client is large, it will cause cache confusion.
Cache-Control
Cache-Control is the header information that appears in http1.1. It is mainly max-agejudged by the value of this field. It is a relative time, such as Cache-Control:max-age=3600, which means that the validity period of the resource is 3600 seconds. In addition to this field, cache-control has the following commonly used setting values:
- no-cache: Do not use local cache. It is necessary to use cache negotiation, and first 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, re-downloading can be avoided.
- 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 each time.
- public: Can be cached by all users, including end users and intermediate proxy servers such as CDNs.
- private: can only be cached by the end user's browser, and is not allowed to be cached by relay cache servers such as CDNs.
Cache-Control and Expires can be enabled at the same time in the server configuration, and Cache-Control has a higher priority when enabled at the same time.
Original link: http://caibaojian.com/browser-cache.htmlNegotiate cache
Negotiating the cache means that the server determines whether the cache resource is available, so the client and the server need to communicate through a certain identifier, so that the server can determine whether the requested resource can be cached and accessed, which mainly involves the following two sets of header fields. Group partners are all 成对present, that is, the response header of the first request carries a certain field ( Last-Modifiedor Etag), and subsequent requests will carry the corresponding request field ( If-Modified-Sinceor If-None-Match). If the response header does not have a Last-Modified or Etag field, The request header will also have no corresponding field. ·
Last-Modify/If-Modify-Since
When the browser requests a resource for the first time, Last-Modify will be added to the header returned by the server. Last-modify is a time marking the last modification time of the resource, such as Last-Modify: Thu,31 Dec 2037 23:59 :59GMT.
When the browser requests the resource again, the request header will contain If-Modify-Since, which is the Last-Modify returned before the cache. After the server receives If-Modify-Since, it determines whether the cache is hit according to the last modification time of the resource.
If the cache is hit, a 304 is returned, and the resource content will not be returned, and Last-Modify will not be returned.
ETag/If-None-Match
Different from Last-Modify/If-Modify-Since, Etag/If-None-Match returns a check code. ETag can ensure that each resource is unique, and resource changes will lead to ETag changes. The server determines whether to hit the cache according to the If-None-Match value sent by the browser.
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.
Why have an Etag
You might think that using Last-Modified is enough to let the browser know if the local cached copy is fresh enough, why do you need an Etag? The emergence of Etag in HTTP 1.1 is mainly to solve several problems that are difficult to solve with Last-Modified:
- Some files may be changed periodically, but their content does not change (only the modified modification time). At this time, we do not want the client to think that the file has been modified and re-GET;
- Some files are modified very frequently, for example, if they are modified within seconds (for example, they are modified N times within 1s), the granularity that If-Modified-Since can check is s-level, and this modification cannot be judged (or It is said that UNIX records MTIME can only be accurate to the second);
- Some servers cannot get the exact last modification time of a file.
Last-Modified and ETag can be used together. The server will first verify the ETag. If it is consistent, it will continue to compare Last-Modified, and finally decide whether to return 304.
The difference between strong cache and negotiated cache can be represented by the following table:
| cache type | Get resource form | status code | send request to server |
|---|---|---|---|
| Strong cache | fetch from cache | 200（from cache） | No, fetch directly from cache |
| Negotiate cache | fetch from cache | 304（Not Modified） | No, tell the server if the cache is available |
The effect of user behavior on caching
| User action | Expires/Cache-Control | Last-Modied/Etag | |
|---|---|---|---|
| Enter in the address bar | efficient | efficient | |
| page link jump | efficient | efficient | |
| new window | efficient | efficient | |
| forward and backward | efficient | efficient | |
| F5 refresh | invalid | efficient | |
| Ctrl+F5 Force refresh | invalid | invalid | |
Practical problem analysis
As per the beginning of the article, after the code is updated online, the user's browser cannot be updated by itself, and we cannot require customers to perform a cache cleaning operation after the system is updated.
In the end how to solve it?
Add a parameter to the URL of the resource request, for example: js/mian.js?ver=0.7.1. This parameter is a version number. Change it every time you deploy. When this parameter changes, the strong cache will be invalidated and reloaded. In this way, static resources need to be reloaded after deployment. This solves the problem perfectly.