Why cache is used:

Advantages of caching:

  1. Accelerate the speed of browser loading web pages, optimize user experience, let users open our web pages faster;
  2. Reduce the number of accesses to the server and lighten the load on the server.
  3. Save bandwidth (save money… Because a lot of bandwidth services are actually charged per view; For users can also save a lot of 4G, 5G traffic… Save money too! Win-win!!)

What are the disadvantages?

If the resource is always cached, users can’t get the latest information when the resource changes! So cache is good, but don’t “drink” oh!

Caches are divided into strong caches and negotiated caches. What are they?

Strong cache

As you can see from the name, a little “mandatory” meaning; That is, as long as the strong cache is in place, I won’t use your resource if it changes, which is… Then what’s the use of it?

The so-called existence is reasonable, it always has its applicable scenarios, how to use it?

Strong caching takes advantage of the Expires and cache-Control fields in the HTTP header.

Expires

As you can see from the figure, its value is an absolute time, which represents the expiration time of the resource, meaning that the cache is always valid and the data in the cache is always read before this time.

However, there is an obvious problem: because it is an absolute time, when the server time deviates from the client time, the cache may become invalid, such as when the user discovers that the local machine can change the time at will.

Cacha-Control

Cache-control is added to http1.1. Max-age =2592001; max-age=2592001;

In addition to max-age, there are some other values:

  1. Cache-control: max-age= XXXX, public public Indicates that both the client and the proxy server (such as the CDN) can cache.

  2. Cache-control: max-age= XXXX, private private (default value) Indicates that only clients can cache.

  3. cache-control: Max-age = XXXX, immutable Immutable If a client requests a resource within XXX seconds, the client directly reads the cache. Statu code:200 does not send HTTP requests to the server even after refreshing the resource. Immutable is a suggestion the Facebook team made to the IETF working group that developed the HTTP standard: they wanted HTTP to add a property field to the cache-control response header to indicate that the resource was never out of date, so that browsers would no longer need to make conditional requests for it. Here is an article that demonstrates immutable

  4. Cache-control: no-cache No-cache the contents of the cache on the client, but whether to cache the contents needs to be checked by negotiation cache.

  5. Cache-control: no-store no-store All contents are not cached, i.e. no strong cache or negotiated cache is used (more on this later);

PS: Expires and cache-control can be enabled at the same time on the server. Cache-control takes a higher priority if both are enabled.

Negotiation cache:

Negotiation cache is a process in which the browser sends a request to the server with the cache id after the cache is invalid or the strong cache is set to cache-control: no-cache. The server decides whether to use the cache based on the cache ID:

The negotiated cache is set by two pairs of values:Last-Modified/If-Modified-Since 和 ETag/If-None-Match

Last-modified/If Modified – Since:

  1. The first time the browser sends a request, the server returns the last-modified value of the requested resource in the Response header. The browser saves this time.

  2. When the browser next requests the request header with if-modified-since (the saved last-modified value). A comparison is made between the modification time sent by the browser and the wh modification time of the server. If the modification time is consistent, the code resource is not changed, and the server returns a response with an empty body, allowing the browser to read the resource in the cache, thus reducing the request consumption.

Disadvantages:

  1. As you can see from the figure above, last-Modified saves the absolute time and is accurate to the second, so if the resource is Modified more than once in a second, it will not be recognized.

  2. For the file only changes the modification time, the same content, this will also make the cache invalid, in fact, this time we do not want the client to request again;

  3. Some servers do not know exactly when a file was last modified;

ETag/If-None-Match:

  1. The first time the browser sends a request for the value of the ETag, it adds if-none-match (the saved ETag value) to the request header.

  2. The value of the ETag sent is compared with the value of the ETag regenerated by the server. If the same value indicates that the resource has not changed, the server returns a response with an empty body, allowing the browser to read the resource from the cache, thereby reducing the request consumption.

  3. ETag works in much the same way as Last-Modified. However, ETag uses a collision-proof hash function (I don’t know what that is) for the resource content, using the hash value of the recently modified timestamp. ETag solves the problem of last-Modified.

Cons: ETag is a solution, but not perfect. ETag requires a read/write operation for every server generation (since it generates a hash), whereas Last-Modified only requires a read operation, which is more expensive.

Last-modified and ETag can also be configured at the same time. The server validates the ETag first. If the ETag is consistent, the server will continue to compare last-Modified, and finally decide whether to return 304.

ETag is higher for accuracy and slightly lower for performance (because of the hash generation)

The negotiated Cache is affected by the strong Cache. The negotiated Cache determines whether the Cache is cached only when the strong Cache expires and cache-control is not a no-store.