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

This article mainly explains "what is the HTTP caching strategy". 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 what the HTTP caching strategy is.

I just discussed HTTP's caching strategy with my friends:

The friend said: "there are too many header to control the cache in HTTP, what a lot of Cache-Control,ETag,Last-Modified, a lot of mess, and the logical relationship is not strong, to master the basic backrest!"

I was a little surprised: "Why do you want to carry this?" All the technology exists to solve the problem, do not understand the problem and simply learn the technology, to, memorize, memorize, it is really boring, and the effect is not good. HTTP caching policy only exists to solve the problem of information asymmetry between client and server. The client will cache some resources in order to speed up the speed, but the next request, the client does not know whether the resource has been updated, the server does not know which version the client is caching, and whether the resource should be returned or not. In fact, it is an information synchronization problem. HTTP cache strategy is to solve this problem. If we jump out of this pure technical thinking, we will find that this kind of information synchronization problem is also very common in our lives. And our ideas to solve these problems are often commonplace. From this point of view, this problem is very easy to understand! "

So I told him a story about renting CDs to watch Altman when I was a kid.

Rent a CD to watch Altman

The thing is, when I was a child, I especially liked watching cartoons, especially Altman, but at that time there was no computer or Internet. I only have one DVD player, so I often go to the CD rental store to rent Altman.

ETag

One day, I finished watching the 10th episode of Esther Altman, and I want to continue to watch it. So I found the owner of the CD store: "Boss, I've finished watching episode 10. Do you have any new ones?" The boss said, "Yes, the eleventh episode has just come out. Take it."

The above simple communication process actually includes a HTTP caching technology, which is ETag! Compared to the network request, I am actually the client, the CD store is the server, and renting the CD is tantamount to initiating a request. But when I went to rent a CD, the boss didn't know which episode I saw, and our information was out of sync. So I told him a Tag, and here it was episode 10, and the boss got it, compared it with his own stock tag, and found that his latest tag was episode 11, so he knew it was updated and gave it to me.

Last-Modified & If-Modified-Since

Again, I finished watching Esther Altman, and I began to watch Tyro Altman. But the boss compared the chicken thief this time, "Tyro Altman" did not buy a genuine copy, he copied it himself, and he did not know which episode it was when he copied it, but he was smart enough to write a copy date on the CD. So the one I'm looking at doesn't have a cover, it just says December 1, 2000. When I finished watching this set, I went to the boss again: "Boss, I have finished watching this December 1, 2000, do you have any new ones?" December 1st, 2000 actually marks the update date of the copy in my hand, which corresponds to one of HTTP's caching technologies, namely Last-Modified and If-Modified-Since. You can understand that the boss also named the date Last-Modified, so the full text on the CD is Last-Modified: December 1, 2000, and when I asked, "Do you have any updates IF-Modified-Since, December 1, 2000?" .

Expires and Max-Age

Go on, I've finished watching Tyro Altman, and I'm starting to watch Leo Altman. This "Leo Altman" is different from the previous two. When I went to rent it, the boss said, "Don't come and ask me every day!" Leo Altman "I go to stock once a week, you can pick it up every Monday!" This sentence also corresponds to a HTTP caching technology, that is, Expires and Max-Age. I know that until next Monday, I have the latest ones on hand, and they will expire (Expire) next Monday. So the saying "I have the latest" has a life cycle, his age is limited, his age is equal to next Monday's update time minus the current time, this is his maximum age (Max-Age).

Immutable

One more. I've finished watching Leo Altman, and I'm starting to watch Nexter Altman. This "Nexter Altman" is different from the previous ones. When I went to rent it, the boss said, "son, you are lucky this time. This" Nexter Altman "is over. You can take it all, and you don't have to ask questions every day!" What is the HTTP caching technology corresponding to this sentence? Immutable, of course! Immutable means literally, immutable! Just like "Nexter Altman", it's over, so you don't have to ask for updates.

Let's get back to the point

Bullshit is over here, let's get back to business! The reason for giving this example is to show that the problems that HTTP caching technology is trying to solve are common in life, and it is easier to understand from these common scenarios. Let's seriously talk about HTTP caching technology:

Two mechanisms

As can be seen from the small examples above, sometimes in order to know if there is an update, I have to ask my boss, such as the first example: "Boss, I have finished watching episode 10, do you have any new ones?" . In order to know whether there is an update or not, we call it negotiation cache, which must be communicated with the server. There are some scenarios that I don't have to ask to know if there are updates. For example, the third example, because I know it's the week shift, I won't ask it until Monday, and I'll ask it on Monday. This kind of thing is called forced caching, which does not need to negotiate with the server to use the local copy directly. In other words, force the cache to use the local cache without making a request, and negotiate the cache to send a request to ask the server if it has been updated. Let's talk about these two caches in detail:

Negotiation cache

The first and second examples above need to ask the server every time, so it is to negotiate the cache.

ETag and If-None-Match

ETag is the Entity Tag of URL, which is the identifier of a URL resource, which is similar to the md5 of a file. When the server returns, you can calculate a hash value or a digital version number based on the returned content, similar to our episode 10. The specific value returned depends on the server's calculation strategy. Then add it to response's header, which might look like this:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

After getting it, the client will save the ETag together with the return value. When the next request is made, use the matching If-None-Match and put this in the header of request. It may look like this:

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Then the server gets the If-None-Match in the request and compares it with the current version of ETag:

If it is the same, directly return 304semantic is Not Modified, do not return content (body), only return header, tell the browser to use the cache directly.

If it is different, return 200 and the latest content

ETag is accompanied by a less commonly used request header-If-Match, which is the opposite of the semantics of the previous If-None-Match. The semantics of the previous If-None-Match is to download if it doesn't match. If-Match is usually used in post or put requests, and the semantics is to submit only if there is a match. For example, if you are editing an item, others may be editing it at the same time. When you submit an editor, someone else may have submitted it before you. At this time, the ETag of the server has changed, and the If-Match will no longer be established. At this time, the server will return a 412 error, that is, Precondition Failed, and the prerequisite fails. If If-Match is set, 200 is returned normally.

Last-Modified & If-Modified-Since

Last-Modified and If-Modified-Since are also used together, similar to the relationship between ETag and If-None-Match. It's just that ETag puts a version number or hash value, and Last-Modified puts the last modification time of the resource. Last-Modified is put into the header of response, and it may look like this:

Last-Modified: Wed, 21 Oct 2000 07:28:00 GMT

When using the client browser, you should put the matching If-Modified-Since into the header of * * request * *, which looks like this:

If-Modified-Since: Wed, 21 Oct 2000 07:28:00 GMT

After the server gets this header, it will compare it with the modification time of the current version:

The revision time of the current version is later than this, that is, it has been changed again after this time, and 200 and new contents are returned.

The modification time of the current version is the same as this, that is, there is no update, 304 is returned, no content is returned, only back, and the client directly uses the cache.

Corresponding to If-Modified-Since, If-Unmodified-Since,If-Modified-Since can be understood as downloading only when there is an update, and If-Unmodified-Since can be downloaded only if there is no update. If the client passes If-Unmodified-Since, like this:

If-Unmodified-Since: Wed, 21 Oct 2000 07:28:00 GMT

After the server gets this header, it will also compare it with the modification time of the current version:

If there is no update after this time, the server returns 200 and the content.

If there is an update after this time, in fact, the if is not valid, the error code 412 will be returned, and the semantics is Precondition Failed.

ETag and Last-Modified priority

Both ETag and Last-Modified are negotiation caches that require the server to calculate and compare, so if both exist, which one should be used? The answer is that ETag,ETag has a higher priority than Last-Modified. Because there is a problem with the design of Last-Modified, that is, the accuracy of Last-Modified can only be up to seconds. If a resource is modified frequently and multiple changes are made in the same second, you can't tell the difference from Last-Modified. But ETag generates a new one every time it is modified, so it is more accurate and accurate than Last-Modified. But ETag is not completely fine. If your ETag is designed as a hash value, it will be calculated for each request, which will cost extra server resources. You need to choose which one to use according to your own project.

Force caching

The third and fourth examples of bullshit above are forced caching, that is, I know that I don't have to ask the server at all for a certain period of time, just use the cache. The Expires mentioned in these two examples is a separate header,max-age and immutable belong to the header of Cache-Control.

Expires

Expires is relatively simple, that is, the header of the server response comes with this field:

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

Then before this time, the client browser will no longer initiate the request, but will directly use the cached resource.

Cache-Control

Cache-Control is relatively complex, and there are many properties that can be set. Max-age is just one of them, which looks like this:

Cache-Control: max-age=20000

This means that the current resource does not have to be requested for 20000 seconds and uses the cache directly.

The immutable mentioned above is also an attribute of Cache-Control, but it is experimental and the compatibility between browsers is not good. Setting Cache-control: immutable means that you have used caching for the rest of your life, and it is impossible to request again.

Other common properties are:

No-cache: force the request to be submitted to the server for authentication (negotiate cache validation) before using caching.

No-store: nothing about client requests or server responses is stored, that is, no caching is used.

In addition, Cache-Control has many properties, you can refer to the documentation of MDN.

Priority of Expires and Cache-Control

Just one sentence: if the max-age or s-maxage instruction is set in the Cache-Control response header, then the Expires header will be ignored.

Negotiate cache and force cache priority

In fact, it is easy to understand that the negotiation cache needs to send a request to negotiate with the server. If the cache is forced to take effect, the request will not be sent at all. So the priority is: first determine the forced cache, if the forced cache takes effect, directly use the cache; if the forced cache expires, then send a request to negotiate with the server to see whether to use the cache.

Thank you for reading, the above is the content of "what is the HTTP caching strategy". After the study of this article, I believe you have a deeper understanding of what the HTTP caching strategy is, and the specific usage 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.