面向前端的CDN原理介紹

為什麼需要CDN

根本上的原因是，通路速度對網際網路應用的使用者體驗、口碑、甚至說直接的營收都有巨大的影響，任何的企業都渴望自己站點有更快的通路速度。而HTTP傳輸時延對web的通路速度的影響很大，在絕大多數情況下是起決定性作用的，這是由TCP/IP協定的一些特點決定的。實體層上的原因是光速有限、信道有限，協定上的原因有丢包、慢啟動、擁塞控制等。

要提高通路速度，最簡單的做法當然就是多設定幾個伺服器，讓終端使用者離伺服器“更近”。典型的例子是各類下載下傳網站在不同地域不同營運商設定鏡像站，或者是像Google那樣設定多個資料中心。但是多設幾個伺服器的問題也不少，一是多地部署時的困難，二是一緻性沒法保障，三則是管理困難、成本很高。實際上，在排除多地容災等特殊需求的情況下，對大多數公司這種做法是不太可取的。當然，這種方案真正做好了，甚至是比後續所說的使用CDN要好的。

CDN是一種公共服務，他本身有很多台位于不同地域、接入不同營運商的伺服器，而所謂的使用CDN實質上就是讓CDN作為網站的門面，使用者通路到的是CDN伺服器，而不是直接通路到網站。由于CDN内部對TCP的優化、對靜态資源的緩存、預取，加上使用者通路CDN時，會被智能地配置設定到最近的節點，降低大量延遲，讓通路速度可以得到很大提升。

CDN的原理

CDN做了兩件事，一是讓使用者通路最近的節點，二是從緩存或者源站擷取資源

CDN有個源站的概念，源站就是提供内容的站點(網站的真實伺服器), 從源站取内容的過程叫做回源。

每次通路的具體流程如圖（以最普通的CDN為例）

具體舉個例子：

使用者在首次通路 https://assets-cdn.github.com/pinned-octocat.svg , 假設不委托local DNS伺服器遞歸查詢，會經曆以下幾個過程

1. 浏覽器檢查本地有沒有這個東東的有效緩存，有則使用緩存，沒有有效緩存則進行對

   assets-cdn.github.com

   的DNS查詢，獲得一個 CNAME記錄, 

   igithub.map.fastly.net

   ,值得注意的是，多個加速域名可以解析到同一個CNAME，CDN回源和緩存的時候考慮到了hostname，?；
2. 進行對

   github.map.fastly.net

   的DNS查詢，獲得一個A/AAAA記錄，給出位址

   103.245.222.133

   （視網站不同傳回的不一樣，可以有多個）, 這一步對CDN來說時十分重要的，它給出了離使用者最近的邊緣節點；
3. 浏覽器選一個傳回的位址，然後進行真正的http請求，開始向

   103.245.222.133

   握手，握手完了把http請求頭也發給了該邊緣伺服器;
4. 邊緣伺服器檢查自己的cache裡面有沒有

   https://assets-cdn.github.com/pinned-octocat.svg

   這個資源，有則傳回給使用者，如果沒有，向CDN中心伺服器發起請求;
5. CDN中心伺服器檢查自己的cache裡面有沒有這個資源，有則傳回給邊緣伺服器，沒有則回源;
6. 中心伺服器發現客戶配置了

   github.map.fastly.net

   的回源位址(這個隻有cdn會知道，假設是

   xxx.xxx.xxx.xxx

   )，就把http請求發到源站位址上，源站傳回後傳回給請求方;