整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
擊右上方，關注開源中國OSC頭條號，獲取最新技術資訊
參與翻譯 (3人) : Tocy, 邊城, 李Sir迷路了
這是一個信息文檔。雖然本質上來說本文在講技術，但它嘗試將復雜的概念講簡單而又實用。為了更容易理解，本文會簡化甚至省略某些方面的材料。如果你想深入了解這些主題，請閱讀最后的參考資料。
Web 緩存是什么？為什么要使用緩存？
Web 緩存處于服務器（也稱為源服務器）和客戶端之間，監視請求并保存響應的副本，比如 HTML 頁面，圖片和文件等（統稱為表述）。如果之后有對同一個 URL 的新請求，它會使用自己保存的內容來響應，而不是再次請求源服務器來獲取內容。
使用 Web 緩存主要有下面兩個原因：
Web 緩存的種類
瀏覽器緩存
你在查看現代 Web 瀏覽器（比如 IE、Safari 或 Mazilla）選項的時候，可能會看到“緩存”設置。這個選項讓你配置一部分硬盤空間來保存你看過的表述。瀏覽器緩存的規則相當簡單。它通常會在一次會話（即當前瀏覽器中第一次調用）中檢查表述是否最新。
這個緩存在用戶使用“回退”按鈕或者點擊一個瀏覽過的鏈接時會特別有用。而且，如果你在網站的各個頁面中瀏覽相同的圖片，他們幾乎能馬上從緩存中加載出來。
代理緩存
Web 代理緩存的工作原理相同，但規模更大。代理以同樣的方式為成百上千的用戶服務；大公司和 ISP 常常把代碼緩存建立在防火墻之上，也可能是以獨立設備的形式存在（也稱為中間設備）。
代理緩存即不是客戶端的一部分，也不是服務器的一部分，而是在網絡之外，必須以某種方式把請求路由過去。其中一種方式是手工修改瀏覽器代理設備，指定要使用的代碼；另一種方式是攔截。攔截式代理會根據其自身的基礎網絡重定向 Web 請求，不需要在客戶端配置，客戶端甚至不知道它們的存在。
代理緩存是一種共享緩存，通常不只是一個用戶，而是大量用戶在使用代理緩存。正因為如此，他們特別擅長降低延遲和網絡傳輸量。這是因為眾人都需要的表述會被多次重復使用。
網關緩存
網關緩存又名“反向代理緩存”或“替代緩存”。網關緩存也是一種中介，它他們不是由網絡管理員部署以節約帶寬，而是由網站管理員自己部署，使其站點更具伸縮性、可靠性以及擁有更好的性能。
很多方法都可以把請求路由到網關緩存，但常見的方法是使用負載均衡器讓他們對于客戶來說，看起來就跟源服務器一樣。
內容分發網絡（CDN）在整個 Internet（或它的一部分）中分發網關緩存，并將其出售給對此感興趣的網站。Speedera 和 Akamai 都是 CDN。
本教程主要關注瀏覽器和代理緩存，不過其中一些信息也適用于對網關緩存有興趣的人。
Web緩存對我有壞處么？我為什么要幫助它們？
Web緩存是互聯網中誤解最深的技術之一。因為代理緩存可以隱藏使用網站的用戶，所以網站管理員特別害怕失去對他們的站點的控制，這會使得他們很難去知道是誰在使用他們的站點。
然而不幸的是，即使沒有Web緩存，網絡上也有非常多的因素可以保證管理員精確的知道一個用戶如何使用他們的站點。如果這是你非常關注的問題的話，這篇手冊將會指導你如何在站點沒有不友好的緩存機制的情況下獲取你需要的統計信息。
另一個問題是，緩存可以提供已經失去時效性或者無效的數據給請求方。這篇手冊將會演示如何配置你的服務端的服務來控制數據內容的緩存方式。
另一方面，如果你把站點規劃的非常好，那么緩存將會使得站點的加載速度更快，同時也會減輕服務端和網絡線路的負擔。這兩者之間的區別是非常顯而易見的：一個沒有使用緩存的站點可能需要數秒時間來完成頁面的加載和展示，而另一個借助了緩存機制的網站可能在瞬間就完成了頁面加載和展示。而用戶會更喜歡加載速度迅速的站點，同時也會更加頻繁的訪問這些加載迅速的站點。
內容傳遞網絡 (CDNs) 是一個非常有意思的發展產物，和通常的代理緩存不同的是，CDNs 的網關緩存和被緩存站點的關注點是一致的，所以上述的問題都得到了處理和解決。然而，即便你使用了 CDNs ，你仍然要知道在下游還是會存在代理和瀏覽器緩存的。
我們可以這樣想一下：許多大型的互聯網公司為了讓他們的用戶可以在使用其提供的服務時得到最快速的響應，會斥資數百萬美元在世界范圍內建立許多服務器機群來復制存儲他們的數據內容。其實，緩存也能做這些事情，而且，相對來說緩存離最終的使用用戶會更近。最好的一點是，你根本不用為此支付任何費用。
而事實是，不管你愿意與否，代理和瀏覽器緩存都會被使用在某個環節中。如果你沒有正確的配置站點的緩存相關配置，站點數據將會按照默認的緩存管理員的配置被緩存下來。
Web緩存是如何工作的？
所有的緩存都有一系列用來決定什么時候從緩存中提供內容的規則。如果可能的話，其中的一些規則被放置在了協議中（HTTP 1.0和1.1），而另一些則由緩存的管理員（諸如瀏覽器緩存的用戶，或者代理管理員）來設置。
通常情況下，下面列出的這些規則是最常用到的規則集（不用擔心你不了解規則的詳細嘻嘻，之后會詳細地對這些規則作出解釋）：
如果在響應中沒有相應的驗證器（ ETag 或者 Last-Modified 頭部），且也沒有明確的刷新信息，則這種數據通常但不總是的會被視為不可緩存的數據。
綜合來看，刷新和驗證是緩存可以正常有效的保存內容的最重要途徑。新的數據內容可以可靠的快速的從緩存中得到，與此同時一個經過驗證的表述則避免了在沒有發生變更的情況下被再次完整的發送出去。
如何（以及如何不）控制緩存
有一些工具可以讓網站設計人員和網站管理員來調整緩存對其站點的操作，這可能會使得服務器的配置發生變更，但是這些變更都是有價值的。對于如何在服務器上使用這些工具，在實現這一章節會詳細闡述。
HTML Meta 標簽和 HTTP 頭信息
HTML 作者可以在文檔的 <HEAD> 段中放置標簽來描述一些屬性。其中 meta 標簽常用于確保文檔不被緩存，或者在一定時間后過期。
meta 標簽很容易使用，但效果不怎么樣。這是因為只有部分瀏覽器緩存會遵從約定，代理緩存卻不會（代理基本上不會去分析文檔中的 HTML）。我們可以在 Web 頁面中放置 Pragma: no-cache 這樣的 meta 標簽，但不要指望他一定會保持刷新。
另一方面，真正的 HTTP 頭能讓你很好的控制瀏覽器緩存和代理緩存對表述內容的處理。HTTP 頭在 HTML 中看不到，它們通常由 Web 服務自動生成。不過你可以在一定程度上控制他們，這取決于你用的是什么服務器。你會在下面的部分看到 HTTP 頭是多么有趣，還會了解到該如何把他們應用到網站上。
如果你的站點托管在 ISP 或者專門的托管服務商那里，他們不允許你自己設置到頭重要的 HTTP 頭（比如 Expires 和 Cache-Control），那就勇敢地提出抗議，因為你的工作需要這些功能。
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 頭（以及為什么它沒用）
很多人認為指定了 Pragma: no-cache HTTP 頭可以避免表述被緩存。這并不一定是真的。HTTP 規范中沒有任何關于 Pragma 響應頭的規定，不過 Pragma 請求頭（就是瀏覽器發送給服務器的頭信息）卻正在商討中。雖然有一小部分緩存會遵從這個頭信息，但大多數不會。你應該使用下面這些頭信息代替它。
使用 Expires HTTP 頭控制新近程度
Expires HTTP 頭是控制緩存的基礎方法，它告訴所有緩存與之相關的表述存在多久的保鮮期。那保鮮期之后，緩存應該檢查源服務器，看文檔是否被改變。幾乎各種緩存都支持 Expires 頭。
多數服務器允許你通過多種方法來設置 Expires 響應頭。一般來說，他們可以設置絕對的過期時間，根據上次客戶端取回表述時（最近訪問時間）計算的時間，或者根據上次服務器文檔修改時間計算的時間（最近修改時間）。
Expires 頭特別適合緩存靜態圖像（比如導航欄和按鈕），因為他們不會經常變化，你可以為他們設置一個非常長的過期時間，使你的站點具有更優勢的響應性能。對于一些更新比較規律遙頁面來說，他們也很有用。舉例來說，如果你每天早晨 6:00 更新新聞頁面，那就可以把表述內容設置在那個時間過期，然后緩存會知道什么時候該去獲取更新的內容，而不需要用戶去點擊“刷新”。
Expires 頭只支持 HTTP 日期值，任何其它值都會被認為“過去時”，結果表述不會被緩存。還要注意，HTTP 日期是格林威治（GMT）時間，而不是本地時間。
比如：
Expires: Fri, 30 Oct 1998 14:19:41 GMT
雖然 Expires 頭很有用，但它也有一些局限。首先日期就是個麻煩事，Web 服務器和緩存上的時鐘就必須同步。如果他們對時間的看法不一致就達不到預期的效果，因為緩存有可能認為已經過期的內容還在有效期內。
如果使用Expires 頭就必須保證服務器時鐘的準確性，這非常重要。要達到這個條件，有一個辦法是使用網絡時間協議（NTP），請向你身邊的系統管理員了解關于 NTP 的知識。
使用 Expires 的另一個問題是容易忘記為某些內容設置了特定的過期時間。如果你沒有在那之前更新 Expires，那么每個請求最終都會到服務器上去獲取內容，既增加延遲，也會增加負載。
Cache-Control HTTP 頭
HTTP 1.1 引入了一類新的頭信, Cache-Control 響應頭，讓 Web 可以更方便地控制內容，避免 Expires 所具有的限制。
Cache-Control 響應頭有如下一些：
舉例說明：
Cache-Control: max-age=3600, must-revalidate
當 Cache-Control 和 Expires 都存在時，Cache-Control 優先。如果你準備使用 Cache-Control 頭，你應該查看 HTTP 1.1 中的優秀文檔; 參見"引文及更多信息"一節。
校驗器和校驗
在 Web 緩存的工作原理一文中，我們說過在表示層發生變化時服務器和緩存使用校驗進行通信。通過使用它，緩存可以避免在本地已有副本時下載整個表示層，但他們不確定它是否仍然是最新的。
校驗器是非常重要的; 如果它不存在，并且沒有任何新的信息（ Expires 或 Cache-Control ）可用，則緩存將根本不存儲表示層。
最通用的校驗器是頭部的 Last-Modified，用來標識文檔最近一次修改的時間。如果緩存存儲了一個帶有Last-Modified 頭部的表示層，緩存可以借助一個 If-Modified-Since 請求向服務端確認當前緩存的表示層在最近一次修改后是否發生了變更。
HTTP1.1引入了一個新的叫做 ETag 的校驗器。ETags是一個由服務端生成的唯一標識符，并且每當表示層發生變更時ETags的值都會發生變化。由于ETag是由服務端生成的，所以當緩存通過 If-None-Match 請求得知ETag在服務端匹配成功時，便可以確認緩存存儲的表示層和服務端的內容是一致的，沒有發生任何變化。
幾乎所有的緩存都使用了最近一次修改時間來作為校驗器，同時ETag校驗器的使用也在逐步增長。
大多數的現代網站服務器會自動地為靜態內容（例如文件）同時生成 ETag 和 Last-Modified 這兩個校驗器，這個過程不需要任何人為參與。然而，服務器在為諸如CGI、ASP或者數據庫站點這樣的動態內容生成ETag 和 Last-Modified 校驗器時就顯得力不從心了，具體可瀏覽編寫緩存可感知的腳本。
關于構建一個緩存感知的站點的忠告
除了使用新鮮度信息和校驗，還有一些其他的處理可以使得你的站點更利于緩存。
編寫緩存可感知的腳本
默認情況下，大多數腳本不會返回校驗器（一個 Last-Modified 或 ETag 響應頭）或新鮮度信息（ Expires 或 Cache-Control ）。雖然一些腳本確實是動態的（意味著它們為每個請求返回不同的響應），但許多（如搜索引擎和數據庫驅動的網站）可以從此類緩存友好中受益。
一般來說，如果腳本生成的輸出在以后的某個時間（無論是幾分鐘還是幾天后）都可以使用相同的請求重現，那么它應該是可緩存的。如果腳本的內容僅根據 URL 中的內容而變動，則它是可緩存的; 如果其輸出取決于cookie、身份認證信息或其他外部標準，則它可能不是可緩存的。
其它技巧：
請閱讀實現說明來了解更具體的信息。
FAQs （常見問題）
實現可緩存最重要的事情是什么？
一個好的策略是識別最流行、最大的表示層（尤其是圖像）并首先在它們上使用。
我如何使用緩存盡可能快地加載頁面？
最可緩存的表示層是具有較長新鮮時間集的那一部分。校驗確實有助于減少查看表示層所花費的時間，但緩存仍然必須聯系原服務器以查看它是否是最新的。 如果緩存已經知道它是最新的，它將被直接提供。
我知道緩存很棒，但我需要統計有多少人訪問了我的頁面！
如果在每次訪問頁面時你都必須知悉，在頁面（或頁面本身）上選擇 ONE 小項，并通過為其提供適當的頭信息使其不可緩存。例如，你參考每個頁面上的 1x1 透明的不可緩存圖像的邏輯。Referer 頭將包含有關哪個頁面調用它的信息。
請注意，即使這樣也無法提供有關你用戶的真實準確的統計信息，并且對互聯網和你的用戶是不友好的; 它會產生不必要的流量，并強迫人們等待下載完成未緩存項。有關此內容的更多信息，請參閱引文中的對訪問統計信息的解讀。
如何獲取一個表示層的HTTP頭部信息？
許多瀏覽器會通過一個“page info”或者一個小型的接口等方式向使用者提供 Expires 和 Last-Modified 的頭部信息。如果可以的話，你會得到一個頁面的菜單和關聯在這個頁面上的任何表示層（比如圖像），以及這些表示層的詳細信息。
如果想要看到表示層的所有HTTP頭部信息，可能需要使用Telnet客戶端手動連接到Web服務器上。
要想通過Telnet連接到服務器上，需要把端口號（默認80）作為一個獨立的字段輸入到連接到請求中，需要以如下的形式連接到服務器上： www.example.com:80 或者 www.example.com 80（以空格分隔） 。具體格式可以參考你使用的客戶端文檔。
一旦連接成功建立，就可以對任意表示層發起請求。例如，如果你想要獲得 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 即可。
我的頁面是受密碼保護的，代理緩存怎么處理這種情況？
默認情況下，受HTTP身份認證保護的頁面被視為是私有的，這些頁面不會被共享緩存保存下來。然而，可以通過緩存控制(Cache-Control): public 頭部使受身份認證保護的頁面變成共有資源，適用于HTTP1.1的緩存就會將這些頁面緩存下來。
如果你想讓這些頁面既能被緩存存儲的同時又能繼續保持其對每個用戶的身份認證特性，就需要將 Cache-Control: public 和 no-cache 結合起來使用。這兩個頭部會要求緩存取出表示層數據返回給請求之前首先將用戶的身份信息提交給服務器進行認證。命令格式如下：
Cache-Control: public, no-cache
不管上面的處理執行與否，最好的方式是最小化認證保護的使用范圍。例如，如果圖片數據是非敏感數據，那么將這些圖片放在一個獨立的文件夾目錄下，然后在服務端配置不對這個文件夾目錄做身份認證保護。這樣，這些圖片就可以被緩存存儲起來了。
如果人們通過緩存訪問我的站點，我需要擔心安全性嗎？
https:// 頁面是不會被代理緩存緩存（或解密）的，因此你不必擔心這一點。然而，因為緩存存儲了從獲取的 http:// 響應和 URL ，所以你應該對不安全的站點小心一些; 一個不道德的管理員可以隨意地收集有關其用戶的信息，尤其是在 URL 中。
實際上，在服務器和客戶端之間的網絡上的任何管理員都可以收集此類信息。一個特別的問題是 CGI 腳本將用戶名和密碼放在 URL 本身中; 這使得其他人找到并使用這些登錄信息變得很簡單。
如果你知道常見的 Web 安全性所存在的問題，那么代理緩存不應該有任何例外。
我正在尋找一個集成 Web 發布解決方案。哪一個是緩存可感知的？
這要看具體情況。一般來說，解決方案越復雜，緩存起來就越困難。最糟糕的是動態生成所有內容并不提供校驗器的解決方案; 它們可能根本是不可緩存的。請與供應商的技術人員聯系以獲取更多信息，并參閱下面的實現說明。
我的圖片在一個月以后才失效，但是我需要現在就在緩存中更新它們！
過期(Expires)頭部是沒有辦法繞過去的，緩存內容會一直被使用直到緩存（不管是瀏覽器緩存還是代理緩存）耗盡了存儲空間并且必須刪除掉所有的表示層。
最有效的解決方法是改變任何指向它們的鏈接，這樣，全新的表示層會從源服務端加載到客戶端。記住，任何引用了這些表示層的頁面也會被緩存保存下來。鑒于此，最好將靜態圖片和相似的表示層全都緩存下來，同時嚴格把控引用這些資源的HTML頁面。
如果想要從某個指定的緩存中重新加載一個表示層，你既可以在使用緩存的時候強制加載（在Firefox中，按下shift的同時按下‘reload’將發出一個 Pragma: no-cache請求頭部來完成這個操作），也可以讓緩存管理員通過他們的接口刪除掉這個表示層。
如何讓用戶在我負責維護的網站托管服務上發布緩存友好的頁面？
如果你使用的的Apache，考慮下容許他們使用 .htaccess文件并且提供對應的文檔。
否則，你可以建立一個事先決定好的區域，這個區域用來對應每個虛擬服務上的各種緩存屬性。例如，可以指定一個 /cache-1m 目錄來維護需要在訪問后緩存一個月的緩存內容的相關信息，一個 /no-cache 目錄通過使用頭部信息標識那些不需要緩存存儲來自其自身的表示層。
不管你能做什么，最好首先在緩存方面和你的最大的客戶一起合作。大部分的節省（帶寬和服務器負載方面）會從高流量站點中產生。
頁面是可緩存的，但是瀏覽器在每次請求時都會重新請求這些頁面。怎么樣可以強制緩存存儲這些表示層？
緩存不需要保留或者重用一個表示層，它只需要在某些情況下不保留或者使用它們。基于表示層的文件大小、類型（圖片或者HTML文件）、以及它們需要占用的存儲空間大小，緩存會決定哪些表示層會被保存下來。相對于更受歡迎或者更大的表示層，緩存認為你的內容可能不值得被緩存存儲起來。
一些緩存機制允許管理員決定哪些表示層可以優先被緩存，而另外一些緩存機制則允許表示層可以被固定在緩存中，這樣它們就總是有效的表示層。
實施說明 — Web 服務器
一般來說，不管你想部署到哪個 Web 服務器，最好都選擇它最新的版本。新版本可能會包含更易于處理緩存的特性，而且通常還會在非常重要的安全和性能方面所有改進。
Apache HTTP 服務器
Apache 使用可選的模塊來包含 Expires 和 Cache-Control 等頭參數。這兩個模塊都是從 1.2 開始加入的。
模塊需要設置到 Apache 中。雖然模塊被包含在發行包中，但默認情況下并未設置可用。想知道某個模塊是否在服務器中可用，找到 https 二進制程序然后運行httpd -l。這個命令會打印出已經生效的模塊列表（注意這只包含了隨 Apache 編譯的模塊。在以后的 Apache 版本中，可以使用 httpd -M 把動態加載的模塊也打印出來）。我們要找 expires_module 和 headers_module 這兩個模塊。
一旦你的 Apache 包含了正確的模塊，就可以使用 mod_expires 來指定表述到期的時間，這個配置寫在 .htaccess 文件或者服務器的 asccess.conf 文件中都行。你可以按訪問時間或修改時間來指定過期時間，可以將其應用于某個文件類型，也可以用作默認配置。請閱讀模塊文檔來了解更多信息，如果發現問題請找你附件的 Apache 專家幫忙。
要應用Cache-Control頭，你需要使用mod_headers模塊，該模塊允許你為某資源指定任意HTTP頭。 請參閱mod_headers文檔。
這是一個示例.htaccess文件，展示了一些頭的使用。
### 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 <Files index.html> Header append Cache-Control "public, must-revalidate" </Files>
Apache 2的配置和1.3版本的非常類似；更多信息請參考2.2 mod_expires和mod_headers文檔。
微軟的IIS
Microsoft的Internet Information Server以一種靈活的方式使得設置頭信息變得非常容易。請注意，這僅適用于服務器的第4版，該版本僅在NT Server上運行。
要指定站點區域的頭信息，請在“Administration Tools”界面中選擇它，然后調出其屬性。在選擇HTTP Headers選項卡之后，你應該看到兩個有趣的區域; Enable Content Expiration和Custom HTTP headers。第一個區域應該是不言自明的，第二個可以用于適用于Cache-Control頭。
有關在Active Server Pages中設置頭的資料，請參閱下面的ASP部分。也可以從ISAPI模塊設置頭; 有關詳細信息，請參考MSDN。
Netscape/iPlanet企業服務器
從版本3.6開始，企業服務器不再提供任何顯式的方法來設置Expires頭。但是，它從3.0開始就支持HTTP 1.1功能。這意味著HTTP 1.1緩存（代理和瀏覽器）將能夠利用你所做的緩存控制配置。
要使用Cache-Control頭，請選擇管理服務器中的Content Management | Cache Control Directives。 然后，使用資源選擇器，選擇要設置頭的目錄。設置完頭信息后，單擊“確定”。更多信息，請參閱NES手冊。
實現附注— 服務器端腳本
由于服務器端腳本的重點在于動態內容，因此即使是對可緩存的內容，也不會生成可緩存的頁面。如果你的內容經常變動，但不是每次點擊都會變動，請考慮設置Cache-Control：max-age頭; 大多數用戶在相對較短的時間內再次訪問該頁面。例如，當用戶點擊“后退”按鈕時，如果沒有任何校驗器或新鮮度信息可用，則他們必須等到從服務器重新下載頁面之后才能看到它。
要記住的一件事是，使用Web服務器時設置HTTP比在腳本語言中設置HTTP標頭更容易。都嘗試下。
CGI
CGI腳本是最常用的生成內容的方式之一。你可以通過在發送正文之前添加HTTP響應頭輕松得附加到HTTP響應頭上;大多數CGI實現已經要求你為Content-Type頭執行此操作。例如，在Perl中;
#!/usr/bin/perl print "Content-type: text/html\n"; print "Expires: Thu, 29 Oct 1998 17:04:19 GMT\n"; print "\n"; ### the content body follows...
既然它全是文本，你可以簡單地使用內置函數生成Expires以及其他日期相關的頭信息。如果你使用Cache-Control: max-age將會更簡單；
print "Cache-Control: max-age=600\n";
這將使此腳本在請求后可緩存10分鐘，因此如果用戶點擊“后退”按鈕，他們將不會重新提交請求。
CGI規范還使得在腳本環境中客戶端所發送的請求頭可用; 每個標頭的名稱前面都有“HTTP_”。因此，如果客戶端發出If-Modified-Since請求，它將顯示為HTTP_IF_MODIFIED_SINCE。
Server Side Includes
SSI（通常與擴展名為.shtml的一起使用）是Web發布者能夠將動態內容添加到頁面中的首選方式之一。通過在頁面中使用特殊標記，可以使用有限形式的HTML內腳本。
大多數SSI實現都沒有設置校驗器，因此SSI是不能緩存。 但Apache的實現允許用戶通過在適當的文件上設置組執行權限并結合XbitHack full指令來指定可以緩存哪些SSI文件。更多相關信息，請參閱mod_include文檔。
PHP
PHP是一種服務器端腳本語言，當內置到服務器中時，可用于在頁面的HTML中嵌入腳本，就像SSI一樣，但具有更多的可選項。 PHP可以在任意Web服務器（Unix或Windows）上用作CGI腳本，也可以作為Apache模塊。
默認情況下，PHP處理的表示層不會分配驗證器，因此是不可緩存。但是，開發人員可以使用Header()函數設置HTTP頭。
例如，下列代碼將創建一個Cache-Control頭和一個三天之后過期的Expires頭：
<?php
Header("Cache-Control: must-revalidate");
$offset=60 * 60 * 24 * 3;
$ExpStr="Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT";
Header($ExpStr);
?>
注意 Header() 函數必須置于所有輸出前。
如你所見，你必須手動為Expires頭創建HTTP日期; PHP沒有提供為你完成此操作的函數（盡管最新版本使其更容易;請參閱PHP的date文檔）。當然，設置Cache-Control: max-age頭是很容易，這對大多數情況來說已經不錯了。
有關更多信息，請參閱header的手冊條目。
Cold Fusion
由Macromedia發布的Cold Fusion是一個商業版服務器端腳本引擎，支持在Windows、Linux 以及Unix變體上的多種web服務器。
Cold Fusion 使用CFHEADER標簽使得設置任意HTTP頭相對簡單。遺憾的是，他們設置Expires 頭的示例，如下所示，有一些誤導。
<CFHEADER NAME="Expires" VALUE="#Now()#">
它不像你想象的那樣工作，因為其中的時間值（在這種情況下，發出請求的時間）不會轉換為HTTP有效的日期; 相反，它僅作為Cold Fusion的日期/時間對象的表示打印出來。大多數客戶端將忽略這樣的值，或將其轉換為默認值，如1970年1月1日。
然而，Cold Fusion確實提供了可以完成日期格式化的函數;GetHttpTimeString。與DateAdd配合使用，可以輕松設置過期失效日期; 在此，我們設置一個頭信息，來聲明此頁面的表示在一個月后失效;
<cfheader name="Expires"
value="#GetHttpTimeString(DateAdd('m', 1, Now()))#">
你也可使用CFHEADER 標簽來設置Cache-Control: max-age 以及其他頭信息。
請記住，Web服務器的頭信息是通過Cold Fusion的某些部署進行傳遞的（例如CGI）; 通過在服務器上而不是在Cold Fusion中設置頭信息，驗證下你是否可以使用此功能。
ASP和ASP.NET
Active Server Pages，內置于IIS中，在其他Web服務中也可用，也允許你設置HTTP頭。例如，要設置失效時間，可以使用Response對象的屬性;
<% Response.Expires=1440 %>
從ASP設置HTTP頭時，請確保在任意HTML生成之前放置了對Response方法的調用，或者使用Response.Buffer來緩沖輸出。另請注意，默認情況下，某些版本的IIS在ASP上設置了一個Cache-Control: private的頭，并且必須聲明為公開，才能通過共享緩存進行緩存。
指定從請求到表示層超時的分鐘數。可以像這樣添加到 Cache-Control 頭中：
<% Response.CacheControl="public" %>
在 ASP.NET 中，Response.Expires 已不推薦使用了；設置緩存相關頭信息的正確方法是使用 Response.Cache ;
Response.Cache.SetExpires ( DateTime.Now.AddMinutes ( 60 ) ) ; Response.Cache.SetCacheability ( HttpCacheability.Public ) ;
引用及更多
HTTP 1.1規范
HTTP 1.1 規范中有很多關于實現網頁可緩存的擴展，同時它也是實現此協議權威指南。請查看 13, 14.9, 14.21 以及 14.25 部分內容。
Web-Caching.com
對緩存概念的一篇很棒的介紹，包含其他在線資源的鏈接。
關于訪問信息的解讀
Jeff Goldberg 對你不應該依賴訪問統計和點擊計數器的原因提供了豐富的信息。
REDbot
檢查 HTTP 資源以確定它們與 Web 緩存的交互方式，以及常規情況下它們對協議協議的使用是否得當。
開源社區OSC「好文翻譯」欄目，旨在每天為用戶推薦并翻譯優質的外網文章。再也不用怕因為英語不過關，被擋在許多技術文章的門外。關注開源社區OSC，每日獲取翻譯好文推薦，點擊“了解更多”，閱讀原文章。
HTML、CSS、javascript三者的關系
<!DOCTYPE HTML>
指示 web 瀏覽器關于頁面使用哪個 HTML 版本進行編寫,必須寫在所有代碼的第一行!
如果你的頁面添加了<!DOCTYPE html>，那么就等同于開啟了標準模式，那么瀏覽器就得老老實實的按照W3C的標準解析渲染頁面，這樣一來，你的頁面在所有的瀏覽器里顯示的就都是一個樣子了。
這個屬性會被瀏覽器識別并使用，但是如果你的頁面沒有DOCTYPE的聲明，瀏覽器按照自己的方式解析渲染頁面，那么，在不同的瀏覽器就會顯示不同的樣式。
這就是<!DOCTYPE html>的作用。
固定結構
結構如下：
<html> <head>...</head> <body>...</body> </html>
代碼講解：
在很多國際化的網站中會使用到！<html lang="zh-CN"> </html>告訴瀏覽器等設備，語言使用以中文為顯示和閱讀基礎!英文使用 en
head標簽
下面我們來了解一下<head>標簽的作用。文檔的頭部描述了文檔的各種屬性和信息，包括文檔的標題等。絕大多數文檔頭部包含的數據都不會真正作為內容顯示給讀者。
下面這些標簽可用在 head 部分：
<head> <title>...</title> <meta> <link> <style>...</style> <script>...</script> </head>
<title>標簽：
meta標簽
content="text/HTML; 文檔類型，這里為html,如果JS就是text/javascript，
charset=utf-8 頁面字符集，編碼，eg:gb2312,iso-8859-1,utf-8
meta是html語言head區的一個輔助性標簽。幾乎所有的網頁里，我們可以看到類似下 面這段的html代碼：
<head> <meta http-equiv="content-Type" content="text/html; charset=gb2312"> </head>
也許你認為這些代碼可有可無。其實如果你能夠用好meta標簽，會給你帶來意想不到的效果，例如加入關鍵字會自動被大型搜索網站自動搜集；可以設定頁面格式及刷新等等。
meta標簽共有兩個屬性，它們分別是http-equiv屬性和name屬性，不同的屬性又有不同的參數值，這些不同的參數值就實現了不同的網頁功能。
1、name屬性
name屬性主要用于描述網頁，與之對應的屬性值為content，content中的內容主要是便于搜索引擎機器人查找信息和分類信息用的。
meta標簽的name屬性語法格式是：
<meta name="參數" content="具體的參數值">
其中name屬性主要有以下幾種參數：
1）Keywords(關鍵字) 說明：keywords用來告訴搜索引擎你網頁的關鍵字是什么。 舉例： <meta name="keywords" content="science, education,culture,politics,ecnomics，relationships, entertaiment, human"> 2）description(網站內容描述) 說明：description用來告訴搜索引擎你的網站主要內容。 舉例： <meta name="description" content="This page is about the meaning of science, education,culture."> 3）robots(機器人向導) 說明：robots用來告訴搜索機器人哪些頁面需要索引，哪些頁面不需要索引。 content的參數有all,none,index,noindex,follow,nofollow。默認是all。 舉例： <meta name="robots" content="none"> 4）author(作者) 說明：標注網頁的作者 舉例： <meta name="author" content="root,root@21cn.com">
2、http-equiv屬性
http-equiv顧名思義，相當于http的文件頭作用，它可以向瀏覽器傳回一些有用的信息，以幫助正確和精確地顯示網頁內容，與之對應的屬性值為content，content中的內容其實就是各個參數的變量值。
meta標簽的http-equiv屬性語法格式是：
<meta http-equiv="參數" content="參數變量值">
其中http-equiv屬性主要有以下幾種參數：
1）Expires(期限) 說明：可以用于設定網頁的到期時間。一旦網頁過期，必須到服務器上重新傳輸。 用法： <meta http-equiv="expires" content="Fri, 12 Jan 2001 18:18:18 GMT"> 注意：必須使用GMT的時間格式。 2）Pragma(cache模式) 說明：禁止瀏覽器從本地計算機的緩存中訪問頁面內容。 用法： <meta http-equiv="Pragma" content="no-cache"> 注意：這樣設定，訪問者將無法脫機瀏覽。 3）Refresh(刷新) 說明：自動刷新并指向新頁面。 用法： <meta http-equiv="Refresh" content="2;URL=http://www.root.net">(注意后面的引號，分別在秒數的前面和網址的后面) 注意：其中的2是指停留2秒鐘后自動刷新到URL網址。 4）Set-Cookie(cookie設定) 說明：如果網頁過期，那么存盤的cookie將被刪除。 用法： <meta http-equiv="Set-Cookie" content="cookievalue=xxx; expires=Friday, 12-Jan-2001 18:18:18 GMT； path=/"> 注意：必須使用GMT的時間格式。 5）Window-target(顯示窗口的設定) 說明：強制頁面在當前窗口以獨立頁面顯示。 用法： <meta http-equiv="Window-target" content="_top"> 注意：用來防止別人在框架里調用自己的頁面。 6）content-Type(顯示字符集的設定) 說明：設定頁面使用的字符集。 用法： <meta http-equiv="content-Type" content="text/html; charset=gb2312"> 7）content-Language（顯示語言的設定） 用法： <meta http-equiv="Content-Language" content="zh-cn" />
meta標簽的功能
3、style中的屬性
標題標簽
文章的段落用<p>標簽，那么文章的標題用什么標簽呢？下面我們將使用<hx>標簽來制作文章的標題。
標題標簽一共有6個，h1、h2、h3、h4、h5、h6分別為一級標題、二級標題、三級標題、四級標題、五級標題、六級標題。并且依據重要性遞減。<h1>是最高的等級。
語法：
<hx>標題文本</hx> (x為1-6)
文章的標題前面已經說過了，可以使用標題標簽，另外網頁上的各個欄目的標題也可使用它們。
例如：
<body> <h1>一級標題</h1> <h2>二級標題</h2> <h3>三級標題</h3> <h4>四級標題</h4> <h5>五級標題</h4> </body>
HTML注釋
代碼注釋的作用是幫助程序員標注代碼的用途，過一段時間后再看你所編寫的代碼，就能很快想起這段代碼的用途。代碼注釋不僅方便程序員自己回憶起以前代碼的用途，還可以幫助其他程序員很快的讀懂你的程序的功能，方便多人合作開發網頁代碼。
<!--注釋文字 -->
語義化
標簽的用途：我們學習網頁制作時，常常會聽到一個詞，語義化。那么什么叫做語義化呢，說的通俗點就是：明白每個標簽的用途（在什么情況下使用此標簽合理）比如，網頁上的文章的標題就可以用標題標簽，網頁上的各個欄目的欄目名稱也可以使用標題標簽。文章中內容的段落就得放在段落標簽中，在文章中有想強調的文本，就可以使用 em 標簽表示強調等等。
講了這么多語義化，但是語義化可以給我們帶來什么樣的好處呢？
后面會帶領大家學習了解html中每個標簽的語義（用途）。
喜歡前端的小伙伴們可以在評論區留言，尋找和小馮童鞋一樣熱愛前端的友人，讓我們一起玩轉前端的世界！
者：kevinylzhao，騰訊音樂前端開發工程師
瀏覽器緩存策略對于前端開發同學來說不陌生，大家都有一定的了解，但如果沒有系統的歸納總結，可能三言兩語很難說明白，甚至說錯，尤其在面試過程中感觸頗深，很多候選人對這類基礎知識竟然都是一知半解，說出幾個概念就沒了，所以重新歸納總結下，溫故而知新。
瀏覽器緩存一般分為兩類：強緩存（也稱本地緩存）和協商緩存（也稱弱緩存）。
瀏覽器發送請求前，會先去緩存里查看是否命中強緩存，如果命中，則直接從緩存中讀取資源，不會發送請求到服務器。否則，進入下一步。
當強緩存沒有命中時，瀏覽器一定會向服務器發起請求。服務器會根據 Request Header 中的一些字段來判斷是否命中協商緩存。如果命中，服務器會返回 304 響應，但是不會攜帶任何響應實體，只是告訴瀏覽器可以直接從瀏覽器緩存中獲取這個資源。如果本地緩存和協商緩存都沒有命中，則從直接從服務器加載資源。
按照本地緩存階段和協商緩存階段分類：
上述代碼的作用是告訴瀏覽器當前頁面不被緩存，事實上這種禁用緩存的形式用處很有限：
a. 僅有 IE 才能識別這段 meta 標簽含義，其它主流瀏覽器僅識別“Cache-Control: no-store”的 meta 標簽。
b. 在 IE 中識別到該 meta 標簽含義，并不一定會在請求字段加上 Pragma，但的確會讓當前頁面每次都發新請求（僅限頁面，頁面上的資源則不受影響）。
在 HTTP 請求和響應的消息報頭中，常見的與緩存有關的消息報頭有：
上圖中只是常用的消息報頭，下面來看下不同字段之間的關系和區別：
a. Last-Modified 標注的最后修改只能精確到秒級，如果某些文件在 1 秒鐘以內，被修改多次的話，它將不能準確標注文件的新鮮度；
b. 某些文件也許會周期性的更改，但是它的內容并不改變(僅僅改變的修改時間)，但 Last-Modified 卻改變了，導致文件沒法使用緩存；
c. 有可能存在服務器沒有準確獲取文件修改時間，或者與代理服務器時間不一致等情形。
瀏覽器可以在內存、硬盤中開辟一個空間用于保存請求資源副本。我們經常調試時在 DevTools Network 里看到 Memory Cache（內存緩存）和 Disk Cache（硬盤緩存），指的就是緩存所在的位置。請求一個資源時，會按照優先級（Service Worker -> Memory Cache -> Disk Cache -> Push Cache）依次查找緩存，如果命中則使用緩存，否則發起請求。這里先介紹 Memory Cache 和 Disk Cache。
200 from memory cache
表示不訪問服務器，直接從內存中讀取緩存。因為緩存的資源保存在內存中，所以讀取速度較快，但是關閉進程后，緩存資源也會隨之銷毀，一般來說，系統不會給內存分配較大的容量，因此內存緩存一般用于存儲較小文件。同時內存緩存在有時效性要求的場景下也很有用（比如瀏覽器的隱私模式）。
200 from disk cache
表示不訪問服務器，直接從硬盤中讀取緩存。與內存相比，硬盤的讀取速度相對較慢，但硬盤緩存持續的時間更長，關閉進程之后，緩存的資源仍然存在。由于硬盤的容量較大，因此一般用于存儲大文件。
下圖可清晰看出差別：
200 from prefetch cache
在 preload 或 prefetch 的資源加載時，兩者也是均存儲在 http cache，當資源加載完成后，如果資源是可以被緩存的，那么其被存儲在 http cache 中等待后續使用；如果資源不可被緩存，那么其在被使用前均存儲在 memory cache。
CDN Cache
以騰訊 CDN 為例：X-Cache-Lookup:Hit From MemCache 表示命中 CDN 節點的內存；X-Cache-Lookup:Hit From Disktank 表示命中 CDN 節點的磁盤；X-Cache-Lookup:Hit From Upstream 表示沒有命中 CDN。
從上圖能感受到整個流程，比如常見兩種刷新場景：
IndexedDB 就是瀏覽器提供的本地數據庫，能夠在客戶端存儲可觀數量的結構化數據，并且在這些數據上使用索引進行高性能檢索的 API。
異步 API 方法調用完后會立即返回，而不會阻塞調用線程。要異步訪問數據庫，要調用 window 對象 indexedDB 屬性的 open() 方法。該方法返回一個 IDBRequest 對象 (IDBOpenDBRequest)；異步操作通過在 IDBRequest 對象上觸發事件來和調用程序進行通信。
常用異步 API 如下：
在 16 年曾基于 IndexDB 做過一整套緩存策略，有不錯的優化效果：
SW 從 2014 年提出的草案到現在已經發展很成熟了，基于 SW 做離線緩存，讓用戶能夠進行離線體驗，消息推送體驗，離線緩存能力涉及到 Cache 和 CacheStorage 的概念，篇幅有限，不展開了。
localStorage 屬性允許你訪問一個 Document 源(origin)的對象 Storage 用于存儲當前源的數據，除非用戶人為清除(調用 localStorage api 或者清除瀏覽器數據)， 否則存儲在 localStorage 的數據將被長期保留。
sessionStorage 屬性允許你訪問一個 session Storage 對象，用于存儲當前會話的數據，存儲在 sessionStorage 里面的數據在頁面會話結束時會被清除。頁面會話在瀏覽器打開期間一直保持，并且重新加載或恢復頁面仍會保持原來的頁面會話。
通過了解瀏覽器各種緩存機制和存儲能力特點，結合業務制定合適的緩存策略，善用緩存是基本功，可以用于時常審查負責的業務，可能就會發現個別業務并沒有運用到位，共勉。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
