HTTP 缓存

1. 前言

大部分云服务器提供的最小带宽是 1Mbit/s（不要钱的），传输 1mb 的一个资源，响应需要 8s。

因此本机或者上游代理做缓存，会减少我们对原始服务器的请求，减少冗余数据传输，降低了时延。当然，把钱也给省了不少（做 CDN 的话）

2. HTTP 缓存控制

关于缓存命中和未命中，缓存使用机制的问题。通过以下 HTTP 头部字段控制。
缓存处理步骤：

（1）接收--缓存从网络中读取抵达的请求报文

（2）解析--缓存对报文进行解析，提取 URL 和各种首部

（3）查询--缓存查看本地是否有副本可用，如果没有，就获取一份副本（保存在本地）

（4）新鲜度检测--查询服务器资源本地副本是否足够新鲜，不足则再验证

（5）创建响应--缓存会用新的首部和已缓存主体来构建一条响应报文

（6）发送--缓存通过网络将响应发回客户端

（7）日志--缓存可选地创建一个日志描述这个事务

1. Last-Modified 和 If-Modified-Since

   1. 第一次请求资源：无副本
   2. 服务器响应 200，携带头部字段 Last-Modified = x，存入缓存
   3. 缓存资源提供给客户端
   4. 第二次请求资源，携带头部字段 If-Modified-Since = x
   5. 查询本地资源副本是否足够新鲜（Cache-Control 默认不新鲜），需要再验证
   6. 验证通过，返回 304；验证不通过，相当于第一次请求资源返回 200
   
   附注：Last-Modified 和 If-Modified-Since 字段值的日期格式为 GMT
   

2. Etag 和 If-None-Match

   1. 第一次请求资源：无副本
   2. 服务器响应 200，携带头部字段 Etag = x，存入缓存
   3. 缓存资源提供给客户端
   4. 第二次请求资源，携带头部字段 If-None-Match = x
   5. 查询本地资源副本是否足够新鲜（Cache-Control 默认不新鲜），需要再验证
   6. 验证通过，返回 304；验证不通过，相当于第一次请求资源返回 200
   

3. 实体标签和最后修改日期都提供

   HTTP/1.1 缓存服务器收到的请求既带有 If-Modified-Since, 又带有实体标签条件首部，那么
   只有当这两个条件都符合时，才能返回 304 响应
   

4. Cache-Control

   1. no-store
   不做缓存
   2. no-cache（默认）
   做缓存，但是不信任缓存，需要再验证
   3. public/private max-age
   做缓存，信任缓存，超出信任的 max-age 时间，需要再验证 
   
   附注：no-cache 和 max-age 需要和实体标签、最后修改日期配合使用
   

3. 参考

[HTTP 权威指南第 7 章](HTTP 权威指南)