标签：domain 1.7 dest com cache 缓存 规则 config
配置文件详解
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 进行测试的正则表达式。
次要说明符
辅助说明符是可选的，可用于进一步限制哪些请求受到缓存规则的影响。尽管每种类型的说明符最多只能出现一次，但可以在单个规则中使用多个辅助说明符。换句话说，您可能在同一规则中同时拥有 a
port和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-cacheignore-client-no-cache忽略来自客户端请求的标头。
Cache-Control: no-cacheignore-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
标签：domain,1.7,dest,com,cache,缓存,规则,config 来源： https://www.cnblogs.com/bjcdn/p/14973005.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。