缓存 HTTP POST请求和响应

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的缓存不仅可以用于Get请求，通过对Post体的摘要、处理非idempotent request请求和区别idempotent request和非idempotent request请求，可以实现对Post的缓存。当然为了进一步提高效率，可以使用缓存握手的方式，在互联网上只发送摘要，在客户端和正向代理以及反向代理和服务端之间的局域网类发送完整的消息体。