Experience in Caching policies for large web sites

Cache policy

Browser cache rules

For browser cache, these rules are defined in the HTTP header and the Meta tag of the HTML page. They determine whether the browser can directly use cached copies from two dimensions: freshness and verification value, or whether the browser needs to obtain the updated version from the source server.

Freshness (expiration mechanism): indicates the validity period of the cached copy. A cached copy must meet the following conditions, and the browser will regard it as valid and new enough:

It contains the complete expiration time control header (HTTP header) and is still in the validity period;
The browser has used this cached copy and checked its freshness in a session.

In either case, the browser directly retrieves copies from the cache and renders them.

Verification Value (verification mechanism): When the server returns a resource, it sometimes carries the resource Entity Tag (Etag) in the control header information, which can be used as the verification identifier for the browser request again. If the check mark does not match, the resource has been modified or expired, and the browser needs to obtain the resource content again.

An important concept

Cache hit rate: the cache validity is measured based on the cache hit rate. It is based on the ratio of the number of data requests to the number of all requests. A high cache hit rate means that a high rate of data is obtained from the cache.


Web cache function

Reduces network bandwidth consumption
Reduce server pressure
Reduces network latency and speeds up page opening

HTTP cache mechanism

The cache behavior is mainly determined by the cache policy, and the cache policy is set by the content owner. These policies are clearly expressed through specific HTTP headers.

When a user initiates a static resource request, the browser obtains the resource through the following steps:

Local cache stage: searches for the resource locally. If a resource is found and has not expired, the resource is used and no http request is sent to the server;
Negotiation cache phase: if the corresponding resource is found in the local cache but you do not know whether the resource has expired or has expired, an http request is sent to the server and the server determines the request, if the requested resource has not been changed on the server, the system returns the 304 message so that the browser can use the locally found resource;
Cache failure phase: when the server finds that the requested resource has been modified, or this is a new request (the resource has not been found), the server returns data for this resource and returns 200, of course, this means that if the resource is found, if the server does not have this resource, 404 is returned.

User Operation behavior and cache

The impact of operations in the browser on the cache:

Force refresh? When you press ctrl + F5 to refresh the page, the browser will bypass various caches (local cache and negotiated cache) and directly let the server return the latest resources;
Normal refresh? When you press F5 to refresh the page, the browser will bypass the local squat to send the request to the server. At this time, the negotiated cache is valid.
Enter or turn? When you press enter or the jump button in the address bar, all caches take effect.

Local cache stage

Expires

Specify the absolute time of expires GMT. If max-age is set, max-age overwrites expires. If expires, you need to request again.
Cache-Control

Cache-Control: this is newly added in http 1.1 to compensate for the Expires defect.

Control cached content:

Cache-control: public indicates that the cached version can be identified by the proxy server or other intermediate servers.

Cache-control: private indicates that the file is different for different users. Only users' browsers can cache data. Public proxy servers cannot cache data.

Cache-control: no-cache means that the file content should not be cached. This is useful in search or flip results, because the corresponding content changes with the same URL.

Other related control fields:

Max-age: specifies the relative time (in seconds) of cache expiration. If max-ag is set to 0 or a negative value, the browser sets Expires to 08:00:00 in the corresponding cache.

S-maxage: Similar to max-age, only used in shared cache, such as proxy.

Public: normally, http authentication is required, and the response cannot be cahce. In addition, public can make it cache.

No-cache: forces the browser to submit an http request to the source server for confirmation before using the cache copy. This is very useful for identity authentication and can be well observed (can be considered in combination with public ). It is also useful for maintaining a resource that is always up-to-date, but it does not completely lose the benefits of cache), because it is locally copied, however, confirmation was made before use, so http requests are not reduced, but a response body may be reduced.

No-store: tells the browser not to cache data under any circumstances and does not keep copies locally.

Must-revalidate: force the browser to strictly abide by the cache rules you set.

Proxy-revalidate: forces the proxy to strictly abide by the cache rules you set.

Example: Cache-Control: max-age = 3600, must-revalidate

Cache: use the local cache without any request.

Negotiate cache stage

Last-Modified & if-modified-since

Last-Modified and If-Modified-Since are two packet headers, which belong to http 1.0.

Last-modified is the last modification time of the object, for example, the last modification time of the file and the last generation time of the dynamic page.
ETag & If-None-Match

ETag and If-None-Match are a pair of packets, which are http 1.1.

ETag can be used to solve this problem. ETag is the unique identifier of a file. Like a hash or fingerprint, each file has a unique identifier. As long as the file changes, the identifier changes.

The ETag mechanism is similar to the optimistic locking mechanism. If The ETag of the request message is inconsistent with that of the server, the resource has been modified and the latest content needs to be sent to the browser.

Both headers are used. If-Modified-Since and If-None-Match are completely matched, the Modified time and Etag are checked. If they are consistent with the server, the server returns 304. Otherwise, the latest content is sent to the browser.

The Etag/lastModified process is as follows:

1. The client requests A page ().

2. The server returns to page A and adds A Last-Modified/ETag to page.

3. The client displays the page and caches the page together with Last-Modified/ETag.

4. The customer requests page A again and passes the Last-Modified/ETag returned by the server in the Last request to the server.

5. The server checks the Last-Modified or ETag and determines that the page has not been Modified since the Last client request. The server returns the response 304 and an empty response body.

304: If-Modified-Since If-Match is used to determine whether the resource is Modified. If the resource is not Modified, 304 is returned. A request occurs, but the request content length is 0, which saves bandwidth. If there are multiple server load balancer servers, the Etag calculated by different servers may be different, which may cause repeated resource loading.

Etag is mainly used to solve some problems that Last-Modified cannot solve:

1. Some files may be changed cyclically, but their content does not change (only the modification time). At this time, we do not want the client to think that the file has been modified, and GET again;

2. Some files are frequently modified, for example, modified within seconds (for example, modified N times within 1 s ), if-Modified-Since can check that the granularity is s-level, and such modifications cannot be judged (or the UNIX record MTIME can only be accurate to seconds );

3. Some servers cannot accurately obtain the last file modification time.

Other labels

Content-Length: Although not explicitly included in the cache, the Content-Length header is important when setting cache policies. If some software does not know the content size in advance to leave enough space, it will refuse to cache the content.

Vary: the cache system usually uses the requested host and path as the key to store the resource. When determining whether a request is the same content, the Vary header can be used to remind the cache system to pay attention to another additional header. It is usually used to tell the cache system to pay attention to the Accept-Encoding header, so that the cache system can distinguish between compressed and uncompressed content.

Server cache

CDN cache

CDN cache, also known as Gateway cache and reverse proxy cache. The browser first initiates a WEB request to the CDN gateway. The gateway server is followed by one or more server load balancer source servers, which dynamically forward requests to the appropriate source server based on their load requests.

CDN cache policy

The CDN edge node Cache policies vary with service providers, but generally follow the http standard protocol by using the Cache-control in the http response header: set the CDN edge node data cache time.

When a client requests data from a CDN node, the CDN node determines whether the cached data has expired. If the cached data does not expire, the cached data is directly returned to the client. Otherwise, the CDN node sends a back-to-source request to the origin site to pull the latest data from the origin site, update the local cache, and return the latest data to the client.

CDN service providers generally provide CDN cache time based on file suffixes and directories to provide users with more refined cache management.

The CDN cache time has a direct impact on the "back-to-source rate. If the CDN cache time is short, the data on the CDN edge node often becomes invalid, resulting in frequent back-to-source, increasing the load on the origin site and increasing the access latency. If the CDN cache time is too long, this may cause slow data update times. Developers need to add specific services for specific data cache time management.

CDN cache refresh CDN edge nodes are transparent to developers. Compared with the force refresh of the browser Ctrl + F5, the local cache of the browser is invalid, developers can use the "refresh cache" interface provided by the CDN service provider to clear the CDN edge node cache. In this way, after updating data, the developer can use the "refresh cache" function to force the data cache on the CDN node to expire, so that the client can pull the latest data during access.

CDN advantages

The CDN node solves the problem of cross-carrier and cross-region access, greatly reducing access latency;
Most of the requests are completed on the CDN edge node, and CDN plays a shunting role, reducing the load on the origin site.

Disadvantages of CDN cache

When the website is updated, if the data on the CDN node is not updated in time, even if the browser uses Ctrl + F5 to invalidate the browser cache, user access is also abnormal because the CDN edge node does not synchronize the latest data.

Combo service

Combo service, that is, when we finally splice and generate page resource references, we do not generate multiple independent link tags, but splice resource addresses into a url path, requests an online dynamic resource merging service to reduce the need for HTTP requests.

/?? Fle1, file2, file3 ,... the url request response is provided by the dynamic combo service. Its principle is very simple. It is to find multiple corresponding files based on the url and combine them into one file to respond to the request and cache the files, to speed up access.

However, it also has some defects:

The browser has a url length limit, so you cannot merge resources without restrictions.
If a user has a jump between two pages with public resources on the website, because the combo URLs of the two pages are different, the user cannot use the browser cache to speed up access to public resources. If any file in the combo url changes, the entire url cache will become invalid, resulting in reduced browser cache utilization.

HTML5 cache ideas

HTML5 offline application cache manifest

Users can access your applications offline, which is especially important for mobile terminal users who cannot stay online at any time.
Users access local cached files, which usually means faster access.
Only modified resources are loaded to avoid multiple requests from the same resource to the server, which greatly reduces the access pressure on the server.

The manifest file lists the files to be cached.

Cache manifest # wanz app v1 # specify the CACHE entry CACHE: index.htmlstyle.css images/logo.png scripts/main. js # The following resources must access the NETWORK online: login. php # use 404.html instead of FALLBACK:/index. php/404.html

There are several problems in this process:

If the server updates offline resources, you must update the manifest file before these resources can be re-downloaded by the browser. If only the resources are updated but the manifest file is not updated, the browser does not re-download resources, that is, it still uses the original offline storage resources.
Be careful when caching the manifest file, because you may update the manifest file, however, the http cache rule tells the browser that the locally cached manifest file has not expired. In this case, the browser still uses the original manifest file, so it is best not to set the cache for the manifest file.
When the browser downloads resources in the manifest file, it will download all resources at a time. If a resource fails to be downloaded for some reason, all updates will fail, the browser will still use the original resources.
After the resource is updated, the new resource takes effect only after you open the app next time. If you need the resource to take effect immediately, you can use window. applicationCache. the swapCache () method takes effect. The reason for this is that the browser first loads the page with offline resources and then checks whether the manifest has been updated. Therefore, it takes effect until the page is opened again.

LocalStorage

LocalStorage. fresh = "vfresh.org"; // set a key value var a = localStorage. fresh; // Obtain the key value // API // clear the storage localStorage. clear (); // set a key value localStorage. setItem ("fresh", "vfresh.org"); // Obtain a key value localStorage. getItem ("fresh"); // return "vfresh.org" // Obtain the name of the specified underlying key (like Array) localStorage. key (0); // return "fresh" // delete a key value localStorage. removeItem ("fresh ");

The main difference with sessionStroage is the storage time and scope.

In addition, localStorage is more like local data storage like cookies. In addition to the standard cache, developers can use some browser functions to implement custom client "cache ".

Suggestions for building a cacheable site

From alloyteam: how to build a cacheable site

The same resource ensures URL stability
Add an HTTP cache header to Css, js, and image resources, and force the Html entry not to be cached.
Reduce Cookie dependencies
Reduces the use of HTTPS encryption protocols
Use Get to request dynamic Cgi
Dynamic CGI can also be cached