一本好的入門書是帶你進入陌生領(lǐng)域的明燈，《CDN技術(shù)詳解》絕對是帶你進入CDN行業(yè)的那盞最亮的明燈。因此，雖然只是純粹的重點抄錄，我也要把《CDN技術(shù)詳解》的精華放上網(wǎng)。公諸同好。
第一章 引言
“第一公里”是指萬維網(wǎng)流量向用戶傳送的第一個出口，是網(wǎng)站服務器接入互聯(lián)網(wǎng)的鏈路所能提供的帶寬。這個帶寬決定了一個網(wǎng)站能為用戶提供的訪問速度和并發(fā)訪問量。如果業(yè)務繁忙，用戶的訪問數(shù)越多，擁塞越嚴重，網(wǎng)站會在最需要向用戶提供服務時失去用戶。（還有“中間一公里”和“最后一公里”分別代表互聯(lián)網(wǎng)傳輸傳輸和萬維網(wǎng)流量向用戶傳送的最后一段接入鏈路）
從互聯(lián)網(wǎng)的架構(gòu)來看，不同網(wǎng)絡(luò)之間的互聯(lián)互通帶寬，對任何一個運營商網(wǎng)絡(luò)的流量來說，占比都比較小，收斂比是非常高的，因此這里通常都是互聯(lián)網(wǎng)傳輸中的擁堵點（運營商互聯(lián)互通的問題）
其次是骨干網(wǎng)堵塞問題，由于互聯(lián)網(wǎng)上的絕大部分流量都要通過骨干網(wǎng)絡(luò)進行傳輸，這就要求骨干網(wǎng)絡(luò)的承載能力必須與互聯(lián)網(wǎng)的應用同步發(fā)展，但實際上兩者并不是同步的，當骨干網(wǎng)絡(luò)的升級和擴容滯后于互聯(lián)網(wǎng)之上的應用的發(fā)展時，就會階段性地使得大型骨干網(wǎng)的承載能力成為影響互聯(lián)網(wǎng)性能的瓶頸（區(qū)域互聯(lián)互通問題，骨干網(wǎng)帶寬瓶頸）
在互聯(lián)網(wǎng)領(lǐng)域有一個“8秒定律”，用戶訪問一個網(wǎng)站時，如果等待網(wǎng)頁打開的時間超過8秒，會有超過30%的用戶放棄等待
使用CDN會極大簡化網(wǎng)站的系統(tǒng)維護工作量，網(wǎng)站維護人員只需將網(wǎng)站內(nèi)容注入CDN的系統(tǒng)，通過CDN部署在各個物理位置的服務器進行全網(wǎng)分發(fā)，就可以實現(xiàn)跨運營商、跨地域的用戶覆蓋
對于電信運營商，CDN是真正體現(xiàn)管道智能化的技術(shù)
第二章 CDN技術(shù)概述
CDN關(guān)鍵技術(shù)：
1. 緩存算法[Squid]；2. 分發(fā)能力；3. 負載均衡[Nginx]（4. 基于DNS[BIND]）；5. 支持協(xié)議；
緩存算法決定命中率、源服務器壓力、POP節(jié)點存儲能力
分發(fā)能力取決于IDC能力和IDC策略性分布
負載均衡（智能調(diào)度）決定最佳路由、響應時間、可用性、服務質(zhì)量
基于DNS的負載均衡以CNAME實現(xiàn)[to cluster]，智取最優(yōu)節(jié)點服務，
緩存點有客戶端瀏覽器緩存、本地DNS服務器緩存
緩存內(nèi)容有DNS地址緩存、客戶請求內(nèi)容緩存、動態(tài)內(nèi)容緩存
支持協(xié)議如靜動態(tài)加速（圖片加速、https帶證書加速）、下載加速、流媒體加速、企業(yè)應用加速、手機應用加速
CDN提供一種機制，當用戶請求內(nèi)容時，該內(nèi)容能夠由以最快速度交付的Cache來向用戶提供，這個挑選“最優(yōu)”的過程就叫做負載均衡
從功能上看，典型的CDN系統(tǒng)由分發(fā)服務系統(tǒng)，負載均衡系統(tǒng)和運營管理系統(tǒng)組成
– 分發(fā)服務系統(tǒng)：最基本的工作單元就是Cache設(shè)備，cache（邊緣cache）負責直接響應最終用戶的訪問請求，把緩存在本地的內(nèi)容快速地提供給用戶。同時cache還負責與源站點進行內(nèi)容同步，把更新的內(nèi)容以及本地沒有的內(nèi)容從源站點獲取并保存在本地。Cache設(shè)備的數(shù)量、規(guī)模、總服務能力是衡量一個CDN系統(tǒng)服務能力的最基本的指標
– 負載均衡系統(tǒng)：主要功能是負責對所有發(fā)起服務請求的用戶進行訪問調(diào)度，確定提供給用戶的最終實際訪問地址。兩級調(diào)度體系分為全局負載均衡（GSLB）和本地負載均衡（SLB）。GSLB主要根據(jù)用戶就近性原則，通過對每個服務節(jié)點進行“最優(yōu)”判斷，確定向用戶提供服務的cache的物理位置。SLB主要負責節(jié)點內(nèi)部的設(shè)備負載均衡
– 運營管理系統(tǒng)：分為運營管理和網(wǎng)絡(luò)管理子系統(tǒng)，負責處理業(yè)務層面的與外界系統(tǒng)交互所必須的收集、整理、交付工作，包含客戶管理、產(chǎn)品管理、計費管理、統(tǒng)計分析等功能。
負責為用戶提供內(nèi)容服務的cache設(shè)備應部署在物理上的網(wǎng)絡(luò)邊緣位置，即CDN邊緣層。CDN系統(tǒng)中負責全局性管理和控制的設(shè)備組成中心層（二級緩存），中心層同時保存著最多的內(nèi)容副本，當邊緣層設(shè)備未命中時，會向中心層請求，如果在中心層仍未命中，則需要中心層向源站回源（如果是流媒體，代價很大）
CDN骨干點和CDN POP點在功能上不同，中心和區(qū)域節(jié)點一般稱為骨干點，主要作為內(nèi)容分發(fā)和邊緣未命中時的服務點；邊緣節(jié)點又被稱為POP（point of presence）節(jié)點，CDN POP點主要作為直接向用戶提供服務的節(jié)點
應用協(xié)議加速：企業(yè)應用加速主要是動態(tài)加速和SSL加速
廣域網(wǎng)應用加速：
SSL應用加速：由于需要大量的加密解密運算，SSL應用對服務器端的資源消耗是非常巨大的。CDN提供SSL應用加速后，由CDN的專用SSL加速硬件來完成加密解密運算工作
網(wǎng)頁壓縮：HTTP1.1提出對網(wǎng)頁壓縮的支持。在服務器端可以先對網(wǎng)頁數(shù)據(jù)進行壓縮，然后將壓縮后的文件提供給訪問用戶，最后在用戶瀏覽器端解壓顯示（但要衡量加解壓時間）
第三章 內(nèi)容緩存工作原理
有CDN前的網(wǎng)站服務技術(shù)
– 硬件擴展：高成本，靈活性和可擴展性比較差
– 鏡像技術(shù)（mirroring）：鏡像服務器安裝有一個可以進行自動遠程備份的軟件，每隔一定時間，各個鏡像服務器就會到網(wǎng)站的源服務器上去獲取最新的內(nèi)容
– 緩存技術(shù)（caching）：緩存代理緩存被訪問過的內(nèi)容，后續(xù)的相同內(nèi)容訪問直接通過緩存代理獲得服務
– CDN：是緩存技術(shù)的基礎(chǔ)上發(fā)展起來的，是緩存的分布式集群實現(xiàn)
從技術(shù)層面看，Web架構(gòu)的精華有三處：
– 超文本技術(shù)HTML實現(xiàn)信息與信息的連接；
– 統(tǒng)一資源標志符URI實現(xiàn)全球信息的精確定位
– 應用層協(xié)議HTTP實現(xiàn)分布式的信息共享
TCP連接在每一次HTTP（HTTP 1.0）請求和響應完成后就關(guān)閉，如果客戶端還要請求其他對象，需要重新為每個對象建立TCP連接。當一個Web頁面內(nèi)包含多個對象并全部顯示時，客戶端需要與服務器建立的TCP連接數(shù)較多，對整個時延和網(wǎng)絡(luò)流量造成了較大的影響
HTTP1.1采用了效率更高的持續(xù)連接機制，即客戶端和服務器端建立TCP連接后，后續(xù)相關(guān)聯(lián)的HTTP請求可以重復利用已經(jīng)建立起來的TCP連接，不僅整個Web頁面（包括基本的HTML文件和其他對象）可以使用這個持續(xù)的TCP連接來完成HTTP請求和響應，而且同一個服務器內(nèi)的多個Web頁面也可以通過同一個持續(xù)TCP連接來請求和響應。通常情況下，這個持續(xù)的TCP連接會在空閑一段特定的時間后關(guān)閉，而這個最大空閑時間時可以設(shè)置的（連接復用）。
HTTP協(xié)議中的緩存技術(shù)：新鮮度（時間值）和驗證（驗證信息如ETag或last-modified）時確定內(nèi)容可否直接提供服務的最重要依據(jù)。如果緩存內(nèi)容足夠新鮮，緩存的內(nèi)容就能直接滿足HTTP訪問的需求了；如果內(nèi)容過期，而經(jīng)源服務器驗證后發(fā)現(xiàn)內(nèi)容沒有發(fā)生變化，緩存服務器也會避免將內(nèi)容從源服務器重新傳輸一遍
如果要通過META標簽來控制頁面不緩存，一般情況下會在Web頁面的<head>區(qū)域中增加”pragma:no-cache”
驗證的目的就是檢驗緩存內(nèi)容是否可用。當中間緩存存在一個過期的緩存內(nèi)容，并且對應的訪問請求到達時，緩存應該首先向源服務器或者其他保存有未過期的緩存服務器請求驗證來確定本地的緩存內(nèi)容是否可用。（緩存內(nèi)容過期，但源服務器沒有更新內(nèi)容，即緩存內(nèi)容仍可用）
HTTP1.1介紹了cache-control顯示指令來讓網(wǎng)站發(fā)布者可以更全面地控制他們的內(nèi)容，并對過期時間進行限制（控制是否緩存，怎么緩存）
HTTP gzip壓縮：大多數(shù)情況需要壓縮的文件時網(wǎng)頁中出現(xiàn)最頻繁的HTML、CSS、javascript、XML等文件，這類本身是沒有經(jīng)過壓縮的文本文件，可以取得較好的壓縮效果
Web緩存代理軟件：Squid
負載均衡軟件：Nginx
DNS服務器軟件：BIND
第四章 集群服務與負載均衡
Web集群是由多個同時運行同一個web應用的服務器組成，在外界看來就像一個服務器一樣，這多臺服務器共同來為客戶提供更高性能的服務。集群更標準的定 義是：一組相互獨立的服務器在網(wǎng)絡(luò)中表現(xiàn)為單一的系統(tǒng)，并以單一系統(tǒng)的模式加以管理，此單一系統(tǒng)為客戶工作站提供高可靠性的服務。
而負載均衡的任務就是負責多個服務器之間（集群內(nèi)）實現(xiàn)合理的任務分配，使這些服務器（集群）不會出現(xiàn)因某一臺超負荷、而其他的服務器卻沒有充分發(fā)揮處理能力的情況。負載均衡有兩個方面的含義：首先，把大量的并發(fā)訪問或數(shù)據(jù)流量分擔到多臺節(jié)點上分別處理，減少用戶等待響應的時間；其次，單個高負載的運算分擔到多臺節(jié)點上做并行處理，每個節(jié)點設(shè)備處理結(jié)束后，將結(jié)果匯總，再返回給用戶，使得信息系統(tǒng)處理能力可以得到大幅度提高
因此可以看出，集群和負載均衡有本質(zhì)上的不同，它們是解決兩方面問題的不同方案，不要混淆。
集群技術(shù)可以分為三大類：
1、高性能性集群(HPC Cluster)
2、高可用性集群(HA Cluster)
3、高可擴展性集群
一、高性能性集群(HPC Cluster)
指以提高科學計算能力為目標的集群技術(shù)。該集群技術(shù)主要用于科學計算，這里不打算介紹，如果感興趣可以參考相關(guān)的資料。
二、高可用性集群(HA Cluster)
指為了使群集的整體服務盡可能可用，減少服務宕機時間為目的的集群技術(shù)。如果高可用性集群中的某節(jié)點發(fā)生了故障，那么這段時間內(nèi)將由其他節(jié)點代替它的工作。當然對于其他節(jié)點來講，負載相應的就增加了。
為了提高整個系統(tǒng)的可用性，除了提高計算機各個部件的可靠性以外，一般情況下都會采用該集群的方案。
對于該集群方案，一般會有兩種工作方式：
①主-主(Active-Active)工作方式
這是最常用的集群模型，它提供了高可用性，并且在只有一個節(jié)點時也能提供可以接受的性能，該模型允許最大程度的利用硬件資源。每個節(jié)點都通過網(wǎng)絡(luò)對客戶機提供資源，每個節(jié)點的容量被定義好，使得性能達到最優(yōu)，并且每個節(jié)點都可以在故障轉(zhuǎn)移時臨時接管另一個節(jié)點的工作。所有的服務在故障轉(zhuǎn)移后仍保持可用，但是性能通常都會下降。
這是目前運用最為廣泛的雙節(jié)點雙應用的Active/Active模式。
支撐用戶業(yè)務的應用程序在正常狀態(tài)下分別在兩臺節(jié)點上運行，各自有自己的資源，比如IP地址、磁盤陣列上的卷或者文件系統(tǒng)。當某一方的系統(tǒng)或者資源出現(xiàn)故障時，就會將應用和相關(guān)資源切換到對方的節(jié)點上。
這種模式的最大優(yōu)點是不會有服務器的“閑置”，兩臺服務器在正常情況下都在工作。但如果有故障發(fā)生導致切換，應用將放在同一臺服務器上運行，由于服務器的處理能力有可能不能同時滿足數(shù)據(jù)庫和應用程序的峰值要求，這將會出現(xiàn)處理能力不夠的情況，降低業(yè)務響應水平。
②主-從(Active-Standby)工作方式
為了提供最大的可用性，以及對性能最小的影響，主-從工作方式需要一個在正常工作時處于備用狀態(tài)的節(jié)點，主節(jié)點處理客戶機的請求，而備用節(jié)點處于空閑狀態(tài)，當主節(jié)點出現(xiàn)故障時，備用節(jié)點會接管主節(jié)點的工作，繼續(xù)為客戶機提供服務，并且不會有任何性能上影響。
兩節(jié)點的Active/Standby模式是HA中最簡單的一種，兩臺服務器通過雙心跳線路組成一個集群。應用Application聯(lián)合各個可選的系統(tǒng)組件如：外置共享的磁盤陣列、文件系統(tǒng)和浮動IP地址等組成業(yè)務運行環(huán)境。
PCL為此環(huán)境提供了完全冗余的服務器配置。這種模式的優(yōu)缺點：
三、高可擴展性集群
這里指帶有負載均衡策略（算法）的服務器群集技術(shù)。帶負載均衡集群為企業(yè)需求提供了更實用的方案，它使負載可以在計算機集群中盡可能平均地分攤處理。而需要均衡的可能是應用程序處理負載或是網(wǎng)絡(luò)流量負載。該方案非常適合于運行同一組應用程序的節(jié)點。每個節(jié)點都可以處理一部分負載，并且可以在節(jié)點之間動態(tài)分配負載，以實現(xiàn)平衡。對于網(wǎng)絡(luò)流量也是如此。通常，單個節(jié)點對于太大的網(wǎng)絡(luò)流量無法迅速處理，這就需要將流量發(fā)送給在其它節(jié)點。還可以根據(jù)每個節(jié)點上不同的可用資源或網(wǎng)絡(luò)的特殊環(huán)境來進行優(yōu)化。
負載均衡集群在多節(jié)點之間按照一定的策略（算法）分發(fā)網(wǎng)絡(luò)或計算處理負載。負載均衡建立在現(xiàn)有網(wǎng)絡(luò)結(jié)構(gòu)之上，它提供了一種廉價有效的方法來擴展服務器帶寬，增加吞吐量，提高數(shù)據(jù)處理能力，同時又可以避免單點故障。
前面已經(jīng)說過負載均衡的作用是在多個節(jié)點之間按照一定的策略（算法）分發(fā)網(wǎng)絡(luò)或計算處理負載。負載均衡可以采用軟件和硬件來實現(xiàn)。一般的框架結(jié)構(gòu)可以參考下圖。
后臺的多個Web節(jié)點上面有相同的Web應用，用戶的訪問請求首先進入負載均衡分配節(jié)點(可能是軟件或者硬件)，由它根據(jù)負載均衡策略（算法）合理地分配給某個Web應用節(jié)點。每個Web節(jié)點相同的內(nèi)容做起來不難，所以選擇負載均衡策略（算法）是個關(guān)鍵問題。下面會專門介紹均衡算法。
web負載均衡的作用就是把請求均勻的分配給各個節(jié)點，它是一種動態(tài)均衡，通過一些工具實時地分析數(shù)據(jù)包，掌握網(wǎng)絡(luò)中的數(shù)據(jù)流量狀況，把請求理分配出去。對于不同的應用環(huán)境（如電子商務網(wǎng)站，它的計 算負荷大；再如網(wǎng)絡(luò)數(shù)據(jù)庫應用，讀寫頻繁，服務器的存儲子系統(tǒng)系統(tǒng)面臨很大壓力；再如視頻服務應用，數(shù)據(jù)傳輸量大，網(wǎng)絡(luò)接口負擔重壓。），使用的均衡策略(算法)是不同的。 所以均衡策略（算法）也就有了多種多樣的形式，廣義上的負載均衡既可以設(shè)置專門的網(wǎng)關(guān)、負載均衡器，也可以通過一些專用軟件與協(xié)議來實現(xiàn)。在OSI七層協(xié)議模型中的第二（數(shù)據(jù)鏈路層）、第三（網(wǎng)絡(luò)層）、第四（傳輸層）、第七層（應用層）都有相應的負載均衡策略（算法），在數(shù)據(jù)鏈路層上實現(xiàn)負載均衡的原理是根據(jù)數(shù)據(jù)包的目的MAC地址選擇不同的路徑；在網(wǎng)絡(luò)層上可利用基于IP地址的分配方式將數(shù)據(jù)流疏通到多個節(jié)點；而傳輸層和應用層的交換（Switch），本身便是一種基于訪問流量的控制方式，能夠?qū)崿F(xiàn)負載均衡。
目前，基于負載均衡的算法主要有三種：輪循（Round-Robin）、最小連接數(shù)（Least Connections First），和快速響應優(yōu)先（Faster Response Precedence）。
①輪循算法，就是將來自網(wǎng)絡(luò)的請求依次分配給集群中的節(jié)點進行處理。
②最小連接數(shù)算法，就是為集群中的每臺服務器設(shè)置一個記數(shù)器，記錄每個服務器當前的連接數(shù)，負載均衡系統(tǒng)總是選擇當前連接數(shù)最少的服務器分配任務。 這要比"輪循算法"好很多，因為在有些場合中，簡單的輪循不能判斷哪個節(jié)點的負載更低，也許新的工作又被分配給了一個已經(jīng)很忙的服務器了。
③快速響應優(yōu)先算法，是根據(jù)群集中的節(jié)點的狀態(tài)（CPU、內(nèi)存等主要處理部分）來分配任務。 這一點很難做到，事實上到目前為止，采用這個算法的負載均衡系統(tǒng)還很少。尤其對于硬件負載均衡設(shè)備來說，只能在TCP/IP協(xié)議方面做工作，幾乎不可能深入到服務器的處理系統(tǒng)中進行監(jiān)測。但是它是未來發(fā)展的方向。
上面是負載均衡常用的算法，基于以上負載均衡算法的使用方式上，又分為如下幾種：
1、DNS輪詢
最早的負載均衡技術(shù)是通過DNS來實現(xiàn)的，在DNS中為多個地址配置同一個名字，因而查詢這個名字的客戶機將得到其中一個地址，從而使得不同的客戶訪問不同的服務器，達到負載均衡的目的。
DNS負載均衡是一種簡單而有效的方法，但是它不能區(qū)分服務器的差異，也不能反映服務器的當前運行狀態(tài)。當使用DNS負載均衡的時候，必須盡量保證不同的客戶計算機能均勻獲得不同的地址。由于DNS數(shù)據(jù)具備刷新時間標志，一旦超過這個時間限制，其他DNS服務器就需要和這個服務器交互，以重新獲得地址數(shù)據(jù)，就有可能獲得不同IP地址。因此為了使地址能隨機分配，就應使刷新時間盡量短，不同地方的DNS服務器能更新對應的地址，達到隨機獲得地址，然而將過期時間設(shè)置得過短，將使DNS流量大增，而造成額外的網(wǎng)絡(luò)問題。DNS負載均衡的另一個問題是，一旦某個服務器出現(xiàn)故障，即使及時修改了DNS設(shè)置，還是要等待足夠的時間（刷新時間）才能發(fā)揮作用，在此期間，保存了故障服務器地址的客戶計算機將不能正常訪問服務器
2、反向代理服務器
使用代理服務器，可以將請求轉(zhuǎn)發(fā)給內(nèi)部的服務器，使用這種加速模式顯然可以提升靜態(tài)網(wǎng)頁的訪問速度。然而，也可以考慮這樣一種技術(shù)，使用代理服務器將請求均勻轉(zhuǎn)發(fā)給多臺服務器，從而達到負載均衡的目的。
這種代理方式與普通的代理方式有所不同，標準代理方式是客戶使用代理訪問多個外部服務器，而這種代理方式是代理多個客戶訪問內(nèi)部服務器，因此也被稱為反向代理模式。雖然實現(xiàn)這個任務并不算是特別復雜，然而由于要求特別高的效率，實現(xiàn)起來并不簡單。
使用反向代理的好處是，可以將負載均衡和代理服務器的高速緩存技術(shù)結(jié)合在一起，提供有益的性能。然而它本身也存在一些問題，首先就是必須為每一種服務都專門開發(fā)一個反向代理服務器，這就不是一個輕松的任務。
代理服務器本身雖然可以達到很高效率，但是針對每一次代理，代理服務器就必須維護兩個連接，一個對外的連接，一個對內(nèi)的連接，因此對于特別高的連接請求，代理服務器的負載也就非常之大。反向代理方式下能應用優(yōu)化的負載均衡策略，每次訪問最空閑的內(nèi)部服務器來提供服務。但是隨著并發(fā)連接數(shù)量的增加，代理服務器本身的負載也變得非常大，最后反向代理服務器本身會成為服務的瓶頸。
3、地址轉(zhuǎn)換網(wǎng)關(guān)
支持負載均衡的地址轉(zhuǎn)換網(wǎng)關(guān)，可以將一個外部IP地址映射為多個內(nèi)部IP地址，對每次TCP連接請求動態(tài)使用其中一個內(nèi)部地址，達到負載均衡的目的。很多硬件廠商將這種技術(shù)集成在他們的交換機中，作為他們第四層交換的一種功能來實現(xiàn)，一般采用隨機選擇、根據(jù)服務器的連接數(shù)量或者響應時間進行選擇的負載均衡策略來分配負載。由于地址轉(zhuǎn)換相對來講比較接近網(wǎng)絡(luò)的低層，因此就有可能將它集成在硬件設(shè)備中，通常這樣的硬件設(shè)備是局域網(wǎng)交換機。
第五章 全局負載均衡 （GSLB）
負載均衡就是智能調(diào)度
全局負載均衡（GSLB）的負載均衡主要是在多個節(jié)點之間進行均衡，其結(jié)果可能直接終結(jié)負載均衡過程，也可能將用戶訪問交付下一層次的（區(qū)域或本地）負載均衡系統(tǒng)進行處理。GSLB最通用的是基于DNS解析方式，還有HTTP重定向、IP路由等方法
DNS就是IP地址和網(wǎng)址互換
當需要訪問abc.com這個站點時，實際上我們想要瀏覽的網(wǎng)頁內(nèi)容都存放在互聯(lián)網(wǎng)中對應某個IP的服務器上，而瀏覽器的任務就是找到我們想要訪問的這臺服務器的IP地址，然后向它請求內(nèi)容。
本地DNS服務器（local DNS server）是用戶所在局域網(wǎng)或ISP網(wǎng)絡(luò)中的域名服務器。當客戶端在瀏覽器里請求abc.com時，瀏覽器會首先向本地DNS服務器請求將abc.com解析成IP地址，本地DNS服務器再向整個DNS系統(tǒng)查詢，直到找到解析結(jié)果?？蛻舳丝梢耘渲肈NS服務器或通過DHCP來分配
DNS給使用它的互聯(lián)網(wǎng)應用帶來額外的時延，有時時延還比較大，為了解決問題，需要引入“緩存”機制。緩存是指DNS查詢結(jié)果在主機（local DNS server）中緩存。在區(qū)內(nèi)主機對某個域名發(fā)起第一次查詢請求時，負責處理遞歸查詢的DNS服務器要發(fā)送好幾次查詢（先查.root，再查.com之類，再定位IP地址等）才能找到結(jié)果，不過在這過程中它也得到了許多信息，比如各區(qū)域權(quán)威DNS服務器（就是告訴你最終abc.com在哪里的DNS服務器）和它們的地址、域名解析最終結(jié)果。他會把這些信息保存起來，當其他主機向它發(fā)起查詢請求時，它就直接向主機返回緩存中能夠找到的結(jié)果，直到數(shù)據(jù)過期。
客戶端瀏覽器也可以緩存DNS響應信息。
Internet類資源記錄分為
– A記錄（address）：域名->多個IP的映射。對同一個域名，可以有多條A記錄
– NS記錄（name server）：指定由哪臺DNS服務器來解析
– SOA記錄（start of authority）：指定該區(qū)域的權(quán)威域名服務器
– CNAME記錄（canonical name）：多個域名->服務器的映射
– PTR記錄（pointer record）：IP->域名的映射
DNS系統(tǒng)本身是具備簡單負載分配能力的，這是基于DNS的輪詢機制。如果有多臺Web服務器（多源）同時為站點abc.com提供服務，abc.com的權(quán)威服務器可能會解析出一個或多個IP地址。權(quán)威域名服務器還可以調(diào)整響應中IP地址的排列方式，即在每次響應中將不同的IP地址置于首位（取決于可服務能力和服務質(zhì)量），通過這種方式實現(xiàn)對這些Web服務器的負載均衡
通過CNAME方式實現(xiàn)負載均衡：域名服務器獲得CNAME記錄后，就會用記錄中的別名來替換查找的域名或主機名（實現(xiàn)多個域名->服務器映射）。后面會查詢這個別名的A記錄來獲取相應的IP地址。
具體操作為：先將GSLB的主機名定義為所查詢域名的權(quán)威DNS服務器的別名，然后將GSLB主機名添加多條A記錄，分別對應多個服務器的IP地址。這樣，本地DNS服務器會向客戶端返回多個IP地址作為域名的查詢結(jié)果，并且這些IP地址的排列順序是輪換的。客戶端一般會選擇首個IP地址進行訪問
負載均衡器作為權(quán)威DNS服務器：負載均衡器就會接收所有對這個域名的DNS請求，從而能夠根據(jù)預先設(shè)置的一些策略來提供對域名的智能DNS解析。F5的DNS具有完整的DNS功能以及增強的GSLB特性，F(xiàn)oundry、Nortel、Cisco和Radware的產(chǎn)品能實現(xiàn)部分DNS功能
負載均衡作為代理DNS服務器：負載均衡器被注冊為一個域名空間的權(quán)威DNS服務器，而真正的權(quán)威域名服務器則部署在負載均衡器后面。所有的DNS請求都會先到達負載均衡器，由負載均衡器轉(zhuǎn)發(fā)到真正的權(quán)威DNS服務器，然后修改權(quán)威DNS服務器返回的響應信息。真正的權(quán)威DNS服務器正常響應瀏覽器的DNS請求，返回域名解析結(jié)果列表，這個響應會先發(fā)送到負載均衡器，而負載均衡器會根據(jù)自己的策略選擇一個性能最好的服務器IP并修改需要實現(xiàn)GSLB的域名的DNS查詢響應，對其他請求透明轉(zhuǎn)發(fā)，這樣就不會影響整個域名空間的解析性能。
在基于DNS方式下無論采用何種工作方式，都會有一些請求不會到達GSLB，這是DNS系統(tǒng)本身的緩存機制在起作用。當用戶請求的域名在本地DNS或本機（客戶端瀏覽器）得到了解析結(jié)果，這些請求就不會達到GSLB。Cache更新時間越短，用戶請求達到GSLB的幾率越大。由于DNS的緩存機制屏蔽掉相當一部分用戶請求，從而大大減輕了GSLB處理壓力，使得系統(tǒng)抗流量沖擊能力顯著提升，這也是很多商業(yè)CDN選擇DNS機制做全局負載均衡的原因之一。但弊端在于，如果在DNS緩存刷新間隔之內(nèi)系統(tǒng)發(fā)生影響用戶服務的變化，比如某個節(jié)點故障，某個鏈路擁塞等，用戶依然會被調(diào)度到故障部位去
智能DNS功能，它在向本地DNS返回應答之前會先根據(jù)一些靜態(tài)或動態(tài)策略進行智能計算。
– 服務器的“健康狀況”
– 地理區(qū)域距離
– 會話保持
– 響應時間
– IP地址權(quán)重
– 會話能力閾值
– 往返時間（TTL）
– 其他信息，包括服務器當前可用會話數(shù)、最少選擇次數(shù)、輪詢等
關(guān)于GSLB的部署問題
關(guān)于內(nèi)容的緩存問題（如何智能調(diào)度最有效）和配置
在有些CDN中（用于視頻網(wǎng)站加速的情況較多），網(wǎng)站需要加速的內(nèi)容全部先緩存在OCS（內(nèi)容中心），然后再將一部分（通常是熱門的內(nèi)容）分發(fā)到個POP節(jié)點（Cache邊緣集群），所以POP節(jié)點在某些時候會出現(xiàn)本地不命中而需要回OCS取內(nèi)容或者從其他POP節(jié)點取內(nèi)容的情況
純粹基于DNS方式的GSLB只能完成就近性判斷。為實現(xiàn)智能調(diào)度，大多數(shù)解決方案需要在GSLB設(shè)備附近以旁路的方式部署一臺輔助設(shè)備（為方便描述，我們可稱之為GRM——全局資源管理設(shè)備），用以實現(xiàn)和各POP節(jié)點的本地資源管理設(shè)備進行通信，完成CDN對各POP節(jié)點的狀態(tài)檢查，并根據(jù)POP節(jié)點的狀態(tài)和流量情況，重新制訂用戶調(diào)度策略，將策略實時發(fā)送到GSLB中去執(zhí)行
因為DNS服務采用以UDP為基礎(chǔ)的、默認無連接的訪問方式，給分布式攻擊（DDoS）帶來了更大的便利。（有DNSSEC可以提供某程度的DDoS攻擊保護）
隱藏節(jié)點的存在很大程度上可以避免GSLB被攻擊致癱瘓的機會，實際隱藏節(jié)點的實現(xiàn)方法就是在實際組網(wǎng)時除了部署正常工作的GSLB以外，再部署一臺備份的GSLB設(shè)備，并將這一備份GSLB設(shè)備隱藏起來，不對外公布。
HTTP重定向（CDN GSLB用302重定向）：在HTTP協(xié)議中，有三類重定向狀態(tài)嗎：301永久性轉(zhuǎn)移（permanently moved）、302暫時轉(zhuǎn)移（temporarily moved）、meta fresh在特定時間后重定向到新的網(wǎng)頁
HTTP重定向只適用于HTTP應用，不適用于任何其他應用。比如微軟的MMS協(xié)議，RTSP協(xié)議，就不能使用這種方式進行重定向。其次，由于HTTP重定向過程需要額外解析域名URL，還需要與URL建立TCP連接并且發(fā)送HTTP請求，使得響應時間加長。第三，不同于DNS方式，沒有任何用戶請求能被外部系統(tǒng)終結(jié)（不能緩存），所有請求都必須進入GSLB系統(tǒng)，這將成為性能和可靠性的瓶頸。（流媒體用的比較多）
基于IP路由的GSLB
基于路由協(xié)議算法選擇一條路由到達這兩個本地均衡器中的一個。因為每次訪問請求的終端IP地址不同，路由條件也不同，所以在多個路由器上優(yōu)選的路由不同，從統(tǒng)計復用的角度來看基本是在負載均衡器1和2之間均勻分布的。
IP路由在多個POP點之間實現(xiàn)的負載均衡是一種概率上的均衡，而不是真正的均衡（沒做智能調(diào)度）。
比較項 | 基于DNS解析方式 | 基于HTTP重定向方式 | 基于IP路由方式 |
性能 | 本地DNS服務器和用戶終端DNS緩存能力使GSLB的負載得到有效分擔 | GSLB處理壓力大，容易成為系統(tǒng)性能的瓶頸 | 借助IP網(wǎng)絡(luò)設(shè)備完成負載均衡，沒有單點性能瓶頸 |
準確度 | 定位準確度取決于本地DNS覆蓋范圍，本地DNS設(shè)置錯誤會造成定位不準確 | 在對用戶IP地址數(shù)據(jù)進行有效維護的前提下，定位準確且精度高 | 就近性調(diào)度準確，但對設(shè)備健康性等動態(tài)信息響應會有延遲 |
效率 | 效率約等于DNS系統(tǒng)本身處理效率 | 依靠服務器做處理，對硬件資源的要求高 | 效率約等于IP設(shè)備本身效率 |
擴展性 | 擴展性和通用性好 | 擴展性較差，需對各種應用協(xié)議進行定制開發(fā) | 通用性好，但適用范圍有限 |
商用性 | 在Web加速領(lǐng)域使用較多 | 國內(nèi)流媒體CDN應用較多 | 尚無商用案例 |
第六章 流媒體CDN系統(tǒng)的組成
流媒體業(yè)務是一種對實時性、連續(xù)性、時序性要求非常高的業(yè)務，無論從帶寬消耗上還是質(zhì)量保障上來說，對best-effort的IP網(wǎng)絡(luò)都是一個不小的沖擊
– 高帶寬要求
– 高QoS要求
– 組播、廣播要求（目前IP網(wǎng)絡(luò)無法實現(xiàn)端到端的組播業(yè)務）
播放一個視頻分為以下四個步驟
– Access
– Demux（音視頻分離）
– Decode（解碼解壓縮）
– Output
RTP、RTCP、RTSP、RTMP的關(guān)系：RTSP協(xié)議用來實現(xiàn)遠程播放控制，RTP用來提供時間信息和實現(xiàn)流同步，RTCP協(xié)助RTP完成傳輸質(zhì)量控制<=（播放控制），
=>（傳輸控制）RTMP和HTTP streaming則是將流同步、播放控制、質(zhì)量控制集成起來的企業(yè)自有流媒體傳送協(xié)議
RTMP是adobe的傳輸協(xié)議。RTMP的基本通信單元：消息塊（chunk）和消息（message）
RTMP協(xié)議架構(gòu)在TCP層之上，但RTMP消息并不是直接封裝在TCP中，而是通過一個被稱為消息塊的封裝單元進行傳輸。消息在網(wǎng)絡(luò)上發(fā)送之前往往需要分割成多個較小的部分，這樣較小的部分就是消息塊，屬于不同消息流的消息塊可以在網(wǎng)絡(luò)上交叉發(fā)送。
RTSP/RTP和HTTP streaming是目前應用最廣泛的流化協(xié)議，目前電信運營商在IPTV（特殊通道的基于IP的流媒體播放）的流化上主要以RTSP/RTP技術(shù)為主，而互聯(lián)網(wǎng)視頻網(wǎng)站（點播/直播）則多傾向于使用HTTP streaming的流化技術(shù)。
HTTP streaming前身是progressive download（漸進式下載：邊下載邊播放，直到下載完）。HTTP streaming首先會將視頻數(shù)據(jù)（包括直播的視頻流和點播的視頻文件）在服務器上進行編碼，然后將編碼后的數(shù)據(jù)進行更細粒度的分片，再把每個分片通過HTTP協(xié)議傳輸?shù)娇蛻舳?。HTTP streaming的客戶端需要對視頻文件的每個分片都發(fā)出一個HTTP請求，這樣，在視頻播放速度低于下載速度的情況下，客戶端可以靈活控制HTTP請求的發(fā)出速度，從而保證用戶在中途退出時不會出現(xiàn)下載浪費。另外，因為采用分片的特點，HTTP streaming還可以實現(xiàn)媒體播放過程中的碼率切換（碼率自適應），結(jié)合網(wǎng)絡(luò)帶寬資源，為用戶提供更好的體驗。
HTTP streaming | Progressive download |
支持點播、直播 | 僅支持點播 |
可對分片文件加密，保證數(shù)字版權(quán) | 直接把媒體文件分割成多個小文件分片，無法保障版權(quán)所有 |
因為分片傳輸，故支持碼率自適應 | 只支持固定碼率 |
HTTP streaming | RTSP/RTP |
基于TCP，更高可靠性，也可以直接利用TCP的流控機制來適應帶寬的變化 | 基于UDP |
可將播放過的內(nèi)容保存在客戶端 | 不能保存在客戶端 |
使用80端口，能穿越防火墻 | 使用特殊端口 |
采用標準的HTTP協(xié)議來傳輸，只需要標準的HTTP服務器支撐 | 需要特殊的流媒體服務器 |
HTTP streaming的幾個主流陣營：
– 3GPP adaptive HTTP Streaming
– Microsoft IIS Smooth Streaming
– Adobe HTTP Dynamic Streaming (HDS)
– Apple HTTP Live Streaming (HLS)
HLS流化技術(shù)主要分三個部分：服務器組件、分發(fā)組件和客戶端軟件
– 服務器組件主要負責從原始的音視頻設(shè)備捕捉相應的音視頻流，并對這些輸入的媒體流進行編碼，然后進行封裝和分片，最后交付給分發(fā)組件來進行傳送；
– 分發(fā)組件主要負責接收客戶端發(fā)送的請求，然后將封裝的流媒體分片文件連同相關(guān)的索引文件一起發(fā)送給客戶端。對于沒有采用CDN服務的源服務器，標準的Web服務器就是一個分發(fā)組件，而對于大型的視頻網(wǎng)站或者類似的大規(guī)模應用平臺，分發(fā)組件還應包括支持RTMP協(xié)議的CDN；
– 客戶端軟件負責確定應該請求的具體媒體流，下載相關(guān)資源，并在下載后通過拼接分片將流媒體重新展現(xiàn)給用戶
HLS音視頻流或流媒體文件在經(jīng)過編碼、封裝和分片后，變成多個以.ts結(jié)尾的分片文件。流分割器產(chǎn)生的索引文件是以.M3U8為后綴的，用戶可以直接通過Web訪問來獲取
分發(fā)組件負責將分片文件和索引文件通過HTTP的方式發(fā)送給客戶端，無須對現(xiàn)有的Web服務器和Cache設(shè)備進行額外的擴展、配置和升級
客戶端組件根據(jù)URL來獲取這個視頻的索引文件。索引文件包含了可提供分片文件的具體位置、解密密鑰以及可用的替換流。
HDS，點播內(nèi)容是通過一個簡單的預編碼生成MP4片段以及Manifest清單文件；直播的內(nèi)容準備工作流程相對復雜一點，在播放的過程中生成MP4.（直播推薦用RTMP，使用FMS推流器）
MPEG-2 TS是指TS格式封裝的、MPEG-2編碼格式的媒體流。大多數(shù)IPTV系統(tǒng)使用這種內(nèi)容源。H.264這一層完成原始文件的壓縮編碼，TS這一層負責音視頻的復用以及同步，RTP這一層負責流的順序傳輸，UDP這一層負責數(shù)據(jù)包的交付，IP層負責傳輸路由選擇
流媒體加速的回源要求：因為流媒體文件傳送帶寬需求高，而且往往需要維持TCP長連接，所以一旦CDN回源比例過高，源站服務器I/O將不堪負荷。CDN對內(nèi)容采取分發(fā)方式分為pull和push兩種。Pull是被動下拉的方式，push是主動推送的方式。對于流媒體內(nèi)容，系統(tǒng)一般會選擇對熱點內(nèi)容采取push方式的預分發(fā)，而普通的網(wǎng)頁內(nèi)容幾乎100%是pull方式的。
在流媒體CDN系統(tǒng)中，用戶訪問的調(diào)度會更多考慮內(nèi)容命中，主要是因為流媒體內(nèi)容文件體積大，業(yè)務質(zhì)量要求高，如果從其他節(jié)點拉內(nèi)容再向用戶提供服務會帶來額外的延遲，影響用戶體驗。為進一步提高命中率，流媒體CDN系統(tǒng)普遍采用了對熱點內(nèi)容實施預先push的內(nèi)容分發(fā)策略
在流媒體服務系統(tǒng)中，主要關(guān)注的技術(shù)是對不同流媒體協(xié)議、不同編碼格式、不同播放器、不同業(yè)務質(zhì)量要求等的適應。
流媒體CDN與Web CDN的對比（業(yè)務差異）
主要差異點 | 流媒體CDN | Web CDN |
內(nèi)容類型 | 大文件、實時流、QoS要求高 | 小文件、固定大小、QoS要求低 |
用戶行為 | 拖曳、暫停等播放控制 | 下載后瀏覽 |
內(nèi)容管理 | 內(nèi)容冷熱度差異明顯（對命中率要求高），內(nèi)容生命周期長 | 內(nèi)容冷熱度差異不明顯，內(nèi)容生命周期短 |
回源要求 | 回源比例小 | 回源比例大 |
現(xiàn)在已經(jīng)投入商用的CDN系統(tǒng)，基本都是同時提供Web CDN能力和流媒體CDN能力的，而且這兩種能力的實現(xiàn)在系統(tǒng)內(nèi)部幾乎都是互相隔離的，從調(diào)度系統(tǒng)到節(jié)點設(shè)備都沒有交叉互用
流媒體CDN與Web CDN的設(shè)計差異（設(shè)計差異）
主要差異點 | 流媒體CDN | Web CDN |
Cache | 支持多種流化協(xié)議，硬件配置大存儲、高I/O | 支持多協(xié)議（HTTP、FTP等）硬件配置小存儲、高性能CPU |
負載均衡 | DNS+HTTP重定向方式 | DNS方式 |
內(nèi)容分發(fā)方式 | 熱片PUSH，冷片PULL | 全PULL方式 |
組網(wǎng) | 多級組網(wǎng)，可能要求組播、單播混合組網(wǎng) | 兩級組網(wǎng) |
流媒體CDN的Cache設(shè)備與Web Cache無論在軟件實現(xiàn)還是硬件要求上差異都很大，我們很少看到這兩種業(yè)務共用同一臺設(shè)備
當用戶請求的內(nèi)容在Cache上命中時，Cache直接向用戶提供流服務，此時Cache設(shè)備充當流媒體服務器的角色；當用戶請求內(nèi)容未能在Cache上命中時，Cache會從上一級Cache（二級緩存設(shè)備或中間緩存設(shè)備）或者源站服務器獲取內(nèi)容，再提供給用戶。Cache在用戶與另一個流媒體服務器之間扮演代理的角色
分布式存儲技術(shù)因其大容量、低成本的特點，目前也被業(yè)界關(guān)注和研究作為流媒體CDN系統(tǒng)的存儲解決方案之一。常用的分布式存儲技術(shù)包括分布式文件系統(tǒng)和分布式數(shù)據(jù)庫，由于采用了數(shù)據(jù)副本冗余（每份數(shù)據(jù)復制2~3份）、磁盤冗余（Raid1、Raid10、Raid5）等技術(shù)，通?？梢蕴峁┝己玫臄?shù)據(jù)容錯機制，當單臺存儲設(shè)備斷電或者單個存儲磁盤失效時，整個存儲系統(tǒng)仍能正常工作
負載均衡設(shè)備在進行用戶訪問調(diào)度時，會綜合考慮很多靜態(tài)的、動態(tài)的參數(shù)，包括IP就近性、連接保持、內(nèi)容命中、響應速度、連接數(shù)等。但沒有哪個CDN會考慮所有參數(shù)，而是會根據(jù)業(yè)務特點進行一些取舍，否則均衡系統(tǒng)就太復雜了。而流媒體CDN在進行用戶訪問調(diào)度時，會更多考慮內(nèi)容命中這一參數(shù)
有兩種GSLB實現(xiàn)方式，一種是基于DNS的，一種是基于應用層重定向的
PUSH方式適合內(nèi)容訪問比較集中的情況，如熱點的影視流媒體內(nèi)容，PULL方式比較適合內(nèi)容訪問分散的情況
對使用CDN服務的SP來說，CDN的作用在于盡量就近為用戶提供服務，幫助SP解決長距離IP傳輸和跨域傳輸帶來的種種業(yè)務質(zhì)量問題（通過空間換取時間）。因此，為用戶提供服務的Cache設(shè)備一定部署在離用戶比較近的地方。另一方面，CDN的建設(shè)者從成本角度考慮，又不能把所有內(nèi)容都存放在這些離用戶最近的節(jié)點中，這會消耗大量存儲成本，所以這些提供服務的Cache設(shè)備會根據(jù)需要從源站服務器或者其他Cache獲取內(nèi)容。這樣就形成了CDN網(wǎng)絡(luò)分層部署的概念。
從網(wǎng)絡(luò)分層上看，Web CDN通常是兩級架構(gòu)（也有三級架構(gòu)以減少回源），即中心-邊緣。而流媒體CDN通常有三級以上架構(gòu)，即中心-區(qū)域-邊緣。產(chǎn)生這種區(qū)別的原因在于流媒體回源成本比較高，源站服務器響應一次流媒體內(nèi)容回源請求，要比Web內(nèi)容回源消耗更多資源。尤其對于流媒體直播業(yè)務來說，只要直播節(jié)目沒結(jié)束，服務器就需要長時間持續(xù)吐流，如果沒有第二層節(jié)點作為中繼，那么中心節(jié)點的壓力將是不可想象的。
分層部署的方式，對點播業(yè)務而言的主要意義是節(jié)省存儲成本，對直播業(yè)務而言在于減少帶寬成本。在點播業(yè)務中，邊緣Cache只需存儲用戶訪問量大的內(nèi)容或者內(nèi)容片斷，其余內(nèi)容存儲在區(qū)域Cache中。
在直播業(yè)務中，邊緣Cache從區(qū)域中心獲取直播流，而不需要直接向中心節(jié)點（源站）獲取，從而節(jié)省了區(qū)域中心到中心節(jié)點這一段的大部分帶寬。因為直播流在各個Cache中都不需要占用很大的存儲空間，只需少量緩存空間即可，所以直播業(yè)務方面并不用注重考慮存儲成本
考慮到電信運營商的IP拓撲和流量模型，區(qū)域中心Cache通常部署在重點城市的城域網(wǎng)出口的位置，以保障向各個邊緣Cache的鏈路通暢。邊緣Cache的位置選擇則以整個節(jié)點能夠提供的并發(fā)能力為主要依據(jù)，依據(jù)業(yè)務并發(fā)數(shù)收斂比，計算出單個Cache需要覆蓋的用戶規(guī)模，從而選擇一個合適的部署位置。當然，邊緣Cache離用戶越近，服務質(zhì)量越好，但覆蓋的用戶數(shù)越少，部署成本越高。
內(nèi)容文件預處理
是指視頻內(nèi)容進入CDN以后，進入內(nèi)容分發(fā)流程之前，CDN系統(tǒng)對內(nèi)容進行的一系列處理過程。這個預處理過程的目的有幾個：
– 為全網(wǎng)內(nèi)容管理提供依據(jù)，比如對內(nèi)容進行全網(wǎng)唯一標識，對內(nèi)容基礎(chǔ)信息進行記錄等
– 為提高CDN服務效率或降低系統(tǒng)成本提供手段，比如內(nèi)容切片
– 為滿足業(yè)務要求提供能力，比如對同一內(nèi)容進行多種碼率的轉(zhuǎn)換以滿足動態(tài)帶寬自適應或三屏互動業(yè)務要求
視頻轉(zhuǎn)碼(video transcoding)
– 碼率轉(zhuǎn)換
– 空間分辨率轉(zhuǎn)換
– 時間分辨率轉(zhuǎn)換
– 編碼格式轉(zhuǎn)換。編碼格式主要包括H.264、MPEG-4、MPEG-2、VC-1、REAL、H.263、WMV。通常是把其他編碼格式轉(zhuǎn)換成H.264
文件切片
是指按照一定的規(guī)則把一個完整的文件切成大小一致的若干個小文件；由于流媒體CDN需要提供的內(nèi)容體積越來越大，傳統(tǒng)整片存儲帶來的成本消耗超出了CDN服務商的承受范圍；切片的另一個目的是，使邊緣Cache能夠支持自適應碼率業(yè)務
防盜鏈機制和實現(xiàn)
– 基于IP的黑白名單
– 利用HTTP header的referer字段
– 使用動態(tài)密鑰（隨機生成的key通過算法生成新的url）
– 在內(nèi)容中插入數(shù)據(jù)（對有版權(quán)內(nèi)容進行加密（DRM），如Microsoft的playready，Google的Widevine）
– 打包下載：在原文件的基礎(chǔ)上進一步封裝，使得資源的hash 值改變
–
第七章 動態(tài)內(nèi)容加速服務的實現(xiàn)
隨著Web2.0的興起，產(chǎn)生了動態(tài)網(wǎng)頁、個性化內(nèi)容、電子交易數(shù)據(jù)等內(nèi)容的加速，這些就涉及了動態(tài)內(nèi)容加速技術(shù)。
靜態(tài)內(nèi)容的加速，都是對于表現(xiàn)層的加速，對于動態(tài)頁面等內(nèi)容的加速，則要涉及邏輯層和數(shù)據(jù)訪問層的加速技術(shù)
動態(tài)內(nèi)容的提供不僅僅是HTML頁面的設(shè)計及編輯，它還需要有后臺數(shù)據(jù)庫、應用邏輯程序的支持，以實現(xiàn)與用戶的動態(tài)交互。
Web系統(tǒng)由表現(xiàn)層、業(yè)務邏輯層、數(shù)據(jù)訪問層+用戶數(shù)據(jù)層
表現(xiàn)層是Web系統(tǒng)與外部系統(tǒng)的交互界面，這一層通常由HTTP服務器組成，負責接收用戶端的HTTP內(nèi)容訪問請求，從文件系統(tǒng)中讀取靜態(tài)文件
業(yè)務邏輯層負責處理所有業(yè)務邏輯和動態(tài)內(nèi)容的生成
數(shù)據(jù)訪問層位于系統(tǒng)的后端，負責管理Web系統(tǒng)的主要信息和數(shù)據(jù)存儲，通常由數(shù)據(jù)庫服務器和存儲設(shè)備組成
用戶數(shù)據(jù)層負責存儲用戶信息數(shù)據(jù)和關(guān)聯(lián)關(guān)系，內(nèi)容來自用戶提供和用戶行為分析結(jié)果
Web網(wǎng)站借助CDN技術(shù)能夠獲得更好的擴展性和高性能，核心在于CDN采用的緩存（caching）和復制（replication）機制，其中緩存是將最近經(jīng)常被訪問的源服務器擁有的內(nèi)容復制到邊緣服務器上，可被視為具有特定策略的復制。
CDN的復制機制是指將源Web系統(tǒng)邏輯架構(gòu)的各個層次的相應功用復制到邊緣服務器上實現(xiàn)，以緩解源系統(tǒng)的處理壓力。
– Web系統(tǒng)表現(xiàn)層的復制，就是靜態(tài)內(nèi)容的復制。邊緣服務器又被稱為代理服務器，通過反向代理加速靜態(tài)文件的交付
– Web系統(tǒng)業(yè)務邏輯層的復制。CDN被用于改進動態(tài)生成內(nèi)容的交付性能。即將應用程序和業(yè)務組件直接在CDN的邊緣服務器中計算，從而直接在靠近用戶的地方生成動態(tài)Web內(nèi)容
– – Akamai邊緣計算部署模型，包括用戶（使用瀏覽器）、企業(yè)J2EE應用系統(tǒng)（運行業(yè)務邏輯、原有系統(tǒng)、數(shù)據(jù)庫等）、分布式網(wǎng)絡(luò)服務器（Edge computing平臺）運行支持J2EE應用編程模型的WebSphere或者Tomcat應用服務器
– Web系統(tǒng)數(shù)據(jù)訪問層復制。CDN邊緣服務器能夠具備生成動態(tài)內(nèi)容和掌管內(nèi)容生成數(shù)據(jù)的能力
– – 利用邊緣服務器代替源鉆Web系統(tǒng)的后臺數(shù)據(jù)訪問層中的數(shù)據(jù)庫系統(tǒng)，及時響應業(yè)務邏輯層提出的數(shù)據(jù)查詢需求。
– Web系統(tǒng)用戶文件的復制。
（PS：暫時來說，網(wǎng)宿還沒有實現(xiàn)真正意義的動態(tài)加速，雖然現(xiàn)在已經(jīng)實現(xiàn)一部分，如搜索結(jié)果動態(tài)緩存，重用的動態(tài)頁面智能緩存。其他更多的是通過智能管道來加快用戶與源鉆的訪問效率）
（應用加速技術(shù)實際上是傳統(tǒng)的網(wǎng)絡(luò)負載均衡的升級和擴展，綜合使用了負載均衡（智能調(diào)度）、TCP優(yōu)化管理（TCP keep-alive connection，更激進的TCP窗口策略，基于HTTP1.1），鏈接管理（routing）、SSL VPN、壓縮優(yōu)化（代碼壓縮，圖片壓縮）、智能網(wǎng)絡(luò)地址（NAT-公私網(wǎng)IP轉(zhuǎn)換）、高級路由、智能端口鏡像等技術(shù)。）
TCP的問題
– TCP窗口大小的限制（TCP窗口大小隨傳輸成功而變大，而一旦發(fā)生傳輸失敗，其窗口大小會立即縮小）
– TCP協(xié)議慢啟動（三握手）和擁塞控制
廣域網(wǎng)加速關(guān)鍵技術(shù)
針對層次 | 優(yōu)化技術(shù) | 優(yōu)化原理 |
傳輸發(fā)起端 | 原始數(shù)據(jù)優(yōu)化 | 通過壓縮、重復數(shù)據(jù)刪除和字典等技術(shù)，可節(jié)省絕大多數(shù)傳輸數(shù)據(jù)量，節(jié)約帶寬，提高服務器性能 |
數(shù)據(jù)緩存技術(shù) | 將類HTTP的業(yè)務、圖片、文字等緩存在本地，只傳輸動態(tài)內(nèi)容，減少帶寬占用 | |
物理層（硬件） | 提升設(shè)備性能 | 基于現(xiàn)有TCP/IP，通過硬件方式提高性能，提高大量TCP并發(fā)連接和會話重組等處理能力 |
網(wǎng)絡(luò)層（IP） | QoS和流量控制 | 通過協(xié)議識別，實現(xiàn)在同一端口中不同應用的真正區(qū)分，進而通過分流實現(xiàn)時延敏感應用的帶寬保障 |
傳輸層（TCP） | 代理設(shè)備 | 在傳輸兩端各架設(shè)代理設(shè)備，所有的響應報文都在本地完成，只有真正發(fā)起請求時才通過鏈路，相當于同時在服務器和客戶端進行協(xié)議欺騙 |
TCP協(xié)議優(yōu)化 | 通過在廣域網(wǎng)兩端部署專用設(shè)備，在不影響基本傳輸情況下，通過各種手段對TCP窗口、響應、啟動等機制進行改進，從而提高協(xié)議機制的效率 | |
應用層 | 應用代理（緩存） | 將常用的應用程序緩存在本地并配置好，用戶可不用在本地等待類似于認證等會話過程，而是直接開始下一個應用，實現(xiàn)流水作業(yè) |
數(shù)據(jù)碎片化，就是在應用層將數(shù)據(jù)分成一個個小的數(shù)據(jù)塊，便于后續(xù)的數(shù)據(jù)比對使用。廣域網(wǎng)加速設(shè)備在傳輸數(shù)據(jù)前會將緩存中的數(shù)據(jù)與數(shù)據(jù)切塊進行對比，從而找出那些數(shù)據(jù)是重復數(shù)據(jù)，不再發(fā)送，哪些數(shù)據(jù)是新鮮的、需要傳輸?shù)臄?shù)據(jù)。
數(shù)據(jù)壓縮和指針技術(shù)一般是放在一起使用的，在對數(shù)據(jù)分段后，會對每一段數(shù)據(jù)生成一個數(shù)據(jù)指針，對于重復內(nèi)容，只傳輸指針。在壓縮算法設(shè)計上，要求同時兼顧數(shù)據(jù)壓縮比和壓縮/解壓縮時間。
高速TCP傳輸技術(shù)
– 自適應擁塞窗口
– 有限制地快速重傳
– 連接池：通過維護一個預先建立好的TCP連接池，當有數(shù)據(jù)傳輸需求時，從連接池中挑選一條可用連接今次那個傳輸。
SSL加速技術(shù)
– SSL加密是一種處理器密集型加密算法，如果用服務器軟件處理會消耗大量CPU資源，一般會在提供業(yè)務能力的服務器外圍部署專門的SSL加速設(shè)備，采用硬解密方式實現(xiàn)
– SSL加密分對稱秘鑰和非對稱秘鑰（計算資源消耗更大）
SSL的基本原理和實現(xiàn)
– 可認證性（authentication）
– 隱私性（privacy）
– 完整性（integrity）
– 不可抵賴性（undeniability）：發(fā)送者不能自稱沒有發(fā)出過接受者從他那里收到的內(nèi)容
SSL加速
– 通常是基于硬件的SSL加速
– 通過在服務器上安裝一塊SSL加速板卡，可有效分擔服務器CPU處理SSL事務的壓力
聯(lián)系客服
