Web 開發人員需知的 Web 緩存知識

最近的譯文距今已有4年之久，原文有一定的更新。今天踩著前輩們的肩膀，再次把這篇文章翻譯整理下。一來讓自己對web緩存的理解更深刻些，二來讓大家注意力稍稍轉移下，不要整天HTML5, 面試題啊叨啊叨的~~

什麼是Web緩存，為什麼要使用它？

Web緩存遊走於伺服器和客戶端之間。這個伺服器可能是源伺服器（資源所駐留的伺服器^Add），數量可能是1個或多個；這個客戶端也可能是1個或多個。Web緩存就在伺服器-客戶端之間搞監控，監控請求，並且把請求輸出的內容（例如html頁面、 圖片和文件）（統稱為副本）另存一份；然後，如果下一個請求是相同的URL，則直接請求保存的副本，而不是再次麻煩源伺服器。

使用緩存的2個主要原因：

• 降低延遲：緩存離客戶端更近，因此，從緩存請求內容比從源伺服器所用時間更少，呈現速度更快，網站就顯得更靈敏。
• 降低網路傳輸：副本被重複使用，大大降低了用戶的帶寬使用，其實也是一種變相的省錢（如果流量要付費的話），同時保證了帶寬請求在一個低水平上，更容易維護了。

Web緩存的類型

1. 瀏覽器緩存

在任何現代瀏覽器上(如IE, FireFox, Chrome)折騰清除隱私數據（//zxx: 原文說的是首選項，顯然out了，這裡有改動）的對話框，你很可能會注意到“緩存”這個設置項。

瀏覽器會在你的硬碟上專門開闢一個空間專門為你存儲資源副本。瀏覽器緩存的工作規則很簡單：檢查以確保副本是最新的，通常只要一次會話（就是當前瀏覽器調用的這次^N）。

瀏覽器緩存在用戶觸發“後退”操作或點擊一個之前看過的鏈接的時候很管用。同樣，如果你在網站上訪問同一張圖片，該圖片可以從瀏覽器緩存中調出並幾乎立即顯現出來。

2. 代理伺服器緩存

Web代理伺服器使用同樣的緩存原理，只是規模更大。代理以同樣的方式服務千萬用戶，大公司和ISP(Internet Server Provider, Internet服務提供商^Add)經常在他們的防火牆或者單獨的設備（也被稱為中介(intermediaries)）上架設代理緩存。

由於代理伺服器緩存並非客戶端或者源伺服器的一部分，而是處於網路中，請求需要以某種方式路由到它們。一種方法是手動設置，告訴瀏覽器的你常用的代理伺服器(//zxx: 翻牆的時候常用的)，另外就是使用攔截。攔截代理(Interception proxies)把Web請求根據自己的底層網路重定向，因此，客戶端無需配置，甚至都不需要知道它們。//zxx: 維基百科上提供的幾種檢測攔截代理伺服器存在的方法^add，您若有興趣，可以點擊這裡查看。

代理緩存屬於一種共享緩存；往往有大量的用戶使用，因此，其在降低延時和網路流量上很有用，畢竟每個副本都被大量重用。//zxx: 這裡我有疑問：就算是放在代理伺服器上，每次獲取還是要通過網路的啊，如何降低了網路流量呢？希望誰可以幫忙解惑下。

3. 網關緩存

也被稱為“反向代理緩存”或“替代緩存”。網關緩存同樣是起中介作用的，不過不是（素不相識、不曾謀面的^Add）網路管理員部署的，而多半是網站管理員（公司專門的運維工程師、或UED或程序組某人^Add）他們自己部署，這樣更容易擴展與維護。

可以有多種方法把請求路由到網關緩存，但通常使用某種形式的負載均衡器①，使它們中的一個或多個看起來像是源伺服器。內容分發網路②(CDNs)為整個網路（或部分）分配網關緩存，然後把這些緩存賣給需要的網站。Speedera③和Akamai④就是代表性的網路內容發布商。

①負載均衡器：是一種採用各種分配演算法把網路請求分散到一個伺服器集群中的可用伺服器上去，通過管理進入的Web數據流量和增加有效的網路帶寬，從而使網路訪問者獲得儘可能最佳的聯網體驗的硬體設備。

②內容分發網路：即CDN, 基本思路是儘可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。通過在網路各處放置節點伺服器所構成的在現有的互 聯網基礎之上的一層智能虛擬網路，CDN系統能夠實時地根據網路流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向 離用戶最近的服務節點上。其目的是使用戶可就近取得所需內容，解決 Internet網路擁擠的狀況，提高用戶訪問網站的響應速度。

③Speedera：是一家全球性的內容服務提供商，它與北美、歐洲以及亞太地區的1000多家大型運營商都有聯繫，並為那些不想在自己伺服器上寄存內容的公司提供軟體下載、媒體及其它服務管理等業務。05年的時候被下面要介紹的Akamai以$130m的價格給收購了。

④Akamai：美國Akamai是國際上最大的CDN服務商，它巨大的網路分發能力在峰值時可達到15Tbps。 Akamai公司是為數不多的旨在消除Internet瓶頸和提高下載速度的幾家新公司之一，是一個致力於網路交通提速的”內容發布”公司，是波士頓高技 術區最卓越的新興企業之一。Akamai公司向全球企業提供發送互聯網內容，匯流媒體和應用程序的服務（目前，該公司為15個國家的企業管理著8000多 台伺服器）。1998年，丹尼爾。L和麻省理工學院的一些研究人員一起創立了這家公司，他在麻省理工學院的碩士論文構成了Akamai公司最初的”自由 流”（Freeflow）技術的核心。

本教程重點在瀏覽器和代理緩存，儘管有些信息對網關緩存感興趣的人也適用。

Web緩存無害嗎？為什麼要鼓勵緩存？

Web緩存是互聯網中最容易被誤解的技術之一。網站管理員特別希望知道網站的一舉一動，比方說多少人訪問啦，訪問時間啊什麼的，而緩存會“隱藏”他們的用戶，他們就無從得知到底誰訪問了這個站點。

撿了芝麻丟西瓜，自認為放棄緩存可以精確跟蹤用戶，實際上，互聯網中有太多的變數，想精確得到一張用戶查看網站的圖片？沒那麼簡單的，親！如果你很重視這個問題，恭喜你，本文正好提供了解決之道，即保證緩存友好，同時又能獲得統計。

另外需要注意的是，緩存的內容都是舊的過時的。因此，如何準確更新就成了一個問題。不過不要擔心，本文會向你展示如何配置伺服器，讓緩存就像你的女僕——隨便調教。

CDN算是個挺有意思的技術，不同於代理緩存，CDN的網關緩存和被緩存的Web站點的利益是一致的，因此，上面提到的問題對於CDN而言是沒有的。不過，即使你使用了CDN，你仍要顧慮下游的代理和瀏覽器緩存。

以上為緩存可能的“糟粕”，那他好的地方呢？緩存可以讓你的Web站點載入更快，讓你的伺服器和互聯網鏈接間負擔更小。這種差異會導致一些類似質的 變化，一個網站要幾秒鐘才能載入出來，而另外一個充分發揮緩存的優勢，幾乎瞬間顯示。用戶自然更喜歡那個載入迅速的站點，訪問也更多。

再說個現實示例，許多大型互聯網公司花費了數百萬美元，在世界各地設立伺服器集群來複制他們的內容，以使其儘可能快被他們的用戶訪問。緩存為你做同樣的事情，而且他們更接近最終用戶。最重要的是，你不要花銀子。

實際上呢，無論你喜歡與否，代理和瀏覽器緩存都會被使用。如果你站點的緩存配置不正確，你只能聽天由命了。

Web緩存如何工作

所以的緩存都有一套自己的規則，可以用來決定何時跟緩存曖昧往來。其中部分規則設定在協議中(HTTP 1.0 以及 1.1)，部分由緩存管理員⑤設置。

⑤緩存管理員：如果指的是瀏覽器緩存，則有可能就是我們伺服器專家同事，在伺服器上配置一些緩存規則；如果是代理緩存，則指的就是處理代理伺服器這塊的管理人員。

一般而言有如下常用規則^N：

1. 響應頭明確說明，偶不想被緩存，則不會被緩存；
2. 如果請求信息是需要認證或者安全加密的(如, HTTPS)，相應內容也不會被緩存；
3. 緩存如果有以下表現，則認為是fresh新鮮的（無需檢查源伺服器，直接發送給客戶端）：
   • 含有完整的過期時間和壽命控制頭信息，並且內容仍在保鮮期內，或者
   • 緩存最近已展現，並且在不久前修改。

   則內容緩存直取，繞過源伺服器。

4. 若內容陳舊，則會要求源伺服器做驗證 validate ，或者告訴緩存其拷貝副本是否是OK的。
5. 特定情況下——例如，斷網了，之前有過的響應緩存直取而不檢查源伺服器。

響應如果沒有類似ETag或Last-Modified頭這樣的校驗器，也沒有明確的更新信息，通常（並不絕對）認為是不可緩存的。

總而言之，新鮮度freshness和校驗validation是確定緩存內容是否可用的最重要途徑。如果要展示的足夠新，直接緩存取；如果檢測發現展示內容並未變化，則不會再來一次完整的傳輸。

如何控制緩存和不緩存

有很多工具可以幫助設計師和網站管理員調整伺服器緩存網站的方式，這也許需要你親自動手對伺服器的配置進行一些調整，但絕對值得。了解如何使用這些工具請參考本文後面的章節。

HTML Meta標籤 vs. HTTP頭信息

HTML重構人員可以在文檔的中添加標籤進行描述。這些meta標籤通常用來標記不可緩存或過期時間。

Meta標籤使用簡單，但效果一般。因為只被少數幾個瀏覽器寵幸，而代理緩存基本上就不訪問HTML文檔。儘管我們可以在頁面上試圖添加no-cache meta標籤讓頁面一直是最新的，但其實沒必要。

如果你的網站託管在ISP或者主機託管商那裡，並且他們沒有賦予您任意設置HTTP頭信息的能力(比如Expires和Cache-Control)，你要投訴爭取，因為在你的工作中這些是必須的。

另外一方面： HTTP頭信息可以讓你對瀏覽器和代理伺服器如何處理你的副本進行更多的控制。他們在HTML代碼中是看不見的， 一般由Web伺服器自動生成。但是，根據你使用的伺服器，你可以在某種程度上進行控制。在下文中：你將看到一些有趣的HTTP頭信息，以及如何在你的站點 上應用部署這些特性。

HTTP頭信息發送在HTML代碼之前，只能被瀏覽器和一些中間緩存能看到，一個典型的HTTP 1.1協議返回的頭信息看上去像這樣：

  HTTP/1.1 200 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

頭信息空一行后是HTML代碼的輸出，關於如何設置HTTP頭信息請參考對應章節。

Pragma HTTP頭信息（以及為什麼不起作用）

很多人認為在HTTP頭信息中設置了Pragma: no-cache後會讓內容無法被緩存。但事實並非如此：HTTP的規範 中，響應型頭信息沒有任何關於Pragma屬性的說明，只說明了請求頭信息（瀏覽器發送給伺服器的頭信息）中的Pragma屬性。雖然有少部分緩存會買 賬，但大部分無視，使用Pragma沒作用。若要使用，試試下面的頭信息。

使用Expires HTTP頭信息控制不過期

Expires HTTP頭是控制緩存的基本手段，Expires的中文意思是“有效期”，顯然，就是告訴瀏覽器緩存的有效期。如果過期，緩存會檢查源伺服器以確定文件是否改變了。Expires頭幾乎每個緩存都支持。

大部分的伺服器允許你以多種方式設置Expires響應頭。通常，他們允許設置一個絕對過期時間，然後對比最後一次訪問的時候或者最後一次文檔修改的時候決定客戶端內容的獲取方式。

對於靜態圖片（如導航或按鈕的圖片）而言，Expires頭信息是相當有用的，因為圖片不怎麼修改，您可以給圖片設置一個相當長的過期時間，這回讓 你的用戶感覺網站變快了。Expires對於控制有改變規律的網頁也很有用，例如：你有一個新聞聚合頁面，每天早上6點鐘準時更新，您可以設置緩存的過期 時間也是這個點，於是緩存就可以很聰明地知道什麼時候該去重載新的內容，什麼時候睡大覺。

Expires頭唯一的有效值是HTTP時間，其他值都會被認為是“前男友前女友”之類，不會去緩存的。注意：時間是格林威治時間（GMT），而不是本地時間。如下所示：

  Expires: Fri, 30 Oct 1998 14:19:41 GMT

顯然，如果你要使用Expires頭，確保你的Web伺服器時間的準備就非常重要了。使用網路時間協議⑥(Network Time Protocol –NTP)不失為一個號方法。如果你的身邊有本地系統管理員，可以向他諮詢，或者查看下面的百科^Add 。

儘管Expires頭很有用，但它有一定的局限性。首先，因為牽扯到時間，Web伺服器端的時鐘必須和緩存的同步，否則很可能實現不了預期的結果——緩存把前女友當初現女友，把現女友當作過去式——那就悲劇了。

另外一個問題是，你很容易忘記給某內容設置了一個特定時間，如果返回內容的時候沒有更新這個過期時間，則每個請求都是上訪到伺服器，反而增加了負載和響應時間。

⑥網路時間協議(NTP): 以封包交換把兩台電腦的時鐘同步化的網路協議。NTP使用UDP埠123作為傳輸層。它是用作抵銷可變延遲的影響。NTP是仍在使用中的最古老的網路協 議之一（在1985年前開始）。NTP最初由德拉瓦州大學的Dave Mills設計，他與一群志願者仍在維護NTP。

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

HTTP 1.1引入了新的頭信息：Cache-Control響應頭信息，讓網站的發布者可以更全面的控制他們的內容，更好地處理Expires的些限制。Cache-Control有用的響應頭包括：

• max-age=[秒]：表示在這個時間範圍內緩存是新鮮的無需更新。類似Expires時間，不過這個時間是相對的，而不是絕對的。也就是某次請求成功后多少秒內緩存是新鮮的。
• s-maxage=[秒]：類似max-age, 除了僅應用於共享緩存（如代理）。
• public：標記認證的響應才能夠被緩存。一般而言，需要認證HTTP請求內容會自動私有化（不會被緩存^Add）。
• private^N：允許緩存專門為某一個用戶存儲響應，比方說在瀏覽器中；共享緩存一般不會，例如在代理中。
• no-cache：每次在釋放緩存副本之前都強制發送請求給源伺服器進行驗證，這在確保認證有效性上很管用（和public結合使用）或者保證內容必須是即時的，不得無視緩存的所有優點，如國內的微博、twitter等的刷新顯示^Add。
• no-store：強制緩存在任何情況下都不要保留任何副本。
• must-revalidate：告訴緩存，我給你準備了一些關於新鮮度的信息，在表現的時候要嚴格遵循之。HTTP允許緩存在某些特定情況下返回過期數據，指定了這個屬性，相對於告訴緩存，你丫必須嚴格遵循我的規則。
• proxy-revalidate：類似must-revalidate，除了只能應用於代理緩存。

舉個板栗：

  Cache-Control: max-age=3600, must-revalidate

如果Cache-Control和Expires同時存在，Cache-Control說了算^N。如果你打算使用Cache-Control頭，你應該好好看看”HTTP 1.1 規範“, 詳見參考文章以及拓展閱讀。

驗證器和驗證

在緩存如何工作這段譯文中，我們說過，伺服器以及緩存通過驗證來判斷內容是否改變，在不確定內容是否過期的時候，可以避免本地已經存在副本的時候下載整個內容。

驗證器是很重要的，如果一個都沒有，同時沒有可用的新鮮度信息(Expires或Cache-Control)，緩存一點兒都不會存儲內容。

最常見的驗證是通過Last-Modified頭信息通信確定文檔最後的修改時間，如果緩存有內容存儲，會包含Last-Modified信息的，輔助If-Modified-Since請求，我們可以詢問伺服器內容是否改變了。

HTTP 1.1引入了一個新的驗證器，稱為Etag⑦. Etag是每次展現內容改變時候由伺服器生成的唯一標識符，由於伺服器控制ETag如何生成，當緩存發起If-None-Match請求的時候，如果Etag匹配，就可以確定展示內容其實是一樣的。

⑦Etag: HTTP協議規格說明定義ETag為”被請求變數的實體值”。另一種說法是，ETag是一個可以與Web資源關聯的記號（token）。典型的Web資源 可以一個Web頁，但也可能是JSON或XML文檔。伺服器單獨負責判斷記號是什麼及其含義，並在HTTP響應頭中將其傳送到客戶端，以下是伺服器端返回 的格式：ETag:”50b1c1d4f775c61:df3″客戶端的查詢更新格式是這樣的：If-None-Match : W / “50b1c1d4f775c61:df3″如果ETag沒改變，則返回狀態304然後不返回，這也和Last-Modified一樣。測試Etag主要 在斷點下載時比較有用。

幾乎所有的緩存使用Last-Modified時間作為驗證器，Etag驗證也開始變得流行。

所有新一代的Web伺服器都對靜態內容（如：文件）自動生成ETag和Last-Modified頭信息，而你不必做任何設置。但是，伺服器對於動態內容（例如：CGI, ASP或資料庫生成的網站）並不知道如何生成這些信息，參考一下編寫支持緩存的腳本章節；

創建支持緩存網站的小技巧

除了使用新鮮度信息以及驗證，還有其他一些技巧可以讓你網站的緩存更加友好：

• 保持URL穩定：這是緩存的金科玉律，如果你為不同頁面，不同用戶或不同網站提供相同的內容，他們應該使用相同的URL. 這是簡單卻非常行之有效的方法。例如，你的HTML中的某個引用地址是"/index.html", 則要一直使用這個地址。
• 不同地方的圖片和其他元素使用同一庫。
• 對於不經常改變的圖片/頁面啟用緩存，通過將Cache-Control: max-age頭信息的值設大一點。
• 對於定期更新的內容通過指定max-age或過期時間實現緩存。
• 如果資源改變了（尤其下載文件），改變其名字。由於一般這種資源會有很長的過期時間，而伺服器上一直是正確的版本；因此，鏈接這個下載資源的頁面需要要比較短的過期時間（//zxx: 我司頁面5分鐘過期）。否則，會出現伺服器的資源是新的，但頁面被緩存了，其中的鏈接地址還是舊的，就會出現新舊版本衝突的可能^Add。
• 萬不得已不要變動文件：否則你要設置一個新的Last-Modified值。另外，當你更新站點的時候，只要上傳改動的那些文件，而不要把整個站點都覆蓋過去。
• Cookie能不用就不用：Cookie難以被緩存，且大多情境下是沒有必要的。如果你非得使用Cookie，建議用在動態頁面上。
• 減少SSL⑧的使用：因為共享緩存不能存儲認證頁面，只在必要的時候使用，並且在SSL頁面上減少圖片的使用。
• 使用REDbot⑨檢查你的網站：可以幫助你應用本文所介紹的一些概念。

⑧ SSL：全稱Secure Socket Layer –安全套接層，為Netscape所研發，用以保障在Internet上數據傳輸之安全，利用數據加密(Encryption)技術，可確保數據在網路上之 傳輸過程中不會被截取及竊聽。目前一般通用之規格為40 bit之安全標準，美國則已推出128 bit之更高安全標準，但限制出境。只要3.0版本以上之I.E.或Netscape瀏覽器即可支持SSL。

⑨ REDbot：REDbot = RED + robot，是個機器人，檢查HTTP資源，看他們如何會表現，指出常見的問題，並提出改進建議。雖然它屬於HTTP一致性測試儀，但卻可以找到不少HTTP相關問題。

編寫支持緩存的腳本

默認情況下，大多數的腳本不會返回驗證器（Last-Modified或Etag響應頭）或新鮮度信息（Expires或Cache-Control）。儘管有些腳本的確是動態的（意味著每次請求都有不同的響應），還是有很多（如搜索引擎或資料庫驅動的）網站可以從緩存中受益。

一般來講，對於同一個請求（無論是幾分鐘還是幾天之後），如果腳本產生的內容是可重複的，則可以緩存。腳本內容的改變僅僅依賴於URL，則可以緩存。如果是依賴於Cookie，認證信息或其他外部條件，很可能不緩存。

• 最利於緩存的腳本就是在內容改變時導出成靜態文件，伺服器會想對待其他Web一樣對待它的，生成以及使用驗證器，於是你可以好好地喝杯咖啡了。記住，只有文件更改的時候才寫入，這樣Last-Modified時間就會被保存下來。
• 另外的腳本緩存之道就是使用age相關的頭部，相比Expires, Cache-Control: max-age更容易些，因為是相對時間，每次新請求完成後重新設置，時間到了，再重新請求，再設置新的相對過期時間。
• 如果上面的做法你搞不定，你還可以試試通過腳本生成一個校驗器, 然後回應If-Modified-Since和/或If-None-Match請求。通過分析HTTP頭信息，在適合的時候回應304 Not Modified. 不幸的是，這不是個打打醬油就能搞定的任務。

其他一些技巧

• 不要使用POST：若是獲取數據，盡量不使用POST模式，因為POST方式返回內容大部分不會被緩存，相對的，通過GET以路徑和查詢發送的信息被緩存存儲下來供後續使用。
• URL地址中不要嵌入特定的用戶信息，除非生成的內容對於用戶而言是唯一的。
• 不要指望同一用戶的所有請求來自同一主機，因為緩存經常協同工作。//zxx: 嘛意思？
• 生成Content-Length⑩頭信息。實現不難，可讓你的腳本以持久連接(persistent connection)形式響應。這允許客戶端在一個TCP/IP請求上請求多個內容，而不是為每次請求單獨建立連接，這樣你的網站相應會快很多。

詳見實現注意事項。

⑩Content-Length：指明實體正文的長度，以位元組方式存儲的十進位數字來表示。在數據下行的過程中，Content-Length的方式要預先在伺服器中緩存所有數據，然後所有數據再一股腦兒地發給客戶端。

常見問題解答

緩存可用的最重要事情是？

其中一個不錯的策略是找出常用的、規模較大的內容（尤其圖片），然後優先處理之。

我該如何利用緩存讓我的頁面儘可能的快？

最應該緩存的內容設置一個較長的過期時間。驗證有助於減少查看內容的時間，不過緩存仍會連接源伺服器查看是不是過期了。如果緩存已經知道內容是新鮮的，直接返回。

我知道緩存是個好東西，但是我想隨時知道多少人訪問了我的網頁！

如果你必須知道每一次頁面被訪問的情況，可以選擇頁面上的一個小元素(或頁面本身)，然後給這個元素一個適當的頭信息使它是不可緩存。比如，你可以在每一個頁面上引用一個1像素×1像素的不可緩存（如scr地址後面加個隨機數^Add）的透明圖片。Referer頭信息將會包含調用它的頁面信息。

請注意，即使這樣也不能給出你用戶的精確統計，並且對通過互聯網訪問的用戶也不是很友好：產生不必要的流量，並強迫用戶等待未被緩存的內容從網路上下載回來。更多的信息可參見拓展閱讀中的“解讀訪問統計”對應內容。

我該如何查看HTTP頭？

許多瀏覽器可以查看Expires和Last-Modified頭信息，如右鍵→查看頁面信息或類似面板。例如，在Firefox瀏覽器下^Add：

表示要看到完整的頭，您可以使用Telnet客戶端手動連接到Web伺服器上。

為此，你可能需要用一個欄位指定埠（默認是80），或者連接到www.example.com:80或者www.example.com 80(注意是空格)，更多設置請參考一下telnet客戶端的文檔。

一旦連接到該網站，輸入請求。比如，你想查看http://www.example.com/foo.html的頭信息，首先連接到www.example.com, 使用80埠，並輸入：

 

  GET /foo.html HTTP/1.1 [return]    Host: www.example.com [return][return]

 

[return]等同敲回車鍵，最後輸入兩次確認。這樣就會輸出頭信息，然後跟著實際內容。如果只想看到頭信息，使用HEAD來替換GET.

Telnet：Telnet協議是TCP/IP協議族中 的一員，是Internet遠程登陸服務的標準協議和主要方式。它為用戶提供了在本地計算機上完成遠程主機工作的能力。在終端使用者的電腦上使用 telnet程序，用它連接到伺服器。終端使用者可以在telnet程序中輸入命令，這些命令會在伺服器上運行，就像直接在伺服器的控制台上輸入一樣。可 以在本地就能控制伺服器。要開始一個telnet會話，必須輸入用戶名和密碼來登錄伺服器。Telnet是常用的遠程控制Web伺服器的方法。

我的頁面是密碼保護的，代理緩存是怎麼處理的？

默認情況下，HTTP驗證保護的頁面是私有的，共享緩存是不能保存的。然而，你可以通過Cache-Control: public頭的設置使其公有。HTTP 1.1標準兼容的緩存伺服器可以使之緩存。

如果你希望這些緩存的頁面在用戶查看之前還要驗證一下，可以組合使用Cache-Control: public和no-cache頭，這相對於告訴緩存器它從緩存中送出內容前必須遞交客戶端的驗證給原始伺服器。這個頭信息如下所示：

 

  Cache-Control: public, no-cache

 

不管怎麼，這是最小化驗證最好的方法；例如，你的圖片不敏感，你可以把它放在分離的目錄中，並配置你的服務對它們不做強制驗證。這樣，那些圖片就會很自然的被緩存了。

如果人們通過緩存訪問我的網站，我應該擔心安全嗎？

SSL頁面不會被代理伺服器緩存，所以這個你不需要擔心。但是，代理伺服器就好非SSL頁面請求以及URL抓取這口，你懂的，這是不安全的。無良的管理員可能就會收集網站用戶的信息，尤其在URL中。

事實上，任何網路管理員都可以收集你的客戶端和伺服器端之間的這類信息。CGI 腳本有個漏洞，會把用戶名和密碼放在自身的URL地址中，這很容易讓其他人發現用戶的登陸信息。

如果你懂得互聯網安全的些基本機制，就不會對代理緩存感到任何驚訝。

CGI：通用網關介面(Common Gateway Interface). 用於初始化軟體服務的伺服器方介面。這套介面描述了Web伺服器與同一計算機上的軟體的通信方式。

通用網關介面，它是一段程序，運行在伺服器上，提供同客戶端HTML頁面的介面，通俗的講CGI就像是一座橋，把網頁和WEB伺服器中的執行程序連 接起來，它把HTML接收的指令傳遞給伺服器，再把伺服器執行的結果返還給HTML頁；用CGI可以實現處理表格，資料庫查詢，發送電子郵件等許多操作， 最常見的CGI程序就是計數器。CGI使網頁變得不是靜態的，而是互動式的。

我在尋找一個集成的Web發布解決方案。哪些是可緩存的？

這個是不確定的。一般來說，越複雜的系統越難緩存。最差的情況就是所有的內容都是動態生成，並且不提供校驗器，與緩存壓根無緣。你可以和你供應商的技術人員溝通獲取更多信息，並參考下面實現注意事項。

我的圖片緩存一個月後才到期，我現在就想變動！

Expires頭是繞不過去的，除非緩存（瀏覽器或者代理）空間不足才會刪除副本，緩存副本會一直使用。

最有效的方法是修改鏈接，這樣會從源伺服器獲取完整的新內容。請記住，調用圖片的這個頁面也會被緩存的，正因如此，我們需要讓圖片以及其他類似的靜態資源易緩存，而頁面呢可以隨著自身的改變（例如改變了一個圖片的URL地址^Add）即時更新。

如果你想擺脫特定緩存，重載內容，可以試試強制刷新（在FireFox中，shift鍵+reload按鈕等同於處理Pragma: no-cache請求頭）或者讓緩存管理員使用某些介面刪除內容。

我運行一個Web Hosting服務。我怎樣才能讓我的用戶發布緩存友好的網頁？

如果你使用apahe，可以考慮允許他們使用.htaccess文件並提供相應的文檔。

否則你需要在每一個虛擬主機上為各種緩存屬性建立預定的區域。比如：你可以指定一個叫/cache-1m的目錄用來放讀取后要緩存一個月的內容，然後再建一個/no-cache的目錄，並在頭信息中指定這麼目錄中的內容不被緩存。

不管上面你做的如何，總之最好優先給用戶量大的客戶做緩存處理。大部分伺服器節約的流量以及負載都是來自高容量的網站。

我明明告訴網頁要好好緩存，但它老是去請求，怎麼破？

緩存伺服器並不總是要求內容要保持並重用，某些條件下，他們是不保存不重用的，所有的緩存伺服器都回基於文件的大小、類型（圖片、頁面…），或者伺服器空 間的剩餘來確定如何緩存。如果你的文件比較大或很熱門，可能就不會被緩存。有些緩存伺服器允許管理員決定哪些內容要存儲，有些緩存伺服器允許內容長存緩存 中，所以，它們總是可用的。

實現需注意的：Web伺服器端

一般說來，應該選擇最新版本的Web伺服器程序來部署。不僅因為它們包含更多利於緩存的功能，新版本往往在性能和安全性方面都有很多的改善。

Apache HTTP伺服器

Apache使用可選模塊包含頭信息，頭信息Expires和Cache-Control一併包含。這些模塊在1.2版本以上都支持。

這些模塊需要編譯到Apache中，雖然包含，但是默認並未開啟。為了確定相應模塊已經被啟用，找到httpd程序，運行httpd -l, 它會列出可用的模塊（注意，僅有內部編譯的模塊列表才會顯示，在較新版本的Apache中，使用httpd -M可以包含動態載入的模塊^N），我們需要關注的是expires模塊(expires_module)和headers模塊(headers_module)。

httpd：httpd是Apache超文本傳輸協議(HTTP)伺服器的主程序。被設計為一個獨立運行的後台進程，它會建立一個處理請求的子進程或線程的池。

• 如果這些模塊不可用，你需要聯繫管理員，重新編譯以包含這些模塊。這些模塊可以通過取消配置文件中的註釋掉啟用，或者在編譯的時候增加-enable -module=expires和-enable-module=headers參數(apache 1.3+). 參開Apache中的INSTALL文件。

一旦你的Apache有了相應的模塊，你可以使用mod_expires指定過期的時間，要麼在.htaccess文件，要麼在伺服器的access.conf文件。你可以設置過期時間是從訪問時間開始還是文件修改時間開始，並應用到特定類型文件上或設為默認配置。查看官方該模塊文檔獲得更多信息，或者遇到問題的時候向你身邊的apache專家討教。

為應用Cache-Control頭，你需要使用mod_headers模塊，其允許你為資源指定任意的頭信息。可參考mod_headers官方文檔。

下面是.htaccess文件展示了如何使用頭信息：

• .htaccess文件允許Web發布者使用配置文件中的指定。可以影響目錄以及子目錄內容。和你的伺服器管理員溝通下，看看它們是否可用。

   

    ### activate mod_expires    ExpiresActive On    ### Expire .gif's 1 month from when they're accessed  ExpiresByType image/gif A2592000    ### Expire everything else 1 day from when it's last modified    ### (this uses the Alternative syntax)  ExpiresDefault "modification plus 1 day"    ### Apply a Cache-Control header to index.html     Header append Cache-Control "public, must-revalidate"  

   

• 注意，在有些情況下，mod_expires會自動計算並插入Cache-Control:max-age頭信息。

Apache 2′s的配置和1.3類似，更多信息可以參考2.2