Take a closer look at the HTTP caching mechanism

As an important means of Web performance optimization, HTTP caching mechanism is a basic part of web development Knowledge System library, but for many learners, it is not clear that the browser caches the requested static files, but why it is cached and how the cache takes effect. Here, the HTTP caching mechanism is introduced with simple and concise text, which is expected to be helpful for the learners to understand the front-end cache correctly.

First, caching rules parsing

HTTP caching has a number of rules, according to whether it is necessary to re-initiate requests to the server classification, divided into two categories (forced cache, contrast cache), before the detailed introduction of these two rules, first of all, through the time series diagram of the way, let people have a simple understanding of the two rules.

When cached data already exists, the process for requesting data is based only on the forced cache, as follows:

When cached data already exists, the process for requesting data is based only on the contrast cache:

You can see the difference between the two types of cache rules, forcing the cache to take effect, no need to interact with the server, and the contrast cache, regardless of whether it takes effect, needs to interact with the service side. Two types of cache rules can exist at the same time, forcing the cache to take precedence over the contrast cache, that is, when enforcing a rule that enforces caching, if the cache is in effect, the cache is used directly, and the contrast cache rule is no longer executed.

Second, forced cache

From the above we know that the forced cache, in the case of cache data is not invalidated, can be directly used to cache data, then how the browser to determine whether the cache data is invalid? In the absence of cached data, when the browser requests data from the server, the server returns the data and cache rules, and the cache rule information is included in the response header.

For forced caching, there are two fields in the response header that indicate the failure rule (Expires/cache-control) using Chrome's developer tools, and you can see clearly what the network request is when the force cache is in effect.

The value of Expires:expires is the expiry time returned by the server, i.e., the next request, the request time is less than the expiry time returned by the server, and the cached data is used directly.

However, expires belongs to the HTTP series, and now the default browser uses HTTP by default, so its function is largely ignored. Another problem is that the expiration time is generated by the server, but the client time may be error with the server time, which results in a cache hit error.

Cache-control:cache-control is the most important rule. The common values are private, public, No-cache, Max-age,no-store, and the default is private.

Private: Clients can cache

Public: Both client and proxy servers can be cached (front-end classmates can be considered public and private are the same)

MAX-AGE=XXX: Cached content will expire after xxx seconds

No-cache: Need to use contrast cache to validate cached data (described later)

No-store: All content is not cached, forced cache, contrast cache is not triggered

As an example:

Cache-control only specifies the max-age, so the default is private, the cache time is 31.536 million seconds (365 days) that is, in 365 days to request the data again, will directly get the data in the cache database, directly use. For a little more popular words. When the client accesses the resource for the first time, the server returns Expires:sun, Oct05:43:02 GMT, while returning the contents of the resource.

The server tells the browser: Y first put this file to me cache, before this expiration time, this file will not change, you need this file next time, you do not come to me to ask, you go to the cache to take it, good, fast and good.

The browser replied, "Connaught."

So in the second HTML page to access this resource, and the date of the visit in Sun, Oct 05:43:02 GMT, the browser will not go to the server to get files, and self-reliance from the cache.

But after all, the browser is on the client, the client's time is not accurate, users can modify their own machine time with their own preferences, such as I put my machine time into Sun, Oct 05:43:03 GMT, expired? My browser will no longer use the cache, and every time I go to the server to get the files. So, the server anger: give you an absolute time, you because the environment is modified can not judge expired, then I will give you relative time. So I went back to cache-control:max-age:600, and the browser you cached for me for 10 minutes. So the browser only obediently cached for 10 minutes.

But the problem comes again, if some server also set up expires and cache-control what to do? Then the standard is based on the more advanced Setup Cache-control. OK, now there is a problem, I have a file may occasionally update, the server very much hope that the client can occasionally come to ask whether this file expires, if not expired, the server does not return data to you, only tell the browser your cache has not expired (304). The browser then uses its own stored cache to do the display. This is called a conditional request.

Third, contrast cache

Contrast caching is the need to make a comparison to determine whether the cache can be used. When the browser requests data for the first time, the server returns the cached identity with the data to the client, which the client backs up to the cache database.

When the data is requested again, the client sends the cached identity of the backup to the server, the server is judged based on the cache identity, returns a 304 status code after successful judgment, notifies the client that it is more successful, and can use the cached data.

For contrast caching, the delivery of the cache identity is something we need to understand, which is passed between the request header and the response header, and is divided into two identity passes, which we'll cover separately.

Last-modified/if-modified-since

Last-modified: When the server responds to a request, it tells the browser the last modified time of the resource.

If-modified-since: When you request the server again, this field notifies the server of the last time the resource was returned when it was requested. When the server receives the request, it finds that the header if-modified-since is compared to the last modification time of the requested resource. If the last modification time of the resource is greater than if-modified-since, indicating that the resource has been changed, then response to the entire resource content, return the status code 200; If the last modification time of the resource is less than or equal to if-modified-since, the resource has no new modifications, the response HTTP 304, tell the browser to continue using the saved cache.

Etag/if-none-match (priority higher than last-modified/if-modified-since): The first time the client accesses the resource, the server returns the resource content while returning the etag:1234. Tell the client: the label for this file is 1234, and if I change the resources on my side, the tag will be different.

The second time the client accesses the resource, because the cache has an etag of 1234 of resources, the client to go to the server query is this resource has the wood has expired it? So I took the if-none-match:1234. Tell the server: If your resources over there are 1234-tag resources, you'll return 304 and tell me you don't need to return the resource content. If not, you can return the resources to me. The service side compares the ETag to see if it returns 304 or 200.

Iv. various refreshes

Understanding the above cache tags is a good understanding of the various refreshes.

There are three types of refreshes:

• Write address in Browser, enter
• F5
• Ctrl+f5

Suppose to a resource: the first time the browser accesses, gets the resource content and cache-control:max-age:600,last_modify:wed, 15:32:18 GMT so the browser puts the resource file into the cache, and decided to use the next time to go to the cache directly to take.

Browser URL carriage return: The browser found that the file in the cache, do not send any requests, go directly to the cache to get the display. (fastest)

F5 Refresh: F5 is to tell the browser, do not lazy, at least to the server to see if this file has expired. So the browser on the gall bladder to send a request with if-modify-since:wed, 15:32:18 GMT

Then the server found: This file I have not modified after this time, do not need to give you any information, return 304 on the line. So the browser gets to 304 and then goes to the cache to get the resources in joy.

If we press the CTRL+F5, this is deadly, tell the browser, you first put the cache of this file to me delete, and then go to the server to request a complete resource file down. The client then completes the forced update operation ... In fact, very few people use, because it is calculated using algorithms to derive, and the algorithm will occupy the server computing resources, all server resources are valuable, so it is seldom used.

Take a closer look at the HTTP caching mechanism