HTTP1.1緩衝策略

標籤：style   blog   http   color   使用   ar   for   資料   sp   

　　以下是一幅雖然資訊包含量有限、但足夠以最簡潔的方式說明了“什麼是HTTP1.1緩衝策略”的圖

　 緩衝和緩衝策略

　　web緩衝（web cache）或代理緩衝（proxy cache）是一種特殊的HTTPProxy 伺服器。緩衝減少了冗餘資料的傳輸、緩解頻寬瓶頸、

　　降低距離時延。

　　緩衝策略就是在採用緩衝的情況，client、proxy cache、server三者是如何協同工作，實現正確且快速的資料傳遞。

　　在介紹緩衝策略前，我們需要先明確的概念

　（a）快取命中

　（b）緩衝未命中

　（c）緩衝再驗證命中

　　出現以上三種情況的原因是緩衝是否有效。很明顯，當緩衝有效時候，我們肯定希望從緩衝中獲得資料，那怎麼判斷緩衝是否有效呢？這就是接下來需要討論的問題——新鮮度檢測。與之相關的是兩個很重要的頭部，Expires和Cache-control:max-age，其中Expires來自http/1.0+，Cache-Control來自http/1.1。其中Cache-Control：max-age定義了文檔的使用期，是一個相對時間，如Cache-Control：max-age=3600，單位為秒；Expires指定的是一個絕對時間。很明顯相對時間比絕對時間靠譜多了。因為絕對時間是依賴於電腦時鐘的設定的。但是很多時候兩者都被設定了，主要原因是有些用戶端不支援http/1.1，無法識別Cache-Control，這是一種相容策略。當然，Expires和Cache-control同時存在的時候，Cache-Control的優先順序是高於Expires的。

　　

　　我們還需要明確的一點就是——當文檔在到期時間以內的時候，文檔時新鮮的，即緩衝和原始服務的資料是相吻合的，這一點我們承認，但是單單一個Expires或者是Cache-Control頭部就說明緩衝已經和原始伺服器資料出現偏差，呈現無效狀態，這種說法顯然是欠考慮的。在文檔到期時，緩衝可以問下原始伺服器，文檔在某段時間後有沒有發生變化，如果內容沒有變化，緩衝只要擷取一個新的到期時間，重新標識緩衝為有效，並將緩衝中的資料響應給用戶端，這就是緩衝再驗證命中；而如果緩衝內容發生了變化，緩衝需要得到新的資料資訊，更新舊緩衝，並將新的資料響應給用戶端，這就是緩衝未命中。~而這種緩衝向原始伺服器詢問，就是“伺服器再驗證”。

 

　　與“伺服器再驗證”相關的最有用的頭部是If-Modified-Since:<date>和If-None-Match:<tags>　　

　　If-Modified-Since和Last-Modified伺服器響應首部

　　當緩衝要對已緩衝的文檔進行再驗證時，就會包含一個If-Modified-Since首部，其中有最後修改已快取複本的日期，如果在此期間內容被修改，最後的修改日期就會有所不同，原始伺服器就會返回新的文檔以及一個新的到期時間；否則返回一個304 NOT Modified的響應，沒有文檔主體返回，但會返回一個新的到期時間。

　　If-None-Match實體標籤再驗證

　　If-None-Match的存在是因為If-Modify-Since僅僅以文檔最後修改的時間為依據進行判斷是夠的。以下情況在合理的需求範圍之內的，比如：

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

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

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

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

　　Etag標籤作為文檔的版本號碼、序號、指紋或者校正資訊等參與再驗證，並且Etag可以有多個。當第一次訪問文檔時，服務響應會包含ETag資訊，然後之後再用戶端請求時就會將最近的Etag資訊添加到If-None-Match中，如果Etag匹配，伺服器就會響應304 NOT Modified，否則伺服器會返回新的文檔和新的Etag。

 　有關緩衝的其它頭部資訊：Cache-Control、Pragma　　Cache-Control

　　cache-control作為要求標頭部的一部分時，可取的值為：max-age、max-stale、min-fresh、no-cache、no-store、no-transform、only-if-cached

　　max-age：如果指定max-age的值，那麼在此值內的時間裡是不會重新訪問原始伺服器的。比如，Cache-Control:max-age=5，表示當訪問此網頁後的5秒內不會再次訪問伺服器；

　　max-stale：用戶端可以接受這個超過新鮮度的響應對象，但是前提條件是該回應時間的到期時間必須小於max-stale；

　　min-fresh：接受其新鮮生命期大於其當前age+min-fresh值的緩衝對象；

　　no-cache：不是說不被緩衝，而是會被緩衝，只不過每次在向用戶端提供響應資料時，緩衝都要向原始伺服器再驗證緩衝的有效性；

　　no-store：響應不被緩衝；

　　no-transform：RFC裡面的原話叫做“The no-transform” request directive indicates that an intermediary(whether or not it implements a cache) MUST NOT transfor the payload"。 當指定了該欄位後，中間任何環節都不能再修改有效載荷。=。=其實我不太明白，不過腦子裡有點印象，代理可以修改http頭部，可能指的就是這個，待考證。。。。

　　only-if-cached：用戶端希望響應來自緩衝；所以作為響應有兩種結果，一種是來自緩衝的資料，一種是504響應；

　　cache-control作為回應標頭部的一部分時，可取的值為：must-revalidate、no-cache、no-store、no-transform、public、private、proxy-revalidate、max-age、s-maxage。

　　must-revalidate：緩衝必須在向原始伺服器再驗證成功之後才可以再使用，否則將會響應504；

　　public：任何緩衝代理都可以快取服務器的響應；

　　private：響應針對私人使用者，不能被共有緩衝代理緩衝下來；

　　proxy-revalidate：同樣要求向原始伺服器再驗證，但是對私人快取無效判定；

　　s-maxage：同max-age，但他只用於共用快取；

　　Pragma

　　跟Cache-Control:no-cache相同,Pramma: no-cache相容http 1.0，Cache-Control:no-cache是http1.1提供的。因此，Pragma:no-cache可以應用到http1.0和http1.1，而Cache-Control:no-cache只能應用於http1.1。　　

 

　　有沒有想過，我們討論都是http/1.1的策略，假如我們的策略碰上了一個老伺服器、老用戶端，會發生什麼情況呢？本著一個原則，堅決不返回錯誤資訊，以犧牲效率保證正確性。　　

　　

　　如果撇開細節不談，緩衝策略總結起來就是：實現client、cache、server三者之間最有效、最對等的資訊交流。最有效包括時間有效、準確性的有效，時間的有效通過最大限度的利用緩衝，減少交流成本（新鮮度檢測時，只需要發送頭部資訊，只有的實在很必要的時候才發送文檔主體，減少通訊的資料轉送量就是依照這個原則）以實現；準確性的有效同樣是採用新鮮度檢測的措施；最對等的資訊交流就是server返回一個頭部資訊、client要有相應的頭部資訊最為響應發回。

 

HTTP1.1緩衝策略