http请求缓存
作者：互联网
http请求缓存总结
多余的话不多说，这篇文章主要梳理一下http缓存的整个过程。
http缓存分为强缓存和协商缓存，强缓存优先于协商缓存，总体的过程如下：
- 浏览器在发送http请求时，先判断是否有缓存，如果有缓存（expires/catche-control1），则判断缓存是否失效，如果没有失效，则直接采用缓存，如果已失效则走协商缓存。（catche-control的不同的值2）
- 协商缓存有2套机制：一个last-Modified+If-Modified-Since模式，另一个是Etag+If-None-Match模式，前者通过文件更新时间来判断是否取缓存，后者通过hash值来判断3。
- 第一次请求时，response header里会携带这些缓存信息，浏览器把这些信息保存在缓存中，第二次请求的时候会携带这些信息。
- 服务器比对信息之后，判断是否命中缓存，命中缓存则返回304，通知客户端取浏览器缓存，没有命中则返回200，把资源重新发给客户端。
看下面的图，会有一个更清晰的认识：
expires是http1.0的产物，存储的是一个时间，表示该缓存的过期时间；catche-control是http1.1的产物，目前浏览器大多支持的是1.1，存储的是一个倒计时，表示多少秒之后过期； ↩︎
private: 客户端可以缓存
public: 客户端和代理服务器都可缓存（对于前端来说public和private是一样的）
max-age=xxx: 缓存的内容将在 xxx 秒后失效
no-cache: 需要使用协商缓存来验证缓存数据
no-store: 所有内容都不会缓存，强制缓存，协商缓存都不会触发 ↩︎last-modified是服务端把文件的最新更新时间返回给客户端，客户端第二次请求时，把这个时间带上，服务根据这个时间与文件的更新时间进行对比，如果不一致，说明文件有更新；
Etag模式是服务端返回一个hash值给前端，文件每次更新都会生成一个新的hash值，同样是对比2个hash值是否一致，如果不一致则说明文件有更新。
俩者的区别：Etag模式优先于lastModified，并且更加精确。因为lastModified精确度是到秒，如果一秒内更新了多次，并不能跟踪到每次更新，如果是负载均衡的服务器，各个服务器生成的Last-Modified也有可能不一致。
参考：
[1]: https://www.cnblogs.com/chenqf/p/6386163.html ↩︎
标签：缓存,hash,请求,协商,更新,http,客户端 来源： https://blog.csdn.net/qq_14996903/article/details/118440624