本文轉載網址：https://www.cnblogs.com/tinywan/p/6067131.html
一本好的入門書是帶你進入陌生領域的明燈，《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叢集是由多個同時運作同一個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節點相同的内容做起來不難，是以選擇負載均衡政策（算法）是個關鍵問題。下面會專門介紹均衡算法。
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的實作原理，讓我們先看傳統的未加緩存服務的通路過程，以便了解CDN緩存通路方式與未加緩存通路方式的差别：
使用者送出域名→浏覽器對域名進行解釋→得到目的主機的IP位址→根據IP位址通路送出請求→得到請求資料并回複
由上可見，使用者通路未使用CDN緩存網站的過程為:
1)、使用者向浏覽器提供要通路的域名；
2)、浏覽器調用域名解析函數庫對域名進行解析，以得到此域名對應的IP位址；
3)、浏覽器使用所得到的IP位址，向域名的服務主機發出資料通路請求；
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第四章WEB 叢集與負載均衡基本概念來源：http://blog.csdn.net/lovingprince/article/details/3290916
CDN詳解來源：http://zsvalue.com/201405/foundation-of-cdn-%e3%80%8acdn%e6%8a%80%e6%9c%af%e8%af%a6%e8%a7%a3%e3%80%8bnote/
CDN原理實作來源：http://www.cnblogs.com/rayray/p/3553696.html