As a front, the backend should understand the Web caching knowledge

Caching benefits

Generally speaking, Web caching refers to HTTP devices that can automatically save copies of common HTTP requests. For front-end developers, browsers play an important role. In addition to the common there are a variety of proxy servers can also do caching. When a Web request arrives at the cache, the cache extracts the contents of the replica from the local replica local copy without having to go through the server. This brings the following benefits:

Cache reduces redundant data transfer and saves traffic
Caching alleviates the bandwidth bottleneck problem. Pages can be loaded faster without the need for more bandwidth
Caching eases the momentary congestion and reduces the demand for the original server.
Caching reduces the distance delay because it is slower to load a page from a remote location.

Cache type

Caching can be private to a single user, or it can be shared by multiple users. Private caching is called a private cache, and shared caching is called a public cache.

Private cache

Private caching is only for proprietary users, so there is no need for a lot of space and cheap. There is a built-in private cache in a Web browser--most browsers cache common resources in the disk and memory of your PC. For example, the cache location of the Chrome browser is located in: C:\Users\Your_Account\AppData\Local\Google\Chrome\User Data\default in the cache folder and media cache folder.

Public cache

The public cache is a special shared proxy server, known as a caching proxy or proxy cache (a use of a reverse proxy). The public cache accepts access from multiple users, so it is better to reduce redundant traffic.

Each client in the following illustration will repeatedly access a resource to the server (not in the private cache), so it accesses the server multiple times, increasing server pressure. When using shared public caching, caching only needs to be taken from the server once, and then the server can be reduced significantly to reduce server pressure.

In fact, in practical applications, a hierarchical public cache is usually used, the basic idea is to use small cheap cache near the client, and at a higher level, a larger, more powerful cache is used to load resources shared by multiple users.

Cache processing Process

For the front-end developers, we deal primarily with caching in the browser, so the above diagram process is simplified to:

The following diagram shows a Web site, the request results of different resources, which can see some resources directly from the cache read, and some resources and the server to verify, and some resources from the server side to get.

Note that all the questions we discuss about caching resources are only for GET requests. For post, DELETE, put, this kind of behavioral operation usually does not do any caching

Value of freshness limit

HTTP retains a copy of the server resource over a period of time, known as a freshness limit, through caching. This requires that the same resources are not passed through the server for a period of time. In the HTTP protocol, Cache-control and expires can be used to set the threshold for freshness, which is the new response header in HTTP1.1, and the response head in HTTP1.0. The two do the same thing, but because Cache-control use relative time, and expires may have the client and server-side time is not the same problem, so we are more inclined to choose Cache-control.

Cache-control

Now let's look at what property values Cache-control can set:

Max-age (s) specifies the maximum effective time to set the cache, defined as the length of time. When the browser sends a request to the server, the browser will no longer send requests to the server during the Max-age period.

 
var http = require (' http '); var fs = require (' FS '); Http.createserver (function (req, res) {if (Req.url = = '/' | | req.url = = ' | | req.url = = '/index.html ')
            {Fs.readfile ('./index.html ', function (err, file) {Console.log (Req.url)//Set cache for main document, no effect
            Res.setheader (' Cache-control ', "No-cache, max-age=" + 5);
            Res.setheader (' Content-type ', ' text/html ');
            Res.writehead ('; ', "OK");
        Res.end (file);
    }); } if (Req.url = = '/cache.png ') {fs.readfile ('./cache.png '), function (err, file) {Res.setheader ('
            Cache-control ', "max-age=" + 5);/cache Five Seconds Res.setheader (' Content-type ', ' images/png ');
            Res.writehead (' n ', ' not Modified ');
        Res.end (file);
    }); }). Listen (8888) 
 
When the page is accessed for the second time in 5 seconds, the browser obtains the resource directly from the cache

public specifies that the response can be cached in the proxy cache and can be shared by multiple users. If private is not explicitly specified, the default is public.
Private responses can only be cached in the private cache and cannot be placed on the proxy cache. Resources that are sensitive to some user information are usually set to private.
No-cache indicates that the resource must be verified with the server (depending on if-none-match and etag) before deciding whether to use the local cache.

If the previous deal on Cache.png is changed to the following, then every time the page is accessed, the browser needs to go to the server side to verify that the resource has not been changed.

Fs.readfile ('./cache.png ', function (err, file) {
        console.log (req.headers);
        Console.log (Req.url)
        if (!req.headers[' If-none-match ')) {
            res.setheader (' Cache-control ', "No-cache, Max-age= "+ 5);
            Res.setheader (' Content-type ', ' images/png ');
            Res.setheader (' Etag ', "ffff");
            Res.writehead (' n ', ' not Modified ');
            Res.end (file);
        else {
            if (req.headers[' if-none-match '] = = = ' FFFF ') {
                res.writehead (' 304 ', ' not Modified ');
                Res.end ();
            } else {
                res.setheader (' Cache-control ', "max-age=" + 5);
                Res.setheader (' Content-type ', ' images/png ');
                Res.setheader (' Etag ', "ffff");
                Res.writehead (' n ', ' not Modified ');
                Res.end (file);}}

    );
 

No-store absolutely prohibits caching of any resources, that is, each time a user requests a resource, a request is sent to the server, and the complete resource is downloaded each time. Typically used for confidential resources.

For the use of Cache-control, see this picture below (from large)

Freshness limit for clients

Cache-control can be set not only in the response header, but also in the request header. The browser sets Cache-control through the request header to determine whether to read resources from the cache. That's why sometimes you click on the Browser Refresh button and return in the address bar to see completely different results in the network module

Expires

Using expires is not recommended, it specifies a specific expiration date instead of a number of seconds. Because many servers and clients have clock inconsistencies, it is best to use Cache-control.

Server re-verification

The cached resource in the browser or proxy cache expires, and does not mean that it has a real difference to the resources on the original server, only that it is time to check. This situation is known as server re-validation.

If the resource changes, a new resource needs to be taken and the old resource is replaced in the cache.
If the resource does not change, the cache only needs to get a new response header, and a new expiration time to update the resource expiration time in the cache. HTTP1.1 is recommended for use in If-none-match/etag, and if-modified-since/last-modified in HTTP1.0.

ETag and If-none-match

Generates a hash string based on the entity content that identifies the state of the resource and is generated by the server. The browser passes this string back to the server to verify that the resource has been modified, and if not, the procedure is as follows (the picture comes from a brief discussion of the Web cache):


In the demo above we've seen how the server side validates ETag:

Because the ETag has the server constructs, must guarantee the ETag uniqueness in the cluster environment
If-modified-since and Last-modified

These are the request/response headers used in HTTP1.0 to verify that the resource is out of date, the two headers are dates, and the validation process is similar to ETag, which is not described in detail here. When you use these two headers to verify that a resource is updated, the following problems exist:

Some document resources are periodically rewritten, but the actual content does not change. The file metadata now shows that the file's most recent modification date is not the same as if-modified-since, resulting in unnecessary responses.
Some document resources have been modified, but it is not important to modify the content, do not need all the cache update (such as code comments)

About the cache update problem, please see here Zhang Yunlong answer, this article does not expand in detail.
This demo code is as follows:

<! DOCTYPE html>