CDN技術介紹

CDN技術介紹

 

一、CDN概述

1.1 CDN定義

CDN即Content Delivery Network （內容分發網絡）。CDN是建立在現有IP網絡基礎結構之上的一種增值網絡。是在應用層部署的一層網絡架構。

CDN技術實現將多點負載均衡，路由或緩存技術結合起來，利用智能分配技術，將內容根據來訪用戶的地點，按照就近訪問的原則分配到多個節點。

在傳統的IP網絡中，用戶請求直接指向基於網絡地址的原始服務器，而CDN業務提供了一個服務層，補充和延伸了Internet網絡，把頻繁訪問的內容盡可能向用戶推進，提供了處理基於內容進行流量轉發的新能力，把路由導引到最佳服務器上。動態獲得需要的內容。它改變了分布到使用者信息的方式，從被動的內容恢復轉為主動的內容轉發。

1.2 CDN的實現原理

在描述CDN的實現原理，讓我們先看傳統的未加緩存服務的訪問過程，以便了解CDN緩存訪問方式與未加緩存訪問方式的差別：

用戶提交域名→瀏覽器對域名進行解釋→得到目的主機的IP地址→根據IP地址訪問發出請求→得到請求數據並回復

由上可見，用戶訪問未使用CDN緩存網站的過程為:

1. 用戶向瀏覽器提供要訪問的域名；
2. 瀏覽器調用域名解析函數庫對域名進行解析，以得到此域名對應的IP地址；
3. 瀏覽器使用所得到的IP地址，向域名的服務主機發出數據訪問請求；
4. 瀏覽器根據域名主機返回的數據顯示網頁的內容。

通過以上4個步驟，瀏覽器完成從用戶處接收用戶要訪問的域名到從域名服務主機處獲取數據的整個過程。CDN網絡是在用戶和服務器之間增加Cache層，如何將用戶的請求引導到Cache上獲得源服務器的數據，主要是通過接管DNS實現，下面讓我們看看訪問使用CDN緩存后的網站的過程：

 

通過上圖，我們可以了解到，使用了CDN緩存后的網站的訪問過程變為：

1. 用戶向瀏覽器提供要訪問的域名；
2. 瀏覽器調用域名解析庫對域名進行解析，由於CDN對域名解析過程進行了調整，所以解析函數庫一般得到的是該域名對應的CNAME記錄，為了得到實際IP地址，瀏覽器需要再次對獲得的CNAME域名進行解析以得到實際的IP地址；在此過程中，使用的全局負載均衡DNS解析，如根據地理位置信息解析對應的IP地址，使得用戶能就近訪問；
3. 此次解析得到CDN緩存服務器的IP地址，瀏覽器在得到實際的IP地址以后，向緩存服務器發出訪問請求；
4. 緩存服務器根據瀏覽器提供的要訪問的域名，通過Cache內部專用DNS解析得到此域名的實際IP地址，再由緩存服務器向此實際IP地址提交訪問請求；
5. 緩存服務器從實際IP地址得得到內容以后，一方面在本地進行保存，以備以后使用，另一方面把獲取的數據返回給客戶端，完成數據服務過程；
6. 客戶端得到由緩存服務器返回的數據以后顯示出來並完成整個瀏覽的數據請求過程。

通過以上的分析我們可以得到，為了實現既要對普通用戶透明(即加入緩存以后用戶客戶端無需進行任何設置，直接使用被加速網站原有的域名即可訪問，又要在為指定的網站提供加速服務的同時降低對ICP的影響，只要修改整個訪問過程中的域名解析部分，以實現透明的加速服務，下面是CDN網絡實現的具體操作過程。

1. 作為ICP，只需要把域名解釋權交給CDN運營商，其他方面不需要進行任何的修改；操作時，ICP修改自己域名的解析記錄，一般用cname方式指向CDN網絡Cache服務器的地址。
2. 作為CDN運營商，首先需要為ICP的域名提供公開的解析，為了實現sortlist，一般是把ICP的域名解釋結果指向一個CNAME記錄；
3. 當需要進行sortlist時，CDN運營商可以利用DNS對CNAME指向的域名解析過程進行特殊處理，使DNS服務器在接收到客戶端請求時可以根據客戶端的IP地址，返回相同域名的不同IP地址；
4. 由於從cname獲得的IP地址，並且帶有hostname信息，請求到達Cache之后，Cache必須知道源服務器的IP地址，所以在CDN運營商內部維護一個內部DNS服務器，用於解釋用戶所訪問的域名的真實IP地址；
5. 在維護內部DNS服務器時，還需要維護一台授權服務器，控制哪些域名可以進行緩存，而哪些又不進行緩存，以免發生開放代理的情況。

二、CDN技術詳解

2.1 引言  

“第一公里”是指萬維網流量向用戶傳送的第一個出口，是網站服務器接入互聯網的鏈路所能提供的帶寬。這個帶寬決定了一個網站能為用戶提供的訪問速度和並發訪問量。如果業務繁忙，用戶的訪問數越多，擁塞越嚴重，網站會在最需要向用戶提供服務時失去用戶。“中間一公里” 和“最后一公里”分別代表互聯網傳輸和萬維網流量向用戶傳送的最后一段接入鏈路。

從互聯網的架構來看，不同網絡之間的互聯互通帶寬，對任何一個運營商網絡的流量來說，占比都比較小，收斂比是非常高的，因此這里通常都是互聯網傳輸中的擁堵點（運營商互聯互通的問題）。

其次是骨干網堵塞問題，由於互聯網上的絕大部分流量都要通過骨干網絡進行傳輸，這就要求骨干網絡的承載能力必須與互聯網的應用同步發展，但實際上兩者並不是同步的，當骨干網絡的升級和擴容滯后於互聯網之上的應用的發展時，就會階段性地使得大型骨干網的承載能力成為影響互聯網性能的瓶頸（區域互聯互通問題，骨干網帶寬瓶頸）

在互聯網領域有一個“8秒定律”，用戶訪問一個網站時，如果等待網頁打開的時間超過8秒，會有超過30%的用戶放棄等待。

使用CDN會極大簡化網站的系統維護工作量，網站維護人員只需將網站內容注入CDN的系統，通過CDN部署在各個物理位置的服務器進行全網分發，就可以實現跨運營商、跨地域的用戶覆蓋

對於電信運營商，CDN是真正體現管道智能化的技術

2.2 CDN技術概述

2.2.1 關鍵技術

緩存算法決定命中率、源服務器壓力、POP節點存儲能力。分發能力取決於IDC能力和IDC策略性分布。負載均衡（智能調度）決定最佳路由、響應時間、可用性、服務質量。基於DNS的負載均衡以CNAME實現[to cluster]，智取最優節點服務，緩存點有客戶端瀏覽器緩存、本地DNS服務器緩存。緩存內容有DNS地址緩存、客戶請求內容緩存、動態內容緩存。支持協議如靜動態加速（圖片加速、https帶證書加速）、下載加速、流媒體加速、企業應用加速、手機應用加速。

CDN關鍵技術：

1. 緩存算法[Squid]；

2. 分發能力；

3. 負載均衡[Nginx]

4. 基於DNS[BIND]；

5. 支持協議；

2.2.2 詳細介紹

CDN提供一種機制，當用戶請求內容時，該內容能夠由以最快速度交付的Cache來向用戶提供，這個挑選“最優”的過程就叫做負載均衡。

從功能上看，典型的CDN系統由分發服務系統，負載均衡系統和運營管理系統組成。

分發服務系統：最基本的工作單元就是Cache設備，cache（邊緣cache）負責直接響應最終用戶的訪問請求，把緩存在本地的內容快速地提供給用戶。同時cache還負責與源站點進行內容同步，把更新的內容以及本地沒有的內容從源站點獲取並保存在本地。Cache設備的數量、規模、總服務能力是衡量一個CDN系統服務能力的最基本的指標。

負載均衡系統：主要功能是負責對所有發起服務請求的用戶進行訪問調度，確定提供給用戶的最終實際訪問地址。兩級調度體系分為全局負載均衡（GSLB）和本 地負載均衡（SLB）。GSLB主要根據用戶就近性原則，通過對每個服務節點進行“最優”判斷，確定向用戶提供服務的cache的物理位置。SLB主要負 責節點內部的設備負載均衡。

運營管理系統：分為運營管理和網絡管理子系統，負責處理業務層面的與外界系統交互所必須的收集、整理、交付工作，包含客戶管理、產品管理、計費管理、統計分析等功能。

負責為用戶提供內容服務的cache設備應部署在物理上的網絡邊緣位置，即CDN邊緣層。CDN系統中負責全局性管理和控制的設備組成中心層（二級緩存），中心層同時保存着最多的內容副本，當邊緣層設備未命中時，會向中心層請求，如果在中心層仍未命中，則需要中心層向源站回源（如果是流媒體，代價很大）。

CDN骨干點和CDN POP點在功能上不同，中心和區域節點一般稱為骨干點，主要作為內容分發和邊緣未命中時的服務點；邊緣節點又被稱為POP（point of presence）節點，CDN POP點主要作為直接向用戶提供服務的節點。

2.2.3 協議加速

應用協議加速：企業應用加速主要是動態加速和SSL加速

廣域網應用加速：

SSL應用加速：由於需要大量的加密解密運算，SSL應用對服務器端的資源消耗是非常巨大。CDN提供SSL應用加速后，由CDN的專用SSL加速硬件來完成加密解密運算工作。

網頁壓縮：HTTP1.1提出對網頁壓縮的支持。在服務器端可以先對網頁數據進行壓縮，然后將壓縮后的文件提供給訪問用戶，最后在用戶瀏覽器端解壓顯示（但要衡量加解壓時間）。

2.3 內容緩存工作原理

 有CDN前的網站服務技術：

• 硬件擴展：高成本，靈活性和可擴展性比較差。
• 鏡像技術（mirroring）：鏡像服務器安裝有一個可以進行自動遠程備份的軟件，每隔一定時間，各個鏡像服務器就會到網站的源服務器上去獲取最新的內容。
• 緩存技術（caching）：緩存代理緩存被訪問過的內容，后續的相同內容訪問直接通過緩存代理獲得服務。

CDN是緩存技術的基礎上發展起來的，是緩存的分布式集群實現。

從技術層面看，Web架構的精華有3處：

• 超文本技術HTML實現信息與信息的連接；
• 統一資源標志符URI實現全球信息的精確定位；
• 應用層協議HTTP實現分布式的信息共享。

HTTP1.1采用了效率更高的持續連接機制，即客戶端和服務器端建立TCP連接后，后續相關聯的HTTP請求可以重復利用已經建立起來的TCP連接，不僅整個Web頁面（包括基本的 HTML文件和其他對象）可以使用這個持續的TCP連接來完成HTTP請求和響應，而且同一個服務器內的多個Web頁面也可以通過同一個持續TCP連接來 請求和響應。通常情況下，這個持續的TCP連接會在空閑一段特定的時間后關閉，而這個最大空閑時間時可以設置的（連接復用）。

HTTP協議中的緩存技術：新鮮度（時間值）和驗證（驗證信息如ETag或last-modified）時確定內容可否直接提供服務的最重要依據。如果緩存內容足夠新鮮，緩存的內容就能直接滿足HTTP訪問的需求了；如果內容過期，而經源服務器驗證后發現內容沒有發生變化，緩存服務器也會避免將內容從源服務器重新傳輸一遍。

驗證的目的就是檢驗緩存內容是否可用。當中間緩存存在一個過期的緩存內容，並且對應的訪問請求到達時，緩存應該首先向源服務器或者其他保存有未過期的緩存服務器請求驗證來確定本地的緩存內容是否可用。（緩存內容過期，但源服務器沒有更新內容，即緩存內容仍可用）。

• Web緩存代理軟件：Squid；
• 負載均衡軟件：Nginx；
• DNS服務器軟件：BIND。

2.4 集群服務與負載均衡 

WEB 集群與負載均衡，基本概念，Web集群是由多個同時運行同一個web應用的服務器組成，在外界看來就像一個服務器一樣，這多台服務器共同來為客戶提供更高性能的服務。集群標准的定義是：一組相互獨立的服務器在網絡中表現為單一的系統，並以單一系統的模式加以管理，此單一系統為客戶工作站提供高可靠性的服務。

負載均衡的任務就是負責多個服務器之間（集群內）實現合理的任務分配，使這些服務器（集群）不會出現因某一台超負荷、而其他的服務器卻沒有充分發揮處理能力的情況。負載均衡有兩個方面的含義：首先，把大量的並發訪問或數據流量分擔到多台節點上分別處理，減少用戶等待響應的時間；其次，單個高負載的運算分擔到多台節點上做並行處理，每個節點設備處理結束后，將結果匯總，再返回給用戶，使得信息系統處理能力可以得到大幅度提高。

因此可以看出，集群和負載均衡有本質上的不同，它們是解決兩方面問題的不同方案，不要混淆。

集群技術可以分為三大類：

1、高性能性集群(HPC Cluster)；

2、高可用性集群(HA Cluster)；

3、高可擴展性集群。

 2.4.1 高性能性集群

指以提高科學計算能力為目標的集群技術。該集群技術主要用於科學計算。

 2.4.2 高可用性集群

指為了使群集的整體服務盡可能可用，減少服務宕機時間為目的的集群技術。如果高可用性集群中的某節點發生了故障，那么這段時間內將由其他節點代替它的工作。當然對於其他節點來講，負載相應的就增加了。

為了提高整個系統的可用性，除了提高計算機各個部件的可靠性以外，一般情況下都會采用該集群的方案。

對於該集群方案，一般會有兩種工作方式：主主和主從。

2.4.2.1 主主工作方式

主-主(Active-Active)工作方式：

這是最常用的集群模型，它提供了高可用性，並且在只有一個節點時也能提供可以接受的性能，該模型允許最大程度的利用硬件資源。每個節點都通過網絡對客戶機提供資源，每個節點的容量被定義好，使得性能達到最優，並且每個節點都可以在故障轉移時臨時接管另一個節點的工作。所有的服務在故障轉移后仍保持可用，但是性能通常都會下降。

     

這是目前運用最為廣泛的雙節點雙應用的Active/Active模式。

支撐用戶業務的應用程序在正常狀態下分別在兩台節點上運行，各自有自己的資源，比如IP地址、磁盤陣列上的卷或者文件系統。當某一方的系統或者資源出現故障時，就會將應用和相關資源切換到對方的節點上。

這種模式的最大優點是不會有服務器的“閑置”，兩台服務器在正常情況下都在工作。但如果有故障發生導致切換，應用將放在同一台服務器上運行，由於服務器的處理能力有可能不能同時滿足數據庫和應用程序的峰值要求，這將會出現處理能力不夠的情況，降低業務響應水平。

2.4.2.2 主從工作方式

 主-從(Active-Standby)工作方式：

 為了提供最大的可用性，以及對性能最小的影響，主-從工作方式需要一個在正常工作時處於備用狀態的節點，主節點處理客戶機的請求，而備用節點處於空閑狀態，當主節點出現故障時，備用節點會接管主節點的工作，繼續為客戶機提供服務，並且不會有任何性能上影響。

         

兩節點的Active/Standby模式是HA中最簡單的一種，兩台服務器通過雙心跳線路組成一個集群。應用Application聯合各個可選的系統組件如：外置共享的磁盤陣列、文件系統和浮動IP地址等組成業務運行環境。

PCL為此環境提供了完全冗余的服務器配置。這種模式的優缺點：

缺點：Node2在Node1正常工作時是處於“閑置”狀態，造成服務器資源的浪費。

優點：當Node1發生故障時，Node2能完全接管應用，並且能保證應用運行時的對處理能力要求。

2.4.3 高可擴展性集群

這里指帶有負載均衡策略（算法）的服務器群集技術。帶負載均衡集群為企業需求提供了更實用的方案，它使負載可以在計算機集群中盡可能平均地分攤處理。而需要均衡的可能是應用程序處理負載或是網絡流量負載。該方案非常適合於運行同一組應用程序的節點。每個節點都可以處理一部分負載，並且可以在節點之間動態分配負載，以實現平衡。對於網絡流量也是如此。通常，單個節點對於太大的網絡流量無法迅速處理，這就需要將流量發送給在其它節點。還可以根據每個節點上不同的可用資源或網絡的特殊環境來進行優化。

負載均衡集群在多節點之間按照一定的策略（算法）分發網絡或計算處理負載。負載均衡建立在現有網絡結構之上，它提供了一種廉價有效的方法來擴展服務器帶寬，增加吞吐量，提高數據處理能力，同時又可以避免單點故障。

 

2.5 負載均衡

負載均衡就是智能調度。

負載均衡的任務就是負責多個服務器之間（集群內）實現合理的任務分配，使這些服務器（集群）不會出現因某一台超負荷、而其他的服務器卻沒有充分發揮處理能力的情況。

負載均衡有兩個方面的含義：首先，把大量的並發訪問或數據流量分擔到多台節點上分別處理，減少用戶等待響應的時間；其次，單個高負載的運算分擔到多台節點上做並行處理，每個節點設備處理結束后，將結果匯總，再返回給用戶，使得信息系統處理能力可以得到大幅度提高。

2.5.1 全局負載均衡

全局負載均衡（GSLB）的負載均衡主要是在多個節點之間進行均衡，其結果可能直接終結負載均衡過程，也可能將用戶訪問交付下一層次的（區域或本地）負載均衡系統進行處理。GSLB最通用的是基於DNS解析方式、HTTP重定向、IP路由等方法。

2.5.1.1 DNS

DNS就是IP地址和網址互換。

當需要訪問abc.com這個站點時，實際上我們想要瀏覽的網頁內容都存放在互聯網中對應某個IP的服務器上，而瀏覽器的任務就是找到我們想要訪問的這台服務器的IP地址，然后向它請求內容。

本地DNS服務器（local DNS server）是用戶所在局域網或ISP網絡中的域名服務器。當客戶端在瀏覽器里請求abc.com時，瀏覽器會首先向本地DNS服務器請求將 abc.com解析成IP地址，本地DNS服務器再向整個DNS系統查詢，直到找到解析結果。

DNS給使用它的互聯網應用帶來額外的時延，有時時延還比較大，為了解決問題，需要引入“緩存”機制。緩存是指DNS查詢結果在主機（local DNS server）中緩存。在區內主機對某個域名發起第一次查詢請求時，負責處理遞歸查詢的DNS服務器要發送好幾次查詢（先查.root，再查.com之 類，再定位IP地址等）才能找到結果，不過在這過程中它也得到了許多信息，比如各區域權威DNS服務器（就是告訴你最終abc.com在哪里的DNS服務 器）和它們的地址、域名解析最終結果。他會把這些信息保存起來，當其他主機向它發起查詢請求時，它就直接向主機返回緩存中能夠找到的結果，直到數據過期。

客戶端瀏覽器也可以緩存DNS響應信息。

Internet類資源記錄分為：

• A記錄（address）：域名->多個IP的映射。對同一個域名，可以有多條A記錄；
• NS記錄（name server）：指定由哪台DNS服務器來解析；
• SOA記錄（start of authority）：指定該區域的權威域名服務器；
• CNAME記錄（canonical name）：多個域名->服務器的映射；
• PTR記錄（pointer record）：IP->域名的映射；

2.5.1.2 負載均衡

DNS系統本身是具備簡單負載分配能力的，這是基於DNS的輪詢機制。如果有多台Web服務器（多源）同時為站點 abc.com提供服務，abc.com的權威服務器可能會解析出一個或多個IP地址。權威域名服務器還可以調整響應中IP地址的排列方式，即在每次響應中將不同的IP地址置於首位（取決於可服務能力和服務質量），通過這種方式實現對這些Web服務器的負載均衡

通過CNAME方式實現負載均衡：域名服務器獲得CNAME記錄后，就會用記錄中的別名來替換查找的域名或主機名（實現多個域名->服務器映射）。后面會查詢這個別名的A記錄來獲取相應的IP地址。

具體操作為：先將GSLB的主機名定義為所查詢域名的權威DNS服務器的別名，然后將GSLB主機名添加多條A記錄，分別對應多個服務器的IP地址。這樣，本地DNS服務器會向客戶端返回多個IP地址作為域名的查詢結果，並且這些IP地址的排列順序是輪換的。客戶端一般會選擇首個IP地址進行訪問。

負載均衡器作為權威DNS服務器：負載均衡器就會接收所有對這個域名的DNS請求，從而能夠根據預先設置的一些策略來提供對域名的智能DNS解析。F5的DNS具有完整的DNS功能以及增強的GSLB特性。

負載均衡作為代理DNS服務器：負載均衡器被注冊為一個域名空間的權威DNS服務器，而真正的權威域名服務器則部署在負載均衡器后面。所有的DNS請求都會先到達負載均衡器，由負載均衡器轉發到真正的權威DNS服務器，然后修改權威DNS服務器返回的響應信息。真正的權威 DNS服務器正常響應瀏覽器的DNS請求，返回域名解析結果列表，這個響應會先發送到負載均衡器，而負載均衡器會根據自己的策略選擇一個性能最好的服務器 IP並修改需要實現GSLB的域名的DNS查詢響應，對其他請求透明轉發，這樣就不會影響整個域名空間的解析性能。

在基於DNS方式下無論采用何種工作方式，都會有一些請求不會到達GSLB，這是DNS系統本身的緩存機制在起作用。當用戶請求的域名在本地DNS或本機（客戶端瀏覽器）得到了解析結 果，這些請求就不會達到GSLB。Cache更新時間越短，用戶請求達到GSLB的幾率越大。由於DNS的緩存機制屏蔽掉相當一部分用戶請求，從而大大減輕了GSLB處理壓力，使得系統抗流量沖擊能力顯著提升，這也是很多商業CDN選擇DNS機制做全局負載均衡的原因之一。但弊端在於，如果在DNS緩存刷新間隔之內系統發生影響用戶服務的變化，比如某個節點故障，某個鏈路擁塞等，用戶依然會被調度到故障部位去

2.5.2 智能DNS

智能DNS功能，它在向本地DNS返回應答之前會先根據一些靜態或動態策略進行智能計算。

• 服務器的“健康狀況”；
• 地理區域距離；
• 會話保持；
• 響應時間；
• IP地址權重；
• 會話能力閾值；
• 往返時間（TTL）；
• 其他信息，包括服務器當前可用會話數、最少選擇次數、輪詢等。

2.5.3 GSLB的部署問題

關於內容的緩存問題（如何智能調度最有效）和配置

在有些CDN中（用於視頻網站加速的情況較多），網站需要加速的內容全部先緩存在OCS（內容中心），然后再將一部分 （通常是熱門的內容）分發到個POP節點（Cache邊緣集群），所以POP節點在某些時候會出現本地未命中而需要回OCS取內容或者從其他POP節點取內容的情況

純粹基於DNS方式的GSLB只能完成就近性判斷。為實現智能調度，大多數解決方案需要在GSLB設備附近以旁路的方式部署一台輔助設備（為方便描述，我們可稱之為GRM——全局資源管理設備），用以實現和各POP節點的本地資源管理設備進行通信，完成CDN對各POP節點的狀態檢查，並根據POP節點的狀態和流量情況，重新制訂用戶調度策略，將策略實時發送到GSLB中去執行。

因為DNS服務采用以UDP為基礎的、默認無連接的訪問方式，給分布式攻擊（DDoS）帶來了更大的便利。

隱藏節點的存在很大程度上可以避免GSLB被攻擊致癱瘓的機會，實際隱藏節點的實現方法就是在實際組網時除了部署正常工作的GSLB以外，再部署一台備份的GSLB設備，並將這一備份GSLB設備隱藏起來，不對外公布。

HTTP重定向（CDN GSLB用302重定向）：在HTTP協議中，有三類重定向狀態嗎：301永久性轉移（permanently moved）、302暫時轉移（temporarily moved）、meta fresh在特定時間后重定向到新的網頁。

HTTP重定向只適用於HTTP應用，不適用於任何其他應用。比如微軟的MMS協議，RTSP協議，就不能使用這種方式進行重定向。其次，由於HTTP重定向過程需要額外解析域名URL，還需要與URL建立TCP連接並且發送HTTP請求，使得響應時間加長。不同於 DNS方式，沒有任何用戶請求能被外部系統終結（不能緩存），所有請求都必須進入GSLB系統，這將成為性能和可靠性的瓶頸。（流媒體用的比較多）。

2.5.4 基於IP路由的GSLB

基於路由協議算法選擇一條路由到達這兩個本地均衡器中的一個。因為每次訪問請求的終端IP地址不同，路由條件也不同，所以在多個路由器上優選的路由不同，從統計復用的角度來看基本是在負載均衡器1和2之間均勻分布的。

IP路由在多個POP點之間實現的負載均衡是一種概率上的均衡，而不是真正的均衡（沒做智能調度）。

比較項	基於DNS解析方式	基於HTTP重定向方式	基於IP路由方式
性能	本地DNS服務器和用戶終端DNS緩存能力使GSLB的負載得到有效分擔	GSLB處理壓力大，容易成為系統性能的瓶頸	借助IP網絡設備完成負載均衡，沒有單點性能瓶頸
准確度	定位准確度取決於本地DNS覆蓋范圍，本地DNS設置錯誤會造成定位不准確	在對用戶IP地址數據進行有效維護的前提下，定位准確且精度高	就近性調度准確，但對設備健康性等動態信息響應會有延遲
效率	效率約等於DNS系統本身處理效率	依靠服務器做處理，對硬件資源的要求高	效率約等於IP設備本身效率
擴展性	擴展性和通用性好	擴展性較差，需對各種應用協議進行定制開發	通用性好，但適用范圍有限
商用性	在Web加速領域使用較多	國內流媒體CDN應用較多	尚無商用案例

 

三、流媒體CDN系統的組成

3.1 流媒體

流媒體業務是一種對實時性、連續性、時序性要求非常高的業務，無論從帶寬消耗上還是質量保障上來說，對best-effort的IP網絡都是一個不小的沖擊。

• 高帶寬要求
• 高QoS要求
• 組播、廣播要求（目前IP網絡無法實現端到端的組播業務）

播放一個視頻分為以下4個步驟

1. Access；
2. Demux（音視頻分離）；
3. Decode（解碼解壓縮）；
4. Output。

3.2 協議

3.2.1 RTP相關

 

RTCP：Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP；

RTP：Real-time Transport Protocol；

RTSP：Real Time Streaming Protocol；

RTP、RTCP、RTSP、RTMP的關系：RTSP協議用來實現遠程播放控制，RTP用來提供時間信息和實現流同步，RTCP協助RTP完成傳輸質量控制<=（播放控制），

=>（傳輸控制）RTMP和HTTP streaming則是將流同步、播放控制、質量控制集成起來的企業自有流媒體傳送協議。

RTMP協議架構在TCP層之上，但RTMP消息並不是直接封裝在TCP中，而是通過一個被稱為消息塊的封裝單元進行傳輸。消息在網絡上發送之前往往需要分割成多個較小的部分，這樣較小的部分就是消息塊，屬於不同消息流的消息塊可以在網絡上交叉發送。

RTSP/RTP和HTTP streaming是目前應用最廣泛的流化協議，目前電信運營商在IPTV（特殊通道的基於IP的流媒體播放）的流化上主要以RTSP/RTP技術為主，而互聯網視頻網站（點播/直播）則多傾向於使用HTTP streaming的流化技術。

3.2.2 HTTP streaming

HTTP streaming前身是progressive download（漸進式下載：邊下載邊播放，直到下載完）。HTTP streaming首先會將視頻數據（包括直播的視頻流和點播的視頻文件）在服務器上進行編碼，然后將編碼后的數據進行更細粒度的分片，再把每個分片通過 HTTP協議傳輸到客戶端。HTTP streaming的客戶端需要對視頻文件的每個分片都發出一個HTTP請求，這樣，在視頻播放速度低於下載速度的情況下，客戶端可以靈活控制HTTP請 求的發出速度，從而保證用戶在中途退出時不會出現下載浪費。另外，因為采用分片的特點，HTTP streaming還可以實現媒體播放過程中的碼率切換（碼率自適應），結合網絡帶寬資源，為用戶提供更好的體驗。

HTTP streaming	Progressive download
支持點播、直播	僅支持點播
可對分片文件加密，保證數字版權	直接把媒體文件分割成多個小文件分片，無法保障版權所有
因為分片傳輸，支持碼率自適應	只支持固定碼率

 

HTTP streaming	RTSP/RTP
基於TCP，更高可靠性，也可以直接利用TCP的流控機制來適應帶寬的變化	基於UDP
可將播放過的內容保存在客戶端	不能保存在客戶端
使用80端口，能穿越防火牆	使用特殊端口
采用標准的HTTP協議來傳輸，只需要標准的HTTP服務器支撐	需要特殊的流媒體服務器

• HTTP streaming的幾個主流陣營：
• 3GPP adaptive HTTP Streaming
• Microsoft IIS Smooth Streaming
• Adobe HTTP Dynamic Streaming (HDS)
• Apple HTTP Live Streaming (HLS)

3.2.2.1 HLS

HLS流化技術主要分三個部分：服務器組件、分發組件和客戶端軟件。

服務器組件主要負責從原始的音視頻設備捕捉相應的音視頻流，並對這些輸入的媒體流進行編碼，然后進行封裝和分片，最后交付給分發組件來進行傳送；

分發組件主要負責接收客戶端發送的請求，然后將封裝的流媒體分片文件連同相關的索引文件一起發送給客戶端。對於沒有采用CDN服務的源服務器，標准的Web服務器就是一個分發組件，而對於大型的視頻網站或者類似的大規模應用平台，分發組件還應包括支持RTMP協議的CDN。

客戶端軟件負責確定應該請求的具體媒體流，下載相關資源，並在下載后通過拼接分片將流媒體重新展現給用戶。

HLS音視頻流或流媒體文件在經過編碼、封裝和分片后，變成多個以.ts結尾的分片文件。流分割器產生的索引文件是以.M3U8為后綴的，用戶可以直接通過Web訪問來獲取。

分發組件負責將分片文件和索引文件通過HTTP的方式發送給客戶端，無須對現有的Web服務器和Cache設備進行額外的擴展、配置和升級

客戶端組件根據URL來獲取這個視頻的索引文件。索引文件包含了可提供分片文件的具體位置、解密密鑰以及可用的替換流。

HDS，點播內容是通過一個簡單的預編碼生成MP4片段以及Manifest清單文件；直播的內容准備工作流程相對復雜一點，在播放的過程中生成MP4.（直播推薦用RTMP，使用FMS推流器）。

MPEG-2 TS是指TS格式封裝的、MPEG-2編碼格式的媒體流。大多數IPTV系統使用這種內容源。H.264這一層完成原始文件的壓縮編碼，TS這一層負責音 視頻的復用以及同步，RTP這一層負責流的順序傳輸，UDP這一層負責數據包的交付，IP層負責傳輸路由選擇。

流媒體加速的回源要求：因為流媒體文件傳送帶寬需求高，而且往往需要維持TCP長連接，所以一旦CDN回源比例過高，源站服務器I/O將不堪負荷。CDN對內容采取分發方式分為pull和push兩種。Pull是被動下拉的方式，push是主動推送的方式。對於流媒體內容，系統一般會選擇對熱點內容采取push方式的預分發，而普通的網頁內容幾乎100%是pull方式的。

在流媒體CDN系統中，用戶訪問的調度會更多考慮內容命中，主要是因為流媒體內容文件體積大，業務質量要求高，如果從其他節點拉內容再向用戶提供服務會帶來額外的延遲，影響用戶體驗。為進一步提高命中率，流媒體CDN系統普遍采用了對熱點內容實施預先push的內容分發策略。

3.2.2.2 流媒體CDN與Web CDN

在流媒體服務系統中，主要關注的技術是對不同流媒體協議、不同編碼格式、不同播放器、不同業務質量要求等的適應。

流媒體CDN與Web CDN的對比（業務差異）

主要差異點	流媒體CDN	Web CDN
內容類型	大文件、實時流、QoS要求高	小文件、固定大小、QoS要求低
用戶行為	拖曳、暫停等播放控制	下載后瀏覽
內容管理	內容冷熱度差異明顯（對命中率要求高），內容生命周期長	內容冷熱度差異不明顯，內容生命周期短
回源要求	回源比例小	回源比例大

現在已經投入商用的CDN系統，基本都是同時提供Web CDN能力和流媒體CDN能力的，而且這兩種能力的實現在系統內部幾乎都是互相隔離的，從調度系統到節點設備都沒有交叉互用。

流媒體CDN與Web CDN的設計差異（設計差異）：

主要差異點	流媒體CDN	Web CDN
Cache	支持多種流化協議，硬件配置大存儲、高I/O	支持多協議（HTTP、FTP等）硬件配置小存儲、高性能CPU
負載均衡	DNS+HTTP重定向方式	DNS方式
內容分發方式	熱片PUSH，冷片PULL	全PULL方式
組網	多級組網，可能要求組播、單播混合組網	兩級組網

3.2.3 緩存和部署

流媒體CDN的Cache設備與Web Cache無論在軟件實現還是硬件要求上差異都很大，我們很少看到這兩種業務共用同一台設備。

當用戶請求的內容在Cache上命中時，Cache直接向用戶提供流服務，此時Cache設備充當流媒體服務器的角色； 當用戶請求內容未能在Cache上命中時，Cache會從上一級Cache（二級緩存設備或中間緩存設備）或者源站服務器獲取內容，再提供給用戶。 Cache在用戶與另一個流媒體服務器之間扮演代理的角色。

分布式存儲技術因其大容量、低成本的特點，目前也被業界關注和研究作為流媒體CDN系統的存儲解決方案之一。常用的分布式存儲技術包括分布式文件系統和分布式數據庫，由於采用了數據副本冗余（每份數據復制2~3份）、磁盤冗余（Raid1、Raid10、Raid5）等技術，通常可以提供良好的數據容錯機制，當單台存儲設備斷電或者單個存儲磁盤失效時，整個存儲系統仍能正常工作。

負載均衡設備在進行用戶訪問調度時，會綜合考慮很多靜態的、動態的參數，包括IP就近性、連接保持、內容命中、響應速度、連接數等。但沒有哪個CDN會考慮所有參數，而是會根據業務特點進行一些取舍，否則均衡系統就太復雜了。而流媒體CDN在進行用戶訪問調度時，會更多考慮內容命中這一參數。

從網絡分層上看，Web CDN通常是兩級架構（也有三級架構以減少回源），即中心-邊緣。而流媒體CDN通常有三級以上架構，即中心-區域-邊緣。產生這種區別的原因在於流媒體 回源成本比較高，源站服務器響應一次流媒體內容回源請求，要比Web內容回源消耗更多資源。尤其對於流媒體直播業務來說，只要直播節目沒結束，服務器就需 要長時間持續吐流，如果沒有第二層節點作為中繼，那么中心節點的壓力將是不可想象的。

分層部署的方式，對點播業務而言的主要意義是節省存儲成本，對直播業務而言在於減少帶寬成本。在點播業務中，邊緣Cache只需存儲用戶訪問量大的內容或者內容片斷，其余內容存儲在區域Cache中。

在直播業務中，邊緣Cache從區域中心獲取直播流，而不需要直接向中心節點（源站）獲取，從而節省了區域中心到中心節點這一段的大部分帶寬。因為直播流在各個Cache中都不需要占用很大的存儲空間，只需少量緩存空間即可，所以直播業務方面並不用注重考慮存儲成本。

考慮到電信運營商的IP拓撲和流量模型，區域中心Cache通常部署在重點城市的城域網出口的位置，以保障向各個邊緣 Cache的鏈路通暢。邊緣Cache的位置選擇則以整個節點能夠提供的並發能力為主要依據，依據業務並發數收斂比，計算出單個Cache需要覆蓋的用戶 規模，從而選擇一個合適的部署位置。當然，邊緣Cache離用戶越近，服務質量越好，但覆蓋的用戶數越少，部署成本越高。

3.2.4 內容文件預處理

是指視頻內容進入CDN以后，進入內容分發流程之前，CDN系統對內容進行的一系列處理過程。這個預處理過程的目的有幾個：

• 為全網內容管理提供依據，比如對內容進行全網唯一標識，對內容基礎信息進行記錄等；
• 為提高CDN服務效率或降低系統成本提供手段，比如內容切片；
• 為滿足業務要求提供能力，比如對同一內容進行多種碼率的轉換以滿足動態帶寬自適應或三屏互動業務要求。

視頻轉碼(video transcoding)

• 碼率轉換
• 空間分辨率轉換
• 時間分辨率轉換
• 編碼格式轉換。編碼格式主要包括H.264、MPEG-4、MPEG-2、VC-1、REAL、H.263、WMV。通常是把其他編碼格式轉換成H.264

3.2.5 文件切片

文件切片是指按照一定的規則把一個完整的文件切成大小一致的若干個小文件。由於流媒體CDN需要提供的內容體積越來越大，傳統整片存儲帶來的成本消耗超出了CDN服務商的承受范圍。切片的另一個目的是，使邊緣Cache能夠支持自適應碼率業務。

防盜鏈機制和實現

• 基於IP的黑白名單；
• 利用HTTP header的referer字段；
• 使用動態密鑰（隨機生成的key通過算法生成新的url）；
• 在內容中插入數據（對有版權內容進行加密（DRM），如Microsoft的playready，Google的Widevine）；
• 打包下載：在原文件的基礎上進一步封裝，使得資源的hash 值改變。

四、動態內容加速服務的實現

4.1 WEB

隨着Web2.0的興起，產生了動態網頁、個性化內容、電子交易數據等內容的加速，這些就涉及了動態內容加速技術。

4.2 動態加速

靜態內容的加速，都是對於表現層的加速，對於動態頁面等內容的加速，則要涉及邏輯層和數據訪問層的加速技術。動態內容的提供不僅僅是HTML頁面的設計及編輯，它還需要有后台數據庫、應用邏輯程序的支持，以實現與用戶的動態交互。

Web系統由表現層、業務邏輯層、數據訪問層+用戶數據層。

表現層是Web系統與外部系統的交互界面，這一層通常由HTTP服務器組成，負責接收用戶端的HTTP內容訪問請求，從文件系統中讀取靜態文件。

業務邏輯層負責處理所有業務邏輯和動態內容的生成。

數據訪問層位於系統的后端，負責管理Web系統的主要信息和數據存儲，通常由數據庫服務器和存儲設備組成。

用戶數據層負責存儲用戶信息數據和關聯關系，內容來自用戶提供和用戶行為分析結果。

Web網站借助CDN技術能夠獲得更好的擴展性和高性能，核心在於CDN采用的緩存（caching）和復制（replication）機制，其中緩存是將最近經常被訪問的源服務器擁有的內容復制到邊緣服務器上，可被視為具有特定策略的復制。

CDN的復制機制是指將源Web系統邏輯架構的各個層次的相應功用復制到邊緣服務器上實現，以緩解源系統的處理壓力。

Web系統表現層的復制，就是靜態內容的復制。邊緣服務器又被稱為代理服務器，通過反向代理加速靜態文件的交付。

• Web系統業務邏輯層的復制。CDN被用於改進動態生成內容的交付性能。即將應用程序和業務組件直接在CDN的邊緣服務器中計算，從而直接在靠近用戶的地方生成動態Web內容
• Akamai邊緣計算部署模型，包括用戶（使用瀏覽器）、企業J2EE應用系統（運行業務邏輯、原有系統、數據庫等）、分布式網絡服務器（Edge computing平台）運行支持J2EE應用編程模型的WebSphere或者Tomcat應用服務器
• Web系統數據訪問層復制。CDN邊緣服務器能夠具備生成動態內容和掌管內容生成數據的能力
• 利用邊緣服務器代替源鑽Web系統的后台數據訪問層中的數據庫系統，及時響應業務邏輯層提出的數據查詢需求。
• Web系統用戶文件的復制。

4.3 應用加速

應用加速技術實際上是傳統的網絡負載均衡的升級和擴展，綜合使用了負載均衡（智能調度）、TCP優化管理（TCP keep-alive connection，更激進的TCP窗口策略，基於HTTP1.1），鏈接管理（routing）、SSL VPN、壓縮優化（代碼壓縮，圖片壓縮）、智能網絡地址（NAT-公私網IP轉換）、高級路由、智能端口鏡像等技術。

TCP的問題：

• TCP窗口大小的限制（TCP窗口大小隨傳輸成功而變大，而一旦發生傳輸失敗，其窗口大小會立即縮小）；
• TCP協議慢啟動（三握手）和擁塞控制。

廣域網加速關鍵技術：

針對層次	優化技術	優化原理
傳輸發起端	原始數據優化	通過壓縮、重復數據刪除和字典等技術，可節省絕大多數傳輸數據量，節約帶寬，提高服務器性能
	數據緩存技術	將類HTTP的業務、圖片、文字等緩存在本地，只傳輸動態內容，減少帶寬占用
物理層（硬件）	提升設備性能	基於現有TCP/IP，通過硬件方式提高性能，提高大量TCP並發連接和會話重組等處理能力
網絡層（IP）	QoS和流量控制	通過協議識別，實現在同一端口中不同應用的真正區分，進而通過分流實現時延敏感應用的帶寬保障
傳輸層（TCP）	代理設備	在傳輸兩端各架設代理設備，所有的響應報文都在本地完成，只有真正發起請求時才通過鏈路，相當於同時在服務器和客戶端進行協議欺騙
	TCP協議優化	通過在廣域網兩端部署專用設備，在不影響基本傳輸情況下，通過各種手段對TCP窗口、響應、啟動等機制進行改進，從而提高協議機制的效率
應用層	應用代理（緩存）	將常用的應用程序緩存在本地並配置好，用戶可不用在本地等待類似於認證等會話過程，而是直接開始下一個應用，實現流水作業

數據碎片化，就是在應用層將數據分成一個個小的數據塊，便於后續的數據比對使用。廣域網加速設備在傳輸數據前會將緩存中的數據與數據切塊進行對比，從而找出那些數據是重復數據，不再發送，哪些數據是新鮮的、需要傳輸的數據。

數據壓縮和指針技術一般是放在一起使用的，在對數據分段后，會對每一段數據生成一個數據指針，對於重復內容，只傳輸指針。在壓縮算法設計上，要求同時兼顧數據壓縮比和壓縮/解壓縮時間。

高速TCP傳輸技術

• 自適應擁塞窗口；
• 有限制地快速重傳；
• 連接池：通過維護一個預先建立好的TCP連接池，當有數據傳輸需求時，從連接池中挑選一條可用連接今次那個傳輸。

4.4 SSL

SSL加速技術

• SSL加密是一種處理器密集型加密算法，如果用服務器軟件處理會消耗大量CPU資源，一般會在提供業務能力的服務器外圍部署專門的SSL加速設備，采用硬解密方式實現；
• SSL加密分對稱秘鑰和非對稱秘鑰（計算資源消耗更大）。

SSL的基本原理和實現

• 可認證性（authentication）；
• 隱私性（privacy）；
• 完整性（integrity）；
• 不可抵賴性（undeniability）：發送者不能自稱沒有發出過接受者從他那里收到的內容。

SSL加速

• 通常是基於硬件的SSL加速；
• 通過在服務器上安裝一塊SSL加速板卡，可有效分擔服務器CPU處理SSL事務的壓力。

五、卡頓問題

盡管已經采用了CDN加速，直播類App仍然經常出現訪問慢、卡頓等問題，導致大量用戶投訴，其主要原因是當前架構中存在問題。

5.1 無法就近接入

運營商Local DNS配置不合理導致無法就近接入。

5.2 用戶手機網絡制式切換

假設用戶A從移動4G切換到家中聯通的wifi網絡，仍然按照原先的CDN節點進行加速會出現跨ISP調度，訪問質量差的悲劇事件。通過用戶使用的DNS服務器來判斷客戶端所在的網絡位置，從而返回對應的服務IP。

5.3 BGP

BGP即Border Gateway Protocol（邊界網關協議），業內簡稱BGP。BGP的技術原理往簡單的說就是允許同一IP在不同網絡中廣播不同的路由信息，效果就是同一個IP，當電信用戶來訪問時走電信網內的路由，聯通用戶來訪問時走的聯通的路由。所以BGP技術對跨運營商的訪問帶來了巨大的便利，特別是直播場景。不同於傳統的文件緩存場景，一個圖片哪怕第一次是跨了遙遠的距離從源站獲取后，本地網絡進行緩存，后面的訪問都走本地網絡。直播加速是流式的，並且當要做到低延遲的時候，中間的緩存要盡可能少。BGP相當於給跨網的用戶就近搭建了一坐橋梁，不必繞遠路，延時和穩定性都大大提高了。

在國內一般而言相同的接入運營商（電信、聯通、移動）並且地理位置最近的情況網絡延遲最優，小於15ms。跨省同運營商的網絡延遲25~50ms，跨運營商情況更復雜一些，在50~100ms。總結起來，直播當中每個包的延時可以縮短100ms，由於網絡的疊加效果，反射到上層是秒級的延遲縮減。

HTML5的設計目的是為了在移動設備上支持多媒體。新的語法特征被引進以支持這一點，如video、audio和canvas 標記。

5.4 解決辦法

可以通過接入HTTPDNS解決，終端源站配合的解決方案。

 

下面通過推流階段2個場景說明改進方案如何確保調度到最佳CDN節點。

5.4.1 用例1

Local DNS配置問題導致沒有調度到最優節點的場景：

1. 用戶手機上Local DNS配置不准確，域名解析階段為域名dn返回的是CDN節點B的IP_b，而非最優的CDN節點IP IP_a；
2. 推流的終端應用需要向CDN節點發起鑒權請求，CDN節點在收到鑒權請求后，需要提取終端的公網IP_c，然后除了轉發鑒權相關信息到視頻源站之外，還必須帶上推流終端的公網IP_c 給源站；
3. 源站收到鑒權信息和終端IP后，首先做鑒權工作，然后源站利用推流的域名dn和推流終端公網IP IP_c向HTTPDNS服務器發起請求，獲取最優的CDN節點IP_a，並將IP_a回傳給推流終端，告知推流終端IP_a是最佳接入節點；
4. 終端推流時可以直接向CDN IP_a推流，或者等到發現出現卡頓、慢時切換到IP_a。

5.4.2 用例2

用戶網絡制式切換（如移動4G切聯通wifi）的場景

1. 假設之前移動4G網絡下最佳CDN節點是IP_b，用戶網絡制式切換成聯通wifi后，最佳節點換成了IP_a。網絡切換后，終端第一步仍然向CDN節點IP_b推流，此時會鑒權失敗；
2. 重復場景1的Step 2到Step 4，推流終端最終可以找到最佳CDN節點IP_a並通過IP_a推流。