Shulou(Shulou.com)06/03 Report--

This article mainly explains the "introduction to the principle of HTTP caching". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "introduction to HTTP caching principle".

Obtaining resources through Internet is slow and expensive. To this end, the Http protocol includes a part that controls caching so that Http clients can cache and reuse previously acquired resources to optimize performance and improve the experience. Although the part about cache control in Http has changed a little as the protocol evolves. But I think, as a back-end programmer, when developing Web services, you only need to focus on the request header If-None-Match, the response header ETag, and the response header Cache-Control. Because these three Http headers can meet your needs, and most browsers today support these three Http headers. All we have to do is make sure that each server response provides the correct HTTP header instruction to instruct the browser when and how long the response can be cached.

Where is the cache?

There are three roles in the figure above, the browser, the Web proxy, and the server. The Http cache as shown in the figure exists in the browser and Web proxy. Of course, there are various caches within the server, but this is no longer the Http cache discussed in this article. The so-called Http cache control is a convention that controls the cache policy of browsers and Web agents by setting different response headers Cache-Control, and verifies the effectiveness of caching by setting request headers If-None-Match and response headers ETag.

Response header ETag

ETag, the full name Entity Tag, is used to identify a resource. In a specific implementation, the ETag can be the hash value of the resource or an internally maintained version number. In any case, ETag should reflect changes in the content of resources, which is the basis on which Http caching works.

As shown in the example above, when the server returns a response, it usually contains some metadata information about the response in the Http header, where ETag is one of them. In this case, ETag with the value x1323ddx is returned. When the content of the resource / file changes, the server should return a different ETag.

Request header If-None-Match

For the same resource, such as / file in the previous example, after making a request, the browser already has a version of / file and this version of ETag. The next time the user needs the resource and the browser requests the server again, you can use the request header If-None-Match to tell the server that it already has a / file with the ETag of x1323ddx. If the / file on the server does not change, that is to say, the ETag of / file on the server is also x1323ddx, the server will no longer return the contents of / file, but a response of 304, telling the browser that the resource has not changed and the cache is valid.

As shown in the example above, after using If-None-Match, the server needs only a small response to achieve the same results, thus optimizing performance.

Response header Cache-Control

Each resource can define its own caching policy through the Http header Cache-Control, and Cache-Control controls who can cache the response under what conditions and for how long. The fastest requests are those that do not have to communicate with the server: by making a local copy of the response, we can avoid all network delays and the data cost of data transmission. To this end, the HTTP specification allows the server to return a series of different Cache-Control instructions that control how the browser or other relay cache caches a response and for how long.

The Cache-Control header is defined in the HTTP/1.1 specification, replacing the header that was previously used to define the response caching policy (such as Expires). All current browsers support Cache-Control, so it's enough to use it.

Let me introduce the common instructions that can be set in Cache-Control.

Max-age

This directive specifies the maximum time (in seconds) that the obtained response is allowed to be reused starting from the current request. For example, Cache-Control:max-age=60 indicates that the response can be cached and reused for another 60 seconds. It is important to note that within the time specified by max-age, the browser will not send any requests to the server, including requests to verify that the cache is valid, that is, if the resources on the server change during that time, the browser will not be notified and will instead use the older version of the resources. Therefore, you need to be careful when setting the length of the cache time.

Public and private

If public is set, the response can be cached in the browser or in the Web proxy of any relay, and public is the default, that is, Cache-Control:max-age=60 equals Cache-Control:public, max-age=60.

When the server sets private such as Cache-Control:private, max-age=60, it means that only the user's browser can cache the private response, and no relay Web agent is allowed to cache it-for example, the user's browser can cache HTML pages that contain the user's private information, but CDN cannot.

No-cache

If the server sets no-cache or Cache-Control:no-cache in the response, the browser must confirm with the server whether the response returned has been changed before using the cached resource, and download can be avoided if the resource has not been changed. This verifies whether the previous response has been modified by using the request header If-None-match and response header ETag described above.

It is important to note that the name no-cache is a bit misleading. Once no-cache is set, it's not that the browser no longer caches the data, it's just that when the browser uses the cached data, it needs to make sure that the data is still consistent with the server. If no-cache is set and the implementation of ETag does not reflect changes in resources, it will cause the browser's cached data not to be updated all the time.

No-store

If the server sets no-store, that is, Cache-Control:no-store, in the response, neither the browser nor any relay Web agent will store the corresponding data this time. The next time the resource is requested, the browser can only re-request the server to read the resource from the server again.

How do you determine the Cache-Control strategy for a resource?

The following flow chart can help you.

Thank you for your reading, the above is the content of "introduction to the principle of HTTP caching". After the study of this article, I believe you have a deeper understanding of the introduction of HTTP caching principles, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.