Http协议：Http缓存
这篇文章讨论了HTTP缓存中的Cookie和Session的区别及其有效性检查方法。Cookie作为客户端的临时存储，有效期较长；而Session作为服务器的一次会话存储，则有较短的有效期以减少资源消耗。文章介绍了两种替换方案：强制不检查的有效期（无法同步更新）与协商式检查（基于Last-Modify/If-Modify-Since或Etag/If-None-Match），并通过详细流程说明如何在请求前进行有效的缓存验证与更新同步。总结指出HTTP缓存的关键在于确保客户端与服务器的数据保持一致更新。
文章目录
-
- Cookie和Session
- 缓存有效性检查
- 整体流程
- 总结
Cookie和Session
Cookie
客户端的缓存
Session
服务端的缓存，存储服务器与客户端一次会话的过程中的数据/资源
两者区别
是服务端与客户端的不同需求造成的
有效期
Cookie的有效期很长，Session的较短
原因：相较于客户端而言，服务端的数据访问量庞大得多；服务端无法实现对某个特定访问数据的短暂保存。
存储数据的大小
Cookie保存的数据不超过4K，Session不止
Session 负责在一个会话周期内存储与该会话相关的数据包，而 Cookie 则用于记录并传递处理后的最终信息
存储数据的类型
Cookie保存ASCII类型数据，Session保存任意数据类型
流程
- 第一次请求时，在服务器端会生成一个Session。随后，在浏览器中生成Cookie并存储SessionID值，并将域名与Cookie进行对应关系的绑定。
- 在第二次请求时，在浏览器中查找已有映射关系库中的对应信息。如果发现存在对应的Cookie记录，则将该Cookie的数据传递给服务端进行处理；服务端接收到数据后会解析其中包含的SessionID值，并成功读取对应的Session信息。
缓存有效性检查
定义
客户端使用缓存，首先要去服务端进行缓存有效性检查
客户端缓存与服务端的数据如何保持同步的解决方案
缓存方案：是否进行缓存有效性检查
强制缓存：不进行缓存有效性检查
流程
1.第一次请求响应
响应中带有Expires或Cache-Control，标识有效期，客户端创建缓存并在缓存中记录有效期
不同版本的不同响应参数：
HTTP1.0： Expires
HTTP1.1： Cache-Control:max-age取代Expires
2.以后的请求
仅需判断缓存的存在及其有效性。若超出有效期，则需发起新的请求。当缓存处于有效状态时，则无需发起请求即可返回缓存。
优点
更有效的减少发起请求的次数，提高缓存的使用率
缺点
无法同步更新服务端的数据与客户端的缓存
协商缓存(对比缓存)：进行缓存有效性检查
Last-Modify / If-Modify-Since
流程
首次应答时，在服务端返回的数据中包含Last-Modify字段以指示最后修改日期；随后，在客户端创建缓存并记录这一修改时间。
在后续每一次发起请求时，在客户端发送包含If-Modify-Since字段的数据。
当服务端接收到请求后会自主评估客户端缓存的有效性：
如果存在有效性，则返回状态码304以及没有实体的内容；
否则，则返回最新的资源信息。
ETag/If-None-Match
类似Last-Modify/If-Modify-Since
整体流程
1.发起请求前，检查是否有缓存，没有缓存，发起请求
如果存在缓存项，则需要执行以下操作：首先获取该缓存项的有效期时间；接着判断该缓存项是否已过期；如果已经过期，则应发送新的请求以获取新数据；反之，则将结果直接返回。
若缓存无时长限制，则核查是否存在Etag字段，并在确认后向API发起HTTP请求。
当缓存中不存在Etag记录时,首先验证缓存是否存在Last-Modified字段。若检测到该字段存在,则需发起响应,并在响应头字段中包含If-Modified-Since头。
5.如果缓存中没有记录Last-Modified，发送请求
总结
http缓存重要问题在于如何实现客户端与服务端的数据同步更新问题