Nginx caching mechanism explained in detail! Very detailed and practical

Nginx caching, as an important means of performance optimization, can greatly reduce the load on the back-end server. Below we will introduce the relevant instructions of Nginx caching configuration and http caching mechanism, as well as Nginx caching practice case analysis.

Nginx cache example

Example demonstration, how does the cache appear, how to check it!

When we open a website, such as baidu.com, we can see that some js in the size column are identified as disk cache, which is applied to the cache here.

HTTP caching mechanism

The HTTP caching process is shown in the figure below

Cache can be divided into mandatory cache and contrast cache .

Nginx forced caching

What is mandatory caching? And the configuration parameters that may cause this!

The browser does not send any request to the server, it directly reads the cached data from the local cache and returns a 200 status code, as shown in the figure below. If the cache expires and then find the server, the process is as follows:

The fields that can cause forced caching are as follows:

Expires

Location: HTTP Response Header

Explanation: Expires is the expiration time returned by the server. If the next request is less than the expiration time returned by the server, the cached data will be used directly. Expires is an HTTP1.0 thing, and now browsers use HTTP1.1 by default. And because the value is generated by the server, the time of the client and the time of the server may be inconsistent, resulting in a certain error. So HTTP1.1 uses Cache-Control instead.

# 示例
Expires: Mon, 22 Jul 2019 11:08:59 GMT

Cache-Control

Location: HTTP Response Header

Description: Cache policy definition

• max-age: Identifies the maximum time that the resource can be cached
• public: Indicates that the response can be cached by any middleman, including the client and proxy server
• private: Indicates that the response can only be used in the browser's private cache, and the middleman (proxy server) cannot cache this response
• no-cache: Need to use contrast cache (Last-Modified/If-Modified-Since/Etag/If-None-Match) to verify cached data
• no-store: All content will not be cached, neither forced cache nor comparison cache will be triggered

Nginx vs. caching

Introduce the difference and comparison between using cache and not using cache!

When the browser requests data for the first time, the server returns the cached identifier and the data to the browser, and the browser caches the two in the local cache database.

When the data is requested again, it will be sent to the server with the cached identifier in the request header. The server will compare the cached identifiers. If there is a change, it will return a 200 status code and return the complete response data to the browser. If no update occurs, The 304 status code is returned to tell the browser to continue using the cached data.

As shown in the comparison below, the cache is not used in the first request. When the cache is used for the second time, it is obvious that the request time of the two is different, and the time of the latter is much less. This is because if the server finds that it is not updated after the cache comparison, it only returns the header part and returns a 304 status code to inform the client to use the local cache, and does not return the body part of the message to the browser, so the request time and message size It is obviously optimized. Don't underestimate these tens of milliseconds. When the traffic is very large, a lot of time has been optimized here and a lot of server pressure has been reduced.

First visit, cache is not used:

For the second visit, use the cache:

The HTTP request and response message structure is shown in the figure below:

The fields that will cause the comparison cache are as follows:

• Last-Modified

  • Location: HTTP Response Header

  • Explanation: When the first request is made, the server will set this parameter in the response header to tell the browser the last modification time of the resource.

    # 示例
    Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT

• If-Modified-Since

  • Location: HTTP Request Header
  • Explanation: When requesting the server again (not the first time), the client browser uses this field to notify the server of the last modification time of the resource returned by the server during the last request. After the server receives the request, it finds the If-Modified-Since field in the header, and compares it with the last modification time of the requested resource. If the last modification time of the resource is greater than If-Modified-Since, it means that the resource has been modified, and the response will return the complete content with a status code of 200. If the last modification time of the resource is less than or equal to If-Modified-Since, the resource has not been modified, and a 304 status code is returned to tell the browser to continue using the saved cached data.
• Etag

• Location: HTTP Response Header

  • Explanation: When the server responds to the request, it tells the browser the unique identifier of the current resource on the server (generated by the server).
  • Priority: higher than Last-Modified and If-Modified-Since

• If-None-Match

  • Location: HTTP Request Header
  • Explanation: When requesting the server again, use this field to notify the server of the unique identifier of the resource cached by the client. The server finds the If-None-Match field in the week after receiving the request header, and compares it with the unique identifier of the requested resource. If they are not the same, indicating that the resource has been modified, a complete response will be returned with a status code of 200. If it is the same, indicating that the resource has not been modified, it returns a 304 status code to tell the browser to continue using the cached data.

Nginx caching practice

Actually configure and demonstrate the effect of using the cache!

The content of the configuration file is as follows:

nginx
user  nginx;
pid /run/nginx.pid;
worker_processes  auto;
worker_rlimit_nofile 100000;

events {
    worker_connections  2048;
    multi_accept on;
}

http {
    sendfile on;

    access_log off;
    error_log  /data/log/nginx-1.0/error.log  error;

    proxy_cache_path /data/nginx-1.0/cache levels=1:2 keys_zone=cache_zone:10m inactive=60m;

    server {
        listen 80;
        server_name localhost;
        root /usr/local/services/nginx-1.0/html/;

        location / {

        }

        location ~.*\.(gif|jpg|png|css|js)(.*) {
            proxy_cache cache_zone;
            proxy_cache_valid 200 302 24h;
            expires 1d;
            add_header X-Proxy-Cache $upstream_cache_status;
        }
    }
}

The actual test situation is as follows:

[root@VM_16_4_centos conf]# curl -I http://localhost/test.js
HTTP/1.1 200 OK
Server: nginx/1.14.0
Date: Sun, 21 Jul 2019 12:35:06 GMT
Content-Type: text/plain
Content-Length: 12
Last-Modified: Sun, 21 Jul 2019 12:33:32 GMT
Connection: keep-alive
ETag: "5d345b9c-c"
Expires: Mon, 22 Jul 2019 12:35:06 GMT
Cache-Control: max-age=86400
Accept-Ranges: bytes

Let's take the picture as an example. When we requested http://localhost/google_logo.jpg for the first time, the server returned the unique identifier of the resource Etag to us.

When we requested the second time, we could find that the size of the http message and the response practice were greatly reduced, indicating that our cache sent back the effect.

Author: Escape
Link: escapelife.site/posts/b167e14a.html