浏览器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