fbpx

初探 HTTP 1.1 Cache 機制

Http://

Caching in HTTP

我們都知道 Cache (快取) 的目的就是讓系統反應變快,理所當然快取的概念也同樣設計在 HTTP。HTTP 1.1 是遵循 REST (Representational state transfer) 的架構進行設計,我們先回顧一下 Architectural Styles and the Design of Network-based Software Architectures (by Roy Thomas Fielding) 這一篇文章中,所提到的 Cache 概念。在「CHAPTER 5. Representational State Transfer (REST)」這一個章節中有明確提及 Cache 這個角色在 REST 架構中的位置,如下圖:

5-4

上圖中所代表的「$」就是 Cache 的意思,上圖的架構是把 Cache 放在 Client 中,Client 各位可以想像為瀏覽器。

5-6

上圖是表示比較複雜的 Cache 架構,我們可以看到在上圖中 Server 與 Client 都保留了 Cache 的能力,算是比較靈活的應用情境。圖中「圓柱體」符號為 Connector,這樣的架構中 Cache 由 Connector 進行實作。我們可以把 Connector 想像為瀏覽器核心負責發送 Socket 連線的元件,可以從這個角色直接實作 Cache 機制。

回到 HTTP 1.1 所設計的 Cache 機制,主要的目的為「降低 Request 發送」與「減少 Response 資料」,因此設計了以下兩種機制來達成目的:

    • Expiration, 用來處理 Cache Data 的時間有效期限
    • Validation, 用來驗證 Cache Data 的內容有效機制

這些機制在 HTTP 的實作上,是在 Client 與 Server 之間透過 Header 的「交互作用」來完成,為什麼說是「交互作用」呢?看看前面介紹的 REST Cache 架構圖,其實 Cache 可以在 Client 或 Server 實作,這樣的設計讓 Cache 更具彈性。

HTTP 1.1 Cache Header

其實早在 HTTP 1.0 就已經設計了 Cache 機制,但是使用的 HTTP Header 不一樣。HTTP 1.0 是透過 Expires 與 Pragma 這兩個 Header 進行控制,然而 HTTP 1.1 主要是透過「Cache-Control」這個 Header 提供快取機制,比起 HTTP 1.0 的設計,HTTP 1.1 更加彈性與靈活。其中用來描述 HTTP 1.1 的 RFC 2616 文件中分別定義了 Request 與 Response 可以使用的快取策略,基本定義如下:

  • Request:no-store, max-age, max-stale, min-fresh, no-transform, only-if-cached
  • Response:public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, max-age, s-maxage

HTTP 1.1 除了用到「」Header 進行控制之外,還提供了以下兩種機制來確保 Cache 資料的正確性 (Validation),分別為「Last-Modified / If-Modified-Since」與「ETag / If-None-Match」。第一種是透過資料 (通常用檔案) 的修改時間來驗證有效性,採用 GMT 時間,最小單位是秒。第二種是透過資料內容來驗證,主要利用資料的 Hash 值來比對,像是 Apache 就是利用 File System 的 iNode Hash 來達成,不然每次都計算 Hash 太傷成本。

Cache-Control Response Header 介紹

在實際的使用上,上面章節提到的關鍵字是可以合併使用的,接下來我們介紹幾個常用的 Cache 方式,透過 Chrome 瀏覽器的行為來跟各位介紹。

  • Cache-Control: no-store, 這個最簡單,就是完全不 Cache 的意思。參考以下圖片說明:

no-store

  • Cache-Control: no-cache + Last-Modified: GMT, 接下來我們測試傳說中的 304 Cache,在這裡定義 no-cache 並非完全不 Cache,no-cache 只是 Server Response 建議的策略。在我使用 Chrome 瀏覽器的測試下,如果 Server 有一併送出「Last-Modified」或「ETag」,那麼瀏覽器下次再詢問時依然會夾帶「If-Modified-Since」或「If-None-Match」,當 Server 回傳 304 Not Modified 時,瀏覽器就會直接使用 Cache 資料,達到「減少 Response 資料」這個目的。流程說明如下圖:

no-cache

  • Cache-Control: max-age=秒, 上面的情境雖然「減少 Response 資料」但還是發送了 Request 來驗證 Cache 的有效性,那麼用 max-age 來定義資源期限便可以解決這樣的問題。當有定義 max-age 時,一但有效期限還沒到,Connector 並不會發送連線,而是直接回傳 Cache 資料,以達成「降低 Request 發送」這個目的。請參考下圖說明:

max-age

  • Cache-Control: must-revalidate, 這個算是比較複雜的 Cache 策略,會交由 Client 自行判斷,經過 Chrome 測試,如果是重新整理 (或按 F5) 就送發送 Request 詢問 Cache 有效性;若是在網頁間「點連結」或「上一頁」則會直接使用 Cache 資料。如下圖:

must-revalidate

  • Cache-Control: private, 這個情境用在敏感資料的處理策略,通常在關閉瀏覽器或切換作業系統使用者的過程就會被刪除。如下如:

private

  • Cache-Control: public, 這種策略的 Cache 是可以讓其他使用者共用的,通常用在比較公開的資料,剛好跟 private 相反。以往經驗在 IE 瀏覽器不可與 HTTPS 搭配使用,會衝突造成許多奇怪的現象。請參考下圖:

public

討論

在我們一般的實務應用上,其實多多利用 no-store, max-cache, no-cache, must-revalidate 這幾種策略進行搭配使用,已經可以提昇不少網頁的反應速度與使用者觀感。在使用 Cache 時更特別要注意資料的有效性,避免過度的 Cache 造成即時資訊的顯示錯誤,在設計時要更加小心使用。

HTTP 1.1 對於 Cache 的設計相當完整,這篇文章大概只談到 10% 左右的內容,其實 HTTP 還有很多不同的 Cache 應用,由於本人技術水平與英文閱讀能力有限,無法為大家一一介紹,希望後繼有強者能夠提出指正與補充。感謝。

參考資料

參考投影片

  1 comment for “初探 HTTP 1.1 Cache 機制

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料