英文原文：Caching HTTP POST Requests and Responses

HTTP缓存的基本目的就是使应用执行的更快，更易扩展，但是HTTP缓存通常只适用于idempotent request（可以理解为查询请求，也就是不更新服务端数据的请求），这也就导致了在HTTP的世界里，一般都是对Get请求做缓存，Post请求很少有缓存。

然而，我们有的时候也会遇到一些idempotent request并不能通过Get来实现的时候，例如，搜索API通常会需要很多的参数，尤其是那些拥有很多属性的产品，而这些属性都必须通过参数来传递。 问题来了，如果请求携带的参数超过了GET请求的限制长度怎么办，下面有一些回答：

• 当需要非常多的参数的时候，你可能需要重新评估一些接口的设计，减少一些参数来满足Get的限制。
• 规范中并没有强制性限制，所以我们不应该责备http规范，但是http客户端和服务器会有限制，例如有的支持最大的上限为8k，有的为2k

看到这些，我们发现上面这些回答都不是很满意，他们并没有给出实质的解决方案。

HTTP 缓存基础

在看其他内容之前，让我们来快速看一些http缓存的机制。

HTTP缓存涉及到客户端、代理和服务器。这篇 文章我们将讨论的主要是代理服务器，位于客户端和服务器之间。通常情况下，反向代理部署在服务器附近，正向代理通常离客户端比较近。下图展示了基本的拓扑 结构，正向代理的高速缓存命中节省带宽，并减少往返时间和延迟，反向代理的高速缓存命中降低服务器的负载。

HTTP的协议规范允许满足下列条件中其一的以缓存来响应。

• 缓存的响应与原始服务器的响应是一致的，简而言之就是说代理可以保证缓存的响应和服务器的响应之间的语义等价。
• 到客户端的响应的新鲜度是可以接受的
• 到客户端的响应的新鲜度不可接受，但是附加了合适的警告。

协议中还有更多的关于请求响应头和控制的规范，可以参看：http://tools.ietf.org/html/rfc2616

一个典型的代理服务器缓存idempotent request。该代理获取请求，检查头信息，然后发送到服务器，收到服务器的响应后，检查，如果是可缓存的，则将这个响应以URL为key（会携带一部 分头信息）以响应为内容缓存起来。这种办法对已Get请求很有效，因为反复调用相同的URL将会有相同的响应。代理可以利用idempotent request来缓存get请求。但是对于不是idempotent request的post请求来讲，不能使用URL和头信息来作为key进行缓存，因为响应可能是不同的，相同的URL但是得到了不同的结果。

POST内容摘要

解决办法是将POST的内容（附带一部分头信息），做一个摘要，将摘要附在URL后 面，使用这个来作为缓存的key。换句话说，缓存主键被修改为包括URL以及一些请求体，后续的拥有相同的请求体的请求将会命中缓存。在实践的过程中我添 加了一些头脑保证缓存的唯一性。通常的，虽然我们没有一个标准的推荐算法，如果你使用md5的话，你可以加上Content-MD5作为一个头

现在的问题就是该区分idempotent request的post请求和非idempotent request的post请求了。这里有几种方法可以处理这个问题

• 在代理中配置URL的匹配模式，代理如果匹配到非idempotent request请求就不缓存。
• 在头中添加context-aware以区分不同的请求
• 基于缓存逻辑的一些命名约定，例如API的名称以set、add、delete等开头的就不被缓存。

处理非idempotent request请求

下面我们来解决非idempotent request的问题

当出现下面的任何一种情况的时候，将请求发给原服务器

• 如果URL在“DO NOT CACHE”列表中
• 如果摘要不匹配
• 过了缓存的有效时间
• 任何收到需要重新验证的请求的时候

附加可能已经是过时的内容的警告，以满足规范

允许用户通过客户端的工具关闭代理来直接访问原服务器。

我们使用定制的缓存POST请求的key的方式使用Apache Traffic Server实现了这个解决方案。

优势

这个解决方案提供了下面的好处

• 加快了重复请求的效率，减少了代理到原服务器之间的往返
• 一个用户的请求不仅可以用作缓存该用户的后续请求，其他用户也可共享
• 节省了代理和原服务器之间的带宽

这里有一个请求API响应时间的对比，

无缓存延时:188ms

有缓存延时:90ms

这个解决方案的变种可以用在正向代理和反向代理，甚至两者都用

缓存握手

为了从该解决方案的最大价值，在这个解决方案中，我们在客户端和服务器端部署了正向 代理和反向代理。客户端发送请求到正向代理，代理服务器在高速缓存没有命中的情况下发送请求的摘要到反向代理。反响代理在缓存中查找，如果找到则将请求返 回，所不同的一点是，我们从正向代理到反向代理并不发送完整的请求。服务器向反向代理发送完整的响应，而反向代理只向正向代理发送响应的摘要。由于反向代 理和服务器之间一般是出于同一个局域网中，延迟较小，而正向代理和客户端之间的延迟也比较小，当大量的重复请求发送的时候就能够体会着这种解决方案的优势 了

这个解决方案也可以应用到只有一个代理的两边,代价是客户机或服务器需要改进。在这种情况下,客户端或服务器将不得不发送摘要代替整个主体。与两个代理体系结构中,客户端和服务器保持不变,因此,任何HTTP客户端或服务器可以被优化。POST请求通常是大量的。因为没有代理发送整个请求和整个响应,我们不仅节省带宽也节省涉及到大量的请求和响应的响应时间。尽管这些节省可能看起来微不足道,对于真正的传输负载它们不是那么频繁。正如我们所见,即便POST响应不缓存,我们仍然节省带宽通过不发送有效负载。这个解决方案变得更加有趣和分布式缓存部署在网络。

优势

这里是一个缓存握手拓扑的好处:如果有一个缓存失效，请求将有效负载传输到反向代理缓存。因此,RTT和带宽都需要改进。这同样适用于响应。作为一个托管解决方案,一个请求将帮助节省其他用户请求传输到代理。没有涉及到债务技术。如果你删除代理,你有一个完全http兼容的解决方案。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务