preface
- Nginx.conf is applicable to front-end microservices in the cloud native architecture
- Applicable to the front-end responsible for web Nginx related configuration
- For those of you who want to know about negotiated caching
The target of the cache operation
Although HTTP caching is not required, it is often necessary to reuse cached resources. However, common HTTP caches store only GET responses, not other types of responses. The key to caching is the Request Method and the target URI (usually only GET requests are cached). Common cache cases:
- A successful response to a retrieval request: for
GET
Request, response status code is:200
Is successful. A response that contains, for example, an HTML document, image, or file. - Permanent redirection: Response status code:
301
. - Error response: Response status code:
404
A page of. - Incomplete response: Response status code
206
Returns only partial information. - In addition to
GET
If the request matches the response as a defined cache key name.
Cache-control
头
The cache-control header defined in HTTP/1.1 is used to distinguish between support for caching mechanisms, and is supported by both request and response headers. Caching policies are defined by the different values it provides.
There is no cache
Nothing about client requests and server responses can be stored in the cache. The complete response is downloaded for each request initiated by the client.
Cache-Control: no-store
Copy the code
Cache but revalidate
The following header definition, this way, every time a request, will cache the request to the server (translator note: the request should be with a local cache related validation field), the server will verify the request described in the cache is outdated, if has not expired (note: the actual return 304), the cache to use the local cached copy.
Cache-Control: no-cache
Copy the code
Private and public caches
The “public” directive indicates that the response can be cached by any middleman (intermediate proxy, CDN, etc.). If “public” is specified, pages that are not normally cached by middlemen (such as pages with HTTP authentication information (account password) or some specific status code) will be cached by middlemen.
“Private” means that the response is dedicated to a single user, the middleman cannot cache the response, and the response can only be applied to the browser’s private cache.
Cache-Control: private
Cache-Control: public
Copy the code
overdue
The most important instruction in the expiration mechanism is “max-age=
“, which indicates the maximum amount of time a resource can be cached (kept fresh). In contrast to Expires, max-age is the number of seconds since the request was initiated. For files that do not change in an application, you can manually set the duration to ensure that the cache is valid, such as static resources such as images, CSS, and JS.
Cache-Control: max-age=31536000
Copy the code
Verify the way
When the “must-revalidate” directive is used, it means that when the cache considers using an obsolete resource, its state must be verified and the expired cache will not be used. See more about cache validation below.
Cache-Control: must-revalidate
Copy the code
Expires
The Expires response header contains the date/time after which the response Expires.
An invalid date, such as 0, represents a past date, meaning that the resource has expired.
If a “max-age” or “s-max-age” directive is set in the cache-control response header, the Expires header is ignored.
Cache validation
Cache validation starts when the user hits the refresh button. If the cached response header contains a “cache-control: must-revalidate” definition, the Cache validation will also be triggered during browsing. In addition, setting Advanced->Cache to force validation caching in browser preferences can achieve the same effect.
When a cached document expires, you need to validate the cache or retrieve resources. Validation occurs only if the server returns a strong or weak validator.
ETags
As a strong validator for the cache, the ETag response header is a value that is opaque to the User Agent (UA). For HTTP UAs like browsers, you don’t know what ETag stands for, and you can’t predict what its value will be. If the resource request has an ETag in the response header, the client can apply if-none-match headers to subsequent requests to verify the cache.
The last-Modified response header can serve as a weak validator. Weak because it can only be accurate to one second. If the response header contains this information, the client can validate the cache with if-modified-since on subsequent requests.
When a request is made to the server for cache validation, the server returns either 200 OK indicating a normal result or 304 Not Modified indicating that the browser can use the local cache file. The 304 response header can also update the expiration time of cached documents.
Strong cache
Strong caching can be implemented through Expires or cache-control
We usually just set the HTML to strong cache -1
Cache-Control
server {
listen 8001;
server_name localhost;
+ add_header Cache-Control no-store;location / { ... }... }Copy the code
Expires
server {
listen 8001;
server_name localhost;
+ expires -1;location / { ... }... }Copy the code
Negotiate the cache
We can implement strong Cache Settings through cache-control
Static resources, such as JAVASCRIPT and CSS, are set to be cached by any object (including the client sending the request, proxy server, etc.)
server {
listen 8001;
server_name localhost;
location / {
+ if ($request_uri ~* .*[.](js|css|map|jpg|png|svg|ico)$) {
+ # Non-HTML cache for 1 month
+ add_header Cache-Control "public, max-age=2592000";
+}
+ if ($request_filename ~* ^.*[.](html|htm)$) {
+ # HTML files use a negotiated cache
+ add_header Cache-Control "public, no-cache";
+}. }... }Copy the code
As can be seen from the following figure, HTML will go to the server every time the latest resources, JS, CSS go to the negotiation cache