缓存动态内容的反向代理

Question

我在考虑询问软件推荐，但后来我发现这可能是一个太奇怪的请求，需要先澄清一下。

我的观点是：

• 每个响应都包含一个etag
  • 这是内容的哈希
  • 并且全局唯一（具有足够的概率）

  基本上，代理应该包含一个将etag映射到响应内容的缓存。etag从服务器获取，在最常见的情况下，服务器根本不处理响应内容。

  它应该是这样的：代理总是向服务器发送请求，然后

  • 1服务器只返回etag，代理根据它进行查找并
    • 1.1缓存命中，
      • 它从缓存中读取响应数据
      • 并向客户端发送响应
      • 它再次询问服务器，然后
      • 代理将数据存储在其缓存中

      为了简单起见，我省略了if none match头的处理，这一点非常明显。

      我这样做的原因是，最常见的情况1.1可以在服务器中非常高效地实现（使用其缓存映射请求到etag；内容不会缓存在服务器中），因此大多数请求都可以在服务器不处理响应内容的情况下处理。这应该比先从侧缓存中获取内容，然后再为其提供服务要好。

      在案例1.2中，有两个对服务器的请求，这听起来很糟糕，但并不比服务器请求一个侧缓存并没有命中更糟糕。

      问题1：我想知道，如何将第一个请求映射到HTTP。在案例1中，这就像一个头部请求。在第二种情况下，这就像得到。两者之间的决定取决于服务器：如果它可以在不计算内容的情况下提供etag，那么它就是案例1，否则就是案例2。

      问题2：是否有反向代理执行类似操作？我读过关于nginx、HAProxy和Varnish的文章，但事实似乎并非如此。这让我想到问题3：这是个坏主意吗？为什么？

      问题4：如果不是，那么哪种现有代理最容易适应？

      来自用户U1的GET请求（如/曲库/123/item/456）与一些内容C1和etag： 777777一起提供。代理存储在键777777下的C1。

      现在同样的请求来自用户U2。代理转发它，服务器只返回etag： 777777，代理很幸运，在其缓存中找到C1（案例1.1）并将其发送到U2。在这个例子中，客户端和代理都不知道预期的结果。

      有趣的部分是服务器如何在不计算答案的情况下知道etag。例如，它可以有一个规则，说明这种形式的请求为所有用户返回相同的结果，假设给定的用户被允许看到它。因此，当来自U1的请求传来时，它计算了C1并将etag存储在键/曲库/123/item/456下。当相同的请求来自U2时，它只是验证了U2允许查看结果。

Answer 1

问题1：这是一个GET请求。服务器可以在没有正文的情况下回答“304未修改”。

问题2：openresty（带有一些附加模块的nginx）可以做到这一点，但您需要自己实现一些逻辑（请参阅下面更详细的描述）。

问题3：考虑到你问题中的信息，这听起来是个合理的想法。只是一些值得思考的东西：

>

您还可以将页面拆分为可以独立缓存的用户特定和通用部分。

你不应该期望缓存永远保存计算出的响应。因此，如果服务器返回带有etag:777777（根据您的示例）的304 not modified，但缓存不知道它，您应该可以选择强制重新构建答案，例如，使用另一个带有自定义头的请求X-force-recreaculate:true。

不完全是你问题的一部分，但是：确保设置一个适当的Vary标头以防止缓存问题。

如果这只是关于权限，那么您也可以在签名的cookie中使用权限信息。缓存可以在不询问服务器的情况下从cookie获得权限，并且由于签名，cookie是防篡改的。

问题4：我会使用openresty来实现这一点，特别是lua resty redis模块。将缓存的内容放入redis键值html" target="_blank">存储，并将etag作为键。您需要在Lua中编写查找逻辑，但它不应该超过几行。