Cache type

Strong cache

Definition:

When an HTTP request is made, no request is made to the server. As long as the current time is within the cache validity period, the request is directly obtained from the client cache. After the cache expires, the server can send a request to retrieve resources.

Characteristics of the

The status code returned by the HTTP request is 200 and is followed by from Memory cache or from Disk cache.

How to set up strong cache:

Due to the HTTP version upgrade, before HTTP1, specify the resource expiration time is xpires, note: Maturity refers to the server in response to a request to return to the time, when the client to initiate the request, again will compare local time and cache expiration time, if in the period of validity, the cache data read directly from the local client, this means: you can change the local system through time, mandatory control cache invalidation.

Cache-control specifies the caching mechanism for a request or response. It is unidirectional, meaning that if you set this property in the request header, it does not necessarily exist in the response header. It can be set in two ways, one is set by the client, and the other is set on the server after the server receives the request. The optional values of the two Settings are different, as explained by MDN. The details are as follows:

Optional value meaning in specific reference MDN: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control

What does strong caching do?

1) For the resources that consume bandwidth and seldom change on the page, once downloaded, they can be directly cached in the browser. Users can use them again, which can greatly reduce the loading waiting time and improve user experience;

2) For users with weak network or unstable network, strong cache can reserve enough bandwidth for the main resource request to prevent the page from being displayed normally due to the timeout of the main resource request.

disadvantages

The advantage of strong cache is that as long as the client has resources within the validity period, it will not obtain resources from the server, and his advantage is also his disadvantage. If the server resources are updated, or a bug is corrected, but the forced cache time is too long, it will cause the client information update behind the problem, what to do? Could there be a solution: Every time I request a resource, I ask the server: Do I need to retrieve the resource? The server checks that the cache hasn’t changed, the cache time hasn’t expired, and then tells the client to go ahead and use the stored data, I haven’t changed anything. This solves both caching and updating problems. The requests are still sent each time, and the number of requests is not reduced, but the amount of data transferred is reduced. Is there a solution? There is. What do you call? Negotiate cache.

summary

In the case of a strong cache, the status code returned for the resource obtained from the client or the updated resource obtained from the server is 200. The only difference is whether the status code is followed by from memory cache or from Disk cache. During the validity period, only the first time a request is actually sent to the server for data

Negotiate the cache

How to set up negotiation cache:

Settings in the Response header

etag: '5c20abbd-e2e8'
last-modified: Mon, 24 Dec 2018 09:49:49 GMT
Copy the code

Etag: Each file has a unique eTAG for resource changes. Hash is a file hash, which is added to compare whether the client and server are consistent. If they are inconsistent, the file is updated. If they are consistent, the file is unchanged. Last-modified: Indicates the modification time of a file, accurate to the second.

That is, eTag and Last-Modified from the Response header are returned with each request, and the next request is put in the Request header. The server compares the tag that you brought with it to determine if the resource has changed. If it changes, it returns the new resource directly and updates the etag and last-Modified labels of the corresponding Response header. If the resource has not been modified, then the eTAG, last-modified, and last-modified cache will be negotiated for each request from the client.

Send a request -> see if the resource is expired -> Expired -> Request server -> server comparison resource is really expired -> Not expired -> Return 304 status code -> client with the cache of the old resource.

This is a complete cache negotiation process.

When the server finds that the resource is expired, the following process is performed:

Send a request -> See if the resource is expired -> Expired -> Request server -> Server compare whether the resource is really expired -> Expired -> Return 200 status code -> If the client receives the resource for the first time, Write down max-age, etag, last-Modified, and so on in its cache-control.

Therefore, the negotiation cache steps are summarized as follows:

When requesting a resource, the local ETAG of the resource is sent to the server for comparison with the latest resource. If the resource has not changed, 304 is returned and the browser reads the local cache. If the resource has changed, return 200 to return the latest resource.

Why eTag?

You might think that using Last-Modified is enough to let the browser know if the local cached copy is new enough, so why etag? The introduction of eTag in HTTP1.1 (that is, eTAG was added to address the previous if-Modified defect) was primarily intended to address several difficult last-Modified problems:

1) Some files may change periodically, but their contents do not change (only the modification time is changed). In this case, we do not want the client to think that the file has been modified and get again;

2) Some files are modified very frequently, such as if they are modified less than seconds (say N times in 1s), and if-modified-since the granularity that can be checked is in seconds, so the modification cannot be determined (or the UNIX record MTIME is only accurate to seconds);

3) Some servers cannot accurately determine the last modification time of a file.

summary

The negotiated cache returns a status code of 200 for the first successful request, and then 304 if the file has not changed, so you can determine whether the resource is being updated or from the cache by judging the status code value. In addition, the negotiated cache is not subject to changes in local system time because last-modify and etag, which indicate whether a resource is valid, are determined by the server.

Problem sets:

After reading the above, you can think about the following questions:

Strong cache and negotiated cache are set differently. Does that mean you can set both caches at the same time?

If you can set strong and negotiated caches at the same time, with both valid and invalid states for each cache, where does the client get the data from among the four combinations of cache types and valid states?

Feel free to leave your answers in the comments section

Like + follow, make yourself run a little faster.

Refer to the article

www.jianshu.com/p/9c95db596…

Juejin. Cn/post / 684490…