【原】http緩存與cdn相關技術

摘要：最近要作這個主題的組內分享，因此準備了一個星期，查了比較多的資料。準備的過程雖然很煩很耗時間，不過由於須要查不少的資料，所以整個過程下來，對這方面的知識影響更加深入。來來來，接下來總結總結

 

一 http緩存

 

1.1緩存的分類：

http中具備緩存功能的是：一、瀏覽器緩存、  二、緩存代理服務器。

 

1.2 什麼是緩存：

http緩存的是指:當Web請求抵達緩存時， 若是本地有「已緩存的」副本，就能夠從本地存儲設備而 不是從原始服務器中提取這個文檔。

 

1.3 緩存的好處有：

1. 減小了冗餘的數據傳輸，節省了網費。

2. 減小了服務器的負擔， 大大提升了網站的性能

3. 加快了客戶端加載網頁的速度。優化用戶體驗

 

1.4 緩存示意圖：

 

第一次請求：

 

 

第一次請求，不管是靜態文件仍是其餘文件，都是從服務器那裏讀取的。所以沒有緩存之說。等第一次請求完，瀏覽器就有緩存了，而後整個的加載過程就徹底不同了。看下圖：

 

 

 

瀏覽器再次請求

　流程圖解釋：

 

   瀏覽器再次請求，狀況就不同了。首先會讀取緩存，而後判斷緩存是否過時，若是不過時，就直接讀取緩存。

不然，判斷瀏覽器返回的頭部信息是否存在Etag,若是存在，瀏覽器會像服務器發送帶有If-None-Match的請求頭，來和服務器返回的Etag作對比，

若是if-None-Match和Etag相等。說明緩存沒有更新，服務器返回304，瀏覽器繼續從緩存讀取相應的內容。若是if-None-Match和Etag不等，則服務器返回200，瀏覽器從新需

要從服務器獲取內容。

　　若是服務器的返回信息裏面沒有Etag，則判斷瀏覽器的返回信息裏是否有Last-Modified。若是有，瀏覽器會像服務器發送一個if-Modified-Since的請求頭。而後if-Modified-

Since的值會和Last-Modified的值作對比，若是if-Modified-Since的值大於等於Last-Modified，則服務器返回304，文件沒有更新，直接讀取緩存便可。若是if-Modified-Since

的值小於Last-Modified。則說明瀏覽器的緩存不是最新的，須要從服務器從新讀取。

　　若是服務器返回的頭部信息既沒有Etag，又沒有Last-Modified,則緩存已經失效了，從新服務器抓取。

若是第一次接觸瀏覽器緩存的同窗，可能會暈掉。說的是什麼鬼東西，頭都暈了，尼瑪。好的，接下來就解釋一下上面說的那些概念。

 

2、Http緩存概念解析

 

2.1 Expires策略

　　Expires是web服務器 響應消息頭字段，在響應http請求時告訴瀏覽器在過時時間前，瀏覽器能夠直接從瀏覽器緩存讀取數據，而無需再次請求，它的值對應一個GMT（格林尼治時間），好比「Mon, 22 Jul 2012 11:15:08 GMT」來告訴瀏覽器資源緩存過時時間，若是還沒過該時間點則不發請求。

咱們可使用meta標籤來告知頁面。不過值對ie有效。以下：

<meta http-equiv="expires" content="sun, 19 apr 2016 14:30:00 GMT">

　　

　　不過Expires是HTTP 1.0的東西。如今瀏覽器都是默認HTTP 1.1的了。因此基本能夠忽略它。Expires有一個缺點，就是它的過時時間是服務器的時間，好比個人客戶端時間和服務器時間相差很大，那偏差就很大。好比服務器返回的是2016年7月16號過時，個人電腦時間被我修改了，快了一天爲2016年7月17號，那客戶端緩存就過時了。因此它被Cache-Control：max-age=秒  替代了。

 

 2.2 Cache-control策略

Cache-Control與Expires的做用一致，都是指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數據仍是從新發請求到服務器取數據。

只不過Cache-Control的選擇更多，設置更細緻，若是同時設置的話，其優先級高於Expires。

 

Cache-Control可擁有以下值：

Public
任何狀況下都得緩存該資源。

Private
指示對於單個用戶的整個或部分響應消息，不能被共享緩存處理。緩存只開放給某些特定的用戶，好比服務器的用戶，其餘用戶則不能緩存這些數據。

no-cache
指示請求或響應消息不能緩存，該選項並非說能夠設置」不緩存「，容易望文生義~。要求向服務器發起新鮮度檢驗

no-store
用於防止重要的信息被無心的發佈。在請求消息中發送將使得請求和響應消息都不使用緩存，徹底不存下來。主要用於一些機密文件

max-age
指示客戶端該端時間內緩存都是最新的。以秒爲單位。好比：Cache-Control：max-age=120 表示2分鐘以後過時。

min-fresh
指示客戶端但願獲取一個在小於指定的時間內被更新過的資源，單位爲秒：例如：Cache-Control：min-fresh =120 。向服務器獲取2分鐘內被更新過的資源

max-stale
指示客戶端能夠接收超出超時期間的響應消息。例如：Cache-Control：max-stale =120 ，向服務器獲取超過緩存時間2分鐘的資源。

 

例：

Cache-Control:max-age=645672
指定頁面645672秒（7.47天）後過時。

 

2.3 Last-Modified/If-Modified-Since  （Last-Modified/If-Modified-Since要配合Cache-Control使用。）

 

Last-Modified：

　　標示這個響應資源的最後修改時間，web服務器在響應請求時，告訴瀏覽器資源的最後修改時間。

 

If-Modified-Since：

　　當資源過時時（也就是 Cache-Control:max-age=0，），發現資源具備Last-Modified聲明，則再次向web服務器請求時帶上頭 If-Modified-Since，表示請求時間。web服

務器收到請求後發現有頭If-Modified-Since 則與被請求資源的最後修改時間進行比對。若Last-Modified的時間較新，說明最後修改時間較新，說明資源又被改動過，則響應整

的資源從新從服務器讀取，而不是讀取緩存，返回200狀態嗎；若If-Modified-Since的時間比Last-Modified新或者相等，說明服務器的內容沒有更新，直接讀取緩存便可，

返回304狀態碼，告知瀏覽器繼續使用所保存的cache。

　　

以下圖，用fidder讀取博客園的緩存：

 

If-Modified-Since的時間等於Last-Modified，直接讀取緩存，返回304狀態碼

 

Last-Modified的時間較新，資源有改動，不讀取緩存，從新從服務器獲取資源，返回200狀態碼

 

 

2.4 Etag/If-None-Match：(Etag/If-None-Match也要配合Cache-Control使用。)

 

Etag：

　　web服務器響應請求時，告訴瀏覽器當前資源在服務器的惟一標識（生成規則由服務器決定）。因此咱們不用管它是怎麼生成的。

它就像一個哈希或者指紋，每一個文件都有一個單獨的標誌，只要這個文件發生了改變，這個標誌就會發生變化。

Apache中，ETag的值，默認是對文件的索引節（INode），大小（Size）和最後修改時間（MTime）進行Hash後獲得的。

 

If-None-Match：

　　當資源過時時（也就是 Cache-Control:max-age=0），若是客戶端發現服務端返回的頭部信息具備Etage聲明，則客戶端會再次向web服務器請求時帶上頭If-None-

Match （Etag的值）。web服務器收到請求後發現有頭If-None-Match 則與被請求資源的相應校驗串進行比對，決定返回200或304。

若是Etag的值和If-None-Match的值相等，說明服務器的資源沒有更新，返回304狀態碼，客戶端直接讀取緩存便可。若是Etag的值和If-None-Match的值不等，說明服務器的資

源有更新，返回200狀態碼，不讀取緩存，從新從服務器獲取資源。

 

實例以下：

 

讀到這裏，是否是有個小小的疑問，爲啥Last-Modified已經能夠判斷了，那還要Etag來幹嗎？是否是畫蛇添足了。答案：非也

 

Etag 主要爲了解決 Last-Modified 沒法解決的一些問題。

 

一、一些文件也許會週期性的更改，可是他的內容並不改變(僅僅改變的修改時間)，這個時候咱們並不但願客戶端認爲這個文件被修改了，而從新GET;

 

二、某些文件修改很是頻繁，好比在秒如下的時間內進行修改，(比方說1s內修改了N次)，If-Modified-Since能檢查到的變化時秒爲單位的，這種修改沒法判斷。所以須要Etag來判斷。

 

三、某些服務器不能精確的獲得文件的最後修改時間；

 

 

若是Last-Modified與ETag一塊兒使用時，服務器會優先驗證ETag。而Last-Modified的優先級又高於Expires

 

也就是優先級：ETag>Last-Modified>Expires

 

Last-Modified與ETag是能夠一塊兒使用的，服務器會優先驗證ETag，一致的狀況下，纔會繼續比對Last-Modified，最後才決定是否返回304。

 

 

 

3、cdn相關技術

 

本文仍是主要介紹緩存，其實cdn穿插進來不知道會不會很很差，不過本文是根據作分享的文件來總結的，因此也順便總結一下cdn啦

 

3.1 cdn是什麼？

　　CDN也叫內容分發網絡，是一個經策略性部署的總體系統，包括分佈式存儲、負載均衡、網絡請求的重定向和內容管理4個要件。而其中呢，內容管理和全局的網絡流量管理是CDN的核心所在。經過用戶就進行和服務器負載的判斷，CDN確保內容以一種極爲高效的方式爲用戶的請求提供服務。

 

 

 

3.2 CDN的好處： 

 

（1）CDN節點解決了跨運營商和跨地域訪問的問題，訪問延時大大下降；

（2）大部分請求在CDN邊緣節點完成，CDN起到了分流做用，減輕了源站的負載，解決網站高流量、大併發的問題

 

　　我國的網絡是劃江而治的格局，由於利益之爭，各網絡服務商之間並非通力協做，而是採起各類手段相互限制。

這就致使各網之間的互聯互通存在很大的問題，具體表現爲：電信的用戶訪問放置在網通機房的服務器，響應時間特別長，反之亦然。

使用CDN技術，可讓電信的用戶訪問電信的內容緩存服務器，網通的用戶訪問網通的內容緩存服務器。經過這樣一種策略，繞開了網絡運

營商之間人爲設置的障礙。

 

　　此外，還有如下的幾個案例，使用CDN技術也很好的解決了下面所遇到的問題

 

　　1.一個企業的網站服務器在北京，運營商是電信，在廣東的聯通用戶訪問企業網站時，由於跨地區，跨運營商的緣由，網站打開速度就會比

北京當地的電信客戶訪問速度慢不少，很容易形成這個企業的客戶流失
　　
　　2.一個網站的服務器性能比較差，承載能力有限，有時面臨突發流量，招架不住，直接致使服務器崩潰，網站打不開，好比淘寶的雙十一期，

由於這種狀況網站打不開，那損失必然很大。而CDN也很好的解決了這一問題。

　　3.再好比一些中小企業租用的虛擬主機，由於跟好幾個網站共用一臺服務器，每一個網站所分帶寬有限，帶寬太小常常致使流量稍微一多，

網站打開速度就很慢，甚至打不開。這些也是CDN能夠解決的問題

 

3.3 CDN的限制：

 

一、CDN 對於不常常訪問的資源是無效的。一般只有在 CDN緩存過時前有至少兩次訪問的資源纔算有效。

二、CDN 對於不斷變化的資源不適用。

三、CDN 對於不想公開資源多是一個糟糕的選擇。

 

3.4  CDN的機制和緩存機制：

 

cdn機制：

 

　　通常來講，互聯網更快速度地數據傳輸與源數據和客戶端有密切關係。將源數據的緩存副本放置得與客戶端比較接近，當用戶須要訪問數據時，從最接近的位置檢索它將比從原

始結點檢索會更快兒些。這種作法一般稱爲分佈式緩存，這也是CDN 的做用所在。

　　具體地說，咱們將關注是經過 HTTP 訪問的文件。雖然全部用戶看到相同的 URL文件，不一樣的用戶將被路由到不一樣的 CDN 節點。這是 CDN的要點 ： 將請求路由到就近的

CDN 節點，以提升響應速度。

　　如圖所示：

 

cdn的緩存機制：

 

　　CDN邊緣節點緩存策略因服務商不一樣而不一樣，但通常都會遵循http標準協議，經過http響應頭中的Cache-control: max-age的字段來設置CDN邊緣節點數據緩存時間。當客

戶端向CDN節點請求數據時，CDN節點會判斷緩存數據是否過時，若緩存數據並無過時，則直接將緩存數據返回給客戶端；不然，CDN節點就會向源站發出回源請求，從源站拉

取最新數據，更新本地緩存，並將最新數據返回給客戶端。因此，若是咱們修改了內容，最好加個版本號，來容CDN從新獲取資源，從而減小沒必要要的麻煩，好比 :

app.js?v=20160717 或者 style.css?v=2016071701

　　CDN服務商通常會提供基於文件後綴、目錄多個維度來指定CDN緩存時間，爲用戶提供更精細化的緩存管理。CDN緩存時間會對「回源率」產生直接的影響。若CDN緩存時間較

短，CDN邊緣節點上的數據會常常失效，致使頻繁回源，增長了源站的負載，同時也增大的訪問延時；若CDN緩存時間太長，會帶來數據更新時間慢的問題。開發者須要增對特定的業務，來作特定的數據緩存時間管理。

 

 小小總結，有誤指出，歡迎指出