快取保持副本的新鮮
********************====摘自《http權威指南》******************************===
http有一些簡單的機制可以在不要求伺服器記住有哪些快取擁有文件副本的情況下，保持已快取資料和伺服器資料之間充分一致。http將這些簡單的機制稱為文件過期（document expiration）和伺服器再驗證（server revalidation）。
1、 文件過期
通過特殊的http cache-control首部和expires首部，http讓原始伺服器向每個文件附加乙個「過期日期」。就像一夸脫牛奶上的過期日期一樣，這些首部說明了在多長時間內將這些內容視為新鮮的。
在快取文件過期之前，快取可以以任意頻率使用這些副本，而無需與伺服器聯絡—當然，除非客戶端請求中包含有阻止提供已快取或未驗證資源的首部。但一旦已快取文件過期，快取就必須與伺服器進行核對，詢問文件是否被修改過，如果被修改過，就要獲取乙份新鮮（帶有新的過期日期）的副本。
2、 過期日期和使用期
伺服器用http/1.0+的expires首部或http/1.1的cache-control：max-age響應首部來指定過期日期，同時還會帶有響應主體。expires首部和cache-control首部所做的事本質上時一樣的，但是由於cache-control首部使用的是相對時間而不是絕對日期，所以我們傾向於使用比較新的cache-control首部。絕對日期依賴於計算機時鐘的正確設定。
3、 伺服器再驗證
僅僅是已快取文件過期了並不意味著它和原始伺服器上目前處於活躍狀態的文件由實際的區別；這只是意味著到了要進行核對的時間了。這種情況被稱為「伺服器再驗證」，說明快取需要詢問原始伺服器文件是否發生了變化。
（1）、如果再驗證顯示內容發生了變化，快取會獲取乙份新的副本，並將其儲存在舊的文件位置上，然後將文件傳送給客戶端；
（2）、如果再驗證顯示內容沒有發生變化，快取只需要獲取新的首部，包括乙個新的過期日期，並對快取中的首部進行更新就行了。
快取並不一定要為每條請求驗證文件的有效性—只有在文件過期時它才需要與伺服器進行再驗證。這樣不會提供陳舊的內容，還可以節省伺服器的流量，並擁有更好的使用者響應時間。
http協議要求行為正確的快取返回下列內容之一：
a、「足夠新鮮的」已快取副本；
b、與伺服器進行再驗證，確認其仍然新鮮的已快取副本；
c、如果需要與之進行再驗證的原始伺服器出故障了，就返回一條錯誤報文；
d、附有警告資訊說明內容可能不正確的已快取副本；
4、用條件方法進行再驗證
http的條件方法可以高效的實現再驗證。http允許快取向伺服器傳送乙個「條件get」，請求伺服器只有在文件快取中現有的副本不同時，才回送物件主體。通過這種方式，將新鮮度檢查與物件獲取結合成了單個條件get。向get請求報文中新增一些特殊的條件首部，就可以發起條件get。只有條件為真時，web伺服器才返回物件。
http定義了5個條件請求首部。對快取再驗證來說最有用的2個首部是if-modified-since和if-none-match。所有的條件首部都以字首「if-」開頭。表7-3列出了在快取再驗證中使用的條件請求首部。
5、 if-modified-since：date再驗證
最常見的快取再驗證首部是if-modified-since。if-modified-since再驗證請求通常被稱為ims請求。只有自某個日期之後資源發生了變化的時候，ims才會指示伺服器執行請求：
（1）、如果自指定日期後，文件被修改了，if-modified-since條件就為真，通常get就會成功執行。攜帶新首部的新文件會被返回給快取，新首部除了其他資訊之外，還包含了乙個新的過期日期。
（2）、如果自指定日期後，文件沒有被修改過，條件就為假，會向客戶端返回乙個小的304 not modified響應報文，為了提高有效性，不會返回文件的主體。這些首部是放在響應中返回的，但只會返回那些需要在源端更新的首部。比如content-type首部通常不會被修改，所以通常不需要傳送，一般會傳送乙個新的過期日期。
if-modified-since首部可以last-modified伺服器響應首部配合工作。原始伺服器會將最後的修改日期附加到所提供的文件上去。當快取要對已快取文件進行再驗證時，就會包含乙個if-modified-since首部，其中攜帶有最後修改已快取副本的日期：
if-modified-since ：
如果在此期間內容被修改了，最後的修改日期就會有所不同，原始伺服器就會回送新的文件。否則伺服器會注意到快取的最後修改日期與伺服器文件當前的最後修改日期相符，會返回乙個304 not modified響應。
6、 if-none-match：實體標籤再驗證
有些情況下僅使用最後修改進行再驗證是不夠的。
（1）、有些文件可能會被週期性的重寫（比如，從乙個後台程序中寫入），但實際包含的資料常常是一樣的。儘管內容沒有發生變化，但修改日期會發生變化。
（2）、有些文件可能被修改了，但所做的修改並不重要，不需要讓世界範圍內的快取都重灌資料（比如對拼寫和注釋的修改）。
（3）、有些伺服器無法準確地判斷其頁面的最後修改日期。
（4）、有些伺服器提供的文件會在亞秒間隙發生變化（比如，實時監視器），對這些伺服器來說，以一秒為粒度的修改日期可能就不夠用了。
為了解決這些問題http允許使用者對被稱為實體標籤（etag）的「版本識別符號」進行比較。實體標籤是附加到文件是的任意標籤（引用字串）。他們可能包含了文件的序列號或版本名，或者是文件內容的校驗和及其他指紋資訊。
當發布者對文件進行修改時，可以修改文件的實體標籤來說明這個新版本。這樣，如果實體標籤被修改了，快取就可以用if-none-match條件首部來get文件的新副本了。
7、 強弱驗證器
快取可以用實體標籤來判斷，與伺服器相比，已快取的版本是不是最新的（與使用最近修改日期的方式很像）。從這個角度來看，實體標籤和最近修改日期都是快取驗證器（cache validator）。
有時，伺服器希望在對文件進行一些非實質性或不重要的修改時，不要使所有的已快取副本都失效。http/1.1支援「弱驗證器」。如果只對內容進行了少量修改，就允許伺服器宣告那是「足夠好」的等價體。
只要內容發生了變化，強驗證器就會發生變化。弱驗證器允許對一些內容進行修改，但內容的主要含義發生變化時，通常它還是會發生變化的。有些操作不能用弱驗證器來實現（比如有條件地獲取部分內容），所以，伺服器會用字首「w/」來標識弱驗證器。
etag：w/」v2.6」
if-none-match：w/」v2.6」
不管相關的實體值以何種發生變化，強實體標籤都要發生變化。而相關實體在語義上發生了比較重要的變化時，弱實體標籤也要發生變化。
注意，原始伺服器一定不能為兩個不同的實體重用乙個特定的強實體標籤值，或者為兩個語義不同的實體重用乙個特定的弱實體標籤值。不管過期時間是多少，快取條目都可能會留存任意長的時間，因此，假設快取不會再次通過它在過去某個時刻獲得的驗證器，對乙個條目進行驗證是不合適的。
8、 什麼時候應該使用實體標籤和最近修改日期
如果伺服器回送了乙個實體標籤，http/1.1客戶端就必須使用實體標籤驗證器。如果伺服器只回送了乙個last-modified值，客戶端就可以使用if-modified-since驗證。如果實體標籤和最後修改日期都提供了，客戶端就應該使用這兩種再驗證方案，這樣http/1.0和http/1.1快取就可以正確的響應了。
除非http/1.1原始伺服器無法生成實體標籤驗證器，否則就應該傳送乙個出去，如果使用弱實體標籤有優勢的話，傳送的可能就是個弱實體標籤，而不是強實體標籤。而且，最好同時傳送乙個最近修改值。
如果http/1.1快取或伺服器收到的請求既帶有if-modified-since，又帶有實體標籤條件首部，那麼只有這兩個條件都滿足時，才能返回304 not modified響應。
http頭部如何對快取的控制
文章自于我的個人部落格 使用快取的目的就是在於減少計算，io，網路等時間，可以快速的返回，特別是流量比較大的時候，可以節約很多伺服器頻寬和壓力。乙個請求從快取的方面來說，有三個過程。expires，http 1.0版本定義的response頭部，定義過期時間，如果本地時間發現超過過期時間，就會向伺服...
HTTP協議是如何實現「秘密互動」的？
你知道http訪問的互動過程嗎?那你知道web頁面如何呈現的嗎?網頁內容肯定不會憑空出現，當你在瀏覽器位址列中輸入url 鏈結 時，web瀏覽器會傳送相應的web請求資訊到目標 伺服器 當目標 伺服器接收到請求時伺服器回應相應的內容給你的瀏覽器 客戶端 這樣你就看到了網頁內容。不過這只是基本的訪問過...
HTTP和HTTPS連線是如何建立的？
http和https連線是如何建立的？https指的是超文字傳輸安全協議。https是在http的基礎上和ssl tls證書結合起來的一種協議,保證了傳輸過程中的安全性,減少了被惡意劫持的可能.很好的解決了http的三個缺點 被監聽 被篡改 被偽裝 那麼http和https連線是如何建立的？簡單的理...