这次文章为了理解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, 而是二者同存呢?
强缓存和协商缓存的优先级验证
图中咱们能够看出第一次刷新进行了强缓存, 强缓存过期后, 浏览器携带字段向服务器进行协商缓存
缓存流程图
喜爱该文章的话能够点个赞哦, 这是我创作的能源哈
相干文章
浏览器缓存机制