“永远”和“永远”是唯一有用的缓存持续时间吗？

Question

在Steve Souders（"Cache is King"）的演示文稿at around 14:30中，暗示实际上只有两个缓存持续时间应该用于您的资源：“永远”和“永远”（我自己的术语。）

• “永远”意味着您可以通过设置非常高的最大年龄（例如一年）来有效地使资源永久不变。如果要在某个时刻修改资源，演示文稿建议您只需在不同的URL上发布已修改的资源。 （由于互联网上有大量错误配置的代理，建议部分或全部重命名是必要的。）
• “从不”表示您有效禁用所有形式的缓存，并要求浏览器在每次请求时下载资源。

一方面，谷歌首席执行工程师提供的任何绩效建议都有其自身的重要性。另一方面，HTTP缓存可能设计为具有可变缓存持续时间的原因（不仅仅是“永远”和“从不”），并且仅仅因为资源被修改而将URL更改为资源似乎违背了精神HTTP。

“永远”和“永远”是您在实践中应该使用的唯一缓存持续时间吗？这是否与网络上的其他最佳做法相冲突？

除了典型的“具有浏览器的用户”用例之外，我还想知道这些原则如何应用于REST /超媒体API。

Answer 1

许多人不同意将自己局限于“永远”＃34;或者＆＃34;从不＆＃34;正如你所描述的那样。

首先，它忽略了允许缓存并始终重新验证的选项。在这种情况下，如果客户端（或代理）已缓存资源，则它会发送条件HTTP请求。如果客户端/代理已缓存最新版本的资源，则服务器发送短304响应而不是整个资源。如果客户端（代理）副本已过期，则服务器将发送整个资源。

使用此方案，客户端将始终获得资源的最新版本，如果资源没有更改，则将保存更多带宽。

为了节省更多带宽，可以指示客户端仅在资源超过特定时间段时重新验证。

如果错误的代理是个问题，服务器可以指定只有客户端而不是代理可以缓存资源。

我发现this document非常简洁地描述了您的缓存选项。 This page更长，但也提供了一些很好的信息。

Answer 2

“这取决于”你的用例，你想要实现的目标，以及你的品牌主张。

如果你想要实现的只是一些带宽节省，你可以做一个总成本细分。服务成本可能不会太多。例如，浏览器在优化图像命中方面非常聪明，因此要了解您的HTTP协议。永远，结合版本化资源网址和网址重写规则可能非常合适，就像您的Google工程师建议的那样。

资源波动是另一回事。例如，如果您只提供每日股票图表，它可以安全地缓存一段时间但不是永远。

您的计算成本是否很高？您的用户对及时性是否敏感？数据是实时的还是固定的？例如，您可能正在为COO提供航空公司航线，飓风路径，选项希腊或BI报告。您可能希望将其缓存，但TTL可能会因用户类别而异，从而永远不会。永远不能用于实时数据，但也绝不是错误的答案。

服务器和客户端之间的合作程度可能是另一个因素。例如，在可以分发程序并且希望遵循程序的业务操作环境中，再次查看TTL可能是值得的。

HTH。我怀疑是否有一个神奇的答案。

Answer 3

理想情况下，您会在内容发生变化之前调整缓存，如果在内容因任何原因发生更改时无法清除/刷新缓存，则需要一段时间。但实际上，如果可以，请永久缓存或不缓存。如果您已经知道没有任何改变，则无需刷新。

Answer 4

如果您知道基础数据在任何时间长度内都是静态的，那么缓存是有意义的。我们有一个Web服务，它公开来自数据库的数据，该数据库由来自外部源的夜间ETL作业填充。我们的RESTful Web服务只有在更改时才会进入数据库。在我们的例子中，我们确切地知道数据何时发生变化，并且在ETL过程完成后立即使缓存无效。