Browser caching mechanism

The browser cache has been used to describe only one approximate, deep principles can not be described, and finally in the front of the two interview process was asked to fall, in order to spite, access to some information to finally have a more in-depth understanding, nonsense not to say, hurry to look at the browser cache of those things, there are wrong places, Please do not hesitate to enlighten me.
This article mainly explains browser-side caching, the role of caching is self-evident, can greatly improve the performance of the Web page, improve the user experience.
1, browser cache
Caching this thing, the first time you must get the resource, and then based on the information returned to tell you how to cache the resource, may be a strong cache, may also tell the client browser is the negotiation cache, which needs to be based on the header content of the response to determine. Here are two pictures to describe how the browser's cache is played, so that everyone has a general understanding.
The first time the browser requests:

Browser follow-up when making a request:

As you can see from the illustration above, the browser cache contains two types, the strong cache (also called the local cache), and the negotiation cache, which is requested again after the first request occurs:
• When a browser requests a resource, it first gets the header information for the resource cache, determines whether to hit the strong cache (Cache-control and expires information), and gets the resource information from the cache, including caching header information This request does not communicate with the server at all; under Firebug you can view a message that has a strong cached resource return, such as a strong cache JS file that is viewed locally firebug

• If you do not hit the strong cache, the browser sends the request to the server, and the request carries the cached header field information (Last-modified/if-modified-since and Etag/if-none-match) that was returned on the first request. A cache hit is negotiated by the server against the related header information in the request, and if hit, the server returns the new response header information to update the corresponding header information in the cache, but does not return the resource content, which tells the browser that it can get directly from the cache ; otherwise return the latest resource content

The difference between a strong cache and a negotiated cache can be described in the following table:
Get Resource Form Status code send request to server
Cache fetch from cache, or directly from cache
The negotiation cache fetch 304 (not modified) from the cache is, as its name means, a server to tell if the cache is available

2. Strong cache-Related header fields
Strong caching is described above, to get resources directly from the cache without the server; There are two header fields associated with the strong cache:
1. Expires, this is the specification of the http1.0; its value is a time string of GMT format for an absolute time, such as Mon, June 2015 21:31:12 GMT, and the local cache is always valid if the request is sent before expires. Otherwise, the request is sent to the server to obtain resources
2. Cache-control:max-age=number, This is the header information that appears when http1.1, the main use of the Max-age value of the field to judge, it is a relative value, the first time the resource request and Cache-control set the validity period, the calculation of a resource expiration time, and then take this expiration with the current request time comparison, if the request time You can hit the cache before the expiration time, otherwise it will not work; Cache-control in addition to the field, there are several more commonly used setting values:
0no-cache: Do not use local cache. A caching negotiation is required to confirm with the server whether the returned response has been changed, and if there is a etag in the previous response, then the request will be validated against the service side, and if the resource has not been changed, you can avoid downloading again.
0no-store: Directly prohibit the browser to cache data, each time the user requests the resource, will send a request to the server, each time will download the full resources.
0public: Can be cached by all users, including the end user and CDN and other intermediary proxy server.
0private: can only be cached by the end user's browser, not allowing a CDN and other relay caching servers to cache it.
Note: If Cache-control and expires exist at the same time, Cache-control priority is higher than expires
3,? Negotiate Cache-Related header fields
The negotiation cache is all determined by the server to determine whether the cached resource is available, so the client and server end up communicating with some kind of identity, allowing the server to determine if the requested resource can be cached for access, which involves two sets of header fields, both of which are paired. That is, a field (last-modified or ETag) on the first requested response header, then the subsequent request takes the corresponding request field (If-modified-since or If-none-match). If the response header does not have a last-modified or ETag field, the request header will not have a corresponding field.
1. Last-modified/if-modified-since
The values of both are time strings in GMT format, in particular:
§ The first time the browser requests a resource from the server, the server returns the resource at the same time, the header of the Respone plus the header of the last-modified, which represents the last time the resource was modified on the server
§ When the browser requests this resource again with the server, add the header of If-modified-since to the header of the request, which is the value of the last-modified returned at the last request
§ When the server receives the resource request again, according to the browser if-modified-since and resources on the server last modified time to determine whether the resource changes, if there is no change then return 304 not Modified, but does not return the resource content; Returns the resource content as normal. When the server returns a response to 304 not modified, the last-modified header is not added to the response header because the last-modified does not change since the resource has not changed, This is the response header when the server returns 304
§ When the browser receives a response of 304, the resource is loaded from the cache
§ If the negotiation cache does not hit, and the browser loads the resource directly from the server, the header of the last-modified is updated when it is reloaded, and If-modified-since enables the last returned last-modified value the next time it is requested
2. Etag/if-none-match
These two values are unique identifier strings for each resource generated by the server and will change as long as the resource changes; the process is similar to last-modified/if-modified-since, and last-modified is not the same as when the server returns 304 In the response of the not modified, the ETag is returned in the response header as the etag is regenerated, even if the etag is unchanged from the previous one.

4, both born last-modified he Shenghou ETag
You might think that using last-modified is enough to let the browser know if the local cache copy is new enough and why it needs etag. The emergence of ETag in HTTP1.1 is mainly to solve several last-modified problems that are more difficult to solve:
• Some files may be periodically changed, but his content does not change (just change the time of modification), at this time we do not want the client to think that the file has been modified, and get back;
• Some files are modified very frequently, such as in the seconds below the time to modify, (such as the 1s modified n times), if-modified-since can check the granularity is S-class, this modification can not be judged (or UNIX records mtime can only be accurate to seconds);
• Some servers cannot accurately get the last modification time of a file.
At this point, the use of etag can be more accurate control of caching, because ETag is the server automatically generated or generated by the developer of the corresponding resources on the server side of the unique identifier.
Last-modified and ETag can be used together, the server will first verify ETag, consistent, will continue to last-modified, and finally decide whether to return 304.
5, the user's behavior on the impact of the cache
Misappropriation of a map of the web, the basic ability to describe the impact of user behavior on the cache

Summary: ETag is a unique identifier on the server side of the server-generated or generated by the developer of the corresponding resource. And Last-modified is the time, if Cache-control and expires exist at the same time, Cache-control priority than expires,last-modified and etag can be used together, The server will first validate the ETag, in the same case, will continue to last-modified, and finally decide whether to return 304.
If the current Catch-control is public,max-age not set, what should be done.
Used locally in the browser (the last time the resource was requested-the time the resource was last modified) that is (date-last-modified)