【Web】Yslow最佳化法則（三）添加緩衝控制首部

標籤：blog   tar   ext   get   strong   art   

添加Expires和Cache-control頭部

Expires和Cache-control實際上是HTTP中的緩衝控制頭部，它主要影響用戶端的請求行為和伺服器端的響應。

本文的許多內容來自《HTTP權威指南》，如有任何問題，歡迎指出。

一．緩衝的基本概念

這裡的緩衝，單指web的緩衝。當web請求抵達緩衝時，如果本地有緩衝的副本且緩衝未到期，那麼就可以從本地讀取資料或文檔，這樣便可以：

1.        減少冗餘的資料轉送，一定程度上減少伺服器的流量和壓力。

2.        緩解了網路瓶頸的問題，不需要更多的頻寬就能更快的載入頁面。

3.        降低了對原始伺服器的要求，伺服器可以更快的響應，避免過載和峰值訪問。

4.        降低了因距離帶來的時延。

    緩衝可以是單個使用者專有的，也可以是數千名使用者共用的。其中專有緩衝稱為私人緩衝，而共用的緩衝則稱為公有緩衝。專有緩衝比較常見，例如常用的瀏覽器便有內建的私人緩衝-大多數瀏覽器都提供了緩衝的功能，通過將常用的文檔緩衝在個人PC電腦的磁碟和記憶體中，減少二次請求的載入時間。共有緩衝則是通過緩衝Proxy 伺服器實現的，它可以接受來自多個使用者的訪問，為更多的使用者提供緩衝功能，因而可以更好的減少冗餘流量。

對於一條包含了緩衝控制的HTTP請求而言，緩衝的處理過程包含了7個步驟。分別是：

1.      接收。緩衝從網路中讀取抵達的請求報文
2.      解析。緩衝對報文進行解析，提取出URL和HTTP請求首部。
3.      查詢。查看本地的副本是否可用，如果沒有，就擷取一份副本，並將其儲存在本地。
4.      到期檢查。查看已經緩衝的文檔副本是否夠新鮮，如果不是，就詢問伺服器是否有更新。
5.      構建響應。利用新的首部和已經緩衝的主體來構建一條響應報文
6.      發送。緩衝通過網路將響應發回給用戶端。

7.      日誌。可選地建立相應的日誌。

二、緩衝相關首部

與緩衝相關的首部主要包括Cache-Control首部，Expires首部，If-Modified-Since和If-None-Match等，其中後兩個首部主要用於用戶端的再驗證。

1.  Cache-Control首部和Expires首部

Cache-Control是與緩衝有關的最重要的頭部之一。需要注意的是：它既可以在要求標頭中出現，也可以在回應標頭中出現。因此，對於該頭部，首先需要知道的是它出現在要求標頭中還是出現在回應標頭中，顯然它們是不同的。以csdn的bbs首頁為例，瀏覽器訪問bbs.csdn.net，抓取到的要求標頭為：

其中的Cache-Control:max-age=0 是告訴緩衝系統，本次的請求沒有失效日期。而相應的伺服器的回應標頭則為：

其中的max-age=0表明緩衝不會到期，private表明這是一個私人緩衝，must-revalidate則表明用戶端在使用緩衝之前，必須要做重新驗證。仔細觀察請求和回應標頭我們還發現：要求標頭與緩衝與關的還有另外一個頭部：if-none-match，回應標頭中則包含了Etag頭部。關於這兩個頭部的詳細解釋，會在之後給出，在此之前，先簡單介紹下：緩衝到期。通過特殊的HTTP Cache-Control和Expires首部，HTTP讓原始伺服器包含每個文檔的到期時間，如同食物的保質期一樣。在緩衝的文檔到期之前，緩衝系統可以直接使用緩衝構建響應而不必每次都請求伺服器（除非要求標頭部中包含了其他阻止緩衝的首部）。Cache-Control: max-age=xxx用於指定文檔的生存期（秒為單位），Expires則是指定文檔的到期時間，生存期與到期時間的區別在於：生存期用於指定從產生文檔開始，文檔的最大使用時間，而到期時間則是指定在什麼時間文檔會到期。說到這裡，順便提一句,由於Expires指定的是絕對的到期日期而不是秒數，由於很多伺服器的時鐘並不同步，或者不正確的，因而並不推薦使用Expires首部。如果響應中同時出現max-age和expires首部，則根據以往的經驗，expires首部將會被覆蓋。

         Cache-Control的值按照不同的作用，可以分為以下幾類：

a．   緩衝的類型：

    public（共有緩衝，可被緩衝Proxy 伺服器緩衝）
    private（私人緩衝，不能被共有緩衝Proxy 伺服器緩衝，可被使用者的代理緩衝如瀏覽器）。

b．   緩衝的行為:

    no-Store: 表明不希望緩衝系統保留文檔的任何副本，緩衝通常會向用戶端轉寄一條no-store的響應，然後刪除對象。
    no-Cache:  標識為no-cache響應實際上可以緩衝在本機快取中的，只是在於原始的伺服器再驗證之前，不能提供給用戶端使用。
    must-revalidate:  該首部告訴緩衝系統，在沒有與原始伺服器進行再驗證的情況下，不能提供這個對象的陳舊副本。如果緩衝在進行must-revalidate再驗證的時候，原始伺服器不可用，則緩衝必須返回一條504 Gateway timeout的錯誤。
    max-age:  前面已經講過，該首部用於指定文檔產生之後的最大有效時間。共有緩衝的響應還可能包括一個s-maxage首部，該首部僅僅用於共用快取。

c．   用戶端行為：

    Min-fresh：用戶端接收回應時間小於目前時間加上指定時間的響應。
    Max-stale：用戶端可以接收超出逾時期間的響應訊息。

由於這些首部很少用到，這裡不再贅述。

2.  If-Modified-Since和 If-none-Match用戶端再驗證

HTTP的條件要求方法可以高效地實現再驗證，通過向原始伺服器發送一個條件GET請求，請求伺服器只有在文檔與緩衝中現有的副本不同時，才提供對象主體。

HTTP定義了5個條件請求首部，對緩衝再驗證來說最有用的2個首部是If-Modified-since和If-None-Match。

a.        If-Modified-Since: 最常用的緩衝再驗證首部之一，如果在指定日期之後，文檔修改過了，就執行請求，攜帶新首部的新文檔將會被返回給緩衝，同時，新的首部中包含了新的到期時間。該首部通常與last-Modified首部配合使用。以csdn 的blog為例，blog請求中靜態資源如css的請求中，第一次請求的要求標頭為：

並不包含If-Modified-Since的首部，伺服器端的響應會包含文檔的最後修改時間，（該時間會被用戶端作為之後請求的if-Modified-Since的時間依據）。如所示：

在第二次之後的請求中，會包含If_modified-Since的請求首部：

後續的請求中，由於文檔並未修改，因此伺服器會回送304 Not Modified響應，緩衝系統會使用緩衝的副本構建響應，該響應不需包含Content-Type和Content-Encoding，Transfer-Encoding等首部（因為文檔不需要重新傳輸），如下所示：

b.        If-none-Match: 實體標籤再驗證。If-Modified-Since能夠很好的解決靜態文檔的再驗證問題，但是很多情況下，僅僅使用文檔的最後修改日期進行再驗證是不夠的，這是由於：

1.  有些文檔可能被周期性的重寫，但是資料可能是一樣的，這樣雖然文檔的內容沒有發生變化，但是文檔的修改時間卻發生了變化。

2.  有些文檔雖然修改了，但是修改並不重要，因此不需要更新所有的緩衝。

3.  有些伺服器無法準確的判斷文檔的最後修改時間或無法正確的支援If-Modified-Since(比如，有的伺服器是使用日期的字串匹配比較而不是日期比較)

4.  對於文檔變化小於1s的即時監控類應用，1s的粒度太大，需要更加精細的粒度控制。

HTTP允許通過實體標籤Etag的方式進行條件GET請求，Etag標籤可以是文檔的版本號碼、序號、指紋或者校正資訊等，Etag可以有多個。以bbs.csdn.net首頁為例，第一次請求文檔時，伺服器的HTTP響應會包含該文檔的Etag資訊（該Etag資訊可以是文檔的MD5摘要等）：

在之後的請求中，用戶端要求標頭會帶上If-none-Match首部:

如果Etag匹配，伺服器會回送304 not Modified響應，相反，伺服器會返回新的文檔和新的Etag標籤。

3．Yslow最佳化法則的建議

Yslow中對於該法則的最佳化法則是：

a.      對於靜態內容，為Expires添加一個較遠的到期日期。例如，csdn中，靜態css檔案的到期日期便是目前時間加一個星期（也就是一個星期後到期）：

         這種方式的弊端在於，如果在文檔到期之前修改了文檔，由於Expires設定的日期並未到，所以在這之前，瀏覽器都是使用緩衝的副本，這當然會帶來很多問題（如無法及時更新用戶端的UI）.多數的做法是，為你的靜態資源添加標識，例如版本號碼，在文檔發生變化時需要更新靜態資源的引用，這樣能保證用戶端使用的靜態資源總是最新的快取複本。

b.      對於動態內容，設定合適的Cache-Control策略。這裡有個比較坑的地方，什麼是合適的策略？由於並沒有通用的設定，我們並不做過多的解釋。不妨思考一下，如何針對特定的伺服器和應用選擇合適的緩衝策略。

參考文獻：

1.      https://developer.yahoo.com/performance/rules.html

2.      http://www.guojl.com/article/40/

3.      http://www.cnblogs.com/cocowool/archive/2011/08/22/2149929.html

4.      http://www.vktone.com/articles/http_browser_cache.html

5.      http://blog.csdn.net/novofly/article/details/7613173