服務端緩存頁面及IIS緩存設置

　　緩存信息基本概念

咱們在看網頁的header信息時，常常看到這幾個參數：Expires、Cache-Control、Last-Modified、ETag，它們是RFC 2616（HTTP/1.1）協議中和網頁緩存相關的幾個字段。前兩個用來控制緩存的失效日期，後兩個用來驗證網頁的有效性。要注意的是， HTTP/1.0有一個功能比較弱的緩存控制機制：Pragma，使用HTTP/1.0的緩存將忽略Expires和Cache-Control頭。

      Expires

     Expires字段聲明瞭一個網頁或URL地址再也不被瀏覽器緩存的時間，一旦超過了這個時間，瀏覽器都應該聯繫原始服務器。RFC告訴咱們：「因爲推斷的失效時間也許會下降語義透明度，應該被謹慎使用，同時咱們鼓勵原始服務器儘量提供確切的失效時間。」

      Cache-Control

      Cache-Control字段中能夠聲明多些元素，例如no-cache, must-revalidate, max-age=0等。這些元素用來指明頁面被緩存最大時限，如何被緩存的，如何被轉換到另外一個不一樣的媒介，以及如何被存放在持久媒介中的。可是任何一個 Cache-Control指令都不能保證隱私性或者數據的安全性。「private」和「no-store」指令能夠爲隱私性和安全性方面提供一些幫助，可是他們並不能用於替代身份驗證和加密。

      Last-Modified

      Last-Modified和ETag是條件請求(Conditional Request)相關的兩個字段。若是一個緩存收到了針對一個頁面的請求，它發送一個驗證請求詢問服務器頁面是否已經更改，在HTTP頭裏面帶上」 ETag」和」If Modify Since」頭。服務器根據這些信息判斷是否有更新信息，若是沒有，就返回HTTP 304（NotModify）；若是有更新，返回HTTP 200和更新的頁面內容，而且攜帶新的」ETag」和」LastModified」。

      使用這個機制，可以避免重複發送文件給瀏覽器，不過仍然會產生一個HTTP請求。

      ETag

      既然有了Last-Modified，爲何還要用ETag字段呢？由於若是在一秒鐘以內對一個文件進行兩次更改，Last-Modified就會不正確。所以，HTTP/1.1利用Entity Tag頭提供了更加嚴格的驗證。

　　IIS下的緩存

　　有兩種模式，一種是用戶模式，一種是內核模式！

　　在操做系統中，cup的處理速度最快最穩定了，其次是一級二級三級緩存，而後就是磁盤了。因此咱們會把主要頁面緩存起來以提升網站的性能，儘可能減少數據庫操做（畢竟讀取磁盤的數據太慢了）。

 

　　另一個須要注意的問題

　　對ASP和ASP.NET進行緩存的時候要當心。

1. 當用戶A訪問一個ASP頁面(假設test.asp)，若是這個ASP頁面裏面用到session的話，在Response裏面會有一個"Set-Cookie"的header，這個字段裏面保存的就是SessionId。若是用戶A後面繼續訪問別的ASP頁面的話，會把這個SessionId傳到服務器去，只有這樣，服務器才能肯定你這個請求仍是來自於同一個用戶A。簡而言之，SessionId是用來惟一表示一個客戶端。

2. 啓用了Kernel mode cache以後，IIS服務就把test.asp的Response放到http.sys(kernel mode cache)

3. 此時，若是用戶B訪問了同一個頁面(test.asp)，IIS就直接把Cache裏面的頁面結果返回到客戶端，也就是傳回了跟用戶A同樣的SessionId

　　如今，就很好解釋登陸問題了。

1) User A登陸了並作了一些操做，User B也登陸進來了，這個時候User A看到的就是 User B的信息了。

2) User A登陸了並作了一些操做，User B也登陸進來了，User A又登出了，User B就發現本身「未登陸」

這個問題，在IIS6裏面的ASP.NET應用有被描述過(http://support.microsoft.com/kb/917072)。當時對於ASP並無這種cache的功能，因此沒有描述。