HTTP cache

foreword

Caching is a technique of keeping a copy of a resource and using that copy directly on the next request.

We use HTTP cache to reduce client waiting time and network traffic by reusing cache resources, and also relieve the pressure on the server side. Can significantly improve the performance of our website and applications.

Although HTTP caching is not necessary, it is often necessary to reuse cached resources, and HTTP caching is an important means of web performance optimization.

Types of HTTP caching

Generally, there are two HTTP caching strategies:

• Strong cache
• Negotiate cache.

From the literal meaning, we can intuitively see the difference between them:

• Strong caching means forcing the direct use of the cache.
• To negotiate a cache, you have to negotiate with the server to confirm whether the cache can be used.

Strong cache

The strong cache will not send a request to the server, but read resources directly from the cache. In the network option of the chrome console, you can see that the request returns a status code of 200, and size displays from disk cache or from memory cache ;

Negotiate cache

The negotiation cache will first send a request to the server. The server will determine whether the negotiation cache is hit according to some parameters of the request header of the request. If it hits, it will return a 304 status code and bring a new response header to notify the browser to read from the cache. Get resources.

HTTP cache control

In HTTP, we can control the caching strategy by setting response headers as well as request headers.

Strong caching can be achieved by setting two response headers Expires and Cache-Control . If both exist, Cache-Control takes precedence over Expires .

Expires

Expires response header, which is a product of HTTP/1.0. Represents the expiration time of the resource, and its value is an absolute time. It tells the browser to access data directly from the browser cache before the expiration time. Since it is an absolute time, factors such as the time difference or error between the client and the server may cause the time between the client and the server to be inconsistent, which will result in a cache hit error. If the max-age or s-max-age command is set in the Cache-Control response header, then Expires will be ignored.

Expires: Wed, 21 Oct 2015 07:28:00 GMT

Cache-Control

Cache-Control appeared in HTTP/1.1. The caching mechanism can be implemented by specifying multiple directives. Mainly used to indicate the maximum effective time of resource cache. That is, within this time period, the client does not need to send a request to the server. Priority is higher than Expires. The value of its expiration time instruction is relative time, which solves the problem of absolute time.

Cache-Control: max-age=315360000

Cache-Control has many attributes, and different attributes represent different meanings.

• public indicates that the response can be cached by any object (including: the client sending the request, the proxy server, etc.).
• private indicates that the response can only be cached by a single user, not as a shared cache (ie the proxy server cannot cache it)
• no-cache does not use strong cache and needs to negotiate cache verification with the server.
• no-store cache should not store anything about client requests or server responses, i.e. no cache is used.

expired

• max-age=<seconds> The maximum period of cache storage, beyond which it is considered expired.
• s-maxage=<seconds> Set shared cache. Will overwrite max-age and expires , private cache will ignore it
• max-stale[=<seconds>] client is willing to receive an expired resource, an optional number of seconds can be set, indicating that the response cannot be expired beyond the given time.
• min-fresh=<seconds> client wants to get the latest response within the specified time

and reload

• must-revalidate If the page expires, go to the server to get it.
• proxy-revalidate is the same as must-revalidate , but for shared cache.

Others

• only-if-cached does not make network requests and only uses cache.
• no-transform Resource must not be transformed and transformed. For example, image formats must not be converted.

The negotiation cache can be controlled by two pairs of headers, Last-Modified / If-Modified-Since and ETag / If-None-Match .

Last-Modified、If-Modified-Since

The values of Last-Modified and If-Modified-Since are both time strings in GMT format, representing the last modification time of the file.

1. When the server responds to the request, it will tell the browser the last modification time of the resource through Last-Modified .
2. When the browser requests the server again, the request header will contain Last-Modified field, followed by the last modification time obtained in the cache.
3. When the server receives the request header with if-Modified-Since , it will compare it with the last modification time of the requested resource. If it is consistent, it will return 304 and the response header. The browser only needs to get the information from the cache. If it has been modified, then start transmitting the response as a whole, the server returns: 200 OK

However, this situation often occurs on the server. A resource is modified, but its actual content has not changed at all. Because the time of Last-Modified does not match, the entire entity is returned to the client (even if there is an identical one in the client cache) Resources). To solve this problem, HTTP/1.1 introduced Etag . Etag has high priority with Last-Modified .

Etag、If-None-Match

Etag is a unique identifier generated by the server for each resource, just like a fingerprint, resource changes will lead to ETag changes, regardless of the last modification time, ETag can guarantee that each resource is unique.

When the browser initiates a request, the browser's request message header will contain If-None-Match field, the value of which is the last returned Etag sent to the server. After the server receives the second message, it finds that If-None-Match is compared with the unique identifier of the requested resource. If the same indicates that the resource has not been modified, the response returns 304, and the browser obtains the data information directly from the cache. If it is different, it means that the resource has been changed, and the whole resource content is responded to and the status code 200 is returned.

Summarize

Through the previous article, we learned that HTTP caching is mainly divided into:

• Force cache
• Negotiate cache.

Forced caching is controlled by Cache-Control , Exipres (HTTP1.0). The browser directly reads the local cache and will no longer interact with the server. The status code is 200.

The negotiation cache is implemented by Last-Modified / IfModified-Since , Etag / If-None-Match , each request needs to let the server determine whether the resource has been updated, so as to determine whether the browser uses the cache, if so, return 304, otherwise complete the response.

~

~ This article is over, thanks for reading!

~

Learn interesting knowledge, meet interesting friends, and shape interesting souls!

Hello everyone, I'm Hermit King , the author of " Programming Samadhi ", my public account is " Programming Samadhi ", welcome to pay attention, I hope you will give more advice!