網頁的緩衝Cache與控制

標籤：建立   server   網路   快取   屬性   簡單   isp   art   安全加密   

 

什麼是緩衝 Cache?

緩衝位於用戶端與伺服器之間， 或者伺服器與伺服器之間。它決定是否儲存所獲資源的副本，以及如何使用副本，何時更新副本，這裡所說的資源套件括頁面的HTML， 圖片，檔案等等。

使用緩衝主要有2大理由：

• 減少響應延遲，讓頁面顯示更快：因為緩衝比原始伺服器離用戶端更近， 如果直接從緩衝而不是原始伺服器響應客戶的請求，耗時更少，讓網站看上去響應更快；
• 減少網路頻寬消耗：當副本被重用時，減少了從原始伺服器擷取資源的次數，從而減少頻寬消耗。

緩衝如何工作？

所有的緩衝都遵循以下基本規則

1. 保留副本：
• 如果回應標頭資訊告訴緩衝器不要保留緩衝；
• 如果請求資訊是需要認證或者安全加密的；
• 如果在回應中不存在校正參數（ETag或者Last-Modified頭資訊），快取服務器會認為缺乏直接的更新度資訊，內容將會被認為不可緩衝。
2. 使用副本：只有夠新鮮，才可以用。夠新鮮的條件：
• 含有完整的到期時間和壽命控制頭資訊，並且內容仍在保鮮期內；
• 瀏覽器已經使用過快取複本，並且在一個會話中已經檢查過內容的新鮮度；
• 緩衝Proxy 伺服器近期內已經使用過快取複本，並且內容的最後更新時間在上次使用期之前；
• 夠新的副本將直接從緩衝中送出，而不會向原始伺服器發送請求；
3. 更新副本：
• 如果緩衝的副本已經太舊，快取服務器將向原始伺服器發出請求校正請求，用於確定是否可以繼續使用當前拷貝繼續服務；

總之：新鮮度和校正是確定內容是否可用的最重要途徑。

 

其中一些規則在協議中有定義（HTTP協議1.0和1.1），另一些規則由緩衝的管理員設定（瀏覽器的使用者或者Proxy 伺服器的管理員）；

 

如何控制緩衝

 

緩衝的控制一般在伺服器端，少數在用戶端。下面是在用戶端控制的一個執行個體：

執行個體1：在用戶端用HTML meta標籤控制瀏覽器，要求瀏覽器不要cache這個頁面：

    <meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate">

    <meta http-equiv="Pragma" content="no-cache">

    <meta http-equiv="Expires" content="0">

以上設定是最少的、適合於各種主流瀏覽器的設定。 建議使用。

 

其中，

* Cache-Control裡面的 no-cache是專門針對IE6的， 如果不需要支援IE6，就省略它。

* Pragma 裡面的 no-cache是HTTP1.0專門針對舊clients的， 如果不需要支援HTTP1.0，就省略它

* Expires是專門針對HTTP1.0 client和proxies的， 如果不需要支援HTTP1.0，就省略它

 

如果以上3項都不支援，最後，就剩下： （不建議用此， 因為使用者實際使用的瀏覽器版本很雜）

    <meta http-equiv="Cache-Control" content="no-store, must-revalidate">

 

HTML META標籤是寫在HTML檔案裡面的，使用很簡單，但是效率並不高，因為只有幾種瀏覽器會遵循這個標記（那些真正會“讀懂”HTML的瀏覽器），沒有一種緩衝Proxy 伺服器能遵循這個規則（因為它們幾乎完全不解析文檔中HTML內容）；有時會在Web頁面中增加：Pragma:no-cache這個META標記，如果要讓頁面保持重新整理，這個標籤其實完全沒有必要。

如果你的網站託管在ISP機房中，並且機房可能不給你許可權去控制HTTP的頭資訊（如：Expires和Cache-Control）；

 

在伺服器端：

HTTP頭資訊，一般由Web伺服器自動產生。但是，根據 你使用的服務，你可以在某種程度上進行控制。他們在HTML代碼中是看不見的。HTTP頭資訊可以讓你對瀏覽器和Proxy 伺服器如何處理你的副本進行更多的控制。

HTTP頭資訊發送在HTML代碼之前，只有被瀏覽器和一些中間緩衝能看到，一個典型的HTTP1.1協議返回的頭資訊看上去像這樣：

HTTP/1.1200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: "3e86-410-3596fbbc"
Content-Length: 1040
Content-Type: text/html

 

Cache-Control （緩衝控制） HTTP 頭信 息

HTTP 1.1定義的一組頭資訊屬性：Cache-Control回應標頭資訊，讓網站的發行者可以更全面的控制他們的內容，並定位到期時間的限制。有用的Cache-Control回應標頭資訊包括：

• max-age=[秒] — 執行緩衝被認為是最新的最長時間。類似於到期時間，這個參數是基於請求時間的相對時間間隔，而不是絕對到期時間，[秒]是一個數字，單位是秒：從請求時間開始到到期時間之間的秒數。
• s-maxage=[秒] — 類似於max-age屬性，除了他應用於共用（如：Proxy 伺服器）緩衝
• public — 標記認證內容也可以被緩衝，一般來說： 經過HTTP認證才能訪問的內容，輸出是自動不可以緩衝的；
• no-cache — 強制每次請求直接發送給原始伺服器，而不經過本機快取版本的校正。這對於需要確認認證應用很有用（可以和public結合使用），或者嚴格要求使用最新資料的應用（不惜犧牲使用緩衝的所有好處）；
• no-store — 強制緩衝在任何情況下都不要保留任何副本
• must-revalidate — 告訴緩衝必須遵循所有你給予副本的新鮮度的，HTTP允許緩衝在某些特定情況下返回到期資料，指定了這個屬性，你快取，你希望嚴格的遵循你的規則。
• proxy-revalidate — 和 must-revalidate類似，除了他只對緩衝Proxy 伺服器起作用

校正參數和校 驗

校正是當副本已經修改後，伺服器和緩衝之間的通訊機制；使用這個機制：快取服務器可以避免副本實際上仍然足夠新的情況下重複下載整個原件。

* 如果沒有任何資訊說明保鮮期（Expires或Cache-Control），緩衝將不會儲存任何副本；

*當一份緩衝包含Last-Modified資訊(最後修改時間)，他基於此資訊，通過添加一個If-Modified-Since請求參數，向伺服器查詢：這個副本從上次查看後是否被修改了。
HTTP 1.1介紹了另外一個校正參數：ETag，這是伺服器產生的唯一識別碼，每次副本的標籤都會變化。由於伺服器控制了ETag如何產生，快取服務器可以通過If-None-Match請求的返回沒變則當前副本和原件完全一致。
* 所有的快取服務器都使用Last-Modified時間來確定副本是否夠新，而ETag校正正變得越來越流行；
* 所有新一代的Web伺服器都對靜態內容（如：檔案）自動產生ETag和Last-Modified頭資訊，而你不必做任何設定。

*伺服器對於動態內容（例如：CGI,ASP或資料庫產生的網站）並不知道如何產生這些資訊；

 

建立利於緩衝網站的竅門

除了使用新鮮度資訊和校正，你還有很多方法使你的網站緩衝友好。

• 保持URL穩定： 這是緩衝的金科玉律，如果你給在不同的頁面上，給不同使用者或者從不同的網站上提供相同的內容，應該使用相同的URL，這是使你的網站緩衝友好最簡單，也是 最高效的方法。例如：如果你在頁面上使用 "/index.html" 做為引用，那麼就一直用這個地址；
• 使用一個共用的庫存放每頁都引用的圖片和其他頁面元素；
• 對於不經常改變的圖片/頁面啟用緩衝，並使用Cache-Control: max-age屬性設定一個較長的到期時間；
• 對於定期更新的內容設定一個快取服務器可識別的max-age屬性或到期時間；
• 如果資料來源（特別是下載檔案）變更，修改名稱，這樣：你可以讓其很長時間不到期，並且保證服務的是正確的版本；而連結到下載檔案的頁面是一個需要設定較短到期時間的頁面。
• 萬不得已不要改變檔案，否則你會提供一個非常新的Last-Modified日期；例如：當你更新了網站，不要複製整個網站的所有檔案，只上傳你修改的檔案。
• 只在必要的時候使用Cookie，cookie是非常難被緩衝的，而且在大多數情況下是不必要的，如果使用cookie，控制在動態網頁上；
• 減少試用SSL，加密的頁面不會被任何共用快取服務器緩衝，只在必要的時候使用，並且在SSL頁面上減少圖片的使用；
• 使用可緩衝性評估引擎，這對於你實踐本文的很多概念都很有協助；

 

編寫利於緩衝的指令碼

指令碼預設不會返回校正參數（返回Last-Modified或ETag頭資訊）或其他新鮮度資訊（Expires或Cache-Control），有些動態指令碼的確是動態內容（每次相應內容都不一樣），但是更多（搜尋引擎，資料庫引擎網站）網站還是能從緩衝友好中獲益的。
一般說來，如果指令碼產生的輸出在未來一段時間（幾分鐘或者幾天）都是可重複復制的，那麼就是可快取的。如果指令碼輸出內容只隨URL變化而變化，也是可快取的；但如果輸出會根據cookie，認證資訊或者其他外部條件變化，則還是不可快取的。

• 最利於緩衝的指令碼就是將內容改變時匯出成靜態檔案，Web伺服器可以將其當作另外一個網頁並產生和試用校正參數，讓一些都變得更簡單，只需要寫入檔案即可，這樣最後修改時間也有了；
• 另外一個讓指令碼可快取的方法是對一段時間內能保持較新的內容設定一個相對壽命的頭資訊，雖然通過Expires頭資訊也可以實現，但更容易的是用Cache-Control: max-age屬性，它會讓首次請求後一段時間內緩衝保持新鮮；
• 如果以上做法你都做不到，你可以讓指令碼產生一個校正屬性，並對 If-Modified-Since 和/或If-None-Match請求作出反應，這些屬性可以從解析HTTP頭資訊得到，並對合格內容返回304 Not Modified（內容未改變），可惜的是，這種做法比不上前2種高效；

其他竅門：

• 盡量避免使用POST，除非萬不得已，POST模式的返回內容不會被大部分快取服務器儲存，如果你發送內容通過URL和查詢（通過GET模式）的內容可以緩衝下來供以後使用；
• 不要在URL中加入針對每個使用者的識別資訊：除非內容是針對每個使用者不同的；
• 不要統計一個使用者來自一個地址的所有請求，因為緩衝常常是一起工作的；
• 產生並返回Content-Length頭資訊，如果方便的話，這個屬性讓你的指令碼在可持續連結模式時：用戶端可以通過一個TCP/IP連結同時請求多個副本，而不是為每次請求單獨建立連結，這樣你的網站相應會快很多；

 

More:

http://www.chedong.com/tech/cache_docs.html

https://www.mnot.net/cache_docs/

 

網頁的緩衝Cache與控制