智能内容缓存是改善网站访问者体验的最有效方法之一。 缓存或临时存储来自先前请求的内容是在HTTP协议内实现的核心内容递送策略的一部分。 整个传递路径中的组件可以全部缓存项目,以加速后续请求,服从为内容声明的缓存策略。
在本指南中,我们将讨论Web内容缓存的一些基本概念。 这将主要涵盖如何选择缓存策略,以确保Internet上的缓存可以正确处理您的内容。 我们将讨论缓存提供的好处,需要注意的副作用,以及采用不同的策略来提供性能和灵活性的最佳组合。
缓存是存储可重用响应的术语,以便使后续请求更快。 有许多不同类型的缓存可用,每个都有自己的特点。 应用程序高速缓存和存储器高速缓存都是受欢迎的,因为它们能够加速某些响应。
Web缓存,本指南的重点,是一种不同类型的缓存。 Web缓存是HTTP协议的核心设计特征,旨在最小化网络流量,同时提高系统整体的感知响应速度。 在从原始服务器到浏览器的内容的每个级别都找到高速缓存。
Web缓存通过根据特定规则缓存请求的HTTP响应来工作。 然后可以从更接近用户的缓存中完成缓存内容的后续请求,而不是将请求一直发送回web服务器。
有效的缓存有助于内容消费者和内容提供商。 缓存带来的内容交付的一些好处是:
在处理缓存时,有几个可能会遇到的可能不熟悉的术语。 一些更常见的如下:
有很多其他缓存术语,但上面的那些应该可以帮助你开始。
某些内容比其他内容更容易缓存。 一些非常缓存友好的内容对于大多数网站是:
这些往往很少改变,所以他们可以受益于缓存更长的时间。
在缓存中必须小心的一些项目是:
几乎从不缓存的一些项目是:
除了上述一般规则之外,还可以指定允许您适当缓存不同类型内容的策略。 例如,如果已通过身份验证的用户都看到您网站的相同视图,则可以在任何位置缓存该视图。 如果已通过身份验证的用户看到网站的用户敏感视图将在一段时间内有效,您可以告诉用户的浏览器缓存,但告诉任何中间缓存不要存储视图。
内容可以在整个交付链中的许多不同点缓存:
这些位置中的每一个可以并且通常根据它们自己的高速缓存策略和在内容源处设置的策略来高速缓存项目。
缓存策略依赖于两个不同的因素。 缓存实体本身决定是否缓存可接受的内容。 它可以决定缓存少于允许缓存,但永远不会更多。
大多数缓存行为由缓存策略确定,缓存策略由内容所有者设置。 这些策略主要通过使用特定的HTTP头来表达。
通过HTTP协议的各种迭代,几个不同的缓存聚焦头部出现了不同级别的复杂性。 你可能还需要注意的那些如下:
Expires
:本Expires
头是非常直接的,虽然在范围相当有限。 基本上,它设置了未来内容将过期的时间。 在这一点上,对相同内容的任何请求将必须返回到源服务器。 这个标题可能最好只用作后退。 Cache-Control
:这是更现代更换为Expires
头。 它被很好地支持,并实现了更灵活的设计。 在几乎所有情况下,这是最好Expires
,但它可能不会伤害同时设置值。 我们将讨论您可以设置的选项具体Cache-Control
稍后。 Etag
:本Etag
头用于缓存验证。 来源可以提供独特的Etag
一个项目时,它最初提供的内容。 当高速缓存需要验证它手头到期后的内容,它可以发送回Etag
它的内容。 原点要么告诉缓存该内容是相同的,或发送更新的内容(具有新的Etag
)。 Last-Modified
:此标头指定该项目被修改的最后一次。 这可以用作确认新内容的验证策略的一部分。 Content-Length
:虽然没有具体参与缓存的Content-Length
的头是很重要的定义缓存策略时设置。 某些软件将拒绝缓存内容,如果它不知道高级内容的大小,它将需要预留空间。 Vary
:一个高速缓存通常使用的请求的主机和路径对资源与其中存储高速缓存项的键。 该Vary
头可以用来告诉缓存决定请求是否是同一项目时,要注意额外的头。 这是最常用的告诉由缓存关键的Accept-Encoding
头为好,这样缓存就知道了压缩和非压缩的内容之间的差异。 该Vary
头为您提供存储不同版本的同一内容在高速缓存中稀释项费用的能力。
在的情况下, Accept-Encoding
,设置Vary
头允许一个关键区别采取压缩和非压缩内容之间的地方。 这是需要正确地服务这些项目到不能处理压缩内容的浏览器,是必要的,以提供基本的可用性。 告诉你一个特点Accept-Encoding
可能是一个很好的候选人Vary
是它只有两个或三个可能的值。
像项目User-Agent
乍一看似乎是移动和桌面浏览器之间的区别来服务不同版本的网站的一个好办法。 然而,由于User-Agent
字符串是非标准的,其结果很可能会在中介缓存相同内容的多个版本,以非常低的缓存命中率。 该Vary
头应谨慎使用,特别是如果你没有正常化您控制中间缓存的要求(这是可能的,举例来说,如果你利用内容分发网络)的能力。
上面我们提到的如何Cache-Control
头被用于现代高速缓存策略规范。 可以使用此报头设置多个不同的策略指令,多个指令由逗号分隔。
一些Cache-Control
你可以用它来决定你的内容的缓存策略选项是:
no-cache
:该指令规定,任何缓存的内容必须在每个请求重新验证被送达给客户端之前。 这实际上将内容标记为立即失效,但允许它使用重新验证技术,以避免重新下载整个项目。 no-store
:该指令指示该内容不能以任何方式被缓存。 这适合于设置如果响应表示敏感数据。 public
:这标志着内容作为公开的,这意味着它可以由浏览器和任何中间缓存被缓存。 对于使用HTTP认证请求,响应标志着private
默认。 此标头覆盖该设置。 private
:这标志着内容为private
。 私人内容可由用户的浏览器被储存,但必须不被任何中间方被高速缓存。 这通常用于特定于用户的数据。 max-age
:该设置配置之前,必须重新验证或重新下载从源服务器的内容的内容可能会被缓存的最大年龄。 在本质上,这取代了Expires
现代浏览头和用于确定一块内容的新鲜度的基础。 此选项的值为秒,最大有效新鲜时间为一年(31536000秒)。 s-maxage
:这是非常相似的max-age
设置,因为它表明该内容可以被高速缓存的时间量。 区别在于,此选项仅适用于中间高速缓存。 将这与上述相结合允许更灵活的策略构造。 must-revalidate
:这表明,所指示的新鲜信息max-age
, s-maxage
或Expires
头必须严格遵守。 过时的内容无法在任何情况下提供。 这防止在网络中断和类似情况下使用缓存的内容。 proxy-revalidate
:该操作与上述相同的设置,但只适用于中介代理。 在这种情况下,用户的浏览器可以潜在地用于在网络中断的情况下提供陈旧的内容,但是中间高速缓存不能用于此目的。 no-transform
:这个选项告诉缓存,他们不允许修改在任何情况下性能的原因接收到的内容。 这意味着,例如,缓存不能发送它没有从源服务器接收的压缩版本的内容,并且不被允许。 这些可以以不同的方式组合以实现各种缓存行为。 一些互斥值是:
no-cache
, no-store
,和普通缓存行为由没有任何表示 public
和private
在no-store
选项取代了no-cache
如果两者都存在。 对于未经身份验证的请求的响应, public
是隐含的。 对于通过身份验证的请求的响应, private
是隐含的。 这些可以通过在相反的选项覆盖Cache-Control
头。
在一个完美的世界中,一切都可以被积极地缓存,并且只会联系您的服务器来偶尔验证内容。 这在实践中通常不会发生,所以你应该尝试设置一些完全缓存策略,旨在实现长期缓存和响应变化的网站的需求之间取得平衡。
在许多情况下,由于内容如何产生(每个用户动态生成)或内容的性质(例如敏感的银行信息),缓存不能或不应该被实现。 许多管理员在设置缓存时所面临的另一个问题是,即使新版本已发布,较旧版本的内容仍旧在旧版本中,但尚未失效。
这些都是经常遇到的问题,可能会严重影响缓存性能和正在提供的内容的准确性。 然而,我们可以通过开发预测这些问题的缓存策略来缓解这些问题。
虽然您的情况将决定您使用的缓存策略,以下建议可以帮助您指导一些合理的决策。
您可以采取一些步骤来增加缓存命中率,然后再担心您使用的特定标头。 一些想法是:
在为不同项目选择正确标题方面,以下内容可作为一般参考:
no-cache
或no-store
选项可以在被设置Cache-Control
头部来实现这一点。 Etag
和Last-Modified
头允许缓存,以验证他们的内容,并重新为它服务,如果它尚未在原点修改,进一步降低负荷。 关键是要达到一个平衡,有利于积极的缓存,尽可能地留下机会,以使未来的条目,当做出改变时无效。 您的网站可能包含以下内容的组合:
目标是在可能的情况下将内容移动到第一类,同时保持可接受的准确度水平。
花时间确保您的网站具备适当的缓存策略,可对您的网站产生重大影响。 缓存允许您减少与重复提供相同内容相关的带宽成本。 您的服务器还将能够使用相同的硬件处理更大量的流量。 也许最重要的是,客户在您的网站上会有更快的体验,这可能会导致他们更频繁地返回。 虽然有效的网络缓存不是一个银弹,设置适当的缓存策略可以带来可衡量的收益与最少的工作。
关注云架构公众号
Linux入门
QQ交流群:308781113