對一條 HTTP GET 報文的基本快取處理過程包括 7 個步驟：
1. 接收——快取從網路中讀取抵達的請求報文。
2. 解析——快取對報文進行解析，提取出 URL 和各種首部。
3. 查詢——快取檢視是否有本地副本可用，如果沒有，就獲取一份副本(並將其儲存在本地)。
4. 新鮮度檢測——快取檢視已快取副本是否足夠新鮮，如果不是，就詢問伺服器是否有任何更新。
5. 建立響應——快取會用新的首部和已快取的主體來構建一條響應報文。
6. 傳送——快取通過網路將響應發回給客戶端。
7. 日誌——快取可選地建立一個日誌檔案條目來描述這個事務。

1. 接收

• 在第一步中，快取檢測到一條網路連線上的活動，讀取輸入資料。
• 高效能的快取會同時從多條輸入連線上讀取資料，在整條報文抵達之前開始對事務進行處理。

2. 解析

• 快取將請求報文解析為片斷，將首部的各個部分放入易於操作的資料結構中。這樣，快取軟體就更容易處理首部欄位並修改它們了。
• 解析程式還要負責首部各部分的標準化，將大小寫或可替換資料格式之類不太重要的區別都看作等效的。而且，某些請求報文中包含有完整的絕對 URL，而其他一些請求中包含的則是相對 URL 和 Host 首部，所以解析程式通常都要將這些細節隱藏起來。

3. 查詢

• 快取獲取了 URL，查詢本地副本。本地副本可能儲存在記憶體、本地磁碟，甚至附近的另一臺計算機中。
• 專業級的快取會使用快速演算法來確定本地快取中是否有某個物件。如果本地沒有這個文件，它可以根據情形和配置，到原始伺服器或父代理中去取，或者返回一條錯誤資訊。
• 已快取物件中包含了伺服器響應主體和原始伺服器響應首部，這樣就會在快取命中時返回正確的伺服器首部。
• 已快取物件中還包含了一些元資料(metadata)，用來記錄物件在快取中停留了多長時間，以及它被用過多少次等。
• 複雜的快取還會保留引發伺服器響應的原始客戶端響應首部的一份副本，以用於 HTTP/1.1 內容協商。

4. 新鮮度檢測

• HTTP 通過快取將伺服器文件的副本保留一段時間。在這段時間裡，都認為文件是“新鮮的”，快取可以在不聯絡伺服器的情況下，直接提供該文件。
• 一旦已快取副本停留的時間太長，超過了文件的新鮮度限值(freshness limit)，就認為物件“過時”了，在提供該文件之前，快取要再次與伺服器進行確認，以檢視文件是否發生了變化。
• 客戶端傳送給快取的所有請求首部自身都可以強制快取進行再驗證，或者完全避免驗證，這使得事情變得更加複雜了。
• HTTP 有一組非常複雜的新鮮度檢測規則，快取產品支援的大量配置選項，以及與非 HTTP 新鮮度標準進行互通的需要則使問題變得更加嚴重了。

5. 建立響應

• 我們希望快取的響應看起來就像來自原始伺服器的一樣，快取將已快取的伺服器響應首部作為響應首部的起點。然後快取對這些基礎首部進行了修改和擴充，以便與客戶端的要求相匹配。
• 比如：伺服器返回的可能是一條 HTTP/1.0 響應(甚至是 HTTP/0.9 響應)，而客戶端期待的是一條 HTTP/1.1 響應，在這種情況下，快取必須對首部進行相應的轉換。
• 快取還會向其中 插入新鮮度資訊(Cache-Control、Age 以及 Expires 首部)，而且通常會包含一個 Via 首部來說明請求是由一個代理快取提供的。
• 注意：快取不應該調整 Date 首部。Date 首部表示的是原始伺服器最初產生這個物件的日期。

6. 傳送

• 一旦響應首部準備好了，快取就將響應回送給客戶端。
• 和所有代理伺服器一樣，代理快取要管理與客戶端之間的連線。
• 高效能的快取會盡力高效地傳送資料，通常可以避免在本地快取和網路 I/O 緩衝區之間進行文件內容的複製。

7. 日誌

• 大多數快取都會儲存日誌檔案以及與快取的使用有關的一些統計資料。
• 每個快取事 務結束之後，快取都會更新快取命中和未命中數目的統計資料(以及其他相關的度量值)，並將條目插入一個用來顯示請求型別、URL 和所發生事件的日誌檔案。
• 最常見的快取日誌格式為 Squid 日誌格式和網景的可擴充套件通用日誌格式，但很多快取產品都允許使用者建立自定義的日誌檔案。

8. 快取處理流程圖

以簡化形式顯示了快取是如何處理請求以 GET 一個 URL 的：