標籤:
轉自: http://www.cnblogs.com/Jessy/p/3568935.html
HTTP的緩衝
至於響應訊息的實體,與請求訊息的實體內容相似,這裡只借紹下User-Agent頭
User-Agent頭域的內容包含發出請求的使用者資訊。
Cache-Control頭域(請求和應答通用頭域) Cache-Control指定請求和響應遵循的緩衝機制。在請求訊息或響應訊息中設定Cache-Control並不會修改另一個訊息處理過程中的緩衝 處理過程。請求時的緩衝指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if- cached,響應訊息中的指令包括public、private、no-cache、no-store、no-transform、must- revalidate、proxy-revalidate、max-age。各個訊息中的指令含義如下: Public 指示響應可被任何緩衝區緩衝。 Private 指示對於單個使用者的整個或部分響應訊息,不能被共用快取處理。這允許伺服器僅僅描述目前使用者的部分響應訊息,此響應訊息對於其他使用者的請求無效。 no-cache 指示請求或響應訊息不能緩衝 no-store 用於防止重要的資訊被無意的發布。在請求訊息中發送將使得請求和響應訊息都不使用緩衝。
If-modified-since: <date> max-age 指示客戶機可以接收生存期不大於指定時間(以秒為單位)的響應。 min-fresh 指示客戶機可以接收回應時間小於目前時間加上指定時間的響應。 max-stale 指示客戶機可以接收超出逾時期間的響應訊息。如果指定max-stale訊息的值,那麼客戶機可以接收超出逾時期指定值之內的響應訊息
Cache-control、expires、last-modified等重要頭域Cache-control:指定請求和響應遵循的緩衝機制。
在請求訊息或響應訊息中設定Cache-Control並不會修改另一個訊息處理過程中的緩衝處理過程。請求時的緩衝指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached,響應訊息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。
Expires:告訴瀏覽器指明應該在什麼時候認為文檔已經到期,從而不再緩衝它。代碼實現:header("Expires:". date(‘D, d M Y H:i:s \G\M\T‘, time()+10));--------這個是把時間截轉化成格林時區字串給expires頭域,這個顯示時間會比中國北京時間少8個小時,東8區的實現:header("Expires:". date(‘r‘, time()+10))last-modified:這個是伺服器返回給瀏覽器,瀏覽器下次請求則把該值賦給if-modified-since頭域傳給伺服器,伺服器就可以根據此值判斷是否有改變,有則繼續運行下去,否者返回304 not modified
refer: 編程書籍\網路知識\HTTP協議(緩衝Cache).ppt
編程書籍\網路知識\HTTP 協議基礎(包含緩衝).ppt
在http中Last-Modified 與If-Modified-Since 都是用於記錄頁面最後修改時間的 HTTP 頭資訊,注意,在這 Last-Modified 是由伺服器往用戶端發送的 HTTP 頭,另一個 If-Modified-Since是由用戶端往伺服器發送的頭,可以看到,再次請求本地存在的 cache 頁面時,用戶端會通過 If-Modified-Since 頭將先前伺服器端發過來的 Last-Modified 最後修改時間戳記發送回去,這是為了讓伺服器端進行驗證,通過這個時間戳記判斷用戶端的頁面是否是最新的,如果不是最新的,則返回新的內容,如果是最新的,則 返回 304 告訴用戶端其本地 cache 的頁面是最新的,於是用戶端就可以直接從本地載入頁面了,這樣在網路上傳輸的資料就會大大減少,同時也減輕了伺服器的負擔。而且在一些ajax應用中,要求擷取的資料永遠是最新的,而不是讀取位於緩衝中的資料,做這樣的設定是非常有必要的。
無意中測試發現nginx與apache對此有不同的演算法:
APACHE:
(1)直接發送請求,返回200,Last-Modified: Mon, 26 Apr 2010 13:22:17 GMT
[[email protected] ~]# curl -I http://www.pengyao.org/test.html
HTTP/1.1 200 OK Date: Mon, 26 Apr 2010 14:59:09 GMT Server: Apache/1.3.41 (Unix) Last-Modified: Mon, 26 Apr 2010 13:22:17 GMT ETag: “92c027-897-4bd59389″ Accept-Ranges: bytes Content-Length: 2199 Content-Type: text/plain (2)指定與Last-Modified時間相同的If-Modified-Since 發送GET請求,返回304
[[email protected] ~]# curl -I -G -H “If-Modified-Since: Mon, 26 Apr 2010 13:22:17 GMT” http://www.pengyao.org/test.html
HTTP/1.1 304 Not Modified Date: Mon, 26 Apr 2010 15:02:06 GMT Server: Apache/1.3.41 (Unix) ETag: “92c027-897-4bd59389″
(3)調後If-Modified-Since 1小時,再次發送GET請求,返回依然為304 [[email protected] ~]# curl -I -G -H “If-Modified-Since: Mon, 26 Apr 2010 14:22:17 GMT” http://www.pengyao.org/test.html
HTTP/1.1 304 Not Modified Date: Mon, 26 Apr 2010 15:05:02 GMT Server: Apache/1.3.41 (Unix) ETag: “92c027-897-4bd59389″
說明Apache 在判斷瀏覽器cache是否到期時,依據從If-Modified-Since開始,檔案Last-Modified是否修改過來判斷的,與RFC1945中對If-Modified-Since描述吻合.
那麼再看下nginx對於此的測試結果:
(1)直接發送請求,返回200,Last-Modified: Wed, 21 Apr 2010 13:14:21 GMT [[email protected] pengyao.org]# curl -I http://www.pengyao.org/index.html HTTP/1.1 200 OK Server: nginx/0.7.61 Date: Mon, 26 Apr 2010 15:18:29 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 323 Last-Modified: Wed, 21 Apr 2010 13:14:21 GMT Connection: keep-alive Accept-Ranges: bytes
(2)指定與Last-Modified時間相同的If-Modified-Since 發送GET請求,返回304
[[email protected] pengyao.org]# curl -I -G -H “If-Modified-Since: Wed, 21 Apr 2010 13:14:21 GMT” http://www.pengyao.org/index.html HTTP/1.1 304 Not Modified Server: nginx/0.7.61 Date: Mon, 26 Apr 2010 15:20:45 GMT Last-Modified: Wed, 21 Apr 2010 13:14:21 GMT Connection: keep-alive
(3)調後If-Modified-Since 1小時,再次發送GET請求,發現返回的結果為200,與Apache不同
[[email protected] pengyao.org]# curl -I -G -H “If-Modified-Since: Wed, 21 Apr 2010 14:14:21 GMT” http://www.pengyao.org/index.html HTTP/1.1 200 OK Server: nginx/0.7.61 Date: Mon, 26 Apr 2010 15:21:19 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 323 Last-Modified: Wed, 21 Apr 2010 13:14:21 GMT Connection: keep-alive Accept-Ranges: bytes 由此可以判斷出,nginx在判斷瀏覽器cache是否到期時,判斷If-Modified-Since與Last-Modified是否匹配,如果不匹配,則認為cache到期,返回200重新下載.
要說更喜歡哪種演算法,個人更傾向於nginx的這種,因為在對檔案更新前,本人習慣於對需要修改的檔案進行備份(保留時間戳),一旦測試出現問題,及時的復原,使用nginx的這種演算法就能保障復原前後瀏覽器cache失效,而Apache的這種策略導致復原到之前的時間戳記的話(Last- Modified),本地由於進行了測試,本地cache檔案的If-Modified-Since時間一般比復原後的Last-Modified新,這樣本地的cache認為依然有效,返回304,而實際上檔案已經不是最新的。當然,Apache的這樣設計完全遵守RFC,個人喜好不代表真實需求.
如何利用用戶端緩衝對網站進行最佳化? If-Modified-Since & If-None-Match
介紹 你的網站在並發訪問很大並且無法承受壓力的情況下,你會選擇如何最佳化? 很多人首先會想從伺服器緩衝方面著手對程式進行最佳化,許多不同的伺服器緩衝方式都有他們自己的特點,像我曾經參與的一些項目中,根據緩衝的命中率不同使用過 Com+/Enterprise Libiary Caching/Windows服務,靜態檔案等方式的伺服器端緩衝和 HTTP Compression技術,但用戶端緩衝往往卻被人們忽略了,即使伺服器的緩衝讓你的頁面訪問起來非常地快,但她依然需要依賴瀏覽器下載並輸出,而當你加入用戶端緩衝時,會給你帶來非常多的好處.因為她可以對網站中訪問最頻繁的頁進行緩衝充分地提高 Web 服務器的輸送量(通常以每秒的請求數計算)以提升應用程式效能和延展性。 一個線上購物調查顯示,大多數人願意去商店排隊,但在線上購物時卻不願意等待。Websense調查公司稱多達70%的上網者表示不願意在頁面讀取上超過10秒鐘。超過70%的人會因為中途速度過慢而取消當前的訂單。
基礎知識 1) 什麼是”Last-Modified”?
在瀏覽器第一次請求某一個URL時,伺服器端的返回狀態會是200,內容是你請求的資源,同時有一個Last-Modified的屬性標記此檔案在服務期端最後被修改的時間,格式類似這樣:
Last-Modified: Fri, 12 May 2006 18:53:33 GMT
用戶端第二次請求此URL時,根據 HTTP 協議的規定,瀏覽器會向伺服器傳送 If-Modified-Since 前序,詢問該時間之後檔案是否有被修改過:
If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT
如果伺服器端的資源沒有變化,則自動返回 HTTP 304 (Not Changed.)狀態代碼,內容為空白,這樣就節省了傳輸資料量。當伺服器端代碼發生改變或者重啟伺服器時,則重新發出資源,返回和第一次請求時類似。從而保證不向用戶端重複發出資源,也保證當伺服器有變化時,用戶端能夠得到最新的資源。
2) 什麼是”Etag”?
HTTP 協議規格說明定義ETag為“被請求變數的實體值” (參見 —— 章節 14.19)。 另一種說法是,ETag是一個可以與Web資源關聯的記號(token)。典型的Web資源可以一個Web頁,但也可能是JSON或XML文檔。伺服器單獨負責判斷記號是什麼及其含義,並在HTTP回應標頭中將其傳送到用戶端,以下是伺服器端返回的格式:
ETag: "50b1c1d4f775c61:df3"
用戶端的查詢更新格式是這樣的:
If-None-Match: W/"50b1c1d4f775c61:df3"
如果ETag沒改變,則返回狀態304然後不返回,這也和Last-Modified一樣。本人測試Etag主要在斷點下載時比較有用。
Last-Modified和Etags如何協助提高效能? 聰明的開發人員會把Last-Modified 和ETags請求的http前序一起使用,這樣可利用用戶端(例如瀏覽器)的緩衝。因為伺服器首先產生 Last-Modified/Etag標記,伺服器可在稍後使用它來判斷頁面是否已經被修改。本質上,用戶端通過將該記號傳回伺服器要求伺服器驗證其(用戶端)緩衝。 過程如下: 1. 用戶端請求一個頁面(A)。 2. 伺服器返回頁面A,並在給A加上一個Last-Modified/ETag。 3. 用戶端展現該頁面,並將頁面連同Last-Modified/ETag一起緩衝。 4. 客戶再次請求頁面A,並將上次請求時伺服器返回的Last-Modified/ETag一起傳遞給伺服器。 5. 伺服器檢查該Last-Modified或ETag,並判斷出該頁面自上次用戶端請求之後還未被修改,直接返迴響應304和一個空的響應體。
範例程式碼 下面的例子描述如何使用伺服器端代碼去操作用戶端緩衝:
Code 1//預設緩衝的秒數 2 int secondsTime = 100; 3 4 //判斷最後修改時間是否在要求的時間內 5 //如果伺服器端的檔案沒有被修改過,則返回狀態是304,內容為空白,這樣就節省了傳輸資料量。如果伺服器端的檔案被修改過,則返回和第一次請求時類似。 6 if (request.Headers["If-Modified-Since"] != null && TimeSpan.FromTicks(DateTime.Now.Ticks - DateTime.Parse(request.Headers["If-Modified-Since"]).Ticks).Seconds < secondsTime) 7 { 8 //測試代碼,在這裡會發現,當瀏覽器返回304狀態時,下面的日期並不會輸出 9 Response.Write(DateTime.Now); 10 11 response.StatusCode = 304; 12 response.Headers.Add("Content-Encoding", "gzip"); 13 response.StatusDescription = "Not Modified"; 14 } 15 else 16 { 17 //輸出目前時間 18 Response.Write(DateTime.Now); 19 20 //設定用戶端緩衝狀態 21 SetClientCaching(response, DateTime.Now); 22 } 23 24 /**//// <summary> 25 /// 設定用戶端緩衝狀態 26 /// </summary> 27 /// <param name="response"></param> 28 /// <param name="lastModified"></param> 29 private void SetClientCaching(HttpResponse response, DateTime lastModified) 30 { 31 response.Cache.SetETag(lastModified.Ticks.ToString()); 32 response.Cache.SetLastModified(lastModified); 33 //public 以指定響應能由用戶端和共用(代理)緩衝進行緩衝。 34 response.Cache.SetCacheability(HttpCacheability.Public); 35 //是允許文檔在被視為陳舊之前存在的最長絕對時間。 36 response.Cache.SetMaxAge(new TimeSpan(7, 0, 0, 0)); 37 //將緩衝到期從絕對時間設定為可調時間 38 response.Cache.SetSlidingExpiration(true); 39 }
如果你的緩衝是基於檔案的方式,如XML或http中的.ashx處理,也可以使用下面的基於檔案方式的用戶端緩衝:
SetFileCaching 1/**//// <summary> 2/// 基於檔案方式設定用戶端緩衝 3/// </summary> 4/// <param name="fileName"></param> 5private void SetFileCaching(HttpResponse response, string fileName) 6{ 7 response.AddFileDependency(fileName); 8 //基於處理常式檔案依賴項的時間戳記設定 ETag HTTP 標題。 9 response.Cache.SetETagFromFileDependencies(); 10 //基於處理常式檔案依賴項的時間戳記設定 Last-Modified HTTP 標題。 11 response.Cache.SetLastModifiedFromFileDependencies(); 12 response.Cache.SetCacheability(HttpCacheability.Public); 13 response.Cache.SetMaxAge(new TimeSpan(7, 0, 0, 0)); 14 response.Cache.SetSlidingExpiration(true); 15} 16
結論 我們已經看了如何使用用戶端緩衝減少頻寬和計算的方法,如前所述,如果能正確合理的利用各種不同的緩衝,他們會給你帶來很多的好處.我希望本文已為你當下或將來基於Web的項目提供了精神食糧,並正確地在底層利用Last- Modified和ETag回應標頭去最佳化你的項目。
[轉] HTTP協議(緩衝機制Cache)