深入理解 ASP.NET 與客戶端快取的 HTTP 協定機制

在開發高效能 Web 應用程式時，善用客戶端快取是提升回應速度、降低伺服器負載的關鍵。ASP.NET 提供了豐富的伺服器端 API 來控制 HTTP 快取相關標頭，讓開發者能建立可配置、可擴充的快取策略。本文將從 HTTP 協定層面剖析快取運作原理，再說明 ASP.NET 如何操控這些標頭以實現最佳化。

HTTP 快取的核心標頭

Last-Modified / If-Modified-Since

當瀏覽器首次請求資源時，伺服器回傳 200 OK 並附上 Last-Modified 標頭，標示資源最後修改時間（如 Fri, 12 May 2006 18:53:33 GMT）。瀏覽器再次請求時會攜帶 If-Modified-Since 標頭詢問該時間後是否有變更。若資源未異動，伺服器回傳 304 Not Modified 且不傳送內容，節省頻寬；若已修改，則回傳 200 與新內容。

ETag / If-None-Match

ETag（Entity Tag）提供另一種驗證機制，RFC 2616 未強制其格式，只需用雙引號包裹（如 "50b1c1d4f775c61:df3"），常見做法是使用檔案雜湊值或版本號。瀏覽器以 If-None-Match 送出先前收到的 ETag，伺服器比對後決定回傳 304 或 200。ETag 可解決 Last-Modified 精度只到秒、或檔案修改時間卻內容未變等問題。

Expires

Expires 直接宣告資源過期時間（如 Sun, 10 Feb 2002 16:00:00 GMT），過期前瀏覽器直接使用快取不發請求。ASP.NET 中舊有的 HttpResponse.ExpiresAbsolute 已不建議使用，應改用 HttpResponse.Cache.SetExpires。

Pragma

HTTP/1.0 遺留標頭，常用 Pragma: no-cache 禁止快取，語意等同於 Cache-Control: no-cache，現代應用以 Cache-Control 為主。

Cache-Control

功能最強大、可擴充的快取控制標頭，支援多個指令組合：

• max-age：以秒為單位的相對過期時間，優先級高於 Expires。
• public：允許共用快取（如 Proxy）儲存回應。
• private：僅允許私有快取（瀏覽器）儲存，不得由共用快取儲存。
• no-cache：強制每次請求都向伺服器驗證（需搭配 ETag/Last-Modified）。
• no-store：嚴禁在任何持久儲存體寫入快取。
• no-transform：禁止中間節點轉換內容格式（如壓縮圖片）。

ASP.NET 實作建議

在 ASP.NET 中，透過 HttpResponse.Cache 物件即可精確設定上述標頭。例如：

Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.SetMaxAge(TimeSpan.FromMinutes(30));
Response.Cache.SetETag("\"v1.2.3\"");
Response.Cache.SetLastModified(DateTime.UtcNow.AddDays(-1));

結合 web.config 的 <caching> 區段，更能集中管理靜態資源與動態頁面的快取原則，達成可配置、可擴充的目標。