Apache HTTP 伺服器 2.4 版
Apache HTTP 伺服器 2.4 版
本文檔補充了 mod_cache、mod_cache_disk、mod_file_cache 和 htcacheclean 參考文件的內容。它描述了如何使用 Apache HTTP 伺服器的快取功能來加速網頁和代理伺服器，同時避免常見問題和錯誤配置。
Apache HTTP 伺服器提供了一系列快取功能，旨在以各種方式提高伺服器的效能。
mod_cache 及其提供者模組 mod_cache_disk 提供了智慧型、HTTP 感知的快取。內容本身儲存在快取中，mod_cache 旨在遵循 RFC2616 第 13 節 中描述的所有各種 HTTP 標頭和選項，這些標頭和選項控制內容的可快取性。mod_cache 適用於簡單和複雜的快取配置，在這些配置中，您需要處理代理內容、動態本地內容或需要加速對潛在緩慢磁碟上的本地檔案的訪問。mod_file_cache 提供了在伺服器啟動時將檔案預載入到內存中的功能，並且可以縮短訪問時間並節省經常訪問的檔案的檔案控制代碼，因為不需要在每次請求時都訪問磁碟。要充分利用本文檔，您應該熟悉 HTTP 的基礎知識，並且已經閱讀了 將 URL 映射到檔案系統 和 內容協商 的使用者指南。
| 相關模組 | 相關指令 |
|---|---|
HTTP 協議包含對內聯快取機制的內建支援，RFC2616 第 13 節 對此進行了描述，並且可以使用 mod_cache 模組來利用此功能。
與簡單的二態鍵值快取不同，在簡單的二態鍵值快取中，內容在不再新鮮時會完全消失，HTTP 快取包含一種保留過時內容的機制，並詢問原始伺服器此過時內容是否已更改，如果沒有更改，則使其再次變為新鮮。
HTTP 快取中的條目存在於以下三種狀態之一：
如果內容太舊（比其新鮮度生命週期長），則認為它是過時的。HTTP 快取應聯繫原始伺服器，並在將過時內容提供給客戶端之前檢查內容是否仍然新鮮。如果不再有效，原始伺服器將響應替換內容，或者理想情況下，原始伺服器將響應一個代碼，告訴快取內容仍然新鮮，而無需再次生成或發送內容。內容再次變為新鮮，並且循環繼續。
HTTP 協議允許快取在某些情況下提供過時數據，例如當嘗試使用原始伺服器刷新數據失敗並出現 5xx 錯誤時，或者當另一個請求已在刷新給定條目的過程中時。在這些情況下，會在響應中添加 Warning 標頭。
有關 HTTP 快取工作原理的詳細信息，請參見 RFC2616 的 第 13 節。
mod_cache 模組可以掛接到伺服器中的兩個可能位置，具體取決於 CacheQuickHandler 指令的值
此階段發生在請求處理的非常早期，就在請求被解析之後。如果在快取中找到內容，則會立即提供內容，並且幾乎所有請求處理都會被繞過。
在此場景中，快取的行為就像它被“固定”在伺服器的前面一樣。
此模式提供了最佳效能，因為繞過了大部分伺服器處理。但是，此模式也繞過了伺服器處理的身份驗證和授權階段，因此在身份驗證和授權很重要時，應謹慎選擇此模式。
當 mod_cache 在此階段運行時，帶有“Authorization”標頭（例如，HTTP 基本身份驗證）的請求既不可快取，也不會從快取中提供。
此階段發生在請求處理的後期，在所有請求階段都完成之後。
在此場景中，快取的行為就像它被“固定”在伺服器的後面一樣。
此模式提供了最大的靈活性，因為有可能在篩選器鏈中精確控制的點進行快取，並且可以在將快取的內容發送到客戶端之前對其進行篩選或個性化。
如果在快取中找不到 URL，mod_cache 將向篩選器堆棧添加一個 篩選器，以便將響應記錄到快取中，然後退出，允許正常的請求處理繼續。如果確定內容是可快取的，則內容將保存到快取中以供將來提供，否則內容將被忽略。
如果在快取中找到的內容已過時，mod_cache 模組會將請求轉換為條件請求。如果原始伺服器響應正常響應，則會快取正常響應，替換已快取的內容。如果原始伺服器響應 304 Not Modified 響應，則內容將再次標記為新鮮，並且篩選器會提供快取的內容，而不是保存它。
當虛擬主機由許多不同的伺服器別名之一所知時，確保將 UseCanonicalName 設置為 On 可以顯著提高快取命中率。這是因為提供內容的虛擬主機的主機名用於快取鍵中。如果將設置設置為 On，則具有多個伺服器名稱或別名的虛擬主機將不會產生不同的快取實體，而是根據規範主機名快取內容。
格式良好的、旨在快取的內容應使用 Cache-Control 標頭的 max-age 或 s-maxage 字段，或者通過包含 Expires 標頭來聲明明確的新鮮度生命週期。
同時，當客戶端在請求中提供自己的 Cache-Control 標頭時，客戶端可以覆蓋原始伺服器定義的新鮮度生命週期。在這種情況下，請求和響應之間的最低新鮮度生命週期獲勝。
當請求或響應中缺少此新鮮度生命週期時，將應用預設新鮮度生命週期。快取實體的預設新鮮度生命週期為一小時，但是可以使用 CacheDefaultExpire 指令輕鬆覆蓋此生命週期。
如果響應不包含 Expires 標頭，但包含 Last-Modified 標頭，則 mod_cache 可以根據啟發式推斷新鮮度生命週期，可以使用 CacheLastModifiedFactor 指令控制此啟發式。
對於本地內容或未定義自己的 Expires 標頭的遠程內容，可以使用 mod_expires 通過添加 max-age 和 Expires 來微調新鮮度生命週期。
也可以使用 CacheMaxExpire 控制最大新鮮度生命週期。
當內容從快取中過期並變為過時時，httpd 不會傳遞原始請求，而是會修改請求以使其成為條件請求。
當原始快取響應中存在 ETag 標頭時，mod_cache 將向發送到原始伺服器的請求添加 If-None-Match 標頭。當原始快取響應中存在 Last-Modified 標頭時，mod_cache 將向發送到原始伺服器的請求添加 If-Modified-Since 標頭。執行這些操作中的任何一個都會使請求成為條件請求。
當原始伺服器收到條件請求時，原始伺服器應檢查 ETag 或 Last-Modified 參數是否已更改，具體取決於請求。如果沒有更改，則原始伺服器應響應簡潔的“304 Not Modified”響應。這向快取發出信號，表明過時內容仍然是新鮮的，應在內容的新鮮度生命週期再次達到之前用於後續請求。
如果內容已更改，則內容的提供方式就像請求一開始就不是條件請求一樣。
條件請求有兩個好處。首先，當向原始伺服器發出此類請求時，如果來自原始伺服器的內容與快取中的內容匹配，則可以輕鬆確定，而無需傳輸整個資源的開銷。
其次，設計良好的原始伺服器會以條件式請求的產生成本遠低於完整回應的方式來設計。對於靜態檔案，通常只需要呼叫 stat() 或類似的系統呼叫，即可查看檔案大小或修改時間是否已更改。因此，即使是本機內容，如果沒有更改，從快取中提供服務的速度可能仍然更快。
原始伺服器應盡一切努力在實際可行的情況下支援條件式請求，但如果不支援條件式請求，原始伺服器將會像請求不是條件式請求一樣回應，並且快取將會像內容已更改一樣回應，並將新內容儲存到快取中。在這種情況下，快取的行為會像一個簡單的雙狀態快取，其中內容實際上不是新鮮的就是被刪除的。
HTTP 快取可以快取哪些回應的完整定義在 RFC2616 第 13.4 節回應可快取性 中定義，可以總結如下
CacheEnable 和 CacheDisable 指令。CacheIgnoreNoLastMod 指令要求其他方式。CacheStorePrivate 要求其他方式，否則它將不會被儲存。CacheStoreNoStore，否則它將不會被儲存。應該由建立請求的客戶端或建構回應的原始伺服器通過正確設定 Cache-Control 標頭來決定內容是否應該可快取，並且 mod_cache 應該單獨保留以適當地尊重客戶端或伺服器的意願。
對時間敏感或根據 HTTP 協商未涵蓋的請求細節而變化的內容不應被快取。此內容應使用 Cache-Control 標頭宣告自身不可快取。
如果內容經常更改（以分鐘或秒表示的新鮮度生命週期），則內容仍然可以被快取，但是強烈建議原始伺服器正確支援**條件式請求**，以確保不必定期產生完整的回應。
可以通過智慧地使用 Vary 回應標頭來快取基於客戶端提供的請求標頭而變化的內容。
當原始伺服器被設計為根據請求中標頭的值回應不同的內容時（例如，在同一個 URL 上提供多種語言），HTTP 的快取機制可以讓同一個頁面的多個變體在同一個 URL 上被快取。
這是通過原始伺服器新增 Vary 標頭來完成的，以指示快取在確定兩個變體是否彼此不同時必須考慮哪些標頭。
例如，如果收到帶有 vary 標頭的回應，例如；
Vary: negotiate,accept-language,accept-charset
mod_cache 將僅向 accept-language 和 accept-charset 標頭與原始請求匹配的請求者提供快取的內容。
可以並排快取多個內容變體，mod_cache 使用 Vary 標頭和 Vary 列出的請求標頭的對應值來決定將多個變體中的哪一個返回給客戶端。
| 相關模組 | 相關指令 |
|---|---|
mod_cache 模組依賴特定的後端儲存實作來管理快取，並且提供了 mod_cache_disk 來支援快取到磁碟。
通常，模組將會配置如下；
CacheRoot "/var/cache/apache/" CacheEnable disk / CacheDirLevels 2 CacheDirLength 1
重要的是，由於快取的檔案是本地儲存的，因此作業系統的記憶體內快取通常也會應用於它們的存取。因此，儘管檔案儲存在磁碟上，但如果它們被頻繁存取，作業系統很可能會確保它們實際上是從記憶體中提供的。
為了在快取中儲存項目，mod_cache_disk 會建立被請求 URL 的 22 個字元雜湊。此雜湊包含主機名、協定、埠、路徑和 URL 的任何 CGI 參數，以及 Vary 標頭定義的元素，以確保多個 URL 不會互相衝突。
每個字元可以是 64 個不同字元中的任何一個，這表示總共有 64^22 個可能的雜湊。例如，URL 可能會被雜湊為 xyTGxSMO2b68mBCykqkp1w。此雜湊用作快取中特定於該 URL 的檔案命名字首，但是首先它會根據 CacheDirLevels 和 CacheDirLength 指令拆分到目錄中。
CacheDirLevels 指定應該有多少級子目錄，而 CacheDirLength 指定每個目錄中應該有多少個字元。使用上面給出的範例設定，雜湊將會變成檔名字首，例如 /var/cache/apache/x/y/TGxSMO2b68mBCykqkp1w。
這種技術的總體目標是減少特定目錄中可能存在的子目錄或檔案的數量，因為大多數檔案系統會隨著此數量的增加而變慢。將 CacheDirLength 設定為「1」，在任何特定級別最多可以有 64 個子目錄。設定為 2 時，可以有 64 * 64 個子目錄，依此類推。除非您有充分的理由不這樣做，否則建議將 CacheDirLength 設定為「1」。
設定 CacheDirLevels 取決於您預計在快取中儲存多少個檔案。使用上面範例中使用的「2」設定，最終可以建立總共 4096 個子目錄。如果快取了 100 萬個檔案，則每個目錄大約有 245 個快取的 URL。
每個 URL 在快取儲存區中至少使用兩個檔案。通常有一個「.header」檔案，其中包含有關 URL 的中繼資訊，例如它何時到期，以及一個「.data」檔案，它是將要提供的內容的逐字副本。
在通過「Vary」標頭協商內容的情況下，將會為相關 URL 建立一個「.vary」目錄。此目錄將有多個對應於不同協商內容的「.data」檔案。
mod_cache_disk 模組不會嘗試調節快取使用的磁碟空間量，儘管它會在發生任何磁碟錯誤時優雅地退出，並表現得好像快取從未存在過一樣。
相反，httpd 提供了 htcacheclean 工具，它允許您定期清理快取。確定執行 htcacheclean 的頻率以及快取的目标大小有些複雜，可能需要反覆試驗才能選擇最佳值。
htcacheclean 有兩種操作模式。它可以作為持續性守護程式運行，也可以定期從 cron 運行。htcacheclean 可能需要一個小時或更長時間才能處理非常大的（數十 GB）快取，如果您從 cron 運行它，建議您確定典型運行需要多長時間，以避免同時運行多個實例。
還建議為 htcacheclean 選擇適當的「nice」級別，以便該工具在伺服器運行時不會導致過多的磁碟 io。
圖 1：典型的快取增長/清理順序。
因為 mod_cache_disk 本身不注意使用了多少空間，所以您應該確保 htcacheclean 配置為在清理後留下足夠的「增長空間」。
使用 mod_cache_socache 模組，mod_cache 可以快取來自各種實作（也稱為「提供者」）的資料。例如，使用 mod_socache_memcache 模組，可以指定將 memcached 用作後端儲存機制。
通常，模組將會配置如下
CacheEnable socache / CacheSocache memcache:memcd.example.com:11211
可以通过将其他 memcached 伺服器添加到 CacheSocache memcache: 行的末尾（以逗号分隔）来指定它们
CacheEnable socache / CacheSocache memcache:mem1.example.com:11211,mem2.example.com:11212
此格式也與其他各種 mod_cache_socache 提供者一起使用。例如
CacheEnable socache / CacheSocache shmcb:/path/to/datafile(512000)
CacheEnable socache / CacheSocache dbm:/path/to/datafile
| 相關模組 | 相關指令 |
|---|---|
Apache HTTP 伺服器提供了一個低級別的共用物件快取，用於在 socache 介面中快取資訊，例如 SSL 會話或驗證憑證。
為每個實作提供了額外的模組，提供以下後端
mod_socache_dbmmod_socache_dcmod_socache_memcachemod_socache_shmcb| 相關模組 | 相關指令 |
|---|---|
mod_authn_socache 模組允許快取驗證結果，從而減輕驗證後端的負擔。
| 相關模組 | 相關指令 |
|---|---|
mod_ssl 模組使用 socache 介面來提供會話快取和裝訂快取。
| 相關模組 | 相關指令 |
|---|---|
在檔案系統可能很慢或檔案控制代碼很昂貴的平台上，可以选择在啟動時將檔案預先載入到記憶體中。
在開啟檔案速度很慢的系統上，可以选择在啟動時開啟檔案並快取檔案控制代碼。這些選項可以幫助存取靜態檔案速度很慢的系統。
開啟檔案的動作本身就可能造成延遲，尤其是在網路檔案系統上。透過維護常用檔案的已開啟檔案描述符快取，httpd 可以避免這種延遲。目前 httpd 提供了一種檔案控制代碼快取的實作。
httpd 中最基本的快取形式是由 mod_file_cache 提供的檔案控制代碼快取。這種快取不是快取檔案內容，而是維護一個已開啟檔案描述符的表格。要以這種方式快取的檔案會在設定檔中使用 CacheFile 指令指定。
CacheFile 指令指示 httpd 在啟動時開啟檔案，並將此檔案控制代碼重複用於所有後續對此檔案的存取。
CacheFile /usr/local/apache2/htdocs/index.html
如果您打算以這種方式快取大量檔案，則必須確保您的作業系統的已開啟檔案數量限制已設定妥當。
雖然使用 CacheFile 並不會導致檔案內容本身被快取，但這確實表示如果檔案在 httpd 執行時發生變更，這些變更將不會被擷取。檔案將會持續以 httpd 啟動時的狀態提供服務。
如果檔案在 httpd 執行時被移除，它將會繼續維護一個已開啟的檔案描述符，並以 httpd 啟動時的狀態提供檔案服務。這通常也表示，雖然檔案已被刪除，且不會顯示在檔案系統中，但在 httpd 停止且檔案描述符關閉之前，額外的可用空間將不會被回收。
直接從系統記憶體提供服務是提供內容的最快方法。從磁碟控制器或更糟的是從遠端網路讀取檔案的速度要慢上好幾個數量級。磁碟控制器通常涉及物理過程，而網路存取則受限於您可用的頻寬。另一方面，記憶體存取只需幾奈秒。
然而，系統記憶體並不便宜，以位元組為單位，它是迄今為止最昂貴的儲存類型，因此確保有效地使用它非常重要。透過將檔案快取到記憶體中，您可以減少系統上可用的記憶體量。正如我們將看到的，在作業系統快取的情況下，這不是什麼大問題，但在使用 httpd 自己的記憶體內快取時，務必確保不要將太多記憶體分配給快取。否則，系統將被迫交換記憶體，這可能會降低效能。
幾乎所有現代作業系統都會將檔案資料快取到由核心直接管理的記憶體中。這是一個強大的功能，在大多數情況下，作業系統都能正確處理。例如，在 Linux 上，讓我們看看第一次和第二次讀取檔案所需時間的差異；
colm@coroebus:~$ time cat testfile > /dev/null real 0m0.065s user 0m0.000s sys 0m0.001s colm@coroebus:~$ time cat testfile > /dev/null real 0m0.003s user 0m0.003s sys 0m0.000s
即使是這麼小的檔案，讀取檔案所需的時間也有很大的差異。這是因為核心已將檔案內容快取到記憶體中。
透過確保系統上有「備用」記憶體，您可以確保越來越多的檔案內容將儲存在此快取中。這是一種非常有效的記憶體內快取方式，而且完全不需要額外設定 httpd。
此外，由於作業系統知道檔案何時被刪除或修改，因此它可以在必要時自動從快取中移除檔案內容。與 httpd 的記憶體內快取相比，這是一個很大的優勢，因為 httpd 無法知道檔案何時發生變更。
儘管自動作業系統快取具有效能和優勢，但在某些情況下，由 httpd 執行記憶體內快取可能會更好。
mod_file_cache 提供了 MMapFile 指令，它允許您讓 httpd 在啟動時將靜態檔案的內容映射到記憶體中（使用 mmap 系統呼叫）。httpd 將使用記憶體內的內容來處理所有後續對此檔案的存取。
MMapFile /usr/local/apache2/htdocs/index.html
與 CacheFile 指令一樣，這些檔案中的任何變更在 httpd 啟動後都不會被擷取。
MMapFile 指令不會追蹤它分配了多少記憶體，因此您必須確保不要過度使用該指令。每個 httpd 子行程都會複製此記憶體，因此務必確保映射的檔案不要太大，以免導致系統交換記憶體。
使用 mod_cache 的預設狀態，其中 CacheQuickHandler 設定為 On，就像在伺服器前面安裝了一個快取反向代理。快取模組將會提供請求，除非它判斷應該查詢原始伺服器，就像外部快取一樣，這會大幅改變 httpd 的安全性模型。
由於遍歷檔案系統階層以檢查潛在的 .htaccess 檔案將是一項非常昂貴的操作，部分抵消了快取的目的（加快請求速度），因此 mod_cache 不會決定是否授權提供快取的實體。換句話說，如果 mod_cache 已快取某些內容，只要該內容尚未過期，就會從快取中提供該內容。
例如，如果您的設定允許透過 IP 位址存取資源，則應確保此內容未被快取。您可以使用 CacheDisable 指令或 mod_expires 來執行此操作。如果未經檢查，mod_cache（很像反向代理）會在提供內容時快取內容，然後將其提供給任何 IP 位址上的任何用戶端。
當 CacheQuickHandler 指令設定為 Off 時，會執行完整的請求處理階段，且安全性模型保持不變。
由於可以從快取中提供對終端使用者的請求，因此快取本身可能會成為那些想要塗鴉或干擾內容的人的目標。務必牢記，快取必須始終可由執行 httpd 的使用者寫入。這與通常建議的所有內容都不可由 Apache 使用者寫入的情況形成鮮明對比。
如果 Apache 使用者遭到入侵，例如透過 CGI 程式的漏洞，則快取可能會成為目標。使用 mod_cache_disk 時，插入或修改快取的實體相對容易。
與其他可能以 Apache 使用者身分發動的攻擊類型相比，這帶來了一些風險。如果您正在使用 mod_cache_disk，請牢記這一點 - 確保在發布安全性更新時升級 httpd，並盡可能使用 suEXEC 以非 Apache 使用者身分執行 CGI 程式。
當 httpd 作為快取代理伺服器執行時，也可能發生所謂的快取污染。快取污染是一個廣泛的術語，指的是攻擊者導致代理伺服器從原始伺服器擷取不正確（通常是不希望的）內容的攻擊。
例如，如果執行 httpd 的系統使用的 DNS 伺服器容易受到 DNS 快取污染的攻擊，則攻擊者可能可以控制 httpd 在從原始伺服器請求內容時連線到的位置。另一個例子是所謂的 HTTP 請求走私攻擊。
本文檔不是深入討論 HTTP 請求走私的正確場所（您可以嘗試使用您喜歡的搜尋引擎），但務必了解，可以發出一系列請求，並利用原始網路伺服器上的漏洞，以便攻擊者可以完全控制代理擷取的內容。
Vary 機制允許並排快取同一個 URL 的多個變體。根據用戶端提供的標頭值，快取將選擇正確的變體返回給用戶端。當嘗試根據已知在正常使用下包含各種可能值的標頭（例如 User-Agent 標頭）進行變更時，此機制可能會成為問題。根據特定網站的熱門程度，可能會為同一個 URL 建立數千或數百萬個重複的快取項目，從而擠掉快取中的其他項目。
在其他情況下，可能需要在每次請求時更改特定資源的 URL，通常是透過在 URL 中新增「快取清除」字串來實現。如果伺服器將此內容宣告為可快取，且具有顯著的新鮮度生命週期，則這些項目可能會擠掉快取中的合法項目。雖然 mod_cache 提供了 CacheIgnoreURLSessionIdentifiers 指令，但應謹慎使用此指令，以確保下游代理或瀏覽器快取不會遇到相同的阻斷服務問題。