HTTP 的缓存代理

Question

之前谈到缓存时，主要讲了客户端（浏览器）上的缓存控制，它能够减少响应时间、节约带宽，提升客户端的用户体验。

但 HTTP 传输链路上，不只是客户端有缓存，服务器上的缓存也是非常有价值的，可以让请求不必走完整个后续处理流程， 就近 获得响应结果。

特别是对于那些 读多写少 的数据，例如突发热点新闻、爆款商品的详情页，一秒钟内可能有成千上万次的请求。即使仅仅缓存数秒钟，也能够把巨大的访问流量挡在外面，让 RPS（request per second）降低好几个数量级，减轻应用服务器的并发压力，对性能的改善是非常显著的。

HTTP 的服务器缓存功能主要由代理服务器来实现（即缓存代理），而源服务器系统内部虽然也经常有各种缓存（如 Memcache、Redis、Varnish 等），但与 HTTP 没有太多关系，所以这里暂且不说

缓存代理服务

我还是沿用 生鲜速递 + 便利店 的比喻，看看缓存代理是怎么回事。

便利店作为超市的代理，生意非常红火，顾客和超市双方都对现状非常满意。但时间一长，超市发现还有进一步提升的空间，因为每次便利店接到顾客的请求后都要专车跑一趟超市，还是挺麻烦的。

干脆这样吧，给便利店配发一个大冰柜。水果海鲜什么的都可以放在冰柜里，只要产品在保鲜期内，就允许顾客直接从冰柜提货。这样便利店就可以一次进货多次出货，省去了超市之间的运输成本。

通过这个比喻，你可以看到：在没有缓存的时候，代理服务器每次都是直接转发客户端和服务器的报文，中间不会存储任何数据，只有最简单的中转功能。

加入了缓存后就不一样了。

代理服务收到源服务器发来的响应数据后需要做两件事。第一个当然是把报文转发给客户端，而第二个就是把报文存入自己的 Cache 里。

下一次再有相同的请求，代理服务器就可以直接发送 304 或者缓存数据，不必再从源服务器那里获取。这样就降低了客户端的等待时间，同时节约了源服务器的网络带宽。

在 HTTP 的缓存体系中，缓存代理的身份十分特殊，它 既是客户端，又是服务器 ，同时也 既不是客户端，又不是服务器 。

说它 即是客户端又是服务器 ，是因为它面向源服务器时是客户端，在面向客户端时又是服务器，所以它即可以用客户端的缓存控制策略也可以用服务器端的缓存控制策略，也就是说它可以同时使用第 20 讲的各种 Cache-Control 属性。

但缓存代理也 即不是客户端又不是服务器 ，因为它只是一个数据的 中转站 ，并不是真正的数据消费者和生产者，所以还需要有一些新的 Cache-Control 属性来对它做特别的约束

源服务器的缓存控制

客户端和代理是不一样的，客户端的缓存只是用户自己使用，而代理的缓存可能会为非常多的客户端提供服务。所以，需要对它的缓存再多一些限制条件。

首先，我们要区分客户端上的缓存和代理上的缓存，可以使用两个新属性 private 和 public 。

private 表示缓存只能在客户端保存，是用户 私有 的，不能放在代理上与别人共享。而 public 的意思就是缓存完全开放，谁都可以存，谁都可以用。

比如你登录论坛，返回的响应报文里用 Set-Cookie 添加了论坛 ID，这就属于私人数据，不能存在代理上。不然，别人访问代理获取了被缓存的响应就麻烦了。

其次，缓存失效后的重新验证也要区分开（即使用条件请求 Last-modified 和 ETag ）， must-revalidate 是只要过期就必须回源服务器验证，而新的 proxy-revalidate 只要求代理的缓存过期后必须验证，客户端不必回源，只验证到代理这个环节就行了。

再次，缓存的生存时间可以使用新的 s-maxage （s 是 share 的意思，注意 maxage 中间没有 - ），只限定在代理上能够存多久，而客户端仍然使用 max_age 。

还有一个代理专用的属性 no-transform 。代理有时候会对缓存下来的数据做一些优化，比如把图片生成 png、webp 等几种格式，方便今后的请求处理，而 no-transform 就会禁止这样做，不许 偷偷摸摸搞小动作 。

这些新的缓存控制属性比较复杂，还是用 便利店冷柜 来举例好理解一些。

水果上贴着标签 private, max-age=5 。这就是说水果不能放进冷柜，必须直接给顾客，保鲜期 5 天，过期了还得去超市重新进货。

冻鱼上贴着标签 public, max-age=5, s-maxage=10 。这个的意思就是可以在冰柜里存 10 天，但顾客那里只能存 5 天，过期了可以来便利店取，只要在 10 天之内就不必再找超市。

排骨上贴着标签 max-age=30, proxy-revalidate, no-transform 。因为缓存默认是 public 的，那么它在便利店和顾客的冰箱里就都可以存 30 天，过期后便利店必须去超市进新货，而且不能擅自把 大排 改成 小排 。

下面的流程图是完整的服务器端缓存控制策略，可以同时控制客户端和代理

源服务器在设置完 Cache-Control 后必须要为报文加上 Last-modified 或 ETag 字段。否则，客户端和代理后面就无法使用条件请求来验证缓存是否有效，也就不会有 304 缓存重定向。

客户端的缓存控制

客户端在 HTTP 缓存体系里要面对的是代理和源服务器，也必须区别对待，这里我就直接上图了，来个 看图说话

max-age、no_store、no_cache 这三个属性，它们也是同样作用于代理和源服务器

关于缓存的生存时间，多了两个新属性 max-stale 和 min-fresh 。

max-stale 的意思是如果代理上的缓存过期了也可以接受，但不能过期太多，超过 x 秒也会不要。 min-fresh 的意思是缓存必须有效，而且必须在 x 秒后依然有效。

比如，草莓上贴着标签 max-age=5 ，现在已经在冰柜里存了 7 天。如果有请求 max-stale=2 ，意思是过期两天也能接受，所以刚好能卖出去。

但要是 min-fresh=1 ，这是绝对不允许过期的，就不会买走。这时如果有另外一个菠萝是 max-age=10 ，那么 7+1<10 ，在一天之后还是新鲜的，所以就能卖出去。

有的时候客户端还会发出一个特别的 only-if-cached 属性，表示只接受代理缓存的数据，不接受源服务器的响应。如果代理上没有缓存或者缓存过期，就应该给客户端返回一个 504（Gateway Timeout）。

小结

• 计算机领域里最常用的性能优化手段是 时空转换 ，也就是 时间换空间 或者 空间换时间 ， HTTP 缓存属于后者；
• 缓存代理是增加了缓存功能的代理服务，缓存源服务器的数据，分发给下游的客户端；
  Cache-Control 字段也可以控制缓存代理，常用的有 private 、 s-maxage 、 no-transform 等，同样必须配合 Last-modified 、 ETag 等字段才能使用；
• 缓存代理有时候也会带来负面影响，缓存不良数据，需要及时刷新或删除