第七章--緩存

1.冗餘的數據傳輸：一些相同的字節會在網絡中一遍遍地傳輸。緩存，就可以保留第一條服務器響應的副本，後繼請求就可以由緩存的副本來應對了。
2.帶寬瓶頸：很多網絡爲本地網絡客戶端提供的帶寬比爲遠程 服務器提供的帶寬要寬。客戶端會以路徑上最慢的網速訪問服務器。 如果客戶端從一個快速局域網的緩存中得到了一份副本，那麼緩存就可以提高性 能——尤其是要傳輸比較大的文件時。
3.瞬間擁塞：很多人幾乎同時去訪問一個 Web 文檔時，就會出現瞬間擁塞。由此造成的過多流量峯值可能會使網絡和 Web 服務器產生災難性的崩潰。
4.距離時延：
5.命中和未命中的
    （1）再驗證
        緩存對緩存的副本進行再驗證時，會向原始服務器發送一個小的再驗證請求。如果內容沒有變化，服務器會以一個小的 304 Not Modified 進行響應。
        If- Modified-Since 首部。將這個首部添加到 GET 請求中去，就可以告訴服務器，只有在緩存了對象的副本之後，又對其進行了修改的情況下，才發送此對象。
        • 再驗證命中：如果服務器對象未被修改，服務器會向客戶端發送一個小的HTTP 304 Not Modified 響應。
        • 再驗證未命中： 如果服務器對象與已緩存副本不同，服務器向客戶端發送一條普通的、帶有完整內容的 HTTP 200 OK 響應。
        • 對象被刪除：如果服務器對象已經被刪除了，服務器就回送一個 404 Not Found 響應，緩存也會將其副本刪除。
    （2）命中率：緩存提供服務的請求所佔的比例被稱爲緩存命中率    
            對現在中等規模的 Web 緩存來說，40% 的命中率是很合理的。
    （3）字節命中率：緩存提供的字節在傳輸的所有字節中所佔的比例。通過這種度量方式，可以得知節省流量的程度。
     (4) 區分命中和未命中的情況:客戶端有一種方法可以判斷響應是否來自緩存，就是使用 Date 首部。將響應中 Date 首部的值與當前時間進行比較，如果響應中的日期值比較早，客戶端通常就可
         以認爲這是一條緩存的響應。客戶端也可以通過 Age 首部來檢測緩存的響應，通過 這個首部可以分辨出這條響應的使用期
6.緩存的拓撲結構
    緩存可以是單個用戶專用的，也可以是數千名用戶共享的。專用緩存被稱爲私有緩 存(private cache)。共享的緩存被稱爲公有緩存(public cache)
    (1)公有代理緩存:公有緩存是特殊的共享代理服務器，被稱爲緩存代理服務器(caching proxy server)，代理緩存會從 本地緩存中提供文檔，或者代表用戶與服務器進行聯繫
    (2)代理緩存的層次結構：
        實現層次化(hierarchy)的緩存是很有意義的，在這種結構中，在較小緩存中未命中的請求會被導向較大的父緩存(parent cache)，由它來爲剩下的那些 “提煉過的”流量提供服務。
    （3）網狀緩存、內容路由以及對等緩存
        網狀緩存中的代理緩存之間會以更加複雜的方式進行對話，做出動態的緩存通信決策，決定與哪個父緩存進行對話，或者決定徹底繞開緩存，直接連接原始服務器。
        這種代理緩存會決定選擇何種路由對內容進行訪問、管理和傳送，因此可將其稱爲 內容路由器(content router)。
        網狀緩存中爲內容路由設計的緩存(除了其他任務之外)要完成下列所有功能。
            • 根據 URL 在父緩存或原始服務器之間進行動態選擇。
            • 根據 URL 動態地選擇一個特定的父緩存。
            • 前往父緩存之前，在本地緩存中搜索已緩存的副本。
            • 允許其他緩存對其緩存的部分內容進行訪問，但不允許因特網流量通過它們的緩存。
7.緩存的處理步驟
    (1) 接收——緩存從網絡中讀取抵達的請求報文。
    (2) 解析——緩存對報文進行解析，提取出 URL 和各種首部。
    (3) 查詢——緩存查看是否有本地副本可用，如果沒有，就獲取一份副本(並將其保存在本地)。
    (4) 新鮮度檢測——緩存查看已緩存副本是否足夠新鮮，如果不是，就詢問服務器是否有任何更新。
    (5) 創建響應——緩存會用新的首部和已緩存的主體來構建一條響應報文。
    (6) 發送——緩存通過網絡將響應發回給客戶端。
    (7) 日誌——緩存可選地創建一個日誌文件條目來描述這個事務。
8.保持副本的新鮮
    (1)文檔過期：通過特殊的 HTTP Cache-Control 首部和 Expires 首部，HTTP 讓原始服務器向每個文檔附加了一個“過期日期”，一旦已緩存文檔過期，緩存就必須與服務器進行覈對，詢問文檔是否被修改過，如果 被修改過，就要獲取一份新鮮(帶有新的過期日期)的副本。
    (2)過期日期和使用期:服務器用 HTTP/1.0+ 的 Expires 首部或 HTTP/1.1 的 Cache-Control: max-age 響應首部來指定過期日期，Cache-Control 首部使用的是 相對時間而不是絕對日期
    (3)服務器再驗證:
        HTTP 協議要求行爲正確的緩存返回下列內容之一:
        • “足夠新鮮”的已緩存副本;
        • 與服務器進行過再驗證，確認其仍然新鮮的已緩存副本;
        • 如果需要與之進行再驗證的原始服務器出故障了，就返回一條錯誤報文 14;
        • 附有警告信息說明內容可能不正確的已緩存副本。
    (4)用條件方法進行再驗證:HTTP 的條件方法可以高效地實現再驗證。HTTP 允許緩存向原始服務器發送一個“條件 GET”，請求服務器只有在文檔與緩存中現有的副本不同時，纔回送對象主體。
        HTTP 定義了 5 個條件請求首部。對緩存再驗證來說最有用的 2 個首部是 If- Modified-Since 和 If-None-Match。
    (5)If-Modified-Since:Date再驗證
        If-Modified-Since 再驗證請 求通常被稱爲 IMS 請求。只有自某個日期之後資源發生了變化的時候，IMS 請求才會指示服務器執行請求:
        • 如果自指定日期後，文檔被修改了，If-Modified-Since 條件就爲真，通常 GET 就會成功執行。攜帶新首部的新文檔會被返回給緩存，新首部除了其他信息之外，還包含了一個新的過期日期。
        • 如果自指定日期後，文檔沒被修改過，條件就爲假，會向客戶端返回一個小 的 304 Not Modified 響應報文，爲了提高有效性，不會返回文檔的主體。這 些首部是放在響應中返回的，但只會返回那些需要在源端更新的首部。比如，Content-Type 首部通常不會被修改，所以通常不需要發送。一般會發送一個新的過期日期。
    (6)If-None-Match:實體標籤再驗證
        有些情況下僅使用最後修改日期進行再驗證是不夠的。
            • 有些文檔可能會被週期性地重寫(比如，從一個後臺進程中寫入)，但實際包含的數據常常是一樣的。儘管內容沒有變化，但修改日期會發生變化。
            • 有些文檔可能被修改了，但所做修改並不重要，不需要讓世界範圍內的緩存都重裝數據(比如對拼寫或註釋的修改)。
            • 有些服務器無法準確地判定其頁面的最後修改日期。
            • 有些服務器提供的文檔會在亞秒間隙發生變化(比如，實時監視器)，對這些服務器來說，以一秒爲粒度的修改日期可能就不夠用了。
        HTTP 允許用戶對被稱爲實體標籤(ETag)的“版本標識符” 進行比較。實體標籤是附加到文檔上的任意標籤(引用字符串)。它們可能包含了文檔的序列號或版本名，或者是文檔內容的校驗和及其他指紋信息。
    (7)什麼時候應該使用實體標籤和最近修改日期
        如果服務器回送了一個實體標籤，HTTP/1.1 客戶端就必須使用實體標籤驗證器。如果服務器只回送了一個 Last-Modified 值，客戶端就可以使用 If-Modified-Since 驗證。
9.控制緩存的能力
    (1)no-Store與no-Cache響應首部
        no-store 首部和 no-cache 首部可以防止緩存提供未經證實的已緩存對象:
        Pragma: no-cache 
        Cache-Control: no-store 
        Cache-Control: no-cache
        標識爲 no-store 的響應會禁止緩存對響應進行復制。
        標識爲 no-cache 的響應實際上是可以存儲在本地緩存區中的。
    (2)max-age響應首部
        Cache-Control: max-age 首部表示的是從服務器將文檔傳來之時起，可以認爲此文檔處於新鮮狀態的秒數。有一個 s-maxage 首部(注意 maxage 的中間沒有連 字符)，其行爲與 max-age 類似，但僅適用於共享(公有)緩存:
        Cache-Control: max-age=3600 
        Cache-Control: s-maxage=3600
    (3)Expires響應首部:不推薦使用 Expires 首部，它指定的是實際的過期日期而不是秒數。
    (4)must-revalidate響應首部:如果原始服務器 希望緩存嚴格遵守過期信息，可以在原始響應中附加一個 Cache-Control: must- revalidate 首部。
        Cache-Control: must-revalidate
        如果在緩存進行 must-revalidate 新鮮度檢查時，原始服務器不可用，緩存就必須返回一條 504 Gateway Timeout 錯誤。
    (5)試探性過期
        如果響應中沒有 Cache-Control: max-age 首部，也沒有 Expires 首部，緩存可以計算出一個試探性最大使用期。
        LM-Factor 算法是一種很常用的試探性過期算法，如果文檔中包含了最後修改日期， 就可以使用這種算法。LM-Factor 算法將最後修改日期作爲依據，來估計文檔有多麼易變。
    (6)客戶端的新鮮度限制
        Web 瀏覽器都有 Refresh(刷新)或 Reload(重載)按鈕，可以強制對瀏覽器或代理緩存中可能過期的內容進行刷新。Refresh 按鈕會發佈一個附加了 Cache- Control 請求首部的 GET 請求，這個請求會強制進行再驗證，或者無條件地從服務器獲取文檔。Refresh 的確切行爲取決於特定的瀏覽器、文檔以及攔截緩存的配置。
10.設置緩存控制
    Apache Web 服務器
    (1)控制Apache的HTTP首部