一本好的入門書是帶你進入陌生領域的明燈，《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窗口、響應、啓動等機制進行改進，從而提高協議機制的效率 |
|
|
應用層 |
應用代理（緩存） |
將常用的應用程序緩存在本地並配置好，用戶可不用在本地等待類似於認證等會話過程，而是直接開始下一個應用，實現流水作業 |
數據碎片化，就是在應用層將數據分成一個個小的數據塊，便於後續的數據比對使用。廣域網加速設備在傳輸數據前會將緩存中的數據與數據切塊進行對比，從而找出那些數據是重複數據，不再發送，哪些數據是新鮮的、需要傳輸的數據。
數據壓縮和指針技術一般是放在一起使用的，在對數據分段後，會對每一段數據生成一個數據指針，對於重複內容，只傳輸指針。在壓縮算法設計上，要求同時兼顧數據壓縮比和壓縮/解壓縮時間。
高速TCP傳輸技術
– 自適應擁塞窗口
– 有限制地快速重傳
– 連接池：通過維護一個預先建立好的TCP連接池，當有數據傳輸需求時，從連接池中挑選一條可用連接今次那個傳輸。
SSL加速技術
– SSL加密是一種處理器密集型加密算法，如果用服務器軟件處理會消耗大量CPU資源，一般會在提供業務能力的服務器外圍部署專門的SSL加速設備，採用硬解密方式實現
– SSL加密分對稱祕鑰和非對稱祕鑰（計算資源消耗更大）
SSL的基本原理和實現
– 可認證性（authentication）
– 隱私性（privacy）
– 完整性（integrity）
– 不可抵賴性（undeniability）：發送者不能自稱沒有發出過接受者從他那裏收到的內容
SSL加速
– 通常是基於硬件的SSL加速
– 通過在服務器上安裝一塊SSL加速板卡，可有效分擔服務器CPU處理SSL事務的壓力
CDN的實現原理
流程圖
CDN第四章WEB 集羣與負載均衡基本概念來源：http://blog.csdn.net/lovingprince/article/details/3290916
CDN原理實現來源：http://www.cnblogs.com/rayray/p/3553696.html