HTTP Cache Summary

Clear several terms before you know the HTTP cache specifically:
1. Cache Hit Rate: The ratio of the number of requests received from the cache to the number of requests. The ideal state is the higher the better.
2. Expired content: The content is marked as "stale" when it exceeds the valid time set. Normally expired content cannot be used to respond to requests from clients, you must re-request new content to the source server or verify that the cached content is still ready.
3. Verify that the expired content in the cache is still valid and the expiration time is refreshed by verifying it.
4, Failure: Failure is to remove the content from the cache. When the content changes, you must remove the invalidated content.

HTML meta tag definition cache
For example
<meta http-equiv= "Pragma" content= "No-store" >
The implication is that the browser does not cache the current page. However, the proxy server does not parse HTML content, which is commonly used to control caching with HTTP header information.
(The way the cache is defined in Meta information does not work for the proxy server, so we will set the cache with the HTTP header.) ）

HTTP header Information Control cache
There are roughly two types: strong cache and negotiated cache.
When a strong cache hits the cache, it does not need to interact with the server side, and the negotiate cache interacts with the server regardless of whether it is hit or not.
Forcing the cache to take precedence over the negotiated cache.

The matching process for strong caches and negotiated caches is as follows:

These two caches are explained in detail below:
First, strong cache
Can be understood as a cache policy that does not require validation. For strong caches, there are two field Expires/cache-control in the response header to indicate the rule.

Expires
Expires refers to the time that the cache expires, exceeding this point in time to represent the resource expiration. One problem is that because of the time spent, it can cause the cache life cycle to go wrong if the time represents an error or does not convert to the correct time zone. And Expires is the http/1.0 standard, now more inclined to use the Cache-control defined in http/1.1. Two simultaneous presence is also a higher priority for Cache-control.

Cache-control
Cache-control can be composed of multiple fields, mainly with the following values:
1. max-age specifies a length of time during which the cache is valid, in units of S. For example, setting cache-control:max-age=31536000, which means that the cache is valid for (31536000/24/60 * 60) days, the server side also returns the Expires field when the resource is first accessed, and the expiration Time is one year later.

Without disabling the cache and not exceeding the valid time, accessing the resource again hits the cache and does not request resources from the server but is taken directly from the browser cache.

 
2. S-maxage with Max-age, covering Max-age, Expires, but only for shared caches, is ignored in the private cache.
3. public indicates that the response can be cached (shared) by any object (the client sending the request, the proxy server, and so on).
4. private indicates that the response can only be cached by a single user (perhaps an operating system user, a browser user), not by a proxy server.
5. No-cache forces all users who have cached the response to send a request with authenticator to the server before using the cached data. Not the literal meaning of not caching.
6. No-store suppresses caching, and each request is re-fetched to the server.

Second, negotiated cache
The cached resource expires, and does not imply that the resource content has changed, and if there is no difference between the resources on the server, there is actually no need to request again. The
client and server side verify that the current request resource can use the cache through some kind of authentication mechanism. The

Browser stores the cached identity of the data and response headers after the first request of the data. The stored header field is brought with the request again, and the server-side validation is available.
If 304 not Modified is returned, the cached data can be used to obtain a new expiration time on behalf of the resource. The
returns 200 instead of re-requesting the resource and replacing the old resource.

last-modified/if-modified-since
Last-modified: The last modification time of the server-side resource, in response to which the header will carry this identity. After the first request, the browser logs the time, and when the request is requested again, the if-modified-since on the request header is the time recorded earlier. When the server receives a request with if-modified-since, it will compare to the last modification time of the resource. If modified, return to the latest resource, status code 200, if not modified, then return 304.

Note: If there is last-modified in the response header and there is no Expire or Cache-control, the browser will have its own algorithm to figure out how long it takes to cache the file for a different browser, so Last-modified to remember to use with Expires/cache-control.

Etag/if-none-match
A hash string generated on the server side, the first request on the response header with ETAG:ABCD, after the request with IF-NONE-MATCH:ABCD, the server checks the ETag, returns 304 or 200.

A lot of people have summed up the difference between last-modified and ETag:
Some servers cannot pinpoint the last modification time of a resource, so the last modification time will not determine whether the resource is being updated.
Last-modified can only be accurate to seconds.
The last modification time of some resources has changed, but the content has not changed, using last-modified to see that the content has not changed.
The accuracy of ETag is higher than last-modified, which is strong authentication, which requires consistent resource byte level and high priority. If an etag is provided on the server side, the ETag must be conditional request first.

Note: The actual use of etag/last-modified should be careful to maintain consistency, do load balancing and reverse proxy words may appear inconsistent situation. The calculation of the ETag is also required to occupy resources, if the changes are not too frequent, see if their own needs with Cache-control can be satisfied.

Practical Application
Back to the actual application, it is first to identify which content is appropriate for the cache.
Consider the contents of the cache:
CSS style files
JS file
Logo, Icon
HTML file
Content that can be downloaded

some content that should not be cached:
Business-sensitive GET requests

The cacheable content is divided into several different situations:
1. Files that do not change frequently.
Set a larger value for Max-age, general settings max-age=31536000
such as the introduction of some third-party files, packaged with a hash suffix css, js file. Generally speaking, the contents of the file have changed, and the version number and hash value will be updated, which is equivalent to requesting another file.
The standard specifies that the value of max-age is not more than one year, so it is set to max-age=31536000. As for outdated content, the cache will delete files that have not been used for some time.
2. Documents that may often need to be changed.
Cache-control:no-cache/max-age=0
For example, the entry index.html file, the contents of the file changed but the name of the resource unchanged. Select the ETag or last-modified to do the verification, before using the cache resources will go to the server to do the validation, hit the cache is a little slower than the first situation, after all, also send a request to communicate.

Note: Here only describes the most basic idea, the actual use of HTTP cache requires a backend collocation configuration, specific treatment, and the implementation of the parties are not necessarily in accordance with the standard, stepping on the pit more healthy.

Related information:
It may be easier to understand HTTPS https://mp.weixin.qq.com/s/E5PINP-HmHuUWsszVOG79g
HTTP caching mechanism 123 HTTP://MP.WEIXIN.QQ.COM/S/EQRFHUTICQO804NHIQWFSG
On Web Cache Http://mp.weixin.qq.com/s/MLmxeIlX6Zy7Uy98SEWbFw
Front-end cross-domain knowledge summary Http://mp.weixin.qq.com/s/NOmsbKZsryTUONQj2gBFIA
Understanding pseudo-elements: Before and: After Http://mp.weixin.qq.com/s/YUxSKRW98Q2uvqpF6zZ3Vg
The principle and practice of front-end cross-domain request HTTPS://MP.WEIXIN.QQ.COM/S/CZGZ0YA_RXHZDKEFV2_9IW

HTTP Cache Summary