共计 1541 个字符，预计需要花费 4 分钟才能阅读完成。
这次文章为了理解 http 缓存的机制, 本人搭建 nginx 和设置 nginx 配置
网上的文章其实有很多, 然而大部分都是文字表白, 缓存这块又比拟偏差实践, 导致我一开始也是云里雾里的
所以这次我通过截图和步骤图来阐明, 并且进行文字补充, 不喜爱看文字的话其实看图片就行啦
以下每次截图都是无痕模式的
强缓存和协商缓存
在这之前咱们想要先理解强缓存和协商缓存:
强缓存 : 不会向服务器发送申请，间接从缓存中读取资源 ，在 chrome 控制台的 Network 选项中能够看到该申请返回 200 的状态码，并且 Size 显示 from disk cache 或 from memory cache。 通常 cache-control 和Expires的属性进行配置
协商缓存 : 强制缓存 生效 后，浏览器携带缓存标识向服务器发动申请，由 服务器依据缓存标识决定 是否应用缓存的过程; 通常 Last-Modified 和ETag进行验证, 返回304 not modified 状态码
强缓存(cache-control)
max-age
我在 nginx 中敞开了协商缓存, 并且 nginx 的 sever 配置中增加 Expires @15h13m; (@15h13m 为每天 15 点 13 分缓存刷新 )
在 nginx 中设置了 Expires, 而服务器返回的response headers 携带了 cache-control: max-age 的字段和 Expires 的字段, 其实两个缓存指向 同一时间点 刷新
咱们能够看到在规定的工夫内浏览器刷新页面会触发缓存, 过期后则从新申请
no-cache(敞开 etag 和 Last-Modified)
no-cache: 缓存须要向服务器验证;
当咱们开启了 no-cache, 浏览器没有缓存的状况下, 向服务器进行协商缓存, 然而咱们敞开了协商缓存的etag 和Last-Modified, 所以申请从新发送
no-store(开启 Etag 和 Last-Modified)
no-store: 这个字段就是通知浏览器不进行缓存
协商缓存
Last-Modified 和 f -Modified-Since(敞开 Etag)
浏览器在第一次拜访资源时，服务器返回资源的同时，在 response header 中增加 Last-Modified 的 header，值是这个资源在服务器上的最初批改工夫，浏览器接管后缓存文件和 header；
比方:
Last-Modified: Fri, 23 Oct 2020 07:33:48 GMT那么下一次申请, 浏览器将携带 Last-Modified 的值到 If-Modified-Since, 并且放在request headers 中进行缓存验证
服务器会依据 If-Modified-Since 值与服务器中这个资源的最初批改工夫 比照
如果没有变动 ，返回 304 和空的响应体，间接从缓存读取
如果 If-Modified-Since 小于服务器的最初批改工夫，阐明文件有更新，于是返回新的资源文件和 200
Last-Modified 存在的弊病:
- 即便没有对文件进行批改，但还是会造成 Last-Modified 被批改，服务端不能命中缓存导致发送雷同的资源
- Last-Modified 只能以秒计时, 秒以下的工夫内进行批改无奈感知, 返回谬误的资源
协商缓存 ETag 和 If-None-Match(敞开 Last-Modified)
协商缓存 ETag 跟Last-Modified相似, 不过 etag 是算法生成的字符串
etag解决 Last-Modified 存在的问题, 那么为什么服务器不间接全副应用 etag 而淘汰 Last-Modified, 而是二者同存呢?
强缓存和协商缓存的优先级验证
图中咱们能够看出第一次刷新进行了强缓存, 强缓存过期后, 浏览器携带字段向服务器进行协商缓存
缓存流程图
喜爱该文章的话能够点个赞哦, 这是我创作的能源哈
相干文章
浏览器缓存机制
