http緩存與cdn相關技術
摘要：最近要做這個主題的組內分享，所以准備了一個星期，查了比較多的資料。准備的過程雖然很煩很耗時間，不過因為需要查很多的資料，因此整個過程下來，對這方面的知識影響更加深刻。來來來，接下來總結總結
一 http緩存
1.1緩存的分類：
http中具有緩存功能的是：1、瀏覽器緩存、 2、緩存代理服務器。
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,則緩存已經失效了，重新服務器抓取。
如果第一次接觸瀏覽器緩存的同學，可能會暈掉。說的是什么鬼東西，頭都暈了，尼瑪。好的，接下來就解釋一下上面說的那些概念。
二、Http緩存概念解析
2.1 Expires策略
Expires是web服務器 響應消息頭字段，在響應http請求時告訴瀏覽器在過期時間前，瀏覽器可以直接從瀏覽器緩存讀取數據，而無需再次請求，它的值對應一個GMT（格林尼治時間），比如“Mon, 22 Jul 2012 11:15:08 GMT”來告訴瀏覽器資源緩存過期時間，如果還沒過該時間點則不發請求。
我們可以使用meta標簽來告知頁面。不過值對ie有效。如下：
|
1
|
<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來干嘛？是不是多此一舉了。答案：非也
三、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的限制：
1、CDN 對於不經常訪問的資源是無效的。通常只有在 CDN緩存過期前有至少兩次訪問的資源才算有效。
2、CDN 對於不斷變化的資源不適用。
3、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緩存時間太長，會帶來數據更新時間慢的問題。開發者需要增對特定的業務，來做特定的數據緩存時間管理。