本文目錄：一、引入
二、CDN定義
三、關於緩存
四、瀏覽器緩存
一、引入
客戶端直接從源站點獲取數據，當服務器訪問量大時會影響訪問速度，進而影響用戶體驗，且無法保證客戶端與源站點間的距離足夠短，適合傳輸數據。
CDN解決的正是如何將數據快速可靠地從源站點傳遞到客戶端，通過CDN對數據的分發，用戶可以從一個距離較近的服務器獲取數據，而不是源站點，從而達到快速訪問、且能減少源站點負載壓力的目的。
二、CDN的定義
CDN：Content Delivery Network/Content Ddistribute Network，即內容分發網絡
客戶端訪問網站的過程：
沒有CDN：
1、用戶在瀏覽器訪問欄中輸入要訪問的域名；
2、瀏覽器向DNS服務器請求對該域名的解析；
3、DNS服務器返回該域名的IP地址給瀏覽器
4、瀏覽器使用該IP地址向服務器請求內容。
5、服務器將用戶請求的內容返回給瀏覽器。
使用了CDN：
1、用戶在瀏覽器中輸入要訪問的域名。
2、瀏覽器向DNS服務器請求對域名進行解析。由於CDN對域名解析進行了調整，DNS服務器會最終將域名的解析權交給CNAME指向的CDN專用DNS服務器。
3、CDN的DNS服務器將CDN的負載均衡設備IP地址返回給用戶。
4、用戶向CDN的負載均衡設備發起內容URL訪問請求。
5、CDN負載均衡設備會為用戶選擇一台合適的緩存服務器提供服務。
選擇的依據包括：根據用戶IP地址，判斷哪一台服務器距離用戶最近；根據用戶所請求的URL中攜帶的內容名稱，判斷哪一台服務器上有用戶所需內容；查詢各個服務器的負載情況，判斷哪一台服務器的負載較小。
基於以上這些依據的綜合分析之后，負載均衡設置會把緩存服務器的IP地址返回給用戶。
6、用戶向緩存服務器發出請求。
7、緩存服務器響應用戶請求，將用戶所需內容傳送到用戶。
如果這台緩存服務器上並沒有用戶想要的內容，而負載均衡設備依然將它分配給了用戶，那么這台服務器就要向它的上一級緩存服務器請求內容，直至追溯到網站的源服務器將內容拉取到本地。
三、關於緩存
沒有CDN：瀏覽器緩存
使用了CDN：瀏覽器緩存+CDN緩存
在用戶第一次訪問網站后，網站的一些靜態資源如圖片等就會被下載到本地，作為緩存，當用戶第二次訪問該網站的時候，瀏覽器就會從緩存中加載資源，不用向服務器請求資源，從而提高了網站的訪問速度，而若使用了CDN，當瀏覽器本地緩存的資源過期之后，瀏覽器不是直接向源站點請求資源，而是向CDN邊緣節點請求資源，CDN邊緣節點中也存在緩存，若CDN中的緩存也過期，那就由CDN邊緣節點向源站點發出回源請求來獲取最新資源。
瀏覽器緩存以及CDN緩存都有一套判斷文件是否需要更新的機制：
瀏覽器在加載資源時，先根據這個資源的一些http header判斷它是否命中強緩存，如果命中，瀏覽器直接從自己的緩存中讀取資源，不會發請求到服務器，當強緩存沒有命中的時候，瀏覽器一定會發送一個請求到服務器，服務器端依據資源的另外一些http header驗證這個資源是否命中協商緩存，如果命中，服務器會將這個請求返回，但是不會返回這個資源的數據，而是告訴客戶端可以直接從緩存中加載這個資源，於是瀏覽器還是從自己的緩存中加載資源，當協商緩存也沒有命中的時候，瀏覽器直接從服務器加載資源數據。
CDN節點緩存機制在不同服務商中是不同的，但一般都遵循HTTP協議，通過http響應頭中的Cache-Control:max-age的字段來設置CDN節點文件緩存時間。當客戶端向CDN節點請求數據時，CDN會判斷緩存數據是否過期，若沒有過期，則直接將緩存數據返回給客戶端，否則就向源站點發出請求，從源站點拉取最新數據，更新本地緩存，並將最新數據返回給客戶端。CDN服務商一般會提供基於文件后綴、目錄多個維度來指定CDN緩存時間，為用戶提供更精細化的緩存管理。CDN緩存時間會對“回源率”產生直接的影響，若CDN緩存時間短，則數據經常失效，導致頻繁回源，增加了源站的負載，同時也增大了訪問延時；若緩存時間長，數據更新時間慢，因此需要針對不同的業務需求來選擇特定的數據緩存管理。
瀏覽器緩存刷新：
1、在地址欄中輸入網址后按回車或者點擊轉到按鈕
瀏覽器以最少的請求來獲取網頁的數據，瀏覽器會對所有沒有過期的內容直接使用本地緩存即使用強緩存，從而減少了對服務器的請求，Expires、max-age標志只對這種方式有效。
2、按F5或瀏覽器刷新按鈕
瀏覽器會在請求中附加比要的緩存協商，但不允許瀏覽器直接使用本地緩存即跳過強緩存的判斷，直接進行協商緩存的判斷，Last-Modified、ETag在這種方式發揮作用。
3、按Ctrl+F5或按Ctrl並點擊刷新按鈕
強制刷新，完全不使用緩存
CDN緩存刷新：
CDN節點對開發者時透明的，可以通過CDN服務商提供的“刷新緩存”接口來達到清理CDN節點緩存的效果，強制使數據過期，從而獲取到最新的數據。
四、瀏覽器緩存
這一點主要解析瀏覽器緩存以及緩存機制的詳細過程。
第三點說到強緩存與協商緩存，下面從這兩點說起：
1.1強緩存：
當瀏覽器對某個資源的請求命中了強緩存時，返回的http狀態碼為200，在chrome開發者工具中的network中的size會顯示from cache
強緩存時利用Expires或者Cache-Control這兩個http header實現的，都用來表示資源在客戶端緩存的有效期
Expires是http1.0提出的一個header，描述的是一個絕對時間，由服務器返回，用GMT格式的字符串表示，如Exprires：Thu，31 Dec 2037 23：55：55 GMT
緩存過程：
1、瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在response的header加上Expires的header
2、瀏覽器在接收到這個資源后，會把這個資源連同所有的response header一起緩存下來，所以緩存命中的請求返回的header並不是來自服務器，而是來自之前緩存的header
3、瀏覽器再請求這個資源時，先從緩存中尋找，找到這個資源后，拿出Expires跟當前的請求時間比較，如果請求時間在Expires指定的時間之前，就能命中緩存，否則就不行。
4、如果緩存沒有命中，瀏覽器直接從服務器加載資源時，Expires Header在重新加載的時候會被更新
Expires是服務器返回的一個絕對時間，在服務器時間與客戶端時間相差較大時，緩存管理容易出現問題，比如隨意修改下客戶端時間，就能影響緩存命中的結果，所以在http1.1的時候，提出了一個新的header，也就是Cache-Control，這是一個相對時間，在進行緩存命中的時候，都是利用客戶端時間進行判斷，因此更有效安全一些，在配置緩存的時候，以秒為單位，用數值表示：如：Cache-Control：max-age=315360000，它的緩存過程是：
1、瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在response的header加上Cache-Control的header
2、瀏覽器在接收到這個資源的時候，會把這個資源連同所有response header一起緩存下來
3、瀏覽器再次請求這個資源的時候，先從緩存中尋找，找到這個資源之后，再拿這個過期時間跟當前的請求時間比較，如果請求時間在過期時間之前，就能命中緩存，否則就不行。
4、如果緩存沒有命中，瀏覽器直接從服務器加載資源時，Cache-Control在重新加載的時候會被更新
這兩個header可以只用一個，也可以同時用兩個，同時存在時，Cache-Control優先級高於Expires
1.2 強緩存的管理
兩種方式來設置是否啟用強緩存：
1、通過代碼的方式，在web服務器返回的響應中添加Expires和Cache-Control Header
2、通過配置web服務器的方式，讓web服務器在響應資源的時候統一添加Expires和Cache-Control Header
1.3 強緩存的應用
強緩存是前端性能優化最有力的工具，對於有大量靜態資源的網頁，一定要利用強緩存，提高響應速度，通常是為這些靜態資源全部配置一個超時時間超長的Expires或Cache-Control，這樣用戶只會在第一次訪問網站時加載靜態資源，其他時間只要緩存沒有失效並且用戶沒有強制刷新的條件下都會從緩存中加載。
然而這種緩存配置方式會帶來一個問題，就是當資源更新時，客戶端由於有緩存不會向服務器請求最新的資源，這個問題已有解決方案：
通過更新頁面中引用的資源路徑，讓瀏覽器主動放棄緩存，加載新資源。
但要實現有更新的文件才需要瀏覽器重新加載，因此必須讓url的修改與文件內容相關聯，利用數據摘要算法對文件求摘要信息，摘要信息與文件內容一一對應，這一點許多前端構建工具都做到了，如webpack
1.4 瀏覽器默認緩存使開發環境下常因為資源沒有及時更新而看不到效果
解決方法：
1、ctrl+F5
2、瀏覽器隱私模式開發
3、chrome開發者工具里將Disable cache選項打勾，阻止緩存
4、在開發階段，給資源加上一個動態的參數，由於每次資源的修改都要更新引用的位置，同時修改參數的值，所以操作起來不是很方便，除非是在動態頁面比如jsp里開發就可以用服務器變量來解決，或者用前端構建工具來處理這個參數修改的問題。
5、如果資源引用的頁面被嵌入到了一個iframe里面，可以在iframe的區域右鍵重新加載該頁面
6、如果緩存問題出現在ajax請求中，最有效的解決辦法就是ajax的請求地址追加隨機數
7、動態設置iframe的src時，有可能因為緩存問題導致看不到最新效果，在src后面添加隨機數即可
8、通過前端開發工具grunt gulp等的插件來啟動一個靜態服務器，則在這個服務器下所有資源返回的response header中，Cache-Control始終被設置為不緩存
1.5 發布問題
發布問題：若頁面和它引用的資源路徑同時更新了，不管是先部署頁面還是先部署資源都會帶來各種問題，這是由於資源是覆蓋式發布的，即用待發布資源覆蓋已發布資源。
解決辦法就是實現非覆蓋式發布：把有修改的資源文件作為一個新的文件發布，不對已有的資源文件進行覆蓋，這樣用戶還可以請求舊的資源文件，不至於發生頁面錯亂的問題，這樣先部署靜態資源，再覆蓋式部署頁面，等到用戶訪問新頁面的時候，新的資源文件也已發布，就可以正確請求，即可解決問題。
2.1 協商緩存
如果命中協商緩存，請求響應返回的http狀態為304以及一個Not Modified字符串，協商緩存利用的是【Last-Modified、If-Modified-Since】、【ETag、If-None-Match】這兩對header來管理的。
【Last-Modified、If-Modified-Since】：
1、瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源時，在response的header加上Last-Modified的header，表示這個資源在服務器上的最后修改時間
2、瀏覽器再次向服務器請求這個資源時，在request的header加上If-Modified-Since的header，這個header的值就是上一次請求時返回的Last-Modified的值
3、服務器再次收到資源請求時，根據瀏覽器傳過來If-Modified-Since和資源在服務器上的最后修改時間判斷資源是否有變化，如果沒有變化則返回304 Not Modified，但是不會返回資源內容，如果有變化就返回資源內容，當服務器返回304 Not Modified的響應時，response header中不會再添加Last-Modified的header，因為資源沒有變化，Last-Modified的值也不變
4、瀏覽器收到304的響應后，就會從緩存中加載資源
5、如果協商緩存沒有命中，瀏覽器直接從服務器加載資源時，Last-Modofied header在重新加載的時候會被更新，下次請求時，If-Modified-Since會采用上一次返回的Last-Modified的值
這一對header都是根據服務器時間返回的，有時候會有服務器資源有變化，但最后修改時間卻沒有變化的情況，因此有了
【Etag、If-None-Match】：
1、瀏覽器第一次向服務器請求一個資源，服務器在返回這個資源的同時，在response的header加上ETag的header，這個header是服務器根據當前請求的資源生成的一個唯一標識，是一個字符串，只要資源內容發生改變，這個字符串也會改變，跟時間沒有關系
2、瀏覽器再次請求這個資源的時候，在request的header上加上If-None-Match的header。這個header的值是上一次請求返回的ETag的值
3、服務器再次收到資源請求時，根據客戶端傳過來的If-None-Match和重新生成的該資源的新的ETag做比較，相同則返回304 Not Modified，不會返回資源內容，如果不同則返回資源內容，但這里即使資源沒有發生變化，也會返回ETag，因為這個ETag重新生成過，即使沒有ETag沒有變化
4、瀏覽器收到304響應后，就從緩存中加載資源
2.2 協商緩存的管理
一般服務器上的【Last-Modified、If-Modified-Since】和【Etag、If-None-Match】會同時啟用，協商緩存需要配合強緩存使用
參考文章：
https://www.cnblogs.com/tinywan/p/6067126.html
https://blog.csdn.net/lihao21/article/details/52808747
https://www.zhihu.com/question/20790576
http://www.cnblogs.com/lyzg/p/5125934.html