Traffic Server 管理員指南

本文轉載自查看原文 2018-09-17 22:24 1747 ATS/ Apache Traffic Server

1. 簡介

Traffic Server 可以加速 Internet 訪問，增強 web 站點性能，同時也提供前所未有的網絡托管能力。

Traffic Server 是一個高性能的 web 代理緩存，它通過將頻繁訪問的信息緩存在網絡的邊緣來改善網絡的效率和性能。這使訪問內容在地理上更接近終端用戶，在更快分發的同時也減少了帶寬的占用。Traffic Server 致力於通過充分利用現有可用的帶寬，來改善企業、ISP、骨干網提供商和大型企業內部網的內容分發效率。

1.1 Traffic Server 部署選項

Traffic Server 有如下部署方式：

作為一個 web 代理緩存
作為一個反向代理
部署在多級緩存

1.1.1 Traffic Server 作為 web 代理緩存

作為 web 代理緩存，Traffic Server 接收用戶直接發往 web server（源服務器）的 web 內容請求。如果 Traffic Server 包含請求的內容，它將直接提供服務。如果請求的內容不在緩存里，Traffic Server 將作為一個代理：為用戶從源服務器取得請求的內容，並在本地保存一份拷貝以服務於將來相同的請求。

Traffic Server 提供直接代理緩存功能，這需要配置用戶的客戶端軟件將請求直接發送給 Traffic Server。直接代理緩存將在 "直接代理緩存"。

Traffic Server 也可以作為透明代理緩存服務器，其中客戶端軟件不需要特殊配置甚至不需要知道代理的存在。透明代理中有該設置的描述。

1.1.2 Traffic Server 作為反向代理

作為反向代理，Traffic Server 需要配置為用戶直接連接的源服務器（典型的用法是將源服務器的主機名解析到 Traffic Server）。反向代理的功能也被稱為服務器加速。反向代理的更多細節在反向代理和HTTP重定向中描述。

1.1.3 Traffic Server 部署在多級緩存

Traffic Server 可以靈活地參與多級緩存，當 Internet 請求不能在一個緩存中得到滿足的時候，將被路由到其他區域的緩存，從而利用附近緩存的內容。在一個多級代理中，Traffic Server 可以作為其他 Traffic Server 系統或者和其相似的緩存產品的父節點或者子節點。

Traffic Server 支持 ICP（Internet Cache Protocol）互連。多級緩存的更多細節將在多級緩存中介紹。

1.1.4 部署限制

Traffic Server 不支持即開即用的部署選項。此類功能可以在插件中實現，但在某些情況下，Traffic Server 的內部 API 或架構限制不會讓它變得更簡單：

負載平衡 - 請注意一個實驗性插件，Balancer 插件。

1.2 Traffic Server 組件

Traffic Server 由若干一起工作的組件來組成一個便於監控和配置的 web 代理緩存。

1.2.1 Traffic Server 緩存

Traffic Server 緩存由高速對象數據庫 Object store 組成。對象數據庫通過 URL 和相關的頭部來索引對象。使用先進的對象管理，Object store 可以緩存同一個對象（可能是不同的語言或編碼類型）的替換版本。它同樣可以高效地存儲非常小和非常大的對象，從而使浪費的空間最小化。當緩存被占滿后，Traffic Server 通過刪除過期的數據來保證經常被請求的對象有效並容易獲取。

Traffic Server 被設計為容忍緩存磁盤的任何失效。如果磁盤完全失效，Traffic Server 會標記整個磁盤為被占用同時繼續使用余下的磁盤。如果緩存的所有磁盤都失效了，Traffic Server 會自動切換為純代理模式。可以對緩存進行分區，來為專門的協議和源服務器存儲數據預存一定數量的磁盤空間。更多關於緩存的信息見 HTTP 代理緩存。

1.2.2 RAM 緩存

Traffic Server 維護着一個包含熱點對象的微型 RAM 緩存。這個 RAM 緩存在盡可能快地服務大部分熱點對象的同時也減少了磁盤負載，特別是在一些流量的高峰。可以根據需要來配置 RAM 緩存的大小。更多的細節見改變 RAB 緩存的大小。

1.2.3 Host 數據庫

Traffic Server host 數據庫負責存儲連接的源服務器 DNS 記錄。這個信息用來適應未來協議的交互以及性能的優化。host 數據庫信息包含：

DNS 信息（加速主機名和 IP 地址的轉換）
每個 host 的 HTTP 版本（可以在新版的服務器上使用增強的協議功能）
host 的可靠性和可用性信息（用戶可以不用等待不工作的服務器）

1.2.4 DNS 解析器

Traffic Server 包含一個快速的、異步的 DNS 解析器來簡化主機名和 IP 地址的轉換。Traffic Server 最初實現的 DNS 解析器就是直接發送 DNS 命令數據包而不是依賴傳統的慢速解析庫。由於許多 DNS 查詢可以並行發送，同時在內存的高速 DNS 緩存中維持着熱點綁定（DNS，IP），使 DNS 流量減少。

1.2.5 Traffic Server 進程

Traffic Server 包括三個一起工作的進程來服務 Traffic Server 的請求，管理/控制/監控系統的健康狀況。下圖說明了三個進程的關系，三個進程將會在下面描述。

traffic_server 進程是 Traffic Server 的事務處理引擎。它負責接收連接、處理協議請求以及從本地緩存或源服務器提供資源。
traffic_manager 進程是用來命令和控制 Traffic Server 的工具，負責啟動、監控以及重新配置 traffic_server 進程。traffic_manager 進程同時負責代理自動配置端口、統計接口、集群管理以及 VIP 故障轉移。
如果 traffic_manager 進程檢測到 traffic_server 進程失敗，它不僅會立即重啟該進程，而且會為所有傳入的請求維護一個連接隊列。在 traffic_server 重新啟動前的幾秒內傳入的所有連接將被保存在一個隊列，並以 FIFO 的方式處理。這個連接隊列接收任何 server 故障重啟時的連接。
traffic_cop 進程監控 traffic_server 和 traffic_manager 進程的健康狀況。traffic_cop 進程通過抓取合成 web 頁面的心跳請求方式周期性地（每分鍾若干次）查詢 traffic_server 和 traffic_manager 進程。如果失敗事件發生（如果在超時時間間隔內沒有收到請求或者收到錯誤的請求），traffic_cop 重啟 traffic_server 和 traffic_manager 進程。

1.2.6 管理員工具

Traffic Server 提供如下的管理選項：

traffic_ctl 命令行接口是一個基於文本的接口，通過它不但可以監控 Traffic Server 的性能和網絡流量，而且可以配置 Traffic Server 系統。
各種各樣的配置文件可以通過一個簡單的文件編輯器以及信號處理接口來配置 Traffic Server。任何通過 traffic_ctl 的更改都會自動地同步到配置文件。
最后，有一個簡潔的 C API，可以很好地利用多種語言。Traffic Server Admin Client 為 Perl 演示了這一點。

1.3 流量分析選項

Traffic Server 為流量分析和監控提供了若干選項：

traffic_ctl 可以用來收集和處理從網絡流量信息中獲取的統計數據。
事務日志記錄了（在一個日志文件中）Traffic Server 接收的每個請求以及每個檢測到的錯誤。通過分析日志文件，可以確定有多少人使用了 Traffic Server 緩存，每人請求了多少信息以及哪些頁面是最熱的。同樣也可以查看一個特定事務出錯的原因以及特定時間 Traffic Server 的狀態。比如，可以看到 Traffic Server 重啟或者集群通信超時等狀況。
Traffic Server 支持若干標准的日志文件格式，比如 Squid 和Netscape，以及其自定義的格式。可以通過現成的分析包來分析標准格式的日志文件。為了便於日志文件分析，可以按協議或者主機來分開生成日志文件。

Traffic Server 事件和錯誤日志，監控以及分析的詳細介紹參見 Monitoring。

1.4 Traffic Server 安全選項

Traffic Server 提供了許多選項來確保 Traffic Server 系統和網絡上其他計算機進行安全的通信。安全選項如下：

控制客戶端對 Traffic Server 代理緩存的訪問。
通過配置 Traffic Server 使用多個 DNS 服務器來匹配站點的安全配置。比如，Traffic Server 可以使用不同的 DNS 服務器來解析防火牆內部或外部的主機名。這使得在保持內部網絡配置安全的情況下，同時可以繼續透明地訪問 Internet 外部網絡。
配置 Traffic Server 在用戶訪問 Traffic Serer 緩存內容之前對其做身份驗證。
在反向代理模式中，客戶端和 Traffic Server，以及 Traffic Server 和源服務器之間使用 SSL 終止選項來進行安全連接。
通過 SSL 控制訪問。

Traffic Server 安全選項的詳細描述在 Security。

2. 代理緩存配置

2.1 會話協議

Traffic Server 支持一些會話級協議來代替 HTTP 或在 HTTP 之上。這些可以通過插件（參閱新協議插件）提供，也可以由 Traffic Server 直接支持。

會話協議由顯式名稱指定：

http/0.9
http/1.0
http/1.1
http/2

代理端口上支持的會話協議是這些值的子集。為方便起見，根據這些基本協議定義了一些偽值：

http 意味着 http/0.9，http/1.0 和 http/1.1
http2 即 http/2

可以在 proxy.config.http.server_ports 中配置每個代理的端口，以支持這些會話協議的子集。對於啟用 TLS 的連接，此配置控制 NPN 提供的協議。協議嗅探用於非 TLS 代理端口，以確定客戶端正在使用哪個協議。如果該代理端口不支持檢測到的協議，則斷開連接。

2.2 HTTP 代理緩存

Web 代理緩存可以用來存儲高頻訪問的 web 對象（比如文檔、圖片等）並為用戶的請求提供這些信息。在改善網絡性能的同時，也為其他任務空出了 Internet 的帶寬。

2.2.1 理解 HTTP web 代理緩存

Internet 用戶向遍布全球的 web 服務器發送請求。緩存服務器必須扮演成一個 web 代理服務器才能服務於這些請求。當 web 代理服務器收到 web 對象的請求時，它可以選擇響應這些請求或者將它們傳遞給源服務器（包含被請求信息源文件的服務器）。Traffic Server 代理支持直接代理緩存方式，這種方式需要客戶端軟件配置成直接發送請求給 Traffic Server 代理。下面大概描述下 Traffic Server 如何響應用戶的請求：

Traffic Server 收到一個用戶對 web 對象的請求。
Traffic Server 嘗試着在其對象數據庫（緩存）中用被請求對象的地址來定位該對象。
如果對象在緩存中，Traffic Server 會檢查該對象是否過期，如果對象沒有過期，Traffic Server 以緩存命中的方式用該對象來響應用戶。如下圖

如果緩存中的數據已經過期，Traffic Server 連接源服務器並檢查該對象是否仍然可用（重新生效）。如果生效，Traffic Server 直接發送緩存中的對象給用戶。
如果對象沒有在緩存中（緩存未命中）或者源服務器顯示緩存中的對象已經失效，Traffic Server 會從源服務器重新獲取該對象。該對象會同時發送給用戶以及 Traffic Server 的本地緩存。由於本地已經有了最新的緩存，后期對該對象的請求將會被更快的響應。

實際的緩存會比上面的概述復雜得多。尤其是概述中沒有講述 Traffic Server 如何確保對象有效，正確地響應不同的 HTTP 版本以及處理那些對不能或不該被緩存的對象的請求。下面的部分將更細致地討論這些問題。

2.2.2 確保被緩存對象的有效性

當 Traffic Server 收到一個 web 對象的請求，它首先嘗試着在緩存中定位該對象。如果該對象在緩存中，Traffic Server 將會檢查該對象是否仍然有效。對於 HTTP 對象而言，Traffic Server 支持可選的作者自定義的有效期。Traffic Server 首先根據有效期判斷；如果有效期不存在，它會在對象被改變的頻率和管理員選擇的有效期方案之間挑選一個有效期。可以通過源服務器檢查對象有效性的方式來重新生效對象。

HTTP 對象保鮮

Traffic Server 通過如下的方式來判斷緩存中的 HTTP 對象是否有效：

檢查 Expires 或者 max-age 頭
一些 HTTP 對象包含 Expires 頭或者 max-age 頭來明確定義對象可以被緩存的時間。Traffic Server 通過比較當前時間和有效期時間來決定該對象是否仍然有效。
檢查 Last-Modified / Date 頭
如果 HTTP 對象沒有 Expires 頭或者 max-age 頭，Traffic Server 使用下面的公式來計算對象有效期：

freshness_limit = ( date - last_modified ) * 0.10

這里的 date 是對象服務器返回的響應頭的日期，而 last_modified 是 Last-Modified 頭部的日期。如果沒有 Last-Modified 頭部，Traffic Server 就使用對象寫入緩存的日期。因子 0.1（10%）可以根據需要來增加或減少（見 Modifying Aging Factor for Freshness Computations）。
計算的有效期被限制在一個最小值和最大值之間，更多信息見 Setting Absolute Freshness Limits。

檢查絕對有效期極值
如果 HTTP 對象既沒有 Expires 頭部也沒有 Last-Modified 和 Date 頭部，Traffic Server 使用一個最大和最小有效期（見 Setting Absolute Freshness Limits）.
檢查 cache.config 文件中的重新生效規則
重新生效規則為特殊的對象提供有效期極值。可以為來自特殊的域或 IP 地址的對象，URL 中包含指定的正則表達式的對象，來自特殊客戶端的對象等設置有效期極值。參見 cache.config。

為有效期的計算修改老化因子

如果一個對象沒有包含任何截止信息，Traffic Server 可以根據其 Last-Modified 和 Date 頭部來估計它的有效期。默認地，Traffic Server 存儲該對象的時長是該對象最近一次被修改后到某個固定時間的 10%。可以根據需要來增大或減少這個百分比。

為有效期的計算修改老化因子：

修改位於 records.config 配置文件中 proxy.config.http.cache.heuristic_lm_factor 的值。
應用更改后的配置：traffic_ctl config reload。

proxy.config.http.cache.heuristic_lm_factor：設置這個變量來指定計算有效期的老化因子。Traffic Server 存儲對象的時間依賴於這個變量。默認置為 0.1，即 10%。

設置絕對有效期極值

一些對象既沒有 Expires 頭部也沒有 Last-Modified 和 Date 頭部。為了控制這些對象在緩存中的時間，需要指定一個絕對有效期極值。

設置一個絕對有效期極值：

修改位於 records.config 配置文件中的 proxy.config.http.cache.heuristic_min_lifetime 和 proxy.config.http.cache.heuristic_max_lifetime 這兩個變量的值。
應用更改后的配置：traffic_ctl config reload。

proxy.config.http.cache.heuristic_min_lifetime：指定沒有截止時間的 HTTP 對象在緩存中有效期的最小值。默認值為 3600 秒（1 小時）。
proxy.config.http.cache.heuristic_max_lifetime：指定沒有截止時間的 HTTP 對象在緩存中有效期的最大值。默認值為 86400 秒（1 天）。

指定頭部的必要條件

為了更好的確保緩存中對象的有效性，可以配置 Traffic Server 只緩存有特殊頭部的對象。默認地，Traffic Server 緩存所有的對象（包括沒有頭部的對象）；可以為特殊的代理情況改變默認設置。如果配置 Traffic Server 只緩存有 Expires 或者 max-age 頭部的 HTTP 對象，緩存命中率將會明顯下降（因為幾乎沒有對象有明確的截止信息）。

配置 Traffic Server 只緩存有特殊頭部的對象：

修改 records.config 配置文件中的 proxy.config.http.cache.required_headers 變量的值。
應用更改后的配置：traffic_ctl config reload。

proxy.config.http.cache.required_headers：設置這個變量為下列值之一：
- 0：對頭部沒有特殊要求
- 1：需要是 Last-Modified 頭部，或者有明確生命期的頭部，Expires 或者 Cache-Control: max-age
- 2：需要明確的生命期，Expires 或者 Cache-Control: max-age

Cache-Control 頭部

盡管一個對象在緩存中可能是有效的，但是客戶端或者服務器經常強加它們自己的不從緩存中獲取對象的約束。比如，一個客戶端請求一個對象時可能不通過緩存，即使通過緩存，對象的緩存時間也不能超過 10 分鍾。Traffic Server 可以給一個緩存的對象在客戶端請求和服務器響應中加上 Cache-Control 頭部。下面的 Cache-Control 頭影響着對象是否可以通過緩存來服務：

客戶端發送的 no-cache 頭部，告訴 Traffic Server 不能直接從緩存獲取任何對象；因此，Traffic Server 總是從源服務器獲取對象。可以配置 Traffic Server 忽略客戶端的 no-cache 頭部，更多信息見 Configuring Traffic Server to Ignore Client no-cache Headers.
服務器發送的 max-age 頭部，用來表示對象的使用期限。如果使用期限小於 max-age，表明對象是有效的，可以直接從緩存獲取對象。
客戶端發送的 min-fresh 頭部，是一個可接收的有效期容忍。這意味着客戶端想讓對象至少這次是有效的。如果一個對象在未來的這樣一段時間內不再有效，那它會重新生效。
客戶端發送的 max-stale 頭部，允許 Traffic Server 使用過期的對象，倘若這些對象不是太老的話。一些瀏覽器傾向於使用過期不久的對象來改善性能，尤其是在 Internet 不是很發達的時期。

Traffic Server 在 HTTP 有效期標准之后使用 Cache-Control 標准。比如，一個對象可能被認為是有效的，但是如果它的使用期限大於它的 max-age，它將不會用於響應請求。

重新生效 HTTP 對象

當客戶端請求一個在緩存中過期的對象，Traffic Server 將重新生效這個對象。重新生效是詢問源服務器檢查這個對象有沒有被修改。重新生效的結果是下列情況之一：

如果對象還是有效的，Traffic Server 將重新設置這個對象的有效期極值，同時用這個對象來服務。
如果這個對象有新拷貝，Traffic Server 緩存這個對象（替換過期對象），同時用新的對象來服務用戶。
如果對象在源服務器已經不存在了，Traffic Server 將不為這個對象提供服務。
如果源服務器沒有響應重新生效查詢，Traffic Server 在用這個過期對象服務的同時，會提供 111 重新生效失敗的警告。

默認情況下，Traffic Server 會重新生效一個緩存中的對象，如果它認為該對象已經過期。Traffic Server 如何評估對象的有效性已在 HTTP Object Freshness 中描述。可以選擇如下選項之一來重新配置 Traffic Server 評估有效性的方式：

Traffic Server 認為所有在緩存中的對象都是過期的：總是對在緩存中的對象進行重新生效。
Traffic Server 認為所有在緩存中的對象都是有效的：從不對在緩存中的對象進行重新生效。
Traffic Server 認為所有沒有 Expires 或 Cache-Control 頭部的 HTTP 對象都是過期的：重新生效所有沒有 Expires 或 Cache-Control 頭部的 HTTP 對象。

可以通過在 cache.config 文件中設置特殊的重新生效規則來配置 Traffic Server 重新生效緩存中對象的方式。

配置重新生效選項：

修改 records.config 配置文件中 proxy.config.http.cache.when_to_revalidate 變量的值。
應用更改后的配置：traffic_ctl config reload。

proxy.config.http.cache.when_to_revalidate：設置這個變量為下列值之一：
- 0：配置 Traffic Server 重新生效 HTTP 對象，當它認為該對象在緩存中已過期（如果可以的話，Traffic Server 檢查對象頭部和有效期極值）。這是默認配置。
- 1：配置 Traffic Server 重新生效沒有 Expires 或 Cache-Control 頭部的 HTTP 對象。
- 2：配置 Traffic Server 總是重新生效 HTTP 對象；Traffic Server 總是認為 HTTP 對象是過期的。
- 3：配置 Traffic Server 從不重新生效 HTTP 對象；Traffic Server 總是認為 HTTP 對象是有效的。

定時更新本地緩存內容

為了進一步增加性能並確保緩存中 HTTP 對象的有效性，可以使用預定更新選項。這個配置可以使 Traffic Server 定時加載特殊的對象到緩存。當使用 Traffic Server 作為反向代理的時候，定時更新功能顯得非常有用，它可以根據預計的需求來預加載內容。

為了使用定時更新選項，必須完成如下的工作：

指定想定時更新對象的 URL 列表，更新發生的時間以及 URL 遞歸的深度。
開啟定時更新選項，同時配置可選的重試次數。

Traffic Server 通過指定的信息來確定相關的 URL。Traffic Server 為每個 URL 獲取所有遞歸的 URL （如果可以的話）並生成唯一的 URL 列表。Traffic Server 使用這個列表為每個未訪問的 URL 發起的 HTTP GET 操作，在任意給定的時間內，確保用戶定義的極值下 HTTP 的流通性。這個系統記錄了所有 HTTP GET 操作的完成過程，可以基於此來監控定時更新的性能狀況。

Traffic Server 也通過一個強制立刻更新的選項，可以在不等待指定更新時間的情況下立刻更新 URL。可以用這個選項來測試定時更新配置（見 Forcing an Immediate Update）.

配置定時更新選項

配置定時更新選項需要下面幾步：

在 update.config 文件中寫入每個要更新的 URL。
在 records.config 中修改如下幾個變量的值：
- proxy.config.update.enabled：設置這個變量為 1 來開啟定時更新選項。
- proxy.config.update.retry_count：設置這個變量來指定當定時更新一個 URL 失敗時重試的次數。默認值為 0.
- proxy.config.update.retry_interval：設置這個變量來指定當定時更新一個 URL 失敗時重試的時間間隔（單位：秒）。默認值為 2.
- proxy.config.update.concurrent_update：設置這個變量來指定在任意同一時間點允許同時更新的最大請求數。這個選項來防止定時更新進程給主機帶來超負荷。默認值為 100.
應用更改后的配置：traffic_ctl config reload。

強制立刻更新

Traffic Server 提供一個強制立刻更新選項，便於立刻驗證 update.config 文件中的 URL 列表。這個強制更新選項忽略 update.config 中設置的更新時間間隔並且立刻更新 URL 列表。

配置強制更新選項需要如下幾步：

修改 records.config 文件中 proxy.config.update.force 變量的值：
- proxy.config.update.force：設置這個變量為 1 來開啟強制更新選項。
確保 proxy.config.update.enabled 變量設置為 1.
應用更改后的配置：traffic_ctl config reload。

當你開啟了強制更新選項，Traffic Server 將不斷地更新 update.config 文件中指定的 URL 直至關閉了該選項。要關閉強制更新選項，設置 proxy.config.update.force 變量為 0.

2.2.3 將內容 PUSH 到緩存

Traffic Server 支持 HTTP PUSH 方法的內容分發。使用 HTTP PUSH，可以不借助用戶請求直接將內容傳遞到緩存。

配置 Traffic Server 接受 PUSH 請求

在使用 HTTP PUSH 傳遞內容到緩存之前，必須先設置 Traffic Server 接受 PUSH 請求。

配置 Traffic Server 接受 PUSH 請求：

向 ip_allow.config 文件添加如下過濾規則來確保只有某些 IP 地址可以向緩存發送 PUSH 請求（示例）：

src_ip=0.0.0.0-255.255.255.255                    action=ip_allow  method=PUSH

啟用 records.config 文件中 proxy.config.http.push_method_enabled 變量
- proxy.config.http.push_method_enabled：設置這個變量為 1 來開啟 Traffic Server 接受 PUSH 請求。

CONFIG proxy.config.http.push_method_enabled INT 1

應用更改后的配置：traffic_ctl config reload。

ip_allow 的詳細描述在 ip_allow.config.

理解 HTTP PUSH

PUSH 使用 HTTP 1.1 的消息格式。PUSH 請求的實體包括響應的頭部以及想在緩存中替換的響應實體。下面是一個 PUSH 請求的例子：

PUSH http://www.company.com HTTP/1.0
Content-length: 84

HTTP/1.0 200 OK
Content-type: text/html
Content-length: 17

<HTML>
a
</HTML>

注：頭部必須包括 Content-Length；Content-Length 必須包括頭部和實體的字節數。

有助於管理 PUSH 的工具

Traffic Server 附帶一個用於 PUSH 的腳本，tpush。這有助於了解如何編寫腳本以自行推送內容。

2.2.4 保留緩存中的內容

固定緩存選項配置 Traffic Server 保證一些 HTTP 對象一段指定的時間內都在緩存中。可以使用這個選項來確保一些最熱點的對象在需要的時候會在緩存中，阻止 Traffic Server 刪除重要的對象。Traffic Server 觀測 Cache-Control 頭部並只會保留一個確定可緩存的對象在緩存中。

設置緩存固定規則並開啟緩存固定功能：

啟用 records.config 文件中 proxy.config.cache.permit.pinning 變量
- proxy.config.cache.permit.pinning：設置這個變量為 1 來開啟固定緩存選項。

CONFIG proxy.config.cache.permit.pinning INT 1

為每個想讓 Traffic Server 保留在緩存中的 URL 添加一條規則到 cache.config 中。比如：

url_regex=^https?://(www.)?apache.org/dev/ pin-in-cache=12h

正則表達式中指定的 URL 即為想讓 Traffic Server 固定在緩存中的 URL。時間的格式可以是 d（天）、h（小時）、m（分鍾）以及 s（秒）。也可以使用混合格式，如：1h15m20s。
3. 應用更改后的配置：traffic_ctl config reload。

2.2.5 緩存 HTTP 對象

當 Traffic Serer 收到一個對沒有在緩存中的對象的請求時，它從源服務器取回這個對象並用其來響應用戶。同時，在緩存中緩存這個對象以便服務后來的請求之前，Traffic Server 先檢查這個對象是否可以緩存。

Traffic Server 響應來自客戶端、源服務器以及通過配置選項和文件指定的緩存指示。

1. 客戶端指示

默認情況下，Traffic Server 不緩存含有如下請求頭部的對象：

Authorization
Cache-Control: no-store
Cache-Control: no-cache
為了配置 Traffic Server 忽略該請求頭部，參見 Configuring Traffic Server to Ignore Client no-cache Headers。
Cookie（文本對象）
默認情況下，Traffic Server 緩存包含 cookies 請求服務的響應對象（除了文本對象）。可以配置 Traffic Server 不緩存任何類型的 cookies 內容、緩存所有的 cookies 內容或者只緩存圖片類型的 cookies 內容。更多信息參見 Caching Cookied Objects。

配置 Traffic Server 忽略客戶端的 no-cache 頭部

默認情況下，Traffic Server 嚴格遵守客戶端 Cache-Control: no-cache 的指示。如果一個被請求的對象包含 no-cache 頭部，即使它在緩存中仍然有效，Traffic Server 也會將該請求傳遞給源服務器。可以配置 Traffic Server 忽略客戶端 no-cache 指示，這樣它將忽略客戶端請求的 no-cache 頭部並用緩存中的對象服務該請求。

配置 Traffic Server 忽略客戶端的 no-cache 頭部：

編輯 records.config 文件中 proxy.config.http.cache.ignore_client_no_cache 變量。
- proxy.config.http.cache.ignore_client_no_cache：設置這個變量為 1 來忽略客戶端的 no-cache 頭部。

CONFIG proxy.config.http.cache.ignore_client_no_cache INT 1

應用更改后的配置：traffic_ctl config reload。

2. 源服務器指示

默認情況下，Traffic Server 不緩存包含如下響應頭部的對象：

Cache-Control: no-store
Cache-Control: private
WWW-Authenticate
為了配置 Traffic Server 忽略 WWW-Authenticate 頭部，參見 Configuring Traffic Server to Ignore WWW-Authenticate Headers.
Set-Cookie
Cache-Control: no-cache
為了配置 Traffic Server 忽略 no-cahce 頭部，參見 Configuring Traffic Server to Ignore Server no-cache Headers.。
Expires 頭部包含 0 值或過去時間

配置 Traffic Server 忽略服務器 no-cache 頭部

默認情況下，Traffic Server 嚴格遵守 Cache-Control: no-cache 指示。一個來自源服務器的帶有 no-cache 頭部的響應將不會被存儲在緩存，該對象之前的緩存中的拷貝也會被刪除。如果配置 Traffic Server 忽略 no-cache 頭部，Traffic Server 同時也忽略 no-store 頭部。在大多數情況下是應該遵守 no-cache 指示的。

配置 Traffic Server 忽略服務器的 no-cache 頭部：

編輯 records.config 中 proxy.config.http.cache.ignore_server_no_cache 變量。
- proxy.config.http.cache.ignore_server_no_cache：設置這個變量為 1 來忽略服務器的 no-cache 頭部。

CONFIG proxy.config.http.cache.ignore_server_no_cache INT 1

應用更改后的配置：traffic_ctl config reload。

配置 Traffic Server 忽略 WWW-Authenticate 頭部

默認情況下，Traffic Server 不緩存包含 WWW-Authenticate 響應頭部的對象。WWW-Authenticate 頭部包含着客戶端准備用來響應源服務器質詢應答的鑒定參數。

當配置 Traffic Server 忽略源服務器的 WWW-Authenticate 頭部，所有帶 WWW-Authenticate 頭部的對象將被存儲在緩存中被用來服務后來的請求，在大多數情況下，應該使用默認的不緩存帶 WWW-Authenticate 頭部對象的行為。只有在對 HTTP 1.1 深入理解的基礎上，再嘗試配置 Traffic Server 忽略服務器 WWW-Authenticate 頭部。

配置 Traffic Server 忽略 WWW-Authenticate 頭部：

編輯 records.config 文件中的 proxy.config.http.cache.ignore_authentication 變量。
- proxy.config.http.cache.ignore_authentication：設置這個變量為 1 來緩存帶 WWW-Authenticate 頭部的對象。

CONFIG proxy.config.http.cache.ignore_authentication INT 1

應用更改后的配置：traffic_ctl config reload。

3. 配置指示

除了客戶端和服務器的指示，Traffic Server 同樣響應配置選項和文件的指示。

可以按如下步驟來配置 Traffic Server：

不緩存任何對象（參見 Disabling HTTP Object Caching.）.
緩存動態內容 -- 對象的 URL 以 .asp 結尾或者包含問號（？）、分號（:）或者 cgi。更多信息參加 Caching Dynamic Content.。
緩存響應 Cookie: 頭部的對象。參見 Caching Cookied Objects.
遵守 cache.config 文件中的 nerver-cache 規則。

關閉 HTTP 對象緩存

默認情況下，Traffic Server 緩存除了在 cache.config 文件中設置了 never-cache 的所有對象。可以關閉 HTTP 對象緩存功能，所有的對象都直接由源服務器服務而且從不緩存。

手動配置關閉 HTTP 對象緩存：

設置 records.config 文件中 proxy.config.http.cache.http 變量為 0.
- proxy.config.http.cache.http：設置這個變量為 0 來關閉 HTTP 對象緩存功能。

CONFIG proxy.config.http.cache.http INT 0

應用更改后的配置：traffic_ctl config reload。

緩存動態內容

一個以 .asp 結尾或包含問號（？）、分號（;）或者 cgi 的 URL 被認為是動態的。Traffic Server 默認緩存動態內容。可以配置系統忽略動態內容，但僅當內容是真正動態時才推薦，但是不能通過適當的 Cache-Control 頭部來 advertise。

配置 Traffic Server 關於動態內容的緩存行為：

編輯 records.config 文件中的 proxy.config.http.cache.cache_urls_that_look_dynamic 變量。是禁止緩存則設置該變量為 0，若是顯式允許緩存則設置為 1.

CONFIG proxy.config.http.cache.cache_urls_that_look_dynamic INT 0

應用更改后的配置：traffic_ctl config reload。

緩存 Cookied 對象

默認情況下，Traffic Server 緩存包含 cookies 請求服務的響應對象（除了文本對象）。Traffic Server 之所以不緩存文本內容的 cookied，是因為對象的頭部和對象是一起存儲的，而帶有隱私的 cookie 頭部是不能和對象一起保存的。對於非文本對象，不能確定是否使用了帶有隱私的 cookie 頭部。

可以配置 Traffic Server：

不緩存任何類型的 cookies 內容。
只緩存圖片類型的 cookies 內容。
緩存所有的 cookies 內容。

配置 Traffic Server 緩存 cookied 內容的方式：

編輯 records.config 文件中 proxy.config.http.cache.cache_responses_to_cookies 變量。
- proxy.config.http.cache.cache_responses_to_cookies：設置這個變量來指定 Traffic Server 緩存 cookied 內容的方式：
  - 0：不緩存任何 cookies 響應。
  - 1：緩存所有的 cookies 響應。
  - 2：只緩存圖片類型的 cookies 響應。
  - 3：緩存除了文本內容類型的所有 cookies 響應。
應用更改后的配置：traffic_ctl config reload。

2.2.6 強制對象緩存

可以強制 Traffic Server 緩存特殊的 URL（包括動態 URL）一段指定的時間，而不考慮 Cache-Control 響應頭部。

強制緩存文檔：

為每個想讓 Traffic Server 強制緩存的 URL 添加一條規則到 cache.config 文件中。比如：

url_regex=^https?://(www.)?apache.org/dev/ ttl-in-cache=6h

應用更改后的配置：traffic_ctl config reload。

2.2.7 緩存 HTTP Alternates

一些源服務器用多種對象來響應同一個 URL 的請求。這些對象的內容是多種多樣的，比如提供不同語言內容的服務、為不同的目標瀏覽器提供不同的表達方式、或者提供不同的文檔格式（HTML、PDF）。同一對象的不同版本被稱為 Alternates，Traffic Server 基於 Vary 響應頭部來緩存它們。可以為特殊的 Content-Type 值指定附加的請求和響應頭部來讓 Traffic Server 識別其為 Alternates 並緩沖之。也可以限制一個對象允許緩存不同版本的數目。

配置 Traffic Server 如何緩存 Alternates

配置 Traffic Server 如何緩存 alternates：

編輯 records.config 中的如下變量：
- proxy.config.http.cache.enabled_default_vary_headers：設置這個變量為 1 來緩存不包含 Vary 頭部的 HTTP 對象的不同版本。
- proxy.config.http.cache.vary_default_text：設置這個變量來指定在請求是文本時 HTTP 頭部的多種格式：比如，HTML 文檔。
- proxy.config.http.cache.vary_default_images：設置這個變量來指定在請求是圖像時 HTTP 頭部的多種格式，比如，.gif 文件。
- proxy.config.http.cache.vary_default_other：設置這個變量來指定在請求不是文本和圖像時 HTTP 頭部的多種格式。
應用更改后的配置：traffic_ctl config reload。

注：如果在上述變量中指定 Cookie 作為頭部變化格式，必須確保正確設置了 proxy.config.http.cache.cache_responses_to_cookies 變量。
比如，如果設置 proxy.config.http.cache.cache_responses_to_cookies 變量為 2（只緩存圖片格式的 cookies 響應），同時設置 proxy.config.http.cache.vary_default_text 變量為指定的 cookie，cookie 的 alternates 將不接受文本格式。

限制一個對象的 Alternates 個數

可以限制 Traffic Server 緩存每個對象 alternates 的個數（默認值為 3）。

alternates 的數量太多會影響 Traffic Server 的性能，因為所有的 alternates 有同一個 URL。盡管 Traffic Server 可以從索引中快速查找 URL，但是必須在對象存儲中順序掃描直到找到可用的 alternates。

限制 alternates 的數目：

編輯 records.config 文件中 proxy.config.cache.limits.http.max_alts 變量。
- proxy.config.cache.limits.http.max_alts：設置這個變量來指定想讓 Traffic Server 緩存一個對象不同版本的數目。默認值為 3.

CONFIG proxy.config.cache.limits.http.max_alts INT 5

應用更改后的配置：traffic_ctl config reload。

2.2.8 使用事務緩存控制

默認情況下，I/O 操作以全速運行，與 Traffic Server 的網絡或緩存可以支持的速度一樣快。如果客戶端連接很慢，則對於大型對象可能會出現問題。在這種情況下，內容將緩存在 RAM 中，同時等待發送給客戶端。如果客戶端連接速度很快，但源服務器連接很慢，則 POST 請求也可能發生這種情況。如果使用非常大的對象，則可能導致 Traffic Server 的內存使用量變得非常大。

通過控制事務使用的緩存空間量可以改善這種問題。根據事務使用的字節數設置高閾值或低閾值。如果使用的緩存空間量超過了標記的高閾值，則會限制連接以防止其他外部數據到達。內部操作繼續全速運行，直到使用的緩存空間量低於低閾值，才重新啟用外部數據 I/O。

雖然這主要是為了限制 Traffic Server 的內存使用量，但它也可以通過設置緩存區限制，然后在外部或通過事務限制客戶端連接來充當原始速率限制器。這將導致與源服務器的連接大致限制為客戶端連接速度。

Traffic Server 以大塊（32k 左右）進行網絡 I/O，因此事務緩存控制的粒度限制在類似的精度。

緩存區大小的計算值包括事務中的所有元素，包括與轉換插件關聯的任何緩沖區。

可以使用配置變量或插件中的 TSHttpTxnConfigIntSet() 來全局啟用事務緩存控制：

Value	Variable	TSHttpTxnConfigIntSet() key
Enable buffering	proxy.config.http.flow_control.enabled	TS_CONFIG_HTTP_FLOW_CONTROL_ENABLED
Set high water	proxy.config.http.flow_control.high_water	TS_CONFIG_HTTP_FLOW_CONTROL_HIGH_WATER_MARK
Set low water	proxy.config.http.flow_control.low_water	TS_CONFIG_HTTP_FLOW_CONTROL_LOW_WATER_MARK

注意始終使低閾值小於或等於高閾值。如果只設置一個，則另一個將設置為相同的值。

如果使用 TSHttpTxnConfigIntSet()，必須在不遲於 TS_HTTP_READ_RESPONSE_HDR_HOOK 的情況下調用它。

2.2.9 減少源服務器請求（避免驚群）

當無法從緩存中提供對象時，請求將被代理到源服務器。對於流行的對象，對源服務器的許多接近同時的請求，可能會導致其相關資源負載過重。Traffic Server 中有幾個功能可以避免這種情況。

read while writer

當 Traffic Server 從源服務器獲取內容時，並在收到響應后，一旦接收到 background_fill_completed_threshold% 的對象數據，就可以允許為任意數量的客戶端開始提供部分填充的緩存對象。

雖然一些其他的 HTTP 代理允許客戶端在代理從源服務器接收到數據時立即開始讀取響應，但 ATS 僅在讀取和處理完整的 HTTP 響應頭之后，才允許客戶端讀取。這是 ATS 的副作用，不區分緩存刷新和冷緩存，這會阻止了解該響應是否可以被緩存。

來自源服務器的不可緩存響應通常是由於該內容對於不同的客戶端請求是唯一的，在確定它能夠緩存對象之前，ATS 將不會使能 read-while-writer 功能。

必須進行如下設置 records.config 以使能 ATS 的 read-while-writer 功能：

CONFIG proxy.config.cache.enable_read_while_writer INT 1
CONFIG proxy.config.http.background_fill_active_timeout INT 0
CONFIG proxy.config.http.background_fill_completed_threshold FLOAT 0.000000
CONFIG proxy.config.cache.max_doc_size INT 0

由於以下原因，所有四種配置都是必需的：

設置 proxy.config.cache.enable_read_while_writer 為 1 以打開該功能，因為它默認為 0。
為每個可能的情況應該允許啟用后台填充功能（proxy.config.http.background_fill_active_timeout 和 proxy.config.http.background_fill_completed_threshold）。必要下，如果一個 writer（第一個請求對象的客戶端會話，將觸發 ATS 連接源服務器）消失，則另一個客戶端會話必須接管 writer。
因此，應該將后台填充超時和閾值設置為 0，這可以保證它們永不超時，並且總是被允許進入。
proxy.config.cache.max_doc_size 變量應該是無限制的（設置為 0），因為對象的大小可能是未知的，超過此限制將導致所服務的對象斷開連接。

一旦啟用這些功能，則可以獲得與 Squid 的 Coolapsed Forwarding 非常接近但又不完全相同的東西。

除了上述設置，設置 proxy.config.cache.read_while_writer.max_retries 和 proxy.config.cache.read_while_writer_retry.delay 允許控制 TS 嘗試觸發 read-while-writer 的次數，直到完成對象的第一個片段的下載：

CONFIG proxy.config.cache.read_while_writer.max_retries INT 10

CONFIG proxy.config.cache.read_while_writer_retry.delay INT 50

打開讀取重試超時（Open Read Retry Timeout）

open read retry 配置嘗試減少向源服務器並發獲取對象的數量。當從源服務器獲取對象時，后續請求將在檢查對象是否可以從緩存中提供之前等待 proxy.config.http.cache.open_read_retry_time 毫秒。如果仍然在獲取對象，則后續請求將重試 proxy.config.http.cache.max_open_read_retries 次。因此，后續請求在建立自己的原始連接之前等待總共 (max_open_read_retries * open_read_retry_time) 毫秒。例如，如果它們分別設置為 5 和 10，則連接將等待長達 50ms 的時間，等待響應從以前的請求返回，直到允許該請求通過為止。

當對象不可緩存時，這些設置是不合適的。在這種情況下，對對象的請求有效地被序列化。后續的請求在代理到源服務器之前至少等待 open_read_retry_time 毫秒。

將以將此設置與 Read While Writer 結合使用，用於比較大的（那些需要超過 (max_open_read_retries * open_read_retry_time) 毫秒來傳輸的）可緩存對象。如果未啟用 rad-while-writer 設置，則當初始獲取正在進行時，不僅后續的請求將延遲最長時間，而且這些請求會導致對源服務器不必要的請求。

由於現在 ATS 支持根據每個請求或重新映射規則來設置這些設置，所以可以更容易地將其配置為適合自己的設置。

默認配置如下：

CONFIG proxy.config.http.cache.max_open_read_retries INT -1
CONFIG proxy.config.http.cache.open_read_retry_time INT 10

默認設置是禁用該功能，並允許每個連接在沒有人為延遲的情況下轉到源服務器。啟用后，將嘗試 max_open_read_retries 次，每次都有一個 open_read_retry_time 超時。

打開寫入失敗操作

除了 open read retry 設置之外，ATS 支持新的設置 proxy.config.http.cache.open_write_fail_action，在 hit-stale 的情況下，或者在除了其中一個請求之外的所有緩存未命中時發生錯誤的情況下，它允許通過返回過期的副本來進一步減少多個並發請求對同一個對象的命中。

2.3 反向代理和 HTTP 重定向

作為反向代理緩存，Traffic Server 為源服務器服務請求。Traffic Server 被配置成對客戶端而言是正常的源服務器的方式。

2.3.1 理解反向代理緩存

通過正向代理緩存，Traffic Server 為客戶端處理發往源服務器的 web 請求。反向代理緩存（又稱服務器加速或虛擬主機托管）和正向代理不同，因為 Traffic Server 作為源服務器的代理緩存並存儲內容。Traffic Server 被配置為用戶直接連接的源服務器（典型的用法是將源服務器的主機名解析到 Traffic Server），直接為客戶端請求提供服務，在必要的時候向真正的源服務器獲取內容。

反向代理解決方案

有多種方式使用 Traffic Server 作為一個反向代理。下面是一些示例場景。

為負載過高的源服務器減負。
為地理上分散的區域高效地分發內容。
為包含機密信息的源服務器提供安全屏障。

為負載過高的源服務器減負

Traffic Server 可以吸收發向源服務器的請求，通過減少源服務器的負載和熱點來改善 web 服務的速度和質量。比如，一個網絡托管商可以用一系列低價格、低性能、低可靠性的 PC 作為后備服務器來維護一個可擴展的 Traffic Server 服務引擎。事實上，單個 Traffic Server 可以為多個后台源服務器充當虛擬源服務器。

為地理上分散的區域分發內容

Traffic Server 可以使用反向代理模式來加速為地理上不鄰近的區域提供服務。緩存更易於管理並且比復制數據更划算。比如，Traffic Server 可以在大洋彼岸充當鏡像站點，不需要通過昂貴的國際連接發送請求和獲取內容就可以服務用戶。

相比於硬件必須要配置成復制所有的數據，並且要處理高峰情況下的復制，Traffic Server 可以通過動態調整來最好的利用硬件的服務和存儲能力。Traffic Server 同時可以自動保持內容的有效性，從而排除了復雜的更新源服務器的操作。

為源服務器提供安全保障

Traffic Server 可以使用反向代理模式來為源服務器提供安全保障。如果想讓包含機密信息的源服務器位於防火牆內來保證安全，可以在防火牆外用 Traffic Server 作為源服務器的反向代理。當外面的客戶端試圖訪問源服務器，請求會被發送到 Traffic Server。如果請求的內容不是機密的，可以通過緩存來服務。如果內容是機密的並且沒有緩存，Traffic Server 就從源服務器獲取該內容（防火牆只允許 Traffic Server 訪問源服務器）。位於源服務器的機密內容就可以安全地留在防火牆內。

反向代理的工作方式

當瀏覽器有請求，它一般直接發送這些請求到源服務器。當 Traffic Server 工作在反向代理模式，它在這些請求到達源服務器之前就攔截它們。典型的用法是將源服務器的 DNS 入口（主機名）解析成 Traffic Server 的 IP 地址。當 Traffic Server 被配置為源服務器，瀏覽器會和 Traffic Server 而非源服務器建立連接。更多的信息參見 HTTP Reverse Proxy。

為了避免 DNS 沖突，源服務器的主機名和外在 DNS 主機名必須不同。

2.3.2 HTTP 反向代理

在反向代理模式中，Traffic Server 為 web 服務器處理 HTTP 請求。反向代理模式下，Traffic Server 處理來自客戶端瀏覽器 HTTP 請求的方式如下圖所示。

圖上包含的步驟如下：

客戶端瀏覽器在 80 端口向名為 www.host.com 的 host 發送一個 HTTP 請求。Traffic Server 以源服務器的角色接收這個請求（源服務器的對外主機名被解析到 Traffic Server）。
Traffic Server 在 remap.config 文件中定位映射規則並重新映射這個請求到一個指定的源服務器（readlhost.com）。
Traffic Server 建立一個和源服務器的 HTTP 連接。
如果請求在緩存中命中而且內容是有效的，Traffic Server 直接從緩存中向客戶端發送被請求的對象。否則，Traffic Server 從源服務器獲取被請求的對象，發送給客戶端，同時在緩存中保存一份該對象的拷貝。

當從源服務器更新自己的緩存時，Traffic Server 將在更新緩存數據庫時同時將該內容發送給客戶端。一旦 Traffic Server 收到並處理了來自源服務器的完整響應頭，就開始響應客戶端包含的請求對象。

要配置 HTTP 反向代理，步驟如下：

在 remap.config 文件中生成映射規則（參見 Creating Mapping Rules for HTTP Request）.

map http://www.host.com http://realhost.com

啟用反向代理選項（參見 Enabling HTTP Reverse Proxy）。

除了上述步驟，也可以參見 Setting Optional HTTP Reverse Proxy Options。

處理源服務器重定向響應

源服務器經常給瀏覽器返回重定向到不同頁面的響應。比如，如果源服務器超載，它會重定向瀏覽器到一個低負載的服務器。源服務器也重定向已經被移到不同位置下的 web 頁面。當 Traffic Server 被配置成一個反向代理，它必須通過改寫來自源服務器的重定向來使瀏覽器重定向到 Traffic Server 而不是其他的源服務器。

Traffic Server 使用反向映射規則來改寫重定向。除非啟用了 proxy.config.url_remap.pristine_host_hdr（默認），否則需要為每個映射規則生成一個反向映射規則。參見 Using Mapping Rules for HTTP Request 來創建反向映射規則。

為 HTTP 請求使用映射規則

Traffic Server 為 HTTP 反向代理使用兩種類型的映射規則。

1. map rule

一個映射規則是將一個客戶端的請求 URL 轉換為定位內容的 URL。當 Traffic Server 使用反向代理模式並接收客戶端的 HTTP 請求，它必須從相關的 URL 和頭部來構造一個完整的 URL。Traffic Server 接下來使用這個完整的 URL 在 remap.config 文件中查找其匹配的目標 URL。要使請求 URL 匹配目標 URL，下面的條件必須滿足：

兩個 URL 必須是一個組合。
兩個 URL 的 host 必須相同。如果請求 URL 中包含一個不合格的主機名，它不可能匹配到一個具有合格的主機名的目標 URL。
兩個 URL 的端口號必須相同。如果指定的 URL 中沒有端口號，URL 的組合將使用默認的端口號。
目標 URL 的路徑部分必須可以和請求 URL 的前綴匹配。

如果 Traffic Server 找到一個匹配，它將請求 URL 轉換為映射規則中的替換 URL：它設置請求 URL 的 host 和路徑去匹配替換 URL。如果 URL 包含 path 前綴，Traffic Server 去掉 path 的和目標 URL 匹配的前綴，同時用替換 URL 中 path 來替換該 path。如果一個請求 URL 有兩個對應的匹配，Traffic Server 接受 remap.config 文件中的第一個匹配。

2. reverse-map rule

一個反向映射規則是將源服務器重定向響應中的 URL 轉換為指向 Traffic Server，這樣客戶端會再次重定向到 Traffic Server 而不是直接訪問一個源服務器。比如，在源服務器 www.molasses.com 上有一個 /pub 目錄，一個客戶端向該源服務器發送一個 /pub 的請求，源服務器可能回復一個 Location: http://realhost.com/pub/ 的重定向來告訴客戶端它請求的是一個目錄，而不是文檔（重定向通常的應用是標准化 URL，這樣客戶端可以正確地標記文檔）。

Traffic Server 使用 reverse_map 規則來阻止客戶端（從源服務器收到重定向）繞過 Traffic Server 直接訪問源服務器。

map 和 reverse-map 規則都由一個目標（源）URL 和一個替換（目的）URL 組成。在一個 map 規則中，目標 URL 指向 Traffic Server 而替換 URL 指定源服務器內容的位置。在一個 reverse-map 規則中，目標 URL 指定源服務器內容的位置而替換 URL 指向 Traffic Server。Traffic Server 在位於 Traffic Server 的 config 目錄下的 remap.config 文件中存儲映射規則。

為 HTTP 請求創建映射規則

將 map 和 reverse-map 規則寫入到 remap.config 中。
應用更改后的配置：traffic_ctl config reload.

啟用 HTTP 反向代理

編輯 records.config 中 proxy.config.reverse_proxy.enabled 變量來開啟反向代理模式。

CONFIG proxy.config.reverse_proxy.enabled INT 1

應用更改后的配置：traffic_ctl config reload.

設置可選的 HTTP 反向代理選項

Traffic Server 在 records.config 中提供了幾個反向代理配置選項，可以啟用它們：

配置 Traffic Server 在轉換的時候保存客戶端的 host 頭部信息。參見 proxy.config.url_remap.pristine_host_hdr.
- proxy.config.url_remap.pristine_host_hdr：
  - 1：Traffic Server 將保存客戶端請求的 host 頭部。
  - 0：Traffic Server 將轉換客戶端請求的 host 頭部。
配置 Traffic Server 只服務發往映射規則中的源服務器的請求。因此，發往不在映射規則中源服務器的請求將不會被服務。參見 proxy.config.url_remap.remap_required。
- proxy.config.url_remap.remap_required：
  - 1：Traffic Server 只為在 remap.config 文件的映射規則中的源服務器的請求服務。
  - 0：Traffic Server 服務所有源服務器的請求。
為來自老版本客戶端的請求指定一個替換的 URL（比如，沒有提供 host 頭部的客戶端）。參見 proxy.config.header.parse.no_host_url_redirect。
- proxy.config.header.parse.no_host_url_redirect：沒有 host 頭部的請求重定向的 URL。

執行 traffic_ctl config reload 以應用上面的配置更新。

2.3.3 重定向 HTTP 請求

可以配置 Traffic Server 不需要聯系任何源服務器就可以重定向 HTTP 請求。比如，如果想重定向所有去 www.ultraseek.com 的請求到 http://www.server1.com/products/portal/search/，則所有去 http://www.ultraseek.com 的請求將直接去 www.server1.com/products/portal/search。

可以通過 Traffic Server 配置永久或臨時重定向。永久重定向通知瀏覽器 URL 的變更（通過返回 HTTP 狀態碼 301），這樣瀏覽器就可以更新標簽。臨時重定向通知瀏覽器指示當前請求的 URL 變更（通過返回 HTTP 狀態碼 307）。

設置重定向規則：

為每個重定向設置一條映射規則到 remap.config 文件中。每個映射規則必須用一個分開的行並且必須由三個確定位置的區域：type、target 和 replacement 組成。如下描述了每個區域的格式。
- type：輸入其中的一個：
  - redirect：不聯系源服務器而永久重定向 HTTP 請求。
  - redirect-temporary：不聯系源服務器而臨時重定向 HTTP 請求。
- target：輸入源 URL。可以由四部分組成：scheme://host:port/path_prefix。
- replacement：輸入目標 URL。可以由四部分組成：scheme://host:port/path_prefix。
執行 ``traffic_ctl config reload``` 應用更改后的配置。

如下示例將到 www.server1.com 的所有的 HTTP 請求永久重定向到 www.server2.com：

redirect http://www.server1.com http://www.server2.com

2.4 顯式代理緩存（Explicit Proxy Caching）

2.5 透明代理緩存（Transparent Proxy Caching）

2.6 多級緩存（Hierarchical Caching）

Traffic Server 可以工作在多級緩存中，請求在一個緩存不能完成時可以路由到別的區域的緩存，從而利用附近緩存的內容。

2.6.1 理解多級緩存

一個多級緩存由可以相互通信的多層緩存組成。Traffic Server 支持若干種類型的多級緩存。所有的緩沖層級都通過父節點和子節點來識別。一個父節點緩存位於層級的高層，Traffic Server 可以向其轉發請求。一個子節點緩存是以 Traffic Server 為父節點的緩存。

Traffic Server 支持如下的層級緩存選項：

父節點緩存
ICP（Internet Cache Protocol）互連

2.6.2 父節點緩存

如果 Traffic Server 在自己的緩存中沒有找到被請求的對象，在從源服務器取回這個對象之前，它會先找一個父節點緩存（這個節點也可以去找別的緩存）。可以配置 Traffic Server 節點使用一個或多個父節點緩存，這樣如果一個父節點緩存不可用時，其它的父節點可以來響應請求。這就是父節點故障轉移。Traffic Server 支持 HTTP 和 HTTPS 的父節點緩存。

如果不想讓所有的請求都去父節點緩存，可以配置 Traffic Server 將特定的請求（比如包含特殊的 URL）直接路由到源服務器。簡單的父節點設置規則見 parent.config.

下圖展示了一個簡單的 Traffic Server 節點配置了父節點緩存的多級緩存。客戶端向在多級緩存中位於子節點（因為它配置了轉發未命中的請求到父節點緩存）的 Traffic Server 發送請求。請求在緩存中未命中，Traffic Server 就將其轉發給了其父節點緩存並且在父節點緩存中命中。隨后這個內容的請求可以直接由 Traffic Server來服務（直到數據過期或失效）。

如果請求在父節點緩存中也未命中，父節點會從源服務器獲取請求的內容（或者從其他緩存，取決於父節點的配置）。父節點緩存該內容並將內容的拷貝發送給 Traffic Server（其子節點），Traffic Server 緩存該內容並響應客戶端。

Parent Selection Policies

Traffic Server 子節點可以使用多種 parent selection policies：

一致性哈希。子節點為每個 URI 選擇一個特定的父節點。這有效地使父節點緩存大小等於每個父節點緩存大小的總和。
輪詢。子節點循環訪問父節點。子節點可以基於客戶端 IP（"true"）或者嚴格循環("strict") 中選擇父節點。
（未命名）。子節點選擇列出的第一個 live 父節點。這種策略有兩種變體。
- 當策略設置為 "false" 時，子節點將使用第一個列出的父節點（為了清晰起見，稱為 p1），直到標記為 down，則子節點將切換到第二個列出的父節點（p2）。然后，當重新檢測到 p1 為 live 時，子節點將重新使用 p1。
- 選擇策略設置為 "latched"，子節點將使用 p1 直到它被標記為 down，此時它將切換到 p2。當重新檢測發現 p1 為 live 時，子節點將繼續使用 p2，直到它被標記為 down。

與 remap.config 的交互

如果需要重新映射規則（proxy.config.reverse_proxy.enabled），當請求發送到子節點時，將在 parent selection 之前評估 remap.config。這意味着客戶端請求是按照重新映射規則進行轉換的，因此，應根據重新映射的主機名進行任意的 parent selection。無論是否啟用了 pristine host 頭部（proxy.config.url_remap.pristine_host_hdr）都是如此。父節點將接收已經轉換的請求（因此需要配置為接受它）。

示例

客戶端向 Traffic Server 請求 http://example.com，請求的源服務器是 http://origin.example.com；父節點是 parent1.example.com，子節點配置為反向代理。

如果子節點的 remap.config 包含：

map http://example.com http://origin.example.com

並且子節點的 parent.config 包含：

dest_domain=origin.example.com method=get parent="parent1.example.com:80"

父節點緩存（parent1.example.com）需要有一個和 remap.config 行類似的：

map http://origin.example.com http://origin.example.com

在此示例中，如果 parent1.example.com 為 down，則子節點將在緩存未命中時自動直接聯系 origin.exampel.com。

父節點故障轉移

Traffic Server 支持使用若干個父節點緩存。這樣確保一個父節點緩存不可用的情況下，其它的父節點緩存仍然可以服務客戶端請求。

當配置 Traffic Server 使用的父節點緩存多於一個，Traffic Server 在檢測到一個父節點不可用時，會發送未命中的請求到另一個父節點緩存。如果指定了多余兩個父節點緩存，父節點被詢問的順序取決於父節點代理規則在 parent.config 配置文件中的順序。默認情況下，父節點緩存被詢問的順序是它們在配置文件中的順序。

配置 Traffic Server 使用父節點緩存

要配置 Traffic Server 使用一個或多個父節點緩存，則必須執行下述步驟。

僅需要配置子節點緩存。假設配置父節點為子節點的源服務器，則作為 Traffic Server 父節點緩存的節點不需要額外的配置。

通過編輯位於 records.config 文件中的 proxy.config.http.parent_proxy.routing_enable 來啟用父節點緩存選項。

CONFIG proxy.config.http.parent_proxy_routing_enable INT 1

識別服務未命中請求的父節點緩存。要使用父節點故障轉移，必須識別多個父節點緩存，這樣當一個不可用時，請求可以發送到其它的父節點緩存。
編輯 parent.config 以設置父節點代理規則，該規則將指定當未命中請求時想要轉發請求的父節點緩存。

下面的示例配置 Traffic Server 將所有包含正則表達式 politics 和路徑 /viewpoint 的請求直接路由到其他源服務器（繞過任何的父節點緩存）：

url_regex=politics prefix=/viewpoint go_direct=true

下面的示例配置 Traffic Server 將所有以 mms://host1 開頭的 URL 未命中請求路由到父節點緩存 parent1。如果 parent1 不能服務這種請求，請求會被轉發到 parent2。因為 round-robin=true，Traffic Server 基於客戶端 IP 地址輪詢的方式來查詢父節點緩存。

dest_host=host1 scheme=http parent="parent1;parent2" round-robin=strict

最后執行 traffic_ctl config reload 以應用更改后的配置。

3. 安全（Security）

3.1 控制訪問（Controlling Access）

Traffic Server 可以配置僅允許某些客戶端使用代理緩存。

為每個允許訪問 Traffic Server 的 IP 地址或 IP 地址段在 ip_allow.config 文件中添加一行。
加載配置：traffic_ctl config reload。

3.2 SSL 終端（SSL Termination）

使能 Traffic Server SSL 終端選項可以在客戶端和 Traffic Server 或者 Traffic Server 和源服務器之間以反向代理模式安全地連接。

以下描述了如何使能並配置 SSL termination 選項。

為客戶端/Traffic Server 的連接使能和配置 SSL termination：Client and Traffic Server Connections.
為 Traffic Server/源服務器的連接使能並配置 SSL termination：Traffic Server and Origin Server Connections.

3.2.1 客戶端和 Traffic Server 連接

下圖說明了在 SSL 終端選項僅開啟和配置了客戶端和 Traffic Server 連接時客戶端和 Traffic Server（以及 Traffic Server 和源服務器）之間的通信。

上圖描述了以下步驟：

1.客戶端發送一個 HTTPS 內容請求。Traffic Server 接收請求並完成 SSL 握手來鑒別客戶端（取決於鑒別選項的配置）並決定接下來使用的加密算法。如果客戶端的訪問被允許，Traffic Server 在其緩存中查找被請求的內容。
2.如果請求在緩存命中且內容有效，Traffic Server 加密內容並發送給客戶端。客戶端解碼內容（使用握手時決定的方法）並展示它。
3.如果請求在緩存未命中或內容過期，Traffic Server 通過 HTTP 和源服務器通信並獲取明文的內容信息。Traffic Server 將明文內容信息保存到緩存，同時將內容加密並發送給客戶端。客戶端解密並展示內容。

要配置 Traffic Server 為客戶端和 Traffic Server 之間的連接使用 SSL 終端選項，步驟如下：

1.從公認的認證授權機構（如 VeriSign）獲取並安裝 SSL 服務證書。SSL 服務證書包含使客戶端鑒別 Traffic Server 以及交互加密密鑰的信息。
2.使用 records.config 文件中的 proxy.config.http.server_ports 為 SSL 通信設置端口號。
3.在 records.config 設置合適的 SSL 證書和密鑰路徑：

CONFIG proxy.config.ssl.server.cert.path STRING "/opt/ts/etc/ssl/certs/"
CONFIG proxy.config.ssl.server.private_key.path STRING "/opt/ts/etc/ssl/keys/"

4.為每個證書和密鑰添加一個條目到 ssl_multicert.config 中，以便 Traffic Server 系統用於終止與客戶端的 SSL 連接。

ip_dest=1.2.3.4 ssl_cert_name=example.com.pem
ip_dest=* ssl_cert_name=default.pem

5.可選地：使用 records.config 中的變量 proxy.config.ssl.client.certification_level 來配置客戶端證書的使用。如果配置 Traffic Server 需要客戶端證書，則 Traffic Server 必須在 SSL 握手階段驗證客戶端的證書。如果配置 Traffic Server 不需要客戶端證書，或者如果將證書配置為可選地，並且連接客戶端不提供證書，然后通過已經設置的其他 Traffic Server 選項（如 ip_allow.config 中的規則）管理對 Traffic Server 的訪問。

CONFIG proxy.config.ssl.client.certification_level INT 0

該變量允許設置為以下值之一：

- 0：不需要客戶端證書
- 1：客戶端證書可選。如果存在，則用於驗證。
- 2：需要客戶端證書，並必須基於配置的 CA 進行驗證。

6.可選地：配置使用 Certification Authorities（CAs）。CAs 通過驗證請求人員的身份來增加安全性。在 records.config 中通過 proxy.config.ssl.CA.cert.path 來配置可接受的 CA 簽名。

CONFIG proxy.config.ssl.CA.cert.path STRING "/opt/CA/certs/private-ca.pem"

7.加載配置：traffic_ctl config reload。

3.2.2 Traffic Server 和源服務器的連接

下圖說明了當為 Traffic Server 和源服務器的連接啟用了 SSL 終端選項時，Traffic Server 和源服務器之間的通信。

上圖描述的步驟如下：

1.如果客戶端請求在緩存未命中或已過期，Traffic Server 向源服務器發送一個 HTTPS 內容請求。源服務器接收請求並完成 SSL 握手來鑒別 Traffic Server 並決定接下來使用的加密算法。
2.如果 Traffic Server 被允許訪問，源服務器將內容加密並發送給 Traffic Server，Traffic Server 使用握手階段決定的方式來解密該內容。內容的明文（可緩存的情況下）被保存在緩存。
3.如果 SSL 終端開啟了客戶端和 Traffic Server 之間的連接，Traffic Server 將再次加密內容並通過 HTTPS 發送給客戶端，客戶端解密並展示內容。如果 SSL 終端沒有開啟了客戶端和 Traffic Server 之間連接，Traffic Server 將通過 HTTP 發送明文內容給客戶端。

為了配置 Traffic Server 在 Traffic Server 和源服務器之間啟用 SSL 終端選項，步驟如下：

1.首先確保源服務器可以正確響應 SSL 請求，並且如果打算使用其作為訪問控制方案的一部分，則配置它以進行客戶端證書驗證。
更多細節參見源服務器文檔。如果源服務器是另一個 Traffic Server 系統，則可以按照客戶端和 Traffic Server 連接中的步驟概述來配置源服務器以驗證客戶端證書。
2.可選地：如果源服務器需要客戶端證書驗證以進行訪問控制，則從公認的證書授權機構中獲取並安裝 SSL 客戶端證書。客戶端證書必須由源服務器識別的證書頒發機構簽名。
如果使用的是客戶端證書，則必須在設置 proxy.config.ssl.client.cert.path 和 proxy.config.ssl.client.cert.filename 中將其位置添加到 records.config 。

CONFIG proxy.config.ssl.client.cert.path STRING "/opt/ts/etc/ssl/certs/"
CONFIG proxy.config.ssl.client.cert.filename STRING "client.pem"

必須提供此證書的私鑰路徑，除非私鑰包含在與證書同一個文件中：

CONFIG proxy.config.ssl.client.private_key.path STRING "/opt/ts/etc/ssl/keys/"
CONFIG proxy.config.ssl.client.private_key.filename STRING "client.pem"

3.根據安全策略，使用 records.config 中的 proxy.config.ssl.client.verify.server 變量來啟用或禁用服務器 SSL 證書驗證：

CONFIG proxy.config.ssl.client.verify.server INT 1

4.設置 records.config 中的 proxy.config.ssl.client.CA.cert.path 和 proxy.config.ssl.client.CA.cert.filanem 來將授權證書頒發機構的集合添加到 Traffic Server 配置中。

CONFIG proxy.config.ssl.client.CA.cert.path STRING "/opt/ts/etc/ssl/certs/"
CONFIG proxy.config.ssl.client.CA.cert.filename STRING "CAs.pem"

5.更新配置：traffic_ctl config reload。

3.2.3 Rotating TLS Session Ticket Keys

可以通過 session tickets 恢復 TLS 會話，session tickets 使用 session ticket key 加密並存儲在客戶端上。為了更好的安全性，可以定期輪換 ticket key，如每 24 小時輪換一次。ticket key 作為 48-byte 塊中的反向隊列存儲在 ticket key 文件中。

生成一個新的 ticket key，並將其 push 到 ticket key 文件的開頭。
可選地：從 ticket key 文件中刪除上一個 ticket key。
touch ssl_multicert.config 以指示 SSL 配置是過期的。
加載更新后的配置：traffic_ctl config reload。

3.2.4 OCSP Stapling

OCSP Stapling 是使用在線證書狀態協議來檢測 SSL 證書撤銷狀態的另一種方法。

在最初的 OCSP 實現下，客戶端直接從頒發證書的證書頒發機構（CA）請求證書的撤銷狀態。這可能會導致 CA 服務器上出現大量負載，因為它們需要定時向給定證書的每個客戶端提供響應。

啟用 OCSP Stapling 指示 Traffic Server 去檢索並緩存所有已配置 SSL 證書的撤銷狀態，並當客戶端請求狀態時將其提供給客戶端。Traffic Server 將會自動查詢 SSL 證書中指定的 OCSP 響應器，以收集最新的撤銷狀態。Traffic Server 將緩存每個配置證書的結果。OCSP 響應器的位置取自簽名證書的 "Authority Information Access" 字段。比如：

Authority Information Access:
            OCSP - URI:http://ocsp.digicert.com
            CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2SecureServerCA.crt

可以使用 OpenSSL 客戶端的 -status 選項測試對 OCSP Stapling 的支持：

$ openssl s_client -connect mozillalabs.com:443 -status
...
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
...

OCSP Stapling TLS 擴展的詳細信息位於 RFC 6961。

為了配置 Traffic Server 使用 OCSP Stapling，編輯位於 records.config 文件中的如下變量：

proxy.config.ssl.ocsp.enabled
proxy.config.ssl.ocsp.cache_timeout
proxy.config.ssl.ocsp.request_timeout
proxy.config.ssl.ocsp.update_period

3.2.5 Split DNS

啟用 Split DNS 選項可以配置 Traffic Server 使用多個 DNS 服務器，這取決於安全需求。比如，可以配置 Traffic Server 使用一組 DNS 服務器來解析內部網絡的主機名，同時允許防火牆外的 DNS 服務器解析網絡上的主機。這可以維護 internet 的安全性，同時繼續提供對 organization 外站點的直接訪問。

配置 Split DNS：

基於目標域，目標主機，或者 URL 正則表達式指定執行 DNS 服務器選擇的規則。這些規則位於 splitdns.config：
通過 records.config 中的 proxy.config.dns.splitDNS.enabled 來啟用 Split DNS：

CONFIG proxy.config.dns.splitDNS.enabled INT 1

加載配置：traffic_ctl config reload.

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 ZooKeeper管理員指南(九) MinIO管理員完整指南 Welink 管理員使用指南 Apache NiFi系統管理員指南 [ 一 ] ceph之ceph-mgr管理員指南 Apache NiFi系統管理員指南 [ 四 ] HUAWEI SecoClient客戶端管理員指南修改ArcGIS Server Account / 站點管理員的賬號、密碼 SQL Server DAC——專用管理員連接 Windows Server 2008 R2父域管理員與子域管理員相互登錄訪問