欣赏器HTTP缓存解读（HTTP Status：200 & 304）

为什么要有欣赏器缓存？

欣赏器缓存(Brower Caching)是欣赏器对之前哀求过的文件举行缓存，以便下一次访问时重复使用，节流带宽，进步访问速率，低沉服务器压力
http缓存机制重要在http相应头中设定，相应头中相干字段为Expires、Cache-Control、Last-Modified、Etag。
欣赏器缓存从无到有，再到使用缓存的流程：

欣赏器初次哀求，缓存从无到有，缓存文件大概不肯定是从web服务器哀求来的，也大概是从CDN来的，但总而言之第一次肯定是哀求来的

欣赏器对同样的资源发起二次哀求，针对差别资源范例（比如JS文件等等），服务器举行判断

部分静态资源文件，可以判断缓存时长，假如未逾期就可以从当地读取

欣赏器缓存范例

- 强缓存

欣赏器不会向服务器发送任何哀求，直接从当地缓存中读取文件并返回 Status Code: 200 OK
从内存读取，由于速率快于硬盘，以是最优先由内存读取

从硬盘读取，假如内存中没有，就会从硬盘中读取

假如以上两个地方都没有对应的缓存资源，才会去服务器探求对应的缓存资源。
增补一下，在强缓存中，寻常革新会忽略它，但不会扫除它，必要逼迫革新。欣赏器逼迫革新时，哀求会带上Cache-Control:no-cache和Pragma:no-cache，如许就会让欣赏器对资源举行重新哀求。而寻常革新的环境下，部分资源文件（比如js、图片），不会带上no-cache属性，也就是会到服务器举行协商，请注意，这里属性携带的位置均位于哀求头，而相应头是否设置，则取决于欣赏器
- 协商缓存

所谓协商缓存，简单说就是先看看当地缓存逾期没有，没逾期直接用，逾期了去服务器看看当地这个缓存还能不能用，能用就接着用（返回304状态码）。不能用就哀求最新的（返回200状态码）。
协商缓存HTTP Code : 304
服务器会根据这个哀求的request header的一些参数来判断是否掷中协商缓存，假如掷中，则返回304状态码并带上新的response header关照欣赏器从缓存中读取资源；

协商缓存HTTP Code : 200
欣赏器初次哀求，当地没有缓存可用。去服务器哀求缓存，得到200的相应

---

欣赏器针对协商缓存判断流程

比如Get哀求JS文件，哀求头中会加入属性：Last-Modified/If-Modified-Since大概ETag/If-None-Match
Last-Modifed/If-Modified-Since和Etag/If-None-Match是分别成对出现的，呈逐一对应关系
之以是会有这两种属性，是由于前者是HTTP 1.0版本的，后者是HTTP 1.1版本出现的
这两个都是用来判断文件是否必要更新的时间戳大概hash值，服务器收到哀求后，根据这两个属性举行判断，假如哀求的文件没有更新，那么就返回HTTP304的状态码，让欣赏器直接用缓存（Disk or Menmory)。而是否追加这个属性，由欣赏器自行判断

但一样平常像是Ajax的Get、Post（雷同这种的XHR）等，假如欣赏器后端使用代码明确设置了Cache-Control：no-cache的选项，则不会缓存数据，到了服务端就重新哀求数据
也就是no-cache的环境下，必须到服务器举行check，当服务器返回304的时间，才答应使用欣赏器缓存，否则必须哀求新数据

注意：ETag的优先级是优于 Last-Modified＆If-Modified-Since，假如校验Header是ETag+If-None-Match的环境下，就会优先验证ETag的Hash值
怎样选择符合的缓存？

大抵的次序

• Cache-Control —— 哀求服务器之前
  
• Expires —— 哀求服务器之前
  
• If-None-Match (Etag) —— 哀求服务器
  
• If-Modified-Since (Last-Modified) —— 哀求服务器
  协商缓存必要共同强缓存使用，假如不启用强缓存的话，协商缓存根本没故意义
  

大部分web服务器都默认开启协商缓存，而且是同时启用【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】
但是下面的场景必要注意：

• 分布式体系里多台呆板间文件的Last-Modified必须保持划一，以免负载均衡到差别呆板导致比对失败；
  
• 分布式体系只管关闭掉ETag(每台呆板天生的ETag都会不一样）；
  

CDN缓存参考：https://blog.csdn.net/Runnymmede/article/details/138315636
参考文章1：https://juejin.cn/post/6844904153043435533
参考文章2：https://juejin.cn/post/6844903838768431118
参考文章3：https://github.com/amandakelake/blog/issues/41
参考文章4：https://segmentfault.com/a/1190000008956069