配置文件详解

cache.config:

   缓存配置文件，文件允许您否决源的缓存策略。您可以添加缓存规则以指定以下内容

• 不缓存来自特定 IP 地址的对象。

• 在缓存中固定特定对象的时间。

• 将缓存的对象视为新鲜对象需要多长时间。

• 是否忽略来自服务器的 no-cache 指令。

  通常，使用此文件来定义缓存策略是一种反模式。通常最好让源通过Cache-Control:标头指定缓存策略 。这样，所有业务逻辑都与内容生成有关。来源可以更好地了解哪些内容可以安全缓存以及缓存多长时间。它可以做出细粒度的决定，改变 Cache-Control: 每个对象的标头值。该文件允许进行一些覆盖，但与原点可以提供的内容相比相对粗糙

  格式

  cache.config文件中的每一行都包含一个缓存规则。Traffic Server 识别三个以空格分隔的标签：

  primary_destination=value secondary_specifier=value action=value
  

  您可以在一条规则中使用多个辅助说明符。但是，您不能重复辅助说明符。以下列表显示了具有允许值的可能的主要目的地。

  主要目的地

  每行上的主要目标字段用于限制缓存规则将应用到的请求。

  dest_domain

  请求的域名。Traffic Server 从请求中的 URL 匹配目标的主机名。

  dest_host

  别名dest_domain。

  dest_ip

  请求的 IP 地址。Traffic Server 匹配请求中目标的 IP 地址。

  host_regex

  要针对请求中的目标主机名进行测试的正则表达式。

  url_regex

  要针对请求中的 URL 进行测试的正则表达式。

  次要说明符

  辅助说明符是可选的，可用于进一步限制哪些请求受到缓存规则的影响。尽管每种类型的说明符最多只能出现一次，但可以在单个规则中使用多个辅助说明符。换句话说，您可能在同一规则中同时拥有 aport和scheme，但您可能没有两个ports。

  port

  请求 URL 端口。

  scheme

  请求 URL 协议（http 或 https）。

  prefix

  URL 路径部分的前缀。

  suffix

  URL 中的文件后缀。

  method

  请求 URL 方法（get、put、post、trace 等）。

  time

  时间范围，例如 08:00-14:00。使用 Traffic Server 服务器时区中的 24 小时制指定。

  src_ip

  客户端 IP 地址。

  internal

  一个布尔值true或false，指定规则是否应匹配（或不匹配）源自内部 API 的交易。这对于区分源自 Traffic Server 插件的事务很有用。

  行动

  缓存规则的最后一个组成部分是动作，它决定了 Traffic Server 将如何处理与相关规则的主要目的地和次要说明符匹配的所有对象。

  action

  以下值之一：

  价值	影响
  never-cache	永远不要缓存指定的对象，它将被ttl-in-cache.
  ignore-no-cache	忽略所有标题。Cache-Control: no-cache
  ignore-client-no-cache	忽略来自客户端请求的标头。Cache-Control: no-cache
  ignore-server-no-cache	忽略来自原始服务器响应的标头。Cache-Control: no-cache

  cache-responses-to-cookies

  更改有关 cookie 的缓存样式。这有效地覆盖了配置参数 proxy.config.http.cache.cache_responses_to_cookies 并使用具有相同语义的相同值。覆盖仅对匹配的请求发生。

  pin-in-cache

  在缓存中保留对象，防止它们被覆盖。不影响确定为不可缓存的对象。此设置可能会出现性能问题，并严重影响缓存。例如，如果主要目标匹配所有对象，一旦缓存已满，则不会写入任何新对象，因为不会驱逐任何内容。类似地，对于每个缓存未命中，每个对象都会进行额外的检查，以确定它要替换的对象是否可以被覆盖。

  该值是您希望将对象保留在缓存中的时间量。允许使用以下时间格式：

  • d好几天; 例如：2d

  • h用了几个小时; 例如：10h

  • m几分钟；例如：5m

  • s几秒钟; 例如：20s

  • 混合单位；例如：1h15m20s

  revalidate

  对于缓存中的对象，覆盖对象被视为新鲜的时间量。使用与pin-in-cache.

  ttl-in-cache

  强制对象被缓存，就好像它们有一个 头一样。可以被带有 cookie 的请求否决。该值是对象保留在缓存中的时间量，无论来自源服务器的响应标头如何。使用与.Cache-Control: max-age:<time>Cache-Controlpin-in-cache

  匹配多个规则

  当在 中指定了多个规则时cache.config，Traffic Server 将针对每个请求依次检查所有规则。因此，匹配相同请求但具有冲突动作的两个规则将导致它们的动作被复合。换句话说，Traffic Server 不会在第一场比赛中停止。

  在某些情况下，这可能会导致令人困惑的行为。例如，请考虑以下两条规则：

  dest_domain=example.com prefix=foo suffix=js revalidate=7d
  dest_domain=example.com suffix=js action=never-cache
  

  在假设 Traffic Server 在第一次匹配时停止的情况下阅读可能会导致假设所有 Javascript 文件都将从 Traffic Server 缓存中排除，除了那些路径以foo. 然而，这是不正确的。相反，第一条规则规定所有带有路径前缀的 Javascript 文件foo将被强制每 7 天重新验证一次，然后第二条规则还对所有 Javascript 文件设置一个操作，不管它们的路径前缀如何，根本不会被缓存。因为根本不会缓存任何 Javascript 文件，所以第一条规则实际上无效。

  一个类似的示例，但至少有一个正确的解决方案，可能是尝试为同一操作设置不同的值，如下所示：

  # Incorrect!
  dest_domain=example.com prefix=foo suffix=js revalidate=7d
  dest_domain=example.com suffix=js revalidate=1d
  
  # Correct!
  dest_domain=example.com suffix=js revalidate=1d
  dest_domain=example.com prefix=foo suffix=js revalidate=7d
  

  后者实现了隐含的目标，即为 Javascript 文件的缓存对象重新验证设置一个默认的或全局的计时器，以及仅针对具有特定前缀的那些 Javascript 文件的更有针对性（和更长）的重新验证时间。前者在这个目标上失败了，因为第二个规则将匹配所有 Javascript 文件，并将覆盖先前revalidate规则可能设置的任何先前值。

  ttl-in-cache 和 never-cache

  当同一请求中匹配多个规则时，never-cache将始终被 覆盖ttl-in-cache。例如：

  # ttl-in-cache=1d never-cache=false
  dest_domain=example.com action=never-cache
  dest_domain=example.com ttl-in-cache=1d
  

  例子

  以下示例将 Traffic Server 配置为每 6 小时重新验证 域中的gif和jpeg对象mydomain.com，并mydomain.com每小时重新验证所有其他对象 。规则按所列顺序应用。

  dest_domain=mydomain.com revalidate=1h
  dest_domain=mydomain.com suffix=gif revalidate=6h
  dest_domain=mydomain.com suffix=jpeg revalidate=6h
  

  强制特定正则表达式在服务器时间的晚上 7 点到 11 点之间在缓存中保留 26 小时。

  url_regex=example.com/articles/popular.* time=19:00-23:00 ttl-in-cache=1d2h
  

  防止对象从缓存中驱逐：

  url_regex=example.com/game/.* pin-in-cache=1h