我们在前两篇的内容中分别学习了缓存和代理，大致了解了缓存有哪些头字段，代理是如何服务于服务器和客户端的，那么把两者结合起来，代理缓存，也就是说代理服务器也可以缓存，当客户端请求数据的时候，未必一定要追溯到源服务器上，代理服务器就可以直接把缓存的数据返回给客户端。并且，HTTP的缓存，大多数其实都是由代理服务器来实现，虽然源服务器也有各种缓存，比如大家可能听过的Redis，还有Memcache、Varnish等等，但是基本上跟HTTP没啥关系.

　　如果没有代理缓存，代理服务器仅仅只是一个中专作用，转发客户端和服务器的豹纹，中间不会存储任何数据。但是一旦给代理加上缓存后，事情就有些变化了。它在转发报文的同时，还要把报文存入自己的Cache里。下一次再有同样的请求，代理服务器就可以自己决断，从自己的缓存中取出数据返回给客户端，就无需再去源服务器获取。这样就降低了用户的等待时间，同时也节约了源服务器的网络带宽.

　　在HTTP的缓存体系中，缓存代理的身份十分特殊，它既是客户端，又是服务器，同时呢，它也既不是客户端，又不是服务器。因为代理面向客户端，就是服务器，面向服务器就表现为客户端，但是实际上代理又只是个中转，并不是真正的数据消费者和生产者，所以我们需要学一些新的Cache-Control属性来对它做些额外的约束.

　　嗯，这些新的属性就是本篇的重点了。建议大家对比着缓存那篇文章来看～ 。

1、源服务器的缓存控制

　　源服务器的缓存控制，额……原谅我重复了一遍标题，在有代理服务器的场景下，它控制了哪些设备或者说终端或者说客户端呢？首先源服务器链路前的所有设备，包括代理服务器，对于源服务器来说都是客户端。那么问题来了，当有多个同样角色的时候，我们要怎么区分它们，针对不同的角色，设置不同的头字段属性呢?

　　我们在缓存那一章所学的Cache-Control的四个属性，对于代理服务器来说也是可以使用的，但是客户端和代理服务器肯定是不一样的，客户端只是自己使用，但是代理服务器，可能会分发给很多客户端使用。所以，第一，我们要做的就是对代理服务器和源服务器的HTTP数据做不同的标识.

　　首先，我们可以使用“ private ”和“ public ”来区分代理服务器和客户端上的缓存。比如像cookie这种私有性很强的数据，只能存储在客户端，不然被黑进了代理获取了用户的私有数据那可是很严重的问题了.

　　还有相对于“ must-revalidate ”是只要缓存过期，就要去源服务器验证，而“ proxy-revalidate ”只要求代理的缓存过期后必须验证，不必回溯到源服务器，只验证代理的缓存就可以了.

　　再次，缓存的生存时间可以使用“ s-maxage ”，其实就是share-maxage的简写，用它来限定在代理上能够存活多久，而客户端扔就使用“ max-age ”.

　　还有一个代理专用的属性，“ no-transform ”。代理有的时候会对缓存下来的数据做一些优化，比如把图片生成如png、webp等各种格式，方便今后的请求，而“no-transform”就会禁止这样的转换.

　　最后，大家一定要注意，源服务器在设置完Cache-Control字段后，必须要为报文加上“Last-Modified”或者“ETag”属性，否则客户端和代理后面就无法使用条件请求来验证缓存是否有效.

　　最后的最后我们基于缓存那一章的流程图，把代理服务器的验证逻辑也加进去.

　　我们仔细来看一下这张图，在缓存失效后的验证节点，如果需要验证的话，会额外的去查看是否是代理缓存，并决定后续是查询代理还是查询源服务器。继而判断中间代理的缓存逻辑，是private还是public。然后继续判断各自路径的maxage.

　　仔细看完这张图后，我们发现，整个验证的核心节点和关键步骤其实是没有什么变化的，只是在判断的节点中额外的加入了是否需要代理的逻辑罢了。大家好好消化，仔细区分.

2、客户端的缓存控制。

　　客户端的缓存控制相比于源服务器的缓存控制，在加入了代理的场景下要相对简单一些。对于客户端来说，代理服务器就是服务器，所以max-age、no-store、no-cache这三个属性，跟面向源服务器时是一样的.

　　但是关于缓存的生存时间，在代理服务器上的约束和条件则多了两个新的属性“ max-stale ”和“ min-fresh ”.

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

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

　　我们还是来看张图巩固下、串联一下这些知识:

  。

　　这张图就是完整的客户端设置缓存约束的判定流程，大家一定要对比着有代理和没代理有啥区别来对照着学习.

3、小结

　　代理服务器可能会在响应报文中加入X-Cache、X-Hit等自定义的头字段，标识缓存是否命中和命中率，方便观察缓存代理的工作情况.

　　另外，大家还记得Vary这个头字段么，我们在之前的章节中学到过，它是内容协商后的结果，相当于报文的一个版本标记，缓存代理必须要存储这些不同的版本，当再收到相同的请求时，代理就会读取缓存里的Vary，对比请求头里的字段判断是否一致，是否可以返回缓存的数据.

　　还有一个“Purge”问题，也就是“缓存清理”，他对于代理也是非常重要的功能，比如：过期的数据、版本老旧、缓存危险数据等等。通常情况下，会使用一个自定义的PURGE方法，来删除对应连接的缓存数据.

　　好啦~到这里，我们学完了缓存代理的相关头字段，其实并不怎么复杂，只是在原有的缓存的头字段的基础上，加上了一些源服务器和客户端设置的头字段属性，让我们得控制缓存的细粒度更精细一些.

　　最后，我再次强调，大家要对比着和缓存那一章节来看图学习.

　　有关于HTTP/1.1的内容基本上就告一段落了。下一篇我们一起去领略一下HTTP/2的风采.

最后此篇关于真正“搞”懂HTTP协议12之缓存代理的文章就讲到这里了,如果你想了解更多关于真正“搞”懂HTTP协议12之缓存代理的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。