配置檔案詳解

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