CDN拾遺

做爲前端er，辛辛苦苦搬完磚，好不容易上線以後，正準備告一聲萬事大吉，回家吃雞。突然qa/pm/老闆問，爲何我這裏仍是沒有更新？只能是弱弱的回一聲，清個緩存看看？或者還有那麼一天，發現大部分區域都是好的，只有某些區域是舊的，這就要討論一個叫CDN的東西了。

背景

說個最經典的結論，不管什麼東西，傳輸都須要時間。這個應該都不會有疑問。
咱們的網絡而言，有兩個用戶，一個在海角天邊，一個就用內網坐在你跟前，你說他們的體驗會不會有差異。這裏就不說結論了，應該比較清晰。
關鍵在於如何解決這個問題，最理想化的，海角天邊的跟前要是也有個相同服務器不就完了。
就是這麼樸素的道理，這樣就引出了CDN。

CDN定義

CDN的全稱是Content Delivery Network，即內容分發網絡。
可以實時地根據網絡流量和各節點的鏈接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求從新導向離用戶最近的服務節點上。
已達到一下三點：

1. 使用戶可就近取得所需內容，
   
2. 解決 Internet網絡擁擠的情況，
   
3. 提升用戶訪問網站的響應速度。

從技術上全面解決因爲網絡帶寬小、用戶訪問量大、網點分佈不均等緣由，解決用戶訪問網站的響應速度慢的根本緣由。

CDN基本原理

在看CDN如何解決以前，先回頭看下經典的問題，用戶輸入url回車以後會發生什麼。
對於未使用CDN以前，以下圖所示：

注：本圖來源見水印，比較經典的圖就不本身瞎畫了
大概有這麼幾個步驟：

1. 用戶輸入url(顯然不能是ip，畢竟一串數字太難記了)
2. 本地DNS系統解析域名
3. 本地DNS服務器若是有緩存，直接響應用戶請求
4. 本地DNS服務器沒有，則遞歸查詢DNS服務器，響應用戶操做
5. 瀏覽器得到DNS解析結果，即url對應的ip地址(dns就是維護域名和ip對應關係的)
6. 瀏覽器相對應服務器發出請求
7. 服務器將正確響應返回給用戶

這樣來看，有這麼幾個地方須要考慮：
請求直接到達服務器上，存在傳輸距離的問題。
每次直接請求服務器，響應速度能夠優化。
流量直接打到服務器上，存在超負荷的可能。

引入cdn以後整個流程以下：

1. 當用戶點擊網站頁面上的內容URL，通過本地DNS系統解析，DNS系統會最終將域名的解析權交給CNAME指向的CDN專用DNS服務器。
2. CDN的DNS服務器將CDN的全局負載均衡設備IP地址返回用戶。
3. 用戶向CDN的全局負載均衡設備發起內容URL訪問請求。
4. CDN全局負載均衡設備根據用戶IP地址，以及用戶請求的內容URL，選擇一臺用戶所屬區域的區域負載均衡設備，告訴用戶向這臺設備發起請求。
5. 區域負載均衡設備會爲用戶選擇一臺合適的緩存服務器提供服務，選擇的依據包括：根據用戶IP地址，判斷哪一臺服務器距用戶最近；根據用戶所請求的URL中攜帶的內容名稱，判斷哪一臺服務器上有用戶所需內容；查詢各個服務器當前的負載狀況，判斷哪一臺服務器尚有服務能力。基於以上這些條件的綜合分析以後，區域負載均衡設備會向全局負載均衡設備返回一臺緩存服務器的IP地址。
6. 全局負載均衡設備把服務器的IP地址返回給用戶。
7. 用戶向緩存服務器發起請求，緩存服務器響應用戶請求，將用戶所需內容傳送到用戶終端。若是這臺緩存服務器上並無用戶想要的內容，而區域均衡設備依然將它分配給了用戶，那麼這臺服務器就要向它的上一級緩存服務器請求內容，直至追溯到網站的源服務器將內容拉到本地。

CDN術語詳解

源站

提供內容的原始站點，也就是咱們的服務器

中心接點

包括CDN網管中心和全局負載均衡DNS重定向解析系統，負責整個CDN網絡的分發及管理。
主要做爲內容分發和邊緣未命中時的服務點

邊緣節點

主要指異地分發節點，由負載均衡設備、高速緩存服務器兩部分組成。
簡單歸納就是離用戶最近的節點。主要做爲直接向用戶提供服務的節點。

CDN緩存

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

當用戶向CDN發出請求時，CDN階段會判斷資源是否過時，未過時直接使用緩存(這也就提高了響應速度)。若是認爲資源過時，那麼就會向實際服務器去請求新的資源,即發生回源。

回源

CDN從源站獲取最新資源的過程即爲回源，該過程會同時更新本地緩存資源，並將新的資源返回給用戶。
固然對於回源咱們是要不推薦的，搭建CDN除了必要狀況下，固然但願都走節點緩存。若是回源率太高能夠參考這裏看看CDN 命中率、回源率常見問題

刷新CDN緩存

對於新資源上線，爲了確保全部節點都能訪問最新資源，須要主動失效CDN緩存。CDN運營商都會暴露主動刷新的接口，通常公司運維也會暴露出刷新CDN的接口的，已解決CDN緩存不主動更新問題。

流量劫持

什麼叫流量劫持，比較籠統的說只要是對請求及數據進行篡改、轉發的均可以認爲是流量劫持。
其實CDN也是一種流量劫持，其經過DNS解析將域名匹配到最近的服務器上。
不過這是一種主動已知的劫持，目的爲更好的用戶體驗。
惡意的劫持通常分爲兩類：

DNS劫持

又稱域名劫持，是指在劫持的網絡範圍內攔截域名解析的請求，分析請求的域名，把審查範圍之外的請求放行，不然返回假的IP地址或者什麼都不作使請求失去響應，其效果就是對特定的網絡不能反應或訪問的是假網址。
常見實現也是經過污染路由器等中間鏈路，將解析請求進行篡改。

數據劫持

數據劫持是指針對明文傳輸的內容發生。
用戶發起HTTP請求，服務器返回頁面內容時，通過中間的運營商網絡，頁面內容被篡改或加塞內容，強行插入彈窗或者廣告。
如何預防？
行業內解決的辦法便是對內容進行HTTPS加密，實現密文傳輸，完全避免劫持問題。

CDN劫持

理想狀況下，CDN 的安全性應該和咱們的服務器一致，但若是，CDN 和用戶之間、CDN服務器之間，走明文的htttp協議也是會出現數據劫持的現象。

結束語

參考文章

http://book.51cto.com/art/201205/338756.htm
https://www.zhihu.com/question/36514327?rf=37353035
http://hpoenixf.com/DNS%E4%B8%8ECDN%E7%9F%A5%E8%AF%86%E6%B1%87%E6%80%BB.html
http://www.javashuo.com/article/p-yalzugfo-gs.html
https://zhuanlan.zhihu.com/p/40682772 本着學習的態度，從上面各類大神的文章中受益不淺，再次感謝上述文章做者。彙總一下做爲本身的解惑筆記，但願也能對其餘人有所幫助。