经常对于HTTP缓存感到困惑，一遍又一遍。今天，我将以图文形式为你解析HTTP缓存（通俗易懂），让你不再害怕😎
1、HTTP缓存的诞生🥚
- 服务器压力太大 🍐
- 想个折中的办法： HTTP缓存出现，帮助服务器减小很多压力
2、后来出现问题了😭：
1、 服务器更新后，缓存没有更新
2、缓存设置过期时间, Expires的诞生🥚
Expires 响应头包含日期/时间，即在此时候之后，响应过期。
yaml
// 过期时间
Expires: Wed, 21 Oct 2015 07:28:00 GMT
BUT，⚠但Expires不完美，它是服务端返回的，它对比客户端时间，难免会出现不一致，那么资源更新有会出问题， 于是Cacahe-Control登场喽
3、Cacahe-Control 过期时长🐺
Cache-Control 通用消息头字段，被用于在 http 请求和响应中，通过指定指令来实现缓存机制。缓存指令是单向的，这意味着在请求中设置的指令，不一定被包含在响应中。
arduino
Cache-Control:public, max-age=31536000
1、Cache-Control的诞生🥚
但是，随着请求量增大，缓存也超过了时长， 服务器压力又扛不住了，然后就出现了强缓存和协商缓存
2、强缓存 VS 协商缓存
-
强缓存：浏览器不会像服务器发送任何请求，直接从本地缓存中读取文件并返回Status Code: 200 OK
-
协商缓存：向服务器发送请求，服务器会根据这个请求的request header的一些参数来判断是否命中协商缓存，如果命中，则返回304状态码并带上新的response header通知浏览器从缓存中读取资源；
然后详细的协商过程就出现了Last-Modified(最后修改时间)
4、Last-Modified 最后修改时间 🐗
Last-Modified 是一个响应首部，其中包含源头服务器认定的资源做出修改的日期及时间。它通常被用作一个验证器来判断接收到的或者存储的资源是否彼此一致。由于精确度比 ETag 要低，所以这是一个备用机制。
具体流程如下：
又又又出问题了： 有新资源的时候，服务器还返回304状态，因为# If-Modified-Since的值是以秒S为单位的，对于1S之内资源的改变，缓存就得不到得不到更新，然后Etag闪亮✨登场
5、ETag文件内容唯一标识 🐴
ETag HTTP 响应头是资源的特定版本的标识符。这可以让缓存更高效，并节省带宽，因为如果内容没有改变，Web 服务器不需要发送完整的响应。而如果内容发生了变化，使用 ETag 有助于防止资源的同时更新相互覆盖（"空中碰撞"）
3、小结
关于HTTP缓存基本就如下图所示，有了这个逻辑也就不怕再谈HTTP缓存了🤪🤪🤪
