Http cache and http Cache

Http cache and http Cache
HTTP Cache System

First, I divide the Http cache system into the following three parts:

1 HTTP/1.1 200 OK2 Cache-Control: no-cache3 Content-Type: image/png4 Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT5 Accept-Ranges: bytes6 Date: Thu, 10 Nov 2016 02:48:50 GMT7 Content-Length: 3534

 

1. cache storage policy

Used to determine whether the Http Response content can be cached by the client and which clients can be cached.

This policy has only one role to determine whether the Http Response content can be cached on the client.

Public, Private, no-Cache, max-age, and no-store in the cache-Control header are used to indicate whether the response content can be stored by the client, the first four of them will cache file data (no-cache should be understood as "local cache is not recommended", and it will still cache data locally ), the latter no-store will not cache any response data on the client. In addition, no-cache and max-age are a bit special. I think it is a mixture. I will discuss it below.

Through the Cache-Control: Public setting, we can store the Http response data locally, but this does not mean that the browser will directly read and use the data from the Cache. Why? Because it cannot determine whether the locally cached data is available (may be invalid), it must also be confirmed by a set of authentication mechanisms. This is the "cache expiration Policy" we will talk about below ".

2. cache expiration Policy

The client determines whether to send a request to the server to obtain the data.

This policy has only one role, that is, to determine whether the client can directly load and display data from the local cache (otherwise, a request is sent to the server for retrieval)

As we have already explained above, after the data is cached locally, it still needs to be judged before it can be used. So what conditions does the browser determine? The answer is: Expires, Expires indicates the absolute time when the cache data is valid. After the client reaches this time point (compared with the client time point), the local cache becomes invalid, at this time point, the client can consider the cached data to be valid and can load and display the data directly from the cache.

However, Http Cache headers are not designed as expected. As mentioned above, Cache-Control (this header is added to Http1.1) the no-cache and max-age in the header are special cases. They include both the cache storage policy and the cache expiration Policy. taking max-age as an example, it is actually equivalent:

Cache-Control: public/private (which is not specific here) Expires: current client time + maxAge.

While Cache-Control: no-cache and Cache-Control: max-age = 0 (unit: Second) is equivalent

Note the following:

1. The Cache expiration policy specified in Cache-Control has a higher priority than Expires. when both of them exist, the latter will be overwritten.

2. When the cached data is marked as expired, it only tells the client that it can no longer directly read the cache from the local machine. It needs to send a request to the server for confirmation, which is not equivalent to the local cache data, in some cases, it will be used again even if it expires.

3. cache comparison Policy

The data ID cached on the client is sent to the server. The server identifies whether the cached data on the client is valid and determines whether to resend the data.

After the client detects that the data has expired or the browser is refreshed, it often initiates an http request to the server again. The server is not eager to return data at this time, check whether the request header has an identifier (If-Modified-Since, If-None-Match). If the identity is still valid, then, 304 is returned to tell the client to use the locally cached data. (Note that you must output the corresponding header information (Last-Modified and ETags) at the first response) to the client ). So far, we have understood that even if the locally cached data is deemed to have expired, it does not mean that the data has never been used since.

For Last-Modified, please note that this response header may affect the cache expiration policy. For the specific reason, I will explain it by answering the two questions mentioned in the beginning.

The above are the cache policies I know. Below I will combine the three elements of the cache policy with several common cache headers (items) so that you can better understand the relationship between them:

I can clearly see which cache policy category each cache item belongs to. This partially overlaps and indicates that these cache items have multiple cache policies, therefore, in actual analysis of cache headers, in addition to regular headers, we also need to separate these items with dual cache policies.

Finally, let's go back to the two questions we mentioned at the beginning. Let's break them down together:

The first question:

HTTP/1.1 200 OKCache-Control: no-cacheContent-Type: image/pngLast-Modified: Tue, 08 Nov 2016 06:59:00 GMTAccept-Ranges: bytesDate: Thu, 10 Nov 2016 02:48:50 GMTContent-Length: 3534

The following two items of the above Http Response hair are related to cache:

Cache-Control: no-cache Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT

We mentioned above that Cache-Control: no-cache is equivalent to Cache-Control: max-age = 0, and they are all multiple policy headers. We need to break them down:

Cache-Control: no-cache equals to Cache-Control: max-age = 0,
Then Cache-Control: max-age = 0 can be decomposed:

Cache-Control: public/private (not sure which of the two is) Expires: Current Time

Finally, we obtained the following three complete cache policies:

So the final result is: the browser will request the server again and carry the time specified by Last-Modified to the server for comparison:

• A)Comparison failed: The server returns 200 and resends the data. After receiving the data, the client displays the data and refreshes the local cache.

• B)Comparison successful: The server returns 304 and does not resend data. After receiving the 304 status code, the client reads the cached data from the local device. The following is the packet capture situation after the request is simulated in this case:

This question is not difficult, but if you think no-cache will not cache data locally, it will be very difficult to understand, because if the file data is not locally cached, after the server returns 304, the image content cannot be displayed, but it can actually be displayed normally. This question proves that no-cache caches data locally.

Question 2:

HTTP/1.1 200 OKCache-Control: privateContent-Type: image/pngLast-Modified: Tue, 08 Nov 2016 06:59:00 GMTAccept-Ranges: bytesDate: Thu, 10 Nov 2016 02:48:50 GMTContent-Length: 3534

The solution is the same as the previous question. First, find the cache items:

Cache-Control: private     Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT

At this time, we will find that the cache expiration policy item cannot be found at all. Will the answer be the same as above? At half past one, the answer will not be analyzed, so it can only be tested:

Let's take a look at the captured packets in Chrome:

As you can see, the browser directly retrieves the local cache for subsequent requests. It seems that there is indeed a cache Expiration Policy (according to the above cache expiration policy theory, if the browser directly loads the cached data from the local, it believes that the local cache data is valid, and there must be some cache expiration judgment condition ). This problem was puzzling and plagued me for a long time. I found the answer on the Caching tab in the Fiddler response information panel by chance:

Originally, without providing any browser cache expiration policies, the browser follows a heuristic cache expiration Policy:

Based on the time difference between the two time fields Date and Last-Modified in the Response Header, take 10% of the value as the cache time period.

Paste the description in the Caching panel. Good English students can accurately translate:

HTTP/1.1 Cache-Control Header is present: privateHTTP Last-Modified Header is present: Tue, 08 Nov 2016 06:59:00 GMTNo explicit HTTP Cache Lifetime information was provided.Heuristic expiration policies suggest defaulting to: 10% of the delta between Last-Modified and Date.That's '05:15:02' so this response will heuristically expire 2016/11/11 0:46:01.

Finally, we obtained the following three complete cache policies:

Final Result

The browser caches the data for a period of time based on the time difference between Date and Last-Modified. During this period, the browser directly uses the local cached data instead of requesting the server (except for mandatory requests). After the cache expires, request the server again, and compare it with the time specified by Last-Modified, and decide whether to load the cached data locally based on the server's response status.

Summary

Http cache settings are not complex, but are easy to underestimate. This article combines two questions to analyze and dissect the relevant cache headers, from a systematic perspective, we have made a complete analysis of the Http cache mechanism: the Http cache mechanism is actually a collection of three elements (dimensions) of the Http Cache Policy, therefore, when analyzing and setting the Http packet cache header, as long as the three elements of the cache can be accurately decomposed, we can accurately predict the final effect of the cache settings.