nginx 与 浏览器缓存

一、本地静态文件

location /html/{
    rewrite ^(html/.*)$  /$1 break;
    root /data/static;
    expires 12h;
    etag off;
    if_modified_since before;
}

效果：

第一次请求页面时，没有last-modified参数， 返回200

第二次请求时，有last-modified参数， 返回 304

304 缓存通常是使用 ETag/If-None-Match 或 Last-Modifed/If-Modified-Since，而这两个头的处理都是 nginx 自带支持的。

在 nginx 中有 etag 和 if_modified_since 两个指令用于配置这两个东西，而且它们都是默认开启的。

if_modified_since :

off 是关闭。exact 是默认值，严格匹配时间，只要有变化，无论如何变化都算变化。而 before 的取值会将两个时间做比较，只有当服务器的文件比客户端新时才会更新。

这里有一个值得思考的问题，客户端的文件版本什么情况下才会别服务器还新？一种情况是服务器是一个集群，更新文件时部分服务器先生效，用户访

问新的服务器后又去访问旧的服务器，所以客户端的资源版本比服务器端还新。如果是为了解决这个问题，使用 before 确实更好。这样客户端就不会

因为服务器资源不同步而来回切换自己缓存的资源，造成传输冗余。但并不是 before 就比 exact 好，考虑到代码可能回滚，如果使用 before 的话，

一旦客户端缓存了新版有 Bug 的程序，服务器即使回滚代码，由于请求时的 Last-Modified 比服务器还新，服务器依然会 304。这可能导致回滚无

法生效的情况。当然，这个问题是可以解决的。因为回滚代码未必是使用旧的文件，或者如果真觉得有问题甚至可以在回滚后把所有资源文件 touch

一下来更新 Last-Modified。所以综合上述，如果代码发布和回滚都处于我可控的范围内，我会更倾向于用 before。

二。缓存静态文件

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
server {
    location / {
        proxy_cache my_cache;
        proxy_cache_revalidate on;
        proxy_cache_min_uses 3;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
        proxy_cache_lock on;
        proxy_pass http://upstream;
    }
}

这些命令配置了下列的行为：

1. proxy_cache_revalidate 指示 Nginx 在刷新来自服务器的内容时使用 GET 请求。如果客户端的请求项已经被缓存过了，但是在缓存控制头部中定

义为过期，那么 Nginx 就会在 GET 请求中包含 If-Modified-Since 字段，发送至服务器端。这项配置可以节约带宽，因为对于 Nginx 已经缓存过

的文件，服务器只会在该文件请求头中 Last-Modified 记录的时间内被修改时才将全部文件一起发送。

2. proxy_cache_min_uses 该指令设置同一链接请求达到几次即被缓存，默认值为 1 。当缓存不断被填满时，这项设置便十分有用，因为这确保了只

有那些被经常访问的内容会被缓存。

3. proxy_cache_use_stale 中的 updating 参数告知 Nginx 在客户端请求的项目的更新正在原服务器中下载时发送旧内容，而不是向服务器转发重

复的请求。第一个请求陈旧文件的用户不得不等待文件在原服务器中更新完毕。陈旧的文件会返回给随后的请求直到更新后的文件被全部下载。

4. proxy_cache_lock 被启用时，当多个客户端请求一个缓存中不存在的文件（MISS），只有这些请求中的第一个被允许发送至服务器。其他请求在第

一个请求得到满意结果之后在缓存中得到文件。如果不启用 proxy_cache_lock，则所有在缓存中找不到文件的请求都会直接与服务器通信。

乐得技术：

浏览器缓存 和 webpack 配置