高性能利器：CDN我建議你好好學一下！

CDN 概述

CDN

 全稱 

Content Delivery Network

，即内容分發網絡。其基本思路是盡可能避開網際網路上有可能影響資料傳輸速度和穩定性的瓶頸和環節，使内容傳輸的更快、更穩定

CDN 的

工作原理

就是将源站的資源緩存CDN各個節點上，當請求命中了某個節點的資源緩存時，立即傳回用戶端，避免每個請求的資源都通過源站擷取，避免網絡擁塞、緩解源站壓力，保證使用者通路資源的速度和體驗。

舉一個

生活

中的例子，我們在某東上

購買商品

，快遞能做到當日送達，其根本原理是通過在全國各地建設本地倉庫。當使用者購買商品時，通過

智能倉配模式

，為消費者選擇就近倉庫發貨，進而

縮短

物流配送時間。

而商品庫存的配置設定，流程可以參考下圖，從 工廠

（源站）

-> 地域倉庫

(二級緩存)

-> 本地倉庫

(一級緩存)

内容分發網絡

就像前面提到的

智能倉配網絡

一樣，解決了因分布、帶寬、伺服器性能帶來的通路延遲問題，适用于站點加速、點播、直播等場景。使使用者可就近取得所需内容，解決 Internet網絡擁擠的狀況，提高使用者通路網站的響應速度和成功率。

CDN的誕生

CDN 誕生于二十多年前，為解決内容源伺服器和傳輸

骨幹網

絡壓力過大的問題，在

1995

年，麻省理工學院教授，網際網路發明者之一

Tom Leighton

帶領着研究所學生 Danny Lewin 和其他幾位頂級研究人員一起嘗試用數學問題解決網絡擁堵問題。

他們使用數學算法，處理内容的動态路由安排，并最終解決了困擾 Internet 使用者的難題。後來，史隆管理學院的 MBA 學生 Jonathan Seelig 加入了 Leighton 的隊伍中，從那以後他們開始實施自己的商業計劃，最終于 1998 年 8 月 20 日正式成立公司，命名為 Akamai。

Akamai

公司通過智能化的網際網路分發，結束了 “World Wide Wait” 的尴尬局面。

同年 1998 年，中國第一家 CDN 公司

ChinaCache

成立

CDN工作原理

接入CDN

在接入

CDN

前，當我們通路某個域名,直接拿到第一個真實伺服器的IP位址，整個流程如下（圖有點簡陋）

當我們需要加速網站時，通過向營運商注冊自己加速域名，源站域名，然後進入到自己域名的DNS配置資訊，将

A

記錄修改成

CNAME

記錄即可。阿裡雲加速申請參考如下：

CDN通路過程

• 1、使用者通路圖檔内容，先經過

  本地DNS

  解析，如果 LDNS 命中，直接傳回給使用者。
• 2、

  LDNS

  MISS，轉發

  授權DNS

  查詢
• 3、傳回域名

  CNAME

  [picwebws.pstatp.com.wsglb0.com.]() 對應IP位址(實際就是DNS排程系統的ip位址)
• 4、域名解析請求發送至

  DNS排程系統

  ，DNS排程系統為請求配置設定最佳節點IP位址。
• 5、傳回的解析

  IP位址

• 6、使用者向

  緩存伺服器

  發起請求，緩存伺服器響應使用者請求，将使用者所需内容傳送到使用者終端。

圖：華為雲全站加速示意圖

CDN解決了什麼問題

骨幹網壓力過大

Tom Leighton

在

1995

年， 帶領團隊嘗試用數學問題解決網絡擁堵問題，進而解決

骨幹網

絡壓力過大的問題。由于

上網沖浪

的少年越來越多，造成骨幹網的核心節點流量吞吐不足以支撐網際網路使用者的增長，通過

CDN

可以避免使用者流量流經骨幹網。

骨幹網是一個全球性的區域網路,一級網際網路服務提供商（ISP）将其高速光纖網絡連接配接在一起，形成網際網路的骨幹網，實作在不同地理區域之間高效地傳輸流量。

1、區域網路

區域網路(Local Area Network，LAN)

是指在某一區域内由多台計算機互聯成的計算機組，比如：在大學時期，晚上12點後斷網了，我們仍然能夠通過路由器開黑打

CS

，

魔獸

。那就是基于區域網路互聯，實作資料共享與資訊之間的通信。

2、骨幹網

這裡引用一下中國電信全網架構，骨幹網可以了解成是一個全國性的區域網路，通過核心節點的流量互通，實作全網網絡的互通。這也是為什麼我們稱為

網際網路

的原因。

北京、上海、廣州，是ChinaNet的超級核心。除了超級核心之外，ChinaNet還有天津、西安、南京、杭州、武漢、成都等普通核心。

三公裡之 middlemile

通常網絡通路中會有"三公裡"路程

• 第一公裡為:源站到ISP接入點
• 第二公裡為:源站ISP接入點到通路使用者的ISP接入點
• 第三公裡(最後一公裡)為:使用者ISP接入點到使用者用戶端

CDN網絡層主要用來

加速

第二公裡(

middlemile

),

在 CDN 的基礎架構中，通常使用兩級 server 做加速：

• L1（下層）：距離使用者（或俗稱網民）越近越好，通常用于緩存那些可緩存的靜态資料，稱之為 lastmile（最後一公裡）。
• L2（上層）：距離源站越近越好，稱之為 firstmile（第一公裡），當 L1 無法命中緩存，或内容不可緩存時，請求會通過 L1 透傳給 L2，若 L2 仍然沒有命中緩存或内容不可緩存，則會繼續透傳給 L2 的 upstream（有可能是源站，也有可能是 L3），同時 L2 還可以做流量、請求數的量級收斂，減少回源量（如果可緩存），降低源站壓力。
• L1 和 L2 之間的部分，是 CDN 的 ”内部網絡“，稱之為 middlemile（中間一公裡）。

CDN的組成

全局負載均衡系統 GLB（Global Load Balance）

• 當使用者通路加入CDN服務的網站時，域名解析請求将最終由 “智能排程DNS”負責處理。
• 它通過一組預先定義好的政策，将當時

  最接近使用者

  的節點位址提供給使用者，使使用者可以得到快速的服務。
• 同時它需要與分布在各地的CDN節點保持通信，跟蹤各節點的健康狀态、容量等資訊，確定将使用者的請求配置設定到就近可用的節點上.

緩存伺服器

緩存伺服器主要的功能就是緩存熱點資料，資料類型包括：

靜态資源

（html,js,css等），

多媒體資源

（img,mp3,mp4等），以及動态資料（

邊緣渲染

）等。

衆所周知耳熟能詳的與 CDN 有關的開源軟體有：

• Squid
• Varnish
• Nginx
• OpenResty
• ATS
• HAProxy

具體對比可參考： https://blog.csdn.net/joeyon1985/article/details/46573281

CDN的分層架構

源站

源站指釋出内容的原始站點。添加、删除和更改網站的檔案，都是在源站上進行的;另外緩存伺服器所抓取的對象也全部來自于源站。

CDN 排程政策

DNS 排程

基于請求端 local DNS 的出口 IP 歸屬地以及營運商的 DNS 排程。

DNS 排程的問題：

• DNS 緩存時間在 TTL 過期前是不會重新整理的， 這樣會導緻節點異常的時候自動排程延時很大，會直接影響線上業務通路。
• 大量的 local DNS 不支援 EDNS 協定，拿不到客戶的真實IP，CDN 絕大多數時候隻能通過local DNS IP來做決策，經常會出現跨區域排程的情況。

HTTP DNS 排程

用戶端請求固定的 HTTP DNS 位址，根據傳回擷取解析結果。可以提高解析的準确性(不像DNS排程，隻能通過local DNS IP來做決策)，能很好的避免劫持等問題。

當然這種模式也有一些問題，例如用戶端每次加載URL都可能産生一次HTTP DNS查詢，這就對性能和網絡接入要求很高。

302排程

基于用戶端 IP 和 302 排程叢集進行實時的流量排程。

我們來看一個例子：

1. 通路 URL 連結後，此時請求到了排程群集上，我們能拿到的用戶端資訊有 用戶端的出口IP（絕大多情況下是相同的），接下來算法和基于 DNS 的排程可以是一樣的，隻是判斷依據由 local DNS 出口 ip 變成了用戶端的出口IP。
2. 浏覽器收到302回應，跟随 Location 中的 URL，繼續發起 http 請求，這次請求的目标 IP 是CDN 邊緣節點，CDN節點會響應實際的檔案内容。

302 排程的優勢：

• 實時排程，因為沒有 local DNS 緩存的，适合 CDN 的削峰處理，對于成本控制意義重大；
• 準确性高，直接擷取用戶端出口 IP 進行排程。

302 排程的劣勢：

• 每次都要跳轉，對于延時敏感的業務不友好。一般隻适用于大檔案。

AnyCast BGP路由排程

基于 BGP AnyCast 路由政策，隻提供極少的對外 IP，路由政策可以很快的調整。

目前 AWS CloudFront、CloudFlare 都使用了這種方式，在路由層面進行排程。

這種方式可以很好地抵禦 DDOS 攻擊，降低網絡擁塞。

當然這種方式的成本和方案設計都比較複雜，是以國内的 CDN 目前還都是用 UniCast 的方式。

一些概念

CDN運作原理

本地緩存的資料，通過

key-value

的形式，将url 和本地緩存進行映射,存儲結構與

Map

相似，采用

hash+連結清單形式

進行緩存。

CDN命中率

衡量我們CDN服務品質的一個核心标準，當使用者通路的資源恰好在緩存系統裡，可以直接傳回給使用者，說明CDN命中；如果CDN緩存中，沒有命中資源，那麼會觸發

回源

動作。

CDN回源

當CDN本地緩存沒有命中時，觸發

回源動作

,

• 一級緩存

  通路

  二級緩存

  是否有相關資料，如果有，傳回一級緩存。

• 二級緩存

  Miss，觸發 二級緩存 回源請求，請求源站對應資料。擷取結果後，緩存到本地緩存，傳回資料到一級緩存。

• 一級緩存

  擷取資料，快取區域後，傳回給使用者。

CDN預熱資料

上面說的通路模式，都是基于

Pull模式

，由使用者決策哪部分熱點資料會最終存留在CDN緩存中；對于大促場景，我們往往需要預先将活動相關資源

預熱

到

邊緣節點（L1）

,避免大促開啟後，大量使用者通路，造成源站壓力過大。這時候采用的是

Push模式

。

CDN的特點總結

1、

資源通路加速

: 本地Cache加速，提高了企業站點（尤其含有大量圖檔和靜态頁面站點）的通路速度，并大大提高以上性質站點的穩定性

消除營運商間網絡互聯的瓶頸問題

: 鏡像服務消除了不同營運商之間互聯的瓶頸造成的影響，實作了跨營運商的網絡加速，保證不同網絡中的使用者都能得到良好的通路品質。

3、

遠端加速

: 遠端通路使用者根據DNS負載均衡技術 智能自動選擇Cache伺服器，選擇最快的Cache伺服器，加快遠端通路的速度

4、

帶寬優化

: 自動生成伺服器的遠端Mirror（鏡像）cache伺服器，遠端使用者通路時從cache伺服器上讀取資料，減少遠端通路的帶寬、分擔網絡流量、減輕原站點WEB伺服器負載等功能。

5、

叢集抗攻擊

: 廣泛分布的CDN節點加上節點之間的智能備援機制，可以有效地預防黑客入侵以及降低各種D.D.o.S攻擊對網站的影響，同時保證較好的服務品質 。

點關注，不迷路

好了各位，以上就是這篇文章的全部内容了，我後面會每周都更新幾篇高品質的大廠面試和常用技術棧相關的文章。感謝大夥能看到這裡，如果這個文章寫得還不錯， 求三連！！！ 感謝各位的支援和認可，我們下篇文章見！

我是

九靈

,有需要交流的童鞋可以關注公衆号：

Java 補習課

！ 如果本篇部落格有任何錯誤，請批評指教，不勝感激 ！