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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。