Shulou(Shulou.com)05/31 Report--

This article focuses on "what is the principle of Nginx client caching", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what is the principle of Nginx client caching"?

The role of caching

Caching is critical for Web services, especially for large, high-load Web sites. Caching, as an important means of performance optimization, can greatly reduce the load of the back-end server. Usually, static resources, that is, resources that are not updated frequently, such as pictures, CSS or JS, are cached without having to request from the server every time, thus reducing the pressure on the server.

Classification of caches

Caching can be divided into client cache and server cache.

The client cache refers to the browser cache, which is the fastest cache because it is obtained directly locally (but it may need to send a request to negotiate the cache). Its advantage is that it can reduce network traffic and speed up requests.

Server-side caching refers to the reverse proxy server or CDN cache, which is used to relieve the pressure on the actual Web Server at the back end.

Browser caching can be divided into two modes, strong caching and negotiation caching.

Strong caching (no HTTP requests, no negotiation)

Read the local cache directly without sending a request confirmation to the server. The HTTP return status code is 200 (from memory cache or from disk cache, the information returned by different browsers is inconsistent).

The related HTTP Header are:

Cache-Control

Expires

Negotiation cache (if there is a HTTP request, you need to negotiate)

Although the browser found that there is a local cache of the resource, the cache has expired, so it asks the server whether the cache content can still be used. If the server thinks that the cache content of the browser is still available, it will return a 304c (Not Modified) HTTP status code, telling the browser to read the local cache; if the server thinks that the cache content of the browser has changed, it returns the new requested resource.

The related HTTP Header are:

Last-Modified

ETag

Cache verification process

Due to the frequent changes in the content of the website, in order to keep the cached content consistent with the content of the website server, the client will quickly determine whether the requested content has been updated through the validity period of the content cache (mandatory cache) and the verification of access requests provided by the Web server (negotiation cache). The flow chart of client cache verification is as follows:

Force caching

Mandatory caching principle: when loading a resource, the browser will first determine whether the cache expires based on the information (Expires and Cache-Control) in the header of the local cache resource. If the cache does not expire, the resources in the cache are used directly; otherwise, a request to negotiate the cache is made to the server.

The client determines whether the cache expires or not is related to the HTTP header field returned by the server during the previous request:

The Cache-Control returned by the server: if the max-age=x client cache time exceeds x seconds, the cache expires. Cache-Control: the no-cache client cannot use the locally cached response directly. It needs to negotiate the cache and send a request to the server to confirm whether the cache can be used. If the Web server returns 304, the client uses the local cache, and if it returns 200, the new data returned by the Web server is used. Cache-Control: the no-store client cannot cache the response. Cache-Control: public can be cached by all users, including end users and intermediate proxy servers such as CDN. Cache-Control:private can only be cached by the end user's browser, and relay cache servers such as CDN are not allowed to cache it. When the expires x client cache time exceeds x seconds, the cache expires, and the priority is lower than Cache-Control: max-age=x. Negotiation cache

Negotiation caching principle: when the client initiates a request to the server, the server will check whether there is a corresponding identity (If-Modified-Since or Etag) in the request. If there is no corresponding identity, the server will return the identity to the client. The next time the client requests, it will take the identity over, and then the server will verify the identity. If the verification passes, it will respond to 304 and tell the browser to read the cache. If the identity fails, the requested resource is returned.

Last-Modified and If-Modified-Since belong to HTTP/1.0, which is a server-side verification method for verifying the modification time of response data. The value of Last-Modified is generated by the server and passed to the client. When the client sends the request, the value of Last-Modified in the local content cache is passed to the server through the If-Modified-Since field of the request message header. If the last modification time of the requested content of the server is inconsistent with the value of If-Modified-Since (default is exact exact match), the new content will be returned, otherwise the response status code 304 will be returned. The client will use the local cache.

Etag and If-None-Match belong to HTTP/1.1, and the verification priority is higher than Last-Modified. It is a server-side verification method used by the server to verify the entity tag of the response data. An Etag is similar to an identity fingerprint and is a token that can be associated with a Web resource. When the client initiates the request for the first time, the value of Etag is passed to the client in the response header; when the client initiates the request again, if server verification needs to be initiated after verifying the local content cache, the value of Etag will be passed to the server through the If-None-Match field of the request header. If the server verifies that the value of If-None-Match does not match the Etag value of the server, it is considered that the content of the request has been updated, and the server will return the new content, otherwise, the response status code 304 will be returned, and the client will use the local cache.

The following figure shows that when the client requests for the first time, there is no If-Modified-Since and Etag identity in the client request, and the server responds to 200 and returns Etag and Last-Modified headers.

When the second client request, with the If-Modified-Since and If-None-Match message headers, and the server after verification returned 304 for the client to use the local cache.

The influence of user behavior on browser caching

When F5 is pressed or refreshed, the client browser adds the request message header field Cache-Control: max-age=0. The request does not perform local verification of the content cache, but directly initiates the request to the Web server. The server verifies based on the value of If-Modified-Since or If-None-Match.

When Ctrl+F5 is pressed or forced refresh, the client browser adds the request header field Cache-Control: no-cache, and ignores all server-verified header fields (Etag and Last-Modified). The request does not perform local verification of the content cache, and it directly initiates the request to the Web server. Because the request does not carry the header field verified by the server, the server will directly return the new content.

The meaning of Cache-Control field in request and response client request

Max-age: you don't want resources that have been cached in the proxy server for too long (> max-age seconds).

Max-stale: you can receive expired caches on the proxy server. If there is no value after max-stable, it means that the client can use it no matter how long it expires.

Min-fresh: requires the server to use its cache to ensure that it does not expire at least within min-fresh seconds.

No-cache: tell the proxy server that you cannot directly use the existing cache as a response return code unless you get a 304verification return code from the upstream server with the cache condition.

No-store: tell each proxy server not to cache this request and its corresponding.

No-transform: tell the proxy server not to modify the contents of the message packet.

Only-if-cached: tell the proxy server that only cache can be returned, and 504 will be returned if there is no cache.

Server response

Max-age: tells the client that the cache expires after the Age exceeds max-age seconds.

S-maxage: similar to max-age, but only for shared cache, and has higher priority than max-age and Expires.

Public: can be cached by all users, including end users and intermediate proxy servers such as CDN.

Private: it can only be cached by the end user's browser, and relay cache servers such as CDN are not allowed to cache it.

No-store: tells all downstream nodes that responses cannot be cached.

No-cache: tells the client that the cached response cannot be used directly and that the 304error code must be verified on the source server before using it.

No-transform: tells the proxy server that the contents of the message packet cannot be modified.

Must-revalidate: tells the client that once the cache expires, it must verify with the server before it can be used.

Proxy-revalidate: similar to must-revalidate, but only valid for the shared cache of the proxy server.

At this point, I believe you have a deeper understanding of "what is the principle of Nginx client caching". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.