服务器 
首页 > 服务器 > 浏览文章

nginx设置资源缓存实战详解

(编辑:jimmy 日期: 2024/11/16 浏览:3 次 )

一直很想学习缓存这一块儿的东西,毕竟前端性能优化缓存在其中占了很大一部分作用。缓存分为两种:强制缓存和协商缓存。看过很多文章讲它们之间的区别,但是没有实战过只知道其意义却不知道怎样去设置,没有实战过也导致记忆总是很模糊,实践才是最好的老师!记录一下我使用nginx服务器学习缓存的过程。

初探

首先我在 nginx 的根目录下新建了一个 index.html 文件以及 index.js 文件。此时 nginx 的配置文件是长这个样子的:

server {
 listen  8080;
 server_name localhost;
 location / {
  root /Volumes/myFile/nginx_root; 
  index index.html index.htm;
 }
}

然后我们浏览器访问 localhost:8080。打开控制台,发现里面有两条请求:

nginx设置资源缓存实战详解

可以看到第一次访问,两条请求的状态码都是 200。我们点开其中一条请求看看响应头信息:

nginx设置资源缓存实战详解

可以看到,响应头中给我们携带了 Etag 以及 Last-Modified 信息。这就是协商缓存所使用的字段嘛。看来 nginx 已经默认给我们使用了缓存。那我们在不修改 html文件以及js文件的基础上再次去刷新页面验证一下,命中协商缓存的话,状态码应该给我们返回 304 Not Modified 。我刷新了几次去观察http请求的状态码。html文件每次都是返回的 304。但是 js 文件在最初是 304 后面却变成了 200 OK (from memory cache) 。也就是说每一次html文件都是命中了协商缓存,而js文件都是命中了强缓存(强缓存的优先级是高于协商缓存的)。为什么会出现这样的情况呢,我百度一下:

为什么有的缓存是 200 OK (from cache),有的缓存是 304 Not Modified 呢?很简单,看是否移除了 Entity Tag。移除了,就总是 200 OK (from cache)。没有移除,就两者会交替出现。

那么,两者触发的时机有什么区别呢?200 OK (from cache) 是直接点击链接访问,输入网址按回车访问也能触发;而 304 Not Modified 是刷新页面时触发,或是设置了强缓存、但 Entity Tags 没有移除时触发。

对照我的例子,我是这样理解的: index.html 文件刷新页面命中协商缓存返回了 304,而 js 文件是在 index.html 文件中链接引入的,所以命中强缓存 200 OK (from cache) 。为了验证我的想法,我用在地址栏直接访问了 index.js 文件。地址栏键入:localhost:8080/index.js,此时的确是返回了 304 给我了,在来看一下此时的请求头:

nginx设置资源缓存实战详解

可以看到此时 Cache-Control 给的是max-age=0;然后也携带上了协商缓存的相关参数。看来在浏览器是刷新操作的时候就会携带上 Cache-Control:max-age=0 以此来避免命中强缓存。

nginx禁用强缓存

在试试 nginx 禁用强缓存之后会发生什么效果。修改 nginx 配置文件:

server {
 listen  8080;
 server_name localhost;
 location / {
  root /Volumes/myFile/nginx_root; 
  index index.html index.htm;
  add_header Cache-Control no-cache;
  # 为 public可以被任何对象缓存,private只能针对个人用户,而不能被代理服务器缓存
  add_header Cache-Control private;
 }
}

修改完 nginx 配置文件之后我们重启一下 nginx 服务器。此时在访问 localhost:8080

nginx设置资源缓存实战详解

可以看到,此时 html 文件和 js文件都是 304 都是命中协商缓存了。

Cache-Control: no-store

禁止一切缓存(这个才是响应不被缓存的意思)。缓存通常会像非缓存代理服务器一样,向客户端转发一条 no-store 响应,然后删除对象。

Cache-Control:no-cache

强制客户端直接向服务器发送请求,也就是说每次请求都必须向服务器发送。服务器接收到请求,然后判断资源是否变更,是则返回新内容,否则返回304,未变更。这个很容易让人产生误解,使人误以为是响应不被缓存。实际上Cache-Control: no-cache是会被缓存的,只不过每次在向客户端(浏览器)提供响应数据时,缓存都要向服务器评估缓存响应的有效性。

其实将 Cache-Control 设置为 no-store 才是真正的不被缓存的意思,那在修改一下 nginx 文件将 Cache-Control 设置为 no-store 看看会发生什么。此时再次刷新浏览器。

nginx设置资源缓存实战详解

可以看到,修改完 nginx 的配置文件之后,除了第一次是304(这次访问浏览器才刚刚接收到 no-store的信息,请求头上还是携带了缓存相关信息) 外,剩下的几次刷新页面都是返回 200了。既没有命中强缓存、也没有命中协商缓存。在看一下 index.js 文件的 http 头信息。

nginx设置资源缓存实战详解

这里的图我没有截完整,其实响应头中还包含了 Cache-Control: no-store 。可以看到,在 Cache-Control: no-store 的加持下,即使在响应头中服务请返回了协商缓存的参数,但是在浏览器在请求资源的时候,并没有带上缓存相关的参数了,所以,现在没有缓存了,既不会命中强缓存,也不会命中协商缓存,每一次http请求的资源都是从服务器上返回的。

结语

这次的探索到现在就结束了,其实就是我一次学习的记录吧。实践了一次之后确实对缓存有了更清晰的理解和认知,果真实践出真知。后续打算还会记录一篇在现在前端使用 React.js 或者 Vue.js 等框架打包之后前端资源如何利用 nginx 做部署还有配置相关缓存的文章,到时候在看有没有记录下来的意义把。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。

上一篇:nginx高可用集群的实现过程
下一篇:Docker部署springboot项目实例解析
一句话新闻
微软与英特尔等合作伙伴联合定义“AI PC”:键盘需配有Copilot物理按键
几个月来,英特尔、微软、AMD和其它厂商都在共同推动“AI PC”的想法,朝着更多的AI功能迈进。在近日,英特尔在台北举行的开发者活动中,也宣布了关于AI PC加速计划、新的PC开发者计划和独立硬件供应商计划。
在此次发布会上,英特尔还发布了全新的全新的酷睿Ultra Meteor Lake NUC开发套件,以及联合微软等合作伙伴联合定义“AI PC”的定义标准。