前端學習筆記--HTTP緩衝

標籤：eve   dev   避免   資訊   行業   caching   實現   樣式   更新   

原文地址：https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn

緩衝並重用之前擷取的資源的能力是效能最佳化的一個關鍵方面。

每個瀏覽器都內建了 HTTP 緩衝實現功能，只需要確保每個伺服器響應都提供正確的 HTTP 標題指令，以指示瀏覽器何時可以緩衝響應以及可以緩衝多久。

 

HTTP 與瀏覽器互動的要求標頭：

當伺服器返迴響應時，還會發出一組 HTTP 標題，用於描述響應的內容類型、長度、緩衝指令、驗證令牌等。例如，在的互動中，伺服器返回一個 1024 位元組的響應，指示用戶端將其緩衝最多 120 秒，並提供一個驗證令牌（“x234dff”），可在響應到期後用來檢查資源是否被修改。

 

通過ETag驗證緩衝的響應

• 伺服器使用ETag HTTP表頭傳遞驗證令牌
• 驗證令牌可以實現高效率的資源檢查：資源未發生變化時不會傳送任何資料

驗證令牌的作用：

假定在首次擷取資源 120 秒後，瀏覽器又對該資源發起了新的請求。首先，瀏覽器會檢查本機快取並找到之前的響應。遺憾的是，該響應現已到期，瀏覽器無法使用。此時，瀏覽器可以直接發出新的請求並擷取新的完整響應。不過，這樣做效率較低，因為如果資源未發生變化，那麼下載與緩衝中已有的完全相同的資訊就毫無道理可言！

這正是驗證令牌（在 ETag 標題中指定）旨在解決的問題。伺服器產生並返回的隨機令牌通常是檔案內容的雜湊值或某個其他指紋。用戶端不需要瞭解指紋是如何產生的，只需在下一次請求時將其發送至伺服器。如果指紋仍然相同，則表示資源未發生變化，您就可以跳過下載。 例如：

在上例中，用戶端自動在“If-None-Match” HTTP 要求標題內提供 ETag 令牌。伺服器根據當前資源核對令牌。如果它未發生變化，伺服器將返回“304 Not Modified”響應，告知瀏覽器緩衝中的響應未發生變化，可以再延用 120 秒。請注意，您不必再次下載響應，這節約了時間和頻寬。

作為網路開發人員，如何利用高效的重新驗證？瀏覽器會替我們完成所有工作：它會自動檢測之前是否指定了驗證令牌，它會將驗證令牌追加到發出的請求上，並且它會根據從伺服器接收的響應在必要時更新緩衝時間戳記。我們唯一要做的就是確保伺服器提供必要的 ETag 令牌。檢查伺服器文檔中有無必要的配置標誌。

提示：HTML5 Boilerplate 項目包含所有最流行伺服器的設定檔範例，其中為每個配置標誌和設定都提供了詳細的註解。在列表中找到您喜愛的伺服器，尋找合適的設定，然後複製/確認您的伺服器配置了推薦的設定。

Cache-Control

• 每個資源都可通過 Cache-Control HTTP 標題定義其緩衝策略
• Cache-Control 指令控制誰在什麼條件下可以緩衝響應以及可以緩衝多久。

從效能最佳化的角度來說，最佳請求是無需與伺服器通訊的請求：可以通過響應的本機複本消除所有網路延遲，以及避免資料傳送的流量費用。為實現此目的，HTTP 規範允許伺服器返回 Cache-Control 指令，這些指令控制瀏覽器和其他中間緩衝如何緩衝各個響應以及緩衝多久。

註：Cache-Control 標題是在 HTTP/1.1 規範中定義的，取代了之前用來定義響應緩衝策略的標題（例如 Expires）。所有現代瀏覽器都支援 Cache-Control，因此，使用它就夠了。

命令：

“no-cache”和“no-store”

“no-cache”表示必須先與伺服器確認返回的響應是否發生了變化，然後才能使用該響應來滿足後續對同一網址的請求。因此，如果存在合適的驗證令牌 (ETag)，no-cache 會發起往返通訊來驗證緩衝的響應，但如果資源未發生變化，則可避免下載。

相比之下，“no-store”則要簡單得多。它直接禁止瀏覽器以及所有中間緩衝儲存任何版本的返迴響應，例如，包含個人隱私資料或銀行業務資料的響應。每次使用者請求該資產時，都會向伺服器發送請求，並下載完整的響應。

“public”與“private”

如果響應被標記為“public”，則即使它有關聯的 HTTP 身分識別驗證，甚至響應狀態碼通常無法緩衝，也可以緩衝響應。大多數情況下，“public”不是必需的，因為明確的緩衝資訊（例如“max-age”）已表示響應是可以緩衝的。

相比之下，瀏覽器可以緩衝“private”響應。不過，這些響應通常只為單個使用者緩衝，因此不允許任何中間緩衝對其進行緩衝。例如，使用者的瀏覽器可以緩衝包含使用者私人資訊的 HTML 網頁，但 CDN 卻不能緩衝。

“max-age”

指令指定從請求的時間開始，允許擷取的響應被重用的最長時間（單位：秒）。例如，“max-age=60”表示可在接下來的 60 秒緩衝和重用響應。

定義最佳的Cache-Control 策略

按照以上決策樹為您的應用使用的特定資源或一組資源確定最佳緩衝策略。在理想的情況下，您的目標應該是在用戶端上緩衝儘可能多的響應，緩衝儘可能長的時間，並且為每個響應提供驗證令牌，以實現高效的重新驗證。

Cache-Control 指令和說明
max-age=86400	瀏覽器以及任何中間緩衝均可將響應（如果是“public”響應）緩衝長達 1 天（60 秒 x 60 分鐘 x 24 小時）。
private, max-age=600	用戶端的瀏覽器只能將響應緩衝最長 10 分鐘（60 秒 x 10 分鐘）。
no-store	不允許緩衝響應，每次請求都必須完整擷取。

 

根據 HTTP Archive，在排名最高的 300,000 個網站（按照 Alexa 排名）中，所有下載的響應中幾乎有半數可由瀏覽器緩衝，這可以大量減少重複的網頁瀏覽和訪問。當然，這並不意味著您的特定應用有 50% 的資源可以緩衝。一些網站的資源 90% 以上都可以緩衝，而其他網站可能有許多私密或時效要求高的資料根本無法緩衝。

審核網頁，確定哪些資源可以緩衝，並確保它們返回正確的 Cache-Control 和 ETag 標題。

廢棄和更新緩衝的響應

• 在資源“到期”之前，將一直使用本機快取的響應。
• 您可以通過在網址中嵌入檔案內容指紋，強制用戶端更新到新版本的響應。
• 為獲得最佳效能，每個應用都需要定義自己的緩衝階層。

瀏覽器發出的所有 HTTP 要求會首先路由到瀏覽器緩衝，以確認是否緩衝了可用於滿足請求的有效響應。如果有匹配的響應，則從緩衝中讀取響應，這樣就避免了網路延遲和傳送產生的流量費用。

不過，如果想更新或廢棄緩衝的響應，該怎麼辦？ 例如，假定已告訴訪問者將某個 CSS 樣式表緩衝長達 24 小時 (max-age=86400)，但設計人員剛剛提交了一個您希望所有使用者都能使用的更新。該如何通知擁有現在“已淘汰”的 CSS 快取複本的所有訪問者更新其緩衝？在不更改資源網址的情況下，做不到。

瀏覽器緩衝響應後，緩衝的版本將一直使用到到期（由 max-age 或 expires 決定），或一直使用到由於某種其他原因從緩衝中刪除，例如使用者清除了瀏覽器緩衝。因此，構建網頁時，不同的使用者可能最終使用的是檔案的不同版本；剛擷取了資源的使用者將使用新版本的響應，而緩衝了早期（但仍有效）副本的使用者將使用舊版本的響應。

所以，如何才能魚和熊掌兼得：用戶端緩衝和快速更新？ 可以在資源內容發生變化時更改它的網址，強制使用者下載新響應。通常情況下，可以通過在檔案名稱中嵌入檔案的指紋或版本號碼來實現 - 例如 style.x234dff.css。

因為能夠定義每個資源的緩衝策略，所以可以定義“緩衝階層”，這樣不但可以控制每個響應的緩衝時間，還可以控制訪問者看到新版本的速度。為了進行說明，我們一起分析一下上面的樣本：

• HTML 被標記為“no-cache”，這意味著瀏覽器在每次請求時都始終會重新驗證文檔，並在內容變化時擷取最新版本。此外，在 HTML 標籤內，在 CSS 和 JavaScript 資產的網址中嵌入指紋：如果這些檔案的內容發生變化，網頁的 HTML 也會隨之改變，並會下載 HTML 響應的新副本。
• 允許瀏覽器和中間緩衝（例如 CDN）緩衝 CSS，並將 CSS 設定為 1 年後到期。請注意，可以放心地使用 1 年的“遠期到期”，因為在檔案名稱中嵌入了檔案的指紋：CSS 更新時網址也會隨之變化。
• JavaScript 同樣設定為 1 年後到期，但標記為 private，這或許是因為它包含的某些使用者私人資料是 CDN 不應緩衝的。
• 映像緩衝時不包含版本或唯一指紋，並設定為 1 天后到期。

可以組合使用 ETag、Cache-Control 和唯一網址來實現一舉多得：較長的到期時間、控制可以緩衝響應的位置以及隨需更新。

緩衝檢查清單

不存在什麼最佳緩衝策略。需要根據通訊模式、提供的資料類型以及應用特定的資料更新要求，為每個資源定義和配置合適的設定，以及整體的“緩衝階層”。

在制定緩衝策略時，需要牢記下面這些技巧和方法：

• 使用一致的網址：如果在不同的網址上提供相同的內容，將會多次擷取和儲存這些內容。提示：請注意，網址區分大小寫。
• 確保伺服器提供驗證令牌 (ETag)：有了驗證令牌，當伺服器上的資源未發生變化時，就不需要傳送相同的位元組。
• 確定中間緩衝可以緩衝哪些資源：對所有使用者的響應完全相同的資源非常適合由 CDN 以及其他中間緩衝進行緩衝。
• 為每個資源確定最佳緩衝周期：不同的資源可能有不同的更新要求。為每個資源審核並確定合適的 max-age。
• 確定最適合的網站的緩衝階層：可以通過為 HTML 文檔組合使用包含內容指紋的資源網址和短時間或 no-cache 周期，來控制用戶端擷取更新的速度。
• 最大限度減少攪動：某些資源的更新比其他資源頻繁。如果資源的特定部分（例如 JavaScript 函數或 CSS 樣式集）會經常更新，可以考慮將其代碼作為單獨的檔案提供。這樣一來，每次擷取更新時，其餘內容（例如變化不是很頻繁的內容庫代碼）可以從緩衝擷取，從而最大限度減少下載的內容大小。

前端學習筆記--HTTP緩衝