CDN技術詳解及實現原理
一本好的入門書是帶你進入陌生領域的明燈，《CDN技術詳解》絕對是帶你進入CDN行業的那盞最亮的明燈。因此，雖然只是純粹的重點抄錄，我也要把《CDN技術詳解》的精華放上網。公諸同好。
第一章 引言
“第一公里”是指全球資訊網流量向用戶傳送的第一個出口，是網站伺服器接入網際網路的鏈路所能提供的頻寬。這個頻寬決定了一個 網站能為使用者提供的訪問速度和併發訪問量。如果業務繁忙，使用者的訪問數越多，擁塞越嚴重，網站會在最需要向用戶提供服務時失去使用者。（還有“中間一公里” 和“最後一公里”分別代表網際網路傳輸傳輸和全球資訊網流量向用戶傳送的最後一段接入鏈路）
從網際網路的架構來看，不同網路之間的互聯互通頻寬，對任何一個運營商網路的流量來說，佔比都比較小，收斂比是非常高的，因此這裡通常都是網際網路傳輸中的擁堵點（運營商互聯互通的問題）
其次是骨幹網堵塞問題，由於網際網路上的絕大部分流量都要通過骨幹網路進行傳輸，這就要求骨幹網路的承載能力必須與網際網路 的應用同步發展，但實際上兩者並不是同步的，當骨幹網路的升級和擴容滯後於網際網路之上的應用的發展時，就會階段性地使得大型骨幹網的承載能力成為影響互聯 網效能的瓶頸（區域互聯互通問題，骨幹網頻寬瓶頸）
在網際網路領域有一個“8秒定律”，使用者訪問一個網站時，如果等待網頁開啟的時間超過8秒，會有超過30%的使用者放棄等待
使用CDN會極大簡化網站的系統維護工作量，網站維護人員只需將網站內容注入CDN的系統，通過CDN部署在各個物理位置的伺服器進行全網分發，就可以實現跨運營商、跨地域的使用者覆蓋
對於電信運營商，CDN是真正體現管道智慧化的技術
第二章 CDN技術概述
CDN關鍵技術：
1. 快取演算法[Squid]；2. 分發能力；3. 負載均衡[Nginx]（4. 基於DNS[BIND]）；5. 支援協議；
快取演算法決定命中率、源伺服器壓力、POP節點儲存能力
分發能力取決於IDC能力和IDC策略性分佈
負載均衡（智慧排程）決定最佳路由、響應時間、可用性、服務質量
基於DNS的負載均衡以CNAME實現[to cluster]，智取最優節點服務，
快取點有客戶端瀏覽器快取、本地DNS伺服器快取
快取內容有DNS地址快取、客戶請求內容快取、動態內容快取
支援協議如靜動態加速（圖片加速、https帶證書加速）、下載加速、流媒體加速、企業應用加速、手機應用加速
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點主要作為直接向用戶提供服務的節點
應用協議加速：企業應用加速主要是動態加速和SSL加速
廣域網應用加速：
SSL應用加速：由於需要大量的加密解密運算，SSL應用對伺服器端的資源消耗是非常巨大的。CDN提供SSL應用加速後，由CDN的專用SSL加速硬體來完成加密解密運算工作
網頁壓縮：HTTP1.1提出對網頁壓縮的支援。在伺服器端可以先對網頁資料進行壓縮，然後將壓縮後的檔案提供給訪問使用者，最後在使用者瀏覽器端解壓顯示（但要衡量加解壓時間）
第三章 內容快取工作原理
有CDN前的網站服務技術
– 硬體擴充套件：高成本，靈活性和可擴充套件性比較差
– 映象技術（mirroring）：映象伺服器安裝有一個可以進行自動遠端備份的軟體，每隔一定時間，各個映象伺服器就會到網站的源伺服器上去獲取最新的內容
– 快取技術（caching）：快取代理快取被訪問過的內容，後續的相同內容訪問直接通過快取代理獲得服務
– CDN：是快取技術的基礎上發展起來的，是快取的分散式叢集實現
從技術層面看，Web架構的精華有三處：
– 超文字技術HTML實現資訊與資訊的連線；
– 統一資源標誌符URI實現全球資訊的精確定位
– 應用層協議HTTP實現分散式的資訊共享
TCP連線在每一次HTTP（HTTP 1.0）請求和響應完成後就關閉，如果客戶端還要請求其他物件，需要重新為每個物件建立TCP連線。當一個Web頁面內包含多個物件並全部顯示時，客戶端需要與伺服器建立的TCP連線數較多，對整個時延和網路流量造成了較大的影響
HTTP1.1採用了效率更高 的持續連線機制，即客戶端和伺服器端建立TCP連線後，後續相關聯的HTTP請求可以重複利用已經建立起來的TCP連線，不僅整個Web頁面（包括基本的 HTML檔案和其他物件）可以使用這個持續的TCP連線來完成HTTP請求和響應，而且同一個伺服器內的多個Web頁面也可以通過同一個持續TCP連線來 請求和響應。通常情況下，這個持續的TCP連線會在空閒一段特定的時間後關閉，而這個最大空閒時間時可以設定的（連線複用）。
HTTP協議中的快取技術：新 鮮度（時間值）和驗證（驗證資訊如ETag或last-modified）時確定內容可否直接提供服務的最重要依據。如果快取內容足夠新鮮，快取的內容就 能直接滿足HTTP訪問的需求了；如果內容過期，而經源伺服器驗證後發現內容沒有發生變化，快取伺服器也會避免將內容從源伺服器重新傳輸一遍
如果要通過META標籤來控制頁面不快取，一般情況下會在Web頁面的<head>區域中增加”pragma:no-cache”
驗證的目的就是檢驗快取內容是否可用。當中間快取存在一個過期的快取內容，並且對應的訪問請求到達時，快取應該首先向源伺服器或者其他儲存有未過期的快取伺服器請求驗證來確定本地的快取內容是否可用。（快取內容過期，但源伺服器沒有更新內容，即快取內容仍可用）
HTTP1.1介紹了cache-control顯示指令來讓網站釋出者可以更全面地控制他們的內容，並對過期時間進行限制（控制是否快取，怎麼快取）
HTTP gzip壓縮：大多數情況需要壓縮的檔案時網頁中出現最頻繁的HTML、CSS、javascript、XML等檔案，這類本身是沒有經過壓縮的文字檔案，可以取得較好的壓縮效果
Web快取代理軟體：Squid
負載均衡軟體：Nginx
DNS伺服器軟體：BIND
第四章 叢集服務與負載均衡
Web叢集是由多個同時運行同一個web應用的伺服器組成，在外界看來就像一個伺服器一樣，這多臺伺服器共同來為客戶提供更高效能的服務。叢集更標準的定 義是：一組相互獨立的伺服器在網路中表現為單一的系統，並以單一系統的模式加以管理，此單一系統為客戶工作站提供高可靠性的服務。
而負載均衡的任務就是負責多個伺服器之
間（叢集內）實現合理的任務分配，使這些伺服器（叢集）不會出現因某一臺超負荷、而其他的伺服器卻沒有充分發揮處理能力的情況。負載均衡有兩個方面的含
義：首先，把大量的併發訪問或資料流量分擔到多臺節點上分別處理，減少使用者等待響應的時間；其次，單個高負載的運算分擔到多臺節點上做並行處理，每個節點
裝置處理結束後，將結果彙總，再返回給使用者，使得資訊系統處理能力可以得到大幅度提高
因此可以看出，叢集和負載均衡有本質上的不同，它們是解決兩方面問題的不同方案，不要混淆。
叢集技術可以分為三大類：
1、高效能性叢集(HPC Cluster)
2、高可用性叢集(HA Cluster)
3、高可擴充套件性叢集
一、高效能性叢集(HPC Cluster)
指以提高科學計算能力為目標的叢集技術。該叢集技術主要用於科學計算，這裡不打算介紹，如果感興趣可以參考相關的資料。
二、高可用性叢集(HA Cluster)
指為了使群集的整體服務儘可能可用，減少服務宕機時間為目的的叢集技術。如果高可用性叢集中的某節點發生了故障，那麼這段時間內將由其他節點代替它的工作。當然對於其他節點來講，負載相應的就增加了。
為了提高整個系統的可用性，除了提高計算機各個部件的可靠性以外，一般情況下都會採用該叢集的方案。
對於該叢集方案，一般會有兩種工作方式：
①主-主(Active-Active)工作方式
這是最常用的叢集模型，它提供了高可用性，並且在只有一個節點時也能提供可以接受的效能，該模型允許最大程度的利用硬體資源。每個節點都通過網路對客戶機
提供資源，每個節點的容量被定義好，使得效能達到最優，並且每個節點都可以在故障轉移時臨時接管另一個節點的工作。所有的服務在故障轉移後仍保持可用，但
是效能通常都會下降。
這是目前運用最為廣泛的雙節點雙應用的Active/Active模式。
支撐使用者業務的應用程式在正常狀態下分別在兩臺節點上執行，各自有自己的資源，比如IP地址、磁碟陣列上的卷或者檔案系統。當某一方的系統或者資源出現故障時，就會將應用和相關資源切換到對方的節點上。
這種模式的最大優點是不會有伺服器的“閒置”，兩臺伺服器在正常情況下都在工作。但如果有故障發生導致切換，應用將放在同一臺伺服器上執行，由於伺服器的處理能力有可能不能同時滿足資料庫和應用程式的峰值要求，這將會出現處理能力不夠的情況，降低業務響應水平。
②主-從(Active-Standby)工作方式
為了提供最大的可用性，以及對效能最小的影響，主-從工作方式需要一個在正常工作時處於備用狀態的節點，主節點處理客戶機的請求，而備用節點處於空閒狀態，當主節點出現故障時，備用節點會接管主節點的工作，繼續為客戶機提供服務，並且不會有任何效能上影響。
兩節點的Active/Standby模式是HA中最簡單的一種，兩臺伺服器通過雙心跳線路組成一個叢集。應用Application聯合各個可選的系統元件如：外接共享的磁碟陣列、檔案系統和浮動IP地址等組成業務執行環境。
PCL為此環境提供了完全冗餘的伺服器配置。這種模式的優缺點：
- 缺點：Node2在Node1正常工作時是處於“閒置”狀態，造成伺服器資源的浪費。
- 優點：當Node1發生故障時，Node2能完全接管應用，並且能保證應用執行時的對處理能力要求。
三、高可擴充套件性叢集
這裡指帶有負載均衡策略（演算法）的伺服器群集技術。帶負載均衡叢集為企業需求提供了更實用的方案，它使負載可以在計算機叢集中儘可能平均地分攤處理。而需
要均衡的可能是應用程式處理負載或是網路流量負載。該方案非常適合於運行同一組應用程式的節點。每個節點都可以處理一部分負載，並且可以在節點之間動態分
配負載，
以實現平衡。對於網路流量也是如此。通常，單個節點對於太大的網路流量無法迅速處理，這就需要將流量傳送給在其它節點。還可以根據每個節點上不同的可用資
源或網路的特殊環境來進行優化。
負載均衡叢集在多節點之間按照一定的策略（演算法）分發網路或計算處理負載。負載均衡建立在現有網路結構之上，它提供了一種廉價有效的方法來擴充套件伺服器頻寬，增加吞吐量，提高資料處理能力，同時又可以避免單點故障。
前面已經說過負載均衡的作用是在多個節點之間按照一定的策略（演算法）分發網路或計算處理負載。負載均衡可以採用軟體和硬體來實現。一般的框架結構可以參考下圖。
後
臺的多個Web節點上面有相同的Web應用，使用者的訪問請求首先進入負載均衡分配節點(可能是軟體或者硬體)，由它根據負載均衡策略（演算法）合理地分配給
某個Web應用節點。每個Web節點相同的內容做起來不難，所以選擇負載均衡策略（演算法）是個關鍵問題。下面會專門介紹均衡演算法。
web
負載均衡的作用就是把請求均勻的分配給各個節點，它是一種動態均衡，通過一些工具實時地分析資料包，掌握網路中的資料流量狀況，把請求理分配出去。對於不
同的應用環境（如電子商務網站，它的計
算負荷大；再如網路資料庫應用，讀寫頻繁，伺服器的儲存子系統系統面臨很大壓力；再如視訊服務應用，資料傳輸量大，網路介面負擔重壓。），使用的均衡策略
(演算法)是不同的。
所以均衡策略（演算法）也就有了多種多樣的形式，廣義上的負載均衡既可以設定專門的閘道器、負載均衡器，也可以通過一些專用軟體與協議來實現。在OSI七層協
議模型中的第二（資料鏈路層）、第三（網路層）、第四（傳輸層）、第七層（應用層）都有相應的負載均衡策略（演算法），在資料鏈路層上實現負載均衡的原理是
根據資料包的目的MAC地址選擇不同的路徑；在網路層上可利用基於IP地址的分配方式將資料流疏通到多個節點；而傳輸層和應用層的交換（Switch），
本身便是一種基於訪問流量的控制方式，能夠實現負載均衡。
目前，基於負載均衡的演算法主要有三種：輪循（Round-Robin）、最小連線數（Least Connections First），和快速響應優先（Faster
Response
Precedence）。
①輪循演算法，就是將來自網路的請求依次分配給叢集中的節點進行處理。
②最小連線數演算法，就是為叢集中的每臺伺服器設定一個記數器，記錄每個伺服器當前的連線數，負載均衡系統總是選擇當前連線數最少的伺服器分配任務。
這要比"輪循演算法"好很多，因為在有些場合中，簡單的輪循不能判斷哪個節點的負載更低，也許新的工作又被分配給了一個已經很忙的伺服器了。
③快速響應優先演算法，是根據群集中的節點的狀態（CPU、記憶體等主要處理部分）來分配任務。
這一點很難做到，事實上到目前為止，採用這個演算法的負載均衡系統還很少。尤其對於硬體負載均衡裝置來說，只能在TCP/IP協議方面做工作，幾乎不可能深入到伺服器的處理系統中進行監測。但是它是未來發展的方向。
上面是負載均衡常用的演算法，基於以上負載均衡演算法的使用方式上，又分為如下幾種：
1、DNS輪詢
最早的負載均衡技術是通過DNS來實現的，在DNS中為多個地址配置同一個名字，因而查詢這個名字的客戶機將得到其中一個地址，從而使得不同的客戶訪問不同的伺服器，達到負載均衡的目的。
DNS負載均衡是一種簡單而有效的方法，但是它不能區分伺服器的差異，也不能反映伺服器的當前執行狀態。當使用DNS負載均衡的時候，必須儘量保證不同的
客戶計算機能均勻獲得不同的地址。由於DNS資料具備重新整理時間標誌，一旦超過這個時間限制，其他DNS伺服器就需要和這個伺服器互動，以重新獲得地址數
據，就有可能獲得不同IP地址。因此為了使地址能隨機分配，就應使重新整理時間儘量短，不同地方的DNS伺服器能更新對應的地址，達到隨機獲得地址，然而將過
期時間設定得過短，將使DNS流量大增，而造成額外的網路問題。DNS負載均衡的另一個問題是，一旦某個伺服器出現故障，即使及時修改了DNS設定，還是
要等待足夠的時間（重新整理時間）才能發揮作用，在此期間，儲存了故障伺服器地址的客戶計算機將不能正常訪問伺服器
2、反向代理伺服器
使用代理伺服器，可以將請求轉發給內部的伺服器，使用這種加速模式顯然可以提升靜態網頁的訪問速度。然而，也可以考慮這樣一種技術，使用代理伺服器將請求均勻轉發給多臺伺服器，從而達到負載均衡的目的。
這種代理方式與普通的代理方式有所不同，標準代理方式是客戶使用代理訪問多個外部伺服器，而這種代理方式是代理多個客戶訪問內部伺服器，因此也被稱為反向代理模式。雖然實現這個任務並不算是特別複雜，然而由於要求特別高的效率，實現起來並不簡單。
使用反向代理的好處是，可以將負載均衡和代理伺服器的快取記憶體技術結合在一起，提供有益的效能。然而它本身也存在一些問題，首先就是必須為每一種服務都專門開發一個反向代理伺服器，這就不是一個輕鬆的任務。
代理伺服器本身雖然可以達到很高效率，但是針對每一次代理，代理伺服器就必須維護兩個連線，一個對外的連線，一個對內的連線，因此對於特別高的連線請求，
代理伺服器的負載也就非常之大。反向代理方式下能應用優化的負載均衡策略，每次訪問最空閒的內部伺服器來提供服務。但是隨著併發連線數量的增加，代理服務
器本身的負載也變得非常大，最後反向代理伺服器本身會成為服務的瓶頸。
3、地址轉換閘道器
支援負載均衡的地址轉換閘道器，可以將一個外部IP地址對映為多個內部IP地址，對每次TCP連線請求動態使用其中一個內部地址，達到負載均衡的目的。很多
硬體廠商將這種技術整合在他們的交換機中，作為他們第四層交換的一種功能來實現，一般採用隨機選擇、根據伺服器的連線數量或者響應時間進行選擇的負載均衡
策略來分配負載。由於地址轉換相對來講比較接近網路的低層，因此就有可能將它整合在硬體裝置中，通常這樣的硬體裝置是區域網交換機。
第五章 全域性負載均衡 （GSLB）
負載均衡就是智慧排程
全域性負載均衡（GSLB）的負載均衡主要是在多個節點之間進行均衡，其結果可能直接終結負載均衡過程，也可能將使用者訪問交付下一層次的（區域或本地）負載均衡系統進行處理。GSLB最通用的是基於DNS解析方式，還有HTTP重定向、IP路由等方法
DNS就是IP地址和網址互換
當需要訪問abc.com這個站點時，實際上我們想要瀏覽的網頁內容都存放在網際網路中對應某個IP的伺服器上，而瀏覽器的任務就是找到我們想要訪問的這臺伺服器的IP地址，然後向它請求內容。
本地DNS伺服器（local DNS server）是使用者所在區域網或ISP網路中的域名伺服器。當客戶端在瀏覽器裡請求abc.com時，瀏覽器會首先向本地DNS伺服器請求將 abc.com解析成IP地址，本地DNS伺服器再向整個DNS系統查詢，直到找到解析結果。客戶端可以配置DNS伺服器或通過DHCP來分配
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->域名的對映
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特性，Foundry、Nortel、Cisco和Radware的產品 能實現部分DNS功能
負載均衡作為代理DNS伺服器：負載均衡器被註冊為一個域名空間的權威DNS伺服器，而真正的權威域名伺服器則部署在負 載均衡器後面。所有的DNS請求都會先到達負載均衡器，由負載均衡器轉發到真正的權威DNS伺服器，然後修改權威DNS伺服器返回的響應資訊。真正的權威 DNS伺服器正常響應瀏覽器的DNS請求，返回域名解析結果列表，這個響應會先發送到負載均衡器，而負載均衡器會根據自己的策略選擇一個性能最好的伺服器 IP並修改需要實現GSLB的域名的DNS查詢響應，對其他請求透明轉發，這樣就不會影響整個域名空間的解析效能。
在基於DNS方式下無論採用何 種工作方式，都會有一些請求不會到達GSLB，這是DNS系統本身的快取機制在起作用。當用戶請求的域名在本地DNS或本機（客戶端瀏覽器）得到了解析結 果，這些請求就不會達到GSLB。Cache更新時間越短，使用者請求達到GSLB的機率越大。由於DNS的快取機制遮蔽掉相當一部分使用者請求，從而大大減 輕了GSLB處理壓力，使得系統抗流量衝擊能力顯著提升，這也是很多商業CDN選擇DNS機制做全域性負載均衡的原因之一。但弊端在於，如果在DNS快取刷 新間隔之內系統發生影響使用者服務的變化，比如某個節點故障，某個鏈路擁塞等，使用者依然會被排程到故障部位去
智慧DNS功能，它在向本地DNS返回應答之前會先根據一些靜態或動態策略進行智慧計算。
– 伺服器的“健康狀況”
– 地理區域距離
– 會話保持
– 響應時間
– IP地址權重
– 會話能力閾值
– 往返時間（TTL）
– 其他資訊，包括伺服器當前可用會話數、最少選擇次數、輪詢等
關於GSLB的部署問題
關於內容的快取問題（如何智慧排程最有效）和配置
在有些CDN中（用於視訊網站加速的情況較多），網站需要加速的內容全部先快取在OCS（內容中心），然後再將一部分 （通常是熱門的內容）分發到個POP節點（Cache邊緣叢集），所以POP節點在某些時候會出現本地不命中而需要回OCS取內容或者從其他POP節點取 內容的情況
純粹基於DNS方式的GSLB只能完成就近性判斷。為實現智慧排程，大多數解決方案需要在GSLB裝置附近以旁路的方式 部署一臺輔助裝置（為方便描述，我們可稱之為GRM——全域性資源管理裝置），用以實現和各POP節點的本地資源管理裝置進行通訊，完成CDN對各POP節 點的狀態檢查，並根據POP節點的狀態和流量情況，重新制訂使用者排程策略，將策略實時傳送到GSLB中去執行
因為DNS服務採用以UDP為基礎的、預設無連線的訪問方式，給分散式攻擊（DDoS）帶來了更大的便利。（有DNSSEC可以提供某程度的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系統，這將成為效能和可靠性的瓶頸。（流媒體用的比較多）
基於IP路由的GSLB
基於路由協議演算法選擇一條路由到達這兩個本地均衡器中的一個。因為每次訪問請求的終端IP地址不同，路由條件也不同，所以在多個路由器上優選的路由不同，從統計複用的角度來看基本是在負載均衡器1和2之間均勻分佈的。
IP路由在多個POP點之間實現的負載均衡是一種概率上的均衡，而不是真正的均衡（沒做智慧排程）。
|
比較項 |
基於DNS解析方式 |
基於HTTP重定向方式 |
基於IP路由方式 |
|
效能 |
本地DNS伺服器和使用者終端DNS快取能力使GSLB的負載得到有效分擔 |
GSLB處理壓力大，容易成為系統性能的瓶頸 |
藉助IP網路裝置完成負載均衡，沒有單點效能瓶頸 |
|
準確度 |
定位準確度取決於本地DNS覆蓋範圍，本地DNS設定錯誤會造成定位不準確 |
在對使用者IP地址資料進行有效維護的前提下，定位準確且精度高 |
就近性排程準確，但對裝置健康性等動態資訊響應會有延遲 |
|
效率 |
效率約等於DNS系統本身處理效率 |
依靠伺服器做處理，對硬體資源的要求高 |
效率約等於IP裝置本身效率 |
|
擴充套件性 |
擴充套件性和通用性好 |
擴充套件性較差，需對各種應用協議進行定製開發 |
通用性好，但適用範圍有限 |
|
商用性 |
在Web加速領域使用較多 |
國內流媒體CDN應用較多 |
尚無商用案例 |
第六章 流媒體CDN系統的組成
流媒體業務是一種對實時性、連續性、時序性要求非常高的業務，無論從頻寬消耗上還是質量保障上來說，對best-effort的IP網路都是一個不小的衝擊
– 高頻寬要求
– 高QoS要求
– 組播、廣播要求（目前IP網路無法實現端到端的組播業務）
播放一個視訊分為以下四個步驟
– Access
– Demux（音視訊分離）
– Decode（解碼解壓縮）
– Output
RTP、RTCP、RTSP、RTMP的關係：RTSP協議用來實現遠端播放控制，RTP用來提供時間資訊和實現流同步，RTCP協助RTP完成傳輸質量控制<=（播放控制），
=>（傳輸控制）RTMP和HTTP streaming則是將流同步、播放控制、質量控制整合起來的企業自有流媒體傳送協議
RTMP是adobe的傳輸協議。RTMP的基本通訊單元：訊息塊（chunk）和訊息（message）
RTMP協議架構在TCP層之上，但RTMP訊息並不是直接封裝在TCP中，而是通過一個被稱為訊息塊的封裝單元進行傳輸。訊息在網路上傳送之前往往需要分割成多個較小的部分，這樣較小的部分就是訊息塊，屬於不同訊息流的訊息塊可以在網路上交叉傳送。
RTSP/RTP和HTTP streaming是目前應用最廣泛的流化協議，目前電信運營商在IPTV（特殊通道的基於IP的流媒體播放）的流化上主要以RTSP/RTP技術為主，而網際網路視訊網站（點播/直播）則多傾向於使用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)
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的內容分發策 略
在流媒體服務系統中，主要關注的技術是對不同流媒體協議、不同編碼格式、不同播放器、不同業務質量要求等的適應。
流媒體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方式 |
|
組網 |
多級組網，可能要求組播、單播混合組網 |
兩級組網 |
流媒體CDN的Cache裝置與Web Cache無論在軟體實現還是硬體要求上差異都很大，我們很少看到這兩種業務共用同一臺裝置
當用戶請求的內容在Cache上命中時，Cache直接向用戶提供流服務，此時Cache裝置充當流媒體伺服器的角色； 當用戶請求內容未能在Cache上命中時，Cache會從上一級Cache（二級快取裝置或中間快取裝置）或者源站伺服器獲取內容，再提供給使用者。 Cache在使用者與另一個流媒體伺服器之間扮演代理的角色
分散式儲存技術因其大容量、低成本的特點，目前也被業界關注和研究作為流媒體CDN系統的儲存解決方案之一。常用的分佈 式儲存技術包括分散式檔案系統和分散式資料庫，由於採用了資料副本冗餘（每份資料複製2~3份）、磁碟冗餘（Raid1、Raid10、Raid5）等技 術，通常可以提供良好的資料容錯機制，當單臺儲存裝置斷電或者單個儲存磁碟失效時，整個儲存系統仍能正常工作
負載均衡裝置在進行使用者訪問排程時，會綜合考慮很多靜態的、動態的引數，包括IP就近性、連線保持、內容命中、響應速 度、連線數等。但沒有哪個CDN會考慮所有引數，而是會根據業務特點進行一些取捨，否則均衡系統就太複雜了。而流媒體CDN在進行使用者訪問排程時，會更多 考慮內容命中這一引數
有兩種GSLB實現方式，一種是基於DNS的，一種是基於應用層重定向的
PUSH方式適合內容訪問比較集中的情況，如熱點的影視流媒體內容，PULL方式比較適合內容訪問分散的情況
對使用CDN服務的SP來說，CDN的作用在於儘量就近為使用者提供服務，幫助SP解決長距離IP傳輸和跨域傳輸帶來的種 種業務質量問題（通過空間換取時間）。因此，為使用者提供服務的Cache裝置一定部署在離使用者比較近的地方。另一方面，CDN的建設者從成本角度考慮，又 不能把所有內容都存放在這些離使用者最近的節點中，這會消耗大量儲存成本，所以這些提供服務的Cache裝置會根據需要從源站伺服器或者其他Cache獲取 內容。這樣就形成了CDN網路分層部署的概念。
從網路分層上看，Web CDN通常是兩級架構（也有三級架構以減少回源），即中心-邊緣。而流媒體CDN通常有三級以上架構，即中心-區域-邊緣。產生這種區別的原因在於流媒體 回源成本比較高，源站伺服器響應一次流媒體內容回源請求，要比Web內容回源消耗更多資源。尤其對於流媒體直播業務來說，只要直播節目沒結束，伺服器就需 要長時間持續吐流，如果沒有第二層節點作為中繼，那麼中心節點的壓力將是不可想象的。
分層部署的方式，對點播業務而言的主要意義是節省儲存成本，對直播業務而言在於減少頻寬成本。在點播業務中，邊緣Cache只需儲存使用者訪問量大的內容或者內容片斷，其餘內容儲存在區域Cache中。
在直播業務中，邊緣Cache從區域中心獲取直播流，而不需要直接向中心節點（源站）獲取，從而節省了區域中心到中心節點這一段的大部分頻寬。因為直播流在各個Cache中都不需要佔用很大的儲存空間，只需少量快取空間即可，所以直播業務方面並不用注重考慮儲存成本
考慮到電信運營商的IP拓撲和流量模型，區域中心Cache通常部署在重點城市的都會網路出口的位置，以保障向各個邊緣 Cache的鏈路通暢。邊緣Cache的位置選擇則以整個節點能夠提供的併發能力為主要依據，依據業務併發數收斂比，計算出單個Cache需要覆蓋的使用者 規模，從而選擇一個合適的部署位置。當然，邊緣Cache離使用者越近，服務質量越好，但覆蓋的使用者數越少，部署成本越高。
內容檔案預處理
是指視訊內容進入CDN以後，進入內容分發流程之前，CDN系統對內容進行的一系列處理過程。這個預處理過程的目的有幾個：
– 為全網內容管理提供依據，比如對內容進行全網唯一標識，對內容基礎資訊進行記錄等
– 為提高CDN服務效率或降低系統成本提供手段，比如內容切片
– 為滿足業務要求提供能力，比如對同一內容進行多種位元速率的轉換以滿足動態頻寬自適應或三屏互動業務要求
視訊轉碼(video transcoding)
– 位元速率轉換
– 空間解析度轉換
– 時間解析度轉換
– 編碼格式轉換。編碼格式主要包括H.264、MPEG-4、MPEG-2、VC-1、REAL、H.263、WMV。通常是把其他編碼格式轉換成H.264
檔案切片
是指按照一定的規則把一個完整的檔案切成大小一致的若干個小檔案；由於流媒體CDN需要提供的內容體積越來越大，傳統整片儲存帶來的成本消耗超出了CDN服務商的承受範圍；切片的另一個目的是，使邊緣Cache能夠支援自適應位元速率業務
防盜鏈機制和實現
– 基於IP的黑白名單
– 利用HTTP header的referer欄位
– 使用動態金鑰（隨機生成的key通過演算法生成新的url）
– 在內容中插入資料（對有版權內容進行加密（DRM），如Microsoft的playready，Google的Widevine）
– 打包下載：在原檔案的基礎上進一步封裝，使得資源的hash 值改變
–
第七章 動態內容加速服務的實現
隨著Web2.0的興起，產生了動態網頁、個性化內容、電子交易資料等內容的加速，這些就涉及了動態內容加速技術。
靜態內容的加速，都是對於表現層的加速，對於動態頁面等內容的加速，則要涉及邏輯層和資料訪問層的加速技術
動態內容的提供不僅僅是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系統使用者檔案的複製。
（PS：暫時來說，網宿還沒有實現真正意義的動態加速，雖然現在已經實現一部分，如搜尋結果動態快取，重用的動態頁面智慧快取。其他更多的是通過智慧管道來加快使用者與源鑽的訪問效率）
（應用加速技術實際上是傳統的網路負載均衡的升級和擴充套件，綜合使用了負載均衡（智慧排程）、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視窗、響應、啟動等機制進行改進，從而提高協議機制的效率 |
|
|
應用層 |
應用代理（快取） |
將常用的應用程式快取在本地並配 |