1.CDN基本原理

CDN 的基本原理是依靠放置在各地的緩存服務(wù)器缴挖，通過全局調(diào)度以及內(nèi)容分發(fā)等功能模塊脖祈，將用戶需要的那部分內(nèi)容部署到最貼近用戶的地方宁舰，將原本低效乒疏、不可靠的網(wǎng)絡(luò)轉(zhuǎn)變成高效法牲、可靠的智能網(wǎng)絡(luò)史汗，滿足用戶對(duì)內(nèi)容訪問質(zhì)量的更高要求， 改善互聯(lián)網(wǎng)網(wǎng)絡(luò)擁塞問題拒垃，提高用戶訪問 網(wǎng)站的響應(yīng)速度停撞。

(1)內(nèi)容CDN的內(nèi)容通常是以下兩種: 靜態(tài)內(nèi)容以及動(dòng)態(tài)內(nèi)容。

靜態(tài)內(nèi)容:內(nèi)容不經(jīng)常更改，并且一旦它在 CDN 緩存中戈毒，可以由許多用戶進(jìn)行訪問艰猬，緩存性強(qiáng)。

靜態(tài)內(nèi)容服務(wù)又可分為 緩存類服務(wù)及流媒體類服務(wù)埋市。

緩存類服務(wù)冠桃，即用戶以最大的速度向服務(wù)器下拉內(nèi)容，如基于HTTP的文件下載道宅， CDN能夠保證下載業(yè)務(wù)中終端用戶的下載速度 食听。

流媒體類服務(wù)，主要是視頻業(yè)務(wù)培己，分為點(diǎn)播與 直播兩種 碳蛋。 與靜態(tài)內(nèi)容不同，流式傳輸方式是流媒體與靜態(tài)內(nèi)容最大的 差異省咨。流媒體服務(wù)將每一幀數(shù)據(jù)打上時(shí)序標(biāo)簽后進(jìn)行流式傳輸肃弟，是一種按視頻的碼流需求向用戶提供實(shí)時(shí)流的分發(fā)方式。發(fā)送端采集音視頻數(shù)據(jù)零蓉，經(jīng)過編碼笤受、格式封裝、推流等過程處理敌蜂，然后進(jìn)行傳輸箩兽，客戶端再下載數(shù)據(jù)并按時(shí)序進(jìn)行解碼播放，實(shí)現(xiàn)這些離不開 CDN對(duì)流媒體協(xié)議的支持章喉。

動(dòng)態(tài)內(nèi)容:內(nèi)容用于特定的用戶或組汗贫，并且更新頻率較高，通常來自源服務(wù)器并實(shí)時(shí)發(fā)送到 CDN 中秸脱，緩存性較弱落包。對(duì)于用戶的每 一 次請(qǐng)求， CDN 都必須從源站服務(wù)器拉取動(dòng)態(tài)內(nèi)容 摊唇，所以 動(dòng)態(tài)內(nèi)容加速的常用方法就是降低源站服務(wù)器和用戶終端之間的傳輸時(shí)延咐蝇。

2.CDN 的基本工作過程

CDN客戶使用CDN的方法：

對(duì)于CDN客戶來說，不需要改動(dòng)網(wǎng)站架構(gòu)巷查，只需要修改自己的DNS解析有序，設(shè)置一個(gè)CNAME指向CDN服務(wù)商即可。原理在下面會(huì)解釋

通過上圖岛请，我們可以了解到旭寿，使用了CDN緩存后的網(wǎng)站的訪問過程變?yōu)椋?/b>

用戶向?yàn)g覽器提供要訪問的域名；

瀏覽器調(diào)用域名解析庫對(duì)域名進(jìn)行解析髓需，由于CDN對(duì)域名解析過程進(jìn)行了調(diào)整许师，所以解析函數(shù)庫得到的是該域名對(duì)應(yīng)的CNAME記錄（由于現(xiàn)在已經(jīng)是使用了CDN服務(wù)，CNAME為CDN服務(wù)商域名），為了得到實(shí)際IP地址微渠，瀏覽器需要再次對(duì)獲得的CNAME域名進(jìn)行解析以得到實(shí)際的IP地址搭幻；在此過程中，使用的全局負(fù)載均衡DNS解析逞盆，如根據(jù)地理位置信息解析對(duì)應(yīng)的IP地址檀蹋，使得用戶能就近訪問。（CDN服務(wù)來提供最近的機(jī)器）

此次解析得到CDN緩存服務(wù)器的IP地址云芦，瀏覽器在得到實(shí)際的IP地址以后俯逾，向緩存服務(wù)器發(fā)出訪問請(qǐng)求；

緩存服務(wù)器根據(jù)瀏覽器提供的要訪問的域名舅逸，通過Cache內(nèi)部專用DNS解析得到此域名的實(shí)際IP地址桌肴，再由緩存服務(wù)器向此實(shí)際IP地址提交訪問請(qǐng)求；

緩存服務(wù)器從實(shí)際IP地址得得到內(nèi)容以后琉历，一方面在本地進(jìn)行保存坠七，以備以后使用，二方面把獲取的數(shù)據(jù)返回給客戶端旗笔，完成數(shù)據(jù)服務(wù)過程彪置；

客戶端得到由緩存服務(wù)器返回的數(shù)據(jù)以后顯示出來并完成整個(gè)瀏覽的數(shù)據(jù)請(qǐng)求過程。

CDN工作原理

①當(dāng)用戶點(diǎn)擊網(wǎng)站頁面上的內(nèi)容URL蝇恶，經(jīng)過本地DNS系統(tǒng)解析拳魁，DNS系統(tǒng)會(huì)最終將域名的解析權(quán)交給CNAME指向的CDN專用DNS服務(wù)器。

②CDN的DNS服務(wù)器將CDN的全局負(fù)載均衡設(shè)備IP地址返回用戶撮弧。

③用戶向CDN的全局負(fù)載均衡設(shè)備發(fā)起內(nèi)容URL訪問請(qǐng)求潘懊。

④CDN全局負(fù)載均衡設(shè)備根據(jù)用戶IP地址，以及用戶請(qǐng)求的內(nèi)容URL贿衍，選擇一臺(tái)用戶所屬區(qū)域的區(qū)域負(fù)載均衡設(shè)備卦尊，告訴用戶向這臺(tái)設(shè)備發(fā)起請(qǐng)求。

⑤區(qū)域負(fù)載均衡設(shè)備會(huì)為用戶選擇一臺(tái)合適的緩存服務(wù)器提供服務(wù)舌厨，選擇的依據(jù)包括：根據(jù)用戶IP地址，判斷哪一臺(tái)服務(wù)器距用戶最近忿薇；根據(jù)用戶所請(qǐng)求的URL中攜帶的內(nèi)容名稱裙椭，判斷哪一臺(tái)服務(wù)器上有用戶所需內(nèi)容；查詢各個(gè)服務(wù)器當(dāng)前的負(fù)載情況署浩，判斷哪一臺(tái)服務(wù)器尚有服務(wù)能力揉燃。基于以上這些條件的綜合分析之后筋栋，區(qū)域負(fù)載均衡設(shè)備會(huì)向全局負(fù)載均衡設(shè)備返回一臺(tái)緩存服務(wù)器的IP地址炊汤。

⑥全局負(fù)載均衡設(shè)備把服務(wù)器的IP地址返回給用戶。

⑦用戶向緩存服務(wù)器發(fā)起請(qǐng)求，緩存服務(wù)器響應(yīng)用戶請(qǐng)求抢腐，將用戶所需內(nèi)容傳送到用戶終端姑曙。如果這臺(tái)緩存服務(wù)器上并沒有用戶想要的內(nèi)容，而區(qū)域均衡設(shè)備依然將它分配給了用戶迈倍，那么這臺(tái)服務(wù)器就要向它的上一級(jí)緩存服務(wù)器請(qǐng)求內(nèi)容伤靠，直至追溯到網(wǎng)站的源服務(wù)器將內(nèi)容拉到本地。

DNS服務(wù)器根據(jù)用戶IP地址啼染，將域名解析成相應(yīng)節(jié)點(diǎn)的緩存服務(wù)器IP地址宴合，實(shí)現(xiàn)用戶就近訪問。使用CDN服務(wù)的網(wǎng)站迹鹅，只需將其域名解析權(quán)交給CDN的GSLB設(shè)備卦洽，將需要分發(fā)的內(nèi)容注入CDN，就可以實(shí)現(xiàn)網(wǎng)站內(nèi)容加速斜棚。

阿里云解釋

通過以下案例阀蒂，您可以了解CDN的工作原理。

假設(shè)您的加速域名為www.a.com打肝，接入CDN網(wǎng)絡(luò)脂新，開始使用加速服務(wù)后，當(dāng)終端用戶（北京）發(fā)起HTTP請(qǐng)求時(shí)粗梭，處理流程如下圖所示争便。

當(dāng)終端用戶（北京）向www.a.com下的指定資源發(fā)起請(qǐng)求時(shí)，首先向LDNS（本地DNS）發(fā)起域名解析請(qǐng)求断医。

LDNS檢查緩存中是否有www.a.com的IP地址記錄滞乙。如果有，則直接返回給終端用戶鉴嗤；如果沒有斩启，則向授權(quán)DNS查詢。

當(dāng)授權(quán)DNS解析www.a.com時(shí)醉锅，返回域名CNAME?www.a.tbcdn.com對(duì)應(yīng)IP地址兔簇。

域名解析請(qǐng)求發(fā)送至阿里云DNS調(diào)度系統(tǒng)，并為請(qǐng)求分配最佳節(jié)點(diǎn)IP地址硬耍。

LDNS獲取DNS返回的解析IP地址垄琐。

用戶獲取解析IP地址。

用戶向獲取的IP地址發(fā)起對(duì)該資源的訪問請(qǐng)求经柴。

如果該IP地址對(duì)應(yīng)的節(jié)點(diǎn)已緩存該資源狸窘，則會(huì)將數(shù)據(jù)直接返回給用戶，例如坯认，圖中步驟7和8翻擒，請(qǐng)求結(jié)束氓涣。

如果該IP地址對(duì)應(yīng)的節(jié)點(diǎn)未緩存該資源，則節(jié)點(diǎn)向源站發(fā)起對(duì)該資源的請(qǐng)求陋气。獲取資源后劳吠，結(jié)合用戶自定義配置的緩存策略，將資源緩存至節(jié)點(diǎn)恩伺，例如赴背，圖中的北京節(jié)點(diǎn)，并返回給用戶晶渠，請(qǐng)求結(jié)束凰荚。配置緩存策略的操作方法，請(qǐng)參見緩存配置褒脯。

詳細(xì)解釋

CDN 的基本工作過程便瑟，包括內(nèi)容注入、用戶請(qǐng)求調(diào)度番川、內(nèi)容分發(fā)以及內(nèi)容服務(wù)這 4個(gè)步驟到涂。

(1 )內(nèi)容注入

內(nèi)容注入是 CDN 能為用戶提供服務(wù)，是內(nèi)容從源站注入 CDN 的過程颁督，使得用戶能從 CDN系統(tǒng)中獲取源站的內(nèi)容践啄。

(2)用戶請(qǐng)求調(diào)度

用戶請(qǐng)求調(diào)度是用戶向網(wǎng)站發(fā)起訪問請(qǐng)求，最終用 戶被引導(dǎo)到最佳的有內(nèi)容的 CDN 節(jié)點(diǎn)的過程沉御，具體如下 :

(a)當(dāng)用戶向網(wǎng)站發(fā)起訪問請(qǐng)求時(shí)屿讽，經(jīng)由本地 DNS 系統(tǒng)解析，本地 DNS 會(huì)通過遞歸方式將域名的解析權(quán)最終交給 CDN 授權(quán) DNS 服務(wù)器 (GSLB);

(b) CDN GSLB 可將 CDN節(jié)點(diǎn)設(shè)備的回地址返回用戶吠裆，也可以將另一個(gè)負(fù)責(zé)解析用戶終端 IP 地址的 GSLB 設(shè)備的 IP 地址返回用戶伐谈。

(c)用戶向 CDN的GSLB設(shè)備發(fā)起內(nèi)容訪問請(qǐng)求(IP調(diào)度方式):

(d) CDN 的 GSLB 設(shè)備根據(jù)用戶地址以及用戶請(qǐng)求的內(nèi)容 URL，選擇一臺(tái)用戶所屬地區(qū)的本地負(fù)載均衡 CSLB)設(shè)備试疙，并讓用戶向該 SLB 發(fā)起訪問請(qǐng)求;

(e)該 SLB 設(shè)備通過決策選擇一 臺(tái)最佳的服務(wù)器為用戶提供服務(wù)诵棵，用戶向該服務(wù)器發(fā)起訪問請(qǐng)求;

(f) 若該服務(wù)器內(nèi)容未命中，而 SLB 仍將該服務(wù)器分配給用戶祝旷，則該服務(wù)器需要向上級(jí)節(jié)點(diǎn)請(qǐng)求內(nèi)容履澳，然后，由該服務(wù)器向用戶提供“邊拉邊放”的服務(wù)或者由上級(jí)節(jié)點(diǎn)直接為用戶提供服務(wù)怀跛。

3.CDN 內(nèi)容接入

1.內(nèi)容存儲(chǔ)接入

內(nèi)容存儲(chǔ)接入指源站(互聯(lián)網(wǎng)應(yīng)用的內(nèi)容源)在發(fā)布內(nèi)容前奇昙，提前把內(nèi)容注入 CDN。內(nèi)容存儲(chǔ)接入方式下敌完，業(yè)務(wù)系統(tǒng)需主動(dòng)向 CDN 內(nèi)容庫發(fā)送操作指令， CDN 根據(jù)指令獲得內(nèi)容并存儲(chǔ)在 CDN 內(nèi)容庫中羊初，從而在終端訪問 CDN 時(shí)直接由 CDN 向終端提供內(nèi)容滨溉，無需再從源站獲取什湘，提升了終端用戶體驗(yàn)。

(2)內(nèi)容預(yù)注入

內(nèi)容預(yù)注入是指源站在內(nèi)容發(fā)布之前將內(nèi)容注入 CDN 中 晦攒。 內(nèi)容預(yù)注入與內(nèi)容存儲(chǔ)接入方式類似闽撤，都是由業(yè)務(wù)系統(tǒng)主動(dòng)向 CDN 發(fā)送操作指令 ， CDN 根據(jù)指令預(yù)先從 內(nèi)容源回源獲取內(nèi)容脯颜，是就近提供服務(wù)的接入方式哟旗。

(3)實(shí)時(shí)回源

實(shí)時(shí)回源 (未注入〉是指源站在 內(nèi) 容發(fā)布之前不向 CDN 注入內(nèi)容，但當(dāng)用戶 內(nèi)容訪問請(qǐng)求時(shí) 栋操， CDN 實(shí)時(shí)地從源站 拉取內(nèi)容闸餐。

靜態(tài)內(nèi)容服務(wù)是指 CDN 承載的內(nèi)容主要是 HTML 文件、文本矾芙、 Flash動(dòng)畫舍沙、圖片、視頻剔宪、應(yīng)用軟件等拂铡。一般來說，這些文件相對(duì)更新頻率較低葱绒，而且熱點(diǎn)內(nèi)容集中感帅，通過緩存技術(shù)可將熱點(diǎn)內(nèi)容分發(fā)存儲(chǔ)在 CDN 的節(jié)點(diǎn)上，以滿足終端用戶就近訪問的需求 地淀。

4.CDN調(diào)度系統(tǒng)是什么

調(diào)度系統(tǒng)是指CDN廠家有能力通過各種機(jī)制將客戶域名的所有現(xiàn)網(wǎng)請(qǐng)求引導(dǎo)到合適的目標(biāo)機(jī)房失球，從而實(shí)現(xiàn)流量控制、質(zhì)量控制骚秦、成本控制以及故障處理她倘。

一般有哪些調(diào)度形式？

1)DNS調(diào)度基于請(qǐng)求端local dns的出口IP歸屬地及運(yùn)營商屬性的DNS調(diào)度作箍；

2)302調(diào)度再是基于客戶端IP歸屬地及運(yùn)營商屬性的302跳轉(zhuǎn)調(diào)度硬梁；

3)路由調(diào)度最后是基于Anycast技術(shù)（BGP路由）的機(jī)房流量調(diào)度；

1) CNAME方式

這是最常見的方式胞得，即CDN廠家向客戶提供一個(gè)調(diào)度域名荧止，客戶將自己業(yè)務(wù)域名的CNAME指向這個(gè)調(diào)度域名，從而實(shí)現(xiàn)將請(qǐng)求引導(dǎo)到CDN上來阶剑。比如騰訊云向客戶提供的CDN是 $domain.cdn.dnsv1com 跃巡，所以客戶的域名 www.test.com 如果需要將請(qǐng)求切到騰訊云CDN上，只需要將 www.test.com 的CNAME 設(shè)置為 www.test.com.cdn.dnsv1.com 即可牧愁。

CNAME方式的背后素邪，又分幾種：?

a) 一種是CDN廠家提供基于DNS的調(diào)度，就最終客戶的域名經(jīng)CDN的調(diào)度域名解析出CDN節(jié)點(diǎn)的IP猪半。騰訊云CDN就是這種玩法兔朦，大家可以dig p200107.ping.dnsv1.com看下效果偷线。 對(duì)應(yīng)前面的調(diào)度方式1。?

b) 一種是CDN廠家給的CNAME實(shí)際不是真正CDN節(jié)點(diǎn)沽甥，而是一個(gè)調(diào)度集群声邦，真正的CDN IP地址是通過在調(diào)度集群上向請(qǐng)求響應(yīng)302跳轉(zhuǎn)實(shí)現(xiàn)的。 對(duì)應(yīng)前面的調(diào)度方式2摆舟。

c) 再有一種亥曹，是Anycast CDN。從DNS層面上看恨诱，CDN廠家提供給你的CNAME的解析結(jié)果只有全球固定的一兩個(gè)IP地址媳瞪，不像方式1中不同地區(qū)的解析結(jié)果IP不同。這種場景下的流量調(diào)度胡野， 不是靠DNS解析材失，而是Anycast BGP路由的調(diào)整，通過調(diào)整Anycast的路由來調(diào)度各地區(qū)的流量到哪個(gè)機(jī)房硫豆。對(duì)應(yīng)前面的調(diào)度方式3龙巨。

第一種基于local DNS的調(diào)度是怎么實(shí)現(xiàn)的？

CDN的調(diào)度服務(wù)器本身就是調(diào)度域名的NS權(quán)威服務(wù)器熊响，調(diào)度域名的TTL被故意設(shè)置成很短（比如3分鐘）旨别，這樣所有請(qǐng)求都會(huì)較頻繁地觸發(fā)客戶端的local DNS重新到CDN調(diào)度服務(wù)器解析新的IP地址。此時(shí)CDN的調(diào)度服務(wù)器依據(jù)是local DNS的出口地址汗茄。

調(diào)度流程如下：

A. 客戶端DNS TTL過期無首次訪問秸弛，向local DNS發(fā)起DNS查詢

B. local DNS在遞歸解析過程中，向CDN的調(diào)度服務(wù)器發(fā)起解析請(qǐng)求洪碳；

C. CDN調(diào)度服務(wù)器可以看到local DNS的出口ip（有時(shí)還有基于EDNS的客戶端ip）递览；

D. 通過IP庫獲取上一步IP的地理及運(yùn)營商屬性，從當(dāng)前調(diào)度域名的策略規(guī)則中去匹配瞳腌，同時(shí)結(jié)合其它的因素（比如質(zhì)量監(jiān)控绞铃、機(jī)房成本因素等）得到最佳的一組IP；

第二種 瀏覽器向第一次拿到的IP發(fā)起http請(qǐng)求嫂侍；

如果這個(gè)IP實(shí)際上是CDN的邊緣節(jié)點(diǎn)儿捧，它會(huì)從本機(jī)的配置文件中讀取信息 p73.ping.dnsv1.com這個(gè)域名的請(qǐng)求Host如果不是IP，URL形式為：http://p73.ping.dnsv1.com/a.php 則將請(qǐng)求轉(zhuǎn)發(fā)到后端調(diào)度集群挑宠；

若請(qǐng)求Host為IP菲盾，對(duì)應(yīng)的URL形式為： http://61.142.166.245/p73.ping.dnsv1.com/a.php 則讀取緩存提供文件服務(wù)逆瑞。

此時(shí)請(qǐng)求到了調(diào)度群集上骆撇，我們能拿到的客戶端信息有 客戶端的出口IP（絕大多情況下是相同的），接下來算法和基于DNS的調(diào)度可以是一樣的瞻离，只是判斷依據(jù)由local DNS出口ip變成了客戶端的出口IP碎浇；

調(diào)度集群畢竟不是CDN節(jié)點(diǎn)临谱，無法向客戶端提供實(shí)際的文件內(nèi)容咆畏，此時(shí)它只能通過302報(bào)文告知客戶端，你可以去上一步驟計(jì)算的IP請(qǐng)求文件吴裤；

瀏覽器收到302回應(yīng)，跟隨Location中的URL溺健，繼續(xù)發(fā)起http請(qǐng)求麦牺，這次請(qǐng)求的目標(biāo)IP是CDN邊緣節(jié)點(diǎn)，且Host是IP鞭缭，CDN節(jié)點(diǎn)會(huì)響應(yīng)實(shí)際的文件內(nèi)容剖膳；

第三類基于Anycast BGP路由的調(diào)度如何實(shí)現(xiàn)

Anycast路由技術(shù)使得物理分布在全球/全球不同區(qū)域的不同服務(wù)器具有相同的IP地址，客戶端對(duì)這個(gè)IP的請(qǐng)求會(huì)在路由層面引導(dǎo)到最近的物理服務(wù)器上岭辣。Anycast CDN我們后續(xù)單獨(dú)用一篇文章講解吱晒，這里先略過實(shí)現(xiàn)細(xì)節(jié)。

Anycast CDN的優(yōu)點(diǎn):

由于IP少且固定沦童，TTL長仑濒，對(duì)CDN權(quán)威服務(wù)器的DNS解析性能要求不高；

在路由層面完成了就近接入CDN偷遗，比DNS抗干擾墩瞳，比302兼容性好；

路由策略變動(dòng)生效時(shí)間快氏豌，優(yōu)于DNS調(diào)度喉酌；

受DDOS攻擊時(shí)，只需調(diào)整路由泵喘，將攻擊流量引導(dǎo)到高帶寬清洗機(jī)房泪电，無需從現(xiàn)網(wǎng)剔除IP；

基于DNS的調(diào)度有哪些缺點(diǎn)纪铺？

調(diào)度策略非實(shí)時(shí)生效

? ? DNS是樹型分布式系統(tǒng)相速，所有節(jié)點(diǎn)上都會(huì)按域名的TTL來做緩存，這就導(dǎo)致CDN的調(diào)度策略其實(shí)并不是實(shí)時(shí)生效的霹陡，比如有個(gè)IP（或VIP）故障和蚪，將它從現(xiàn)網(wǎng)完全隔離需要一定的時(shí)間，比如5~10分鐘烹棉。

這個(gè)問題可通過將CDN調(diào)度域名的DNS TTL調(diào)小攒霹，比如由1~3分鐘調(diào)到秒級(jí)，但又會(huì)遇到新的問題：

? ? ? 》一般運(yùn)營商的DNS服務(wù)器出于安全考慮浆洗，會(huì)忽略太小的TTL值強(qiáng)制改為固定值催束；

? ? ? 》假設(shè)運(yùn)營商老老實(shí)實(shí)按你的極短的秒級(jí)TTL來，也會(huì)導(dǎo)致較頻繁觸發(fā)DNS解析伏社；

? ? DNS解析是有成本的抠刺，當(dāng)客戶端自身網(wǎng)絡(luò)或CDN的DNS權(quán)威網(wǎng)絡(luò)或服務(wù)性能太差時(shí)塔淤，將非常明顯地增加業(yè)務(wù)的請(qǐng)求延遲，這對(duì)冷域名請(qǐng)求量較小的業(yè)務(wù)又是響應(yīng)時(shí)間敏感型業(yè)務(wù)影響非常大速妖。

? ? 如果TTL太長呢高蜂，導(dǎo)致CDN的調(diào)度策略變化后全網(wǎng)生效時(shí)間過長，如果CDN某個(gè)機(jī)房故障需要從現(xiàn)網(wǎng)調(diào)度剔除罕容，DNS全球生效如果要花上30分鐘备恤，那這30分鐘內(nèi)訪問到原故障IP的請(qǐng)求就都仍舊是失敗的。

調(diào)度不夠精確

? ? 大量的local DNS不支持edns協(xié)議锦秒，拿不到客戶的真實(shí)IP露泊，CDN絕大多數(shù)時(shí)候只能通過local DNS ip來做決策，而local DNS ip有時(shí)候不太靠譜旅择。常常遇到的問題有：

? ? 》客戶配置了非本地區(qū)的DNS服務(wù)器惭笑，比如深圳電信用戶配置了北京電信的DNS服務(wù)器，結(jié)果CDN給你分配了北方的CDN節(jié)點(diǎn)IP生真；

? ? 》DNS服務(wù)器的出口IP與入口IP差距大沉噩，比如某些小運(yùn)營商的DNS服務(wù)器IP看起來是本地的，但實(shí)際DNS流量繞大半個(gè)中國從另外的區(qū)域出去汇歹，所以也會(huì)導(dǎo)致CDN給出完全不對(duì)的節(jié)點(diǎn)IP屁擅；

? ? 》上一種類型，還有一種情況产弹，像8.8.8.8這種Public DNS派歌，接入IP是Anycast IP沒有歸屬地一說，出口IP經(jīng)常變動(dòng)痰哨，比如中國大陸使用時(shí)胶果，出口IP經(jīng)常是中國臺(tái)灣的google 機(jī)房。DNSPOD所說有針對(duì)這種情況做特殊處理斤斧，凡是google中國臺(tái)灣來的請(qǐng)求強(qiáng)制判斷為中國大陸早抠。

基于302跳轉(zhuǎn)的調(diào)度有何優(yōu)點(diǎn)：

實(shí)時(shí)調(diào)度

由于每次拿到的最終IP都是實(shí)時(shí)計(jì)算的結(jié)果，所以調(diào)度策略是實(shí)時(shí)生效的撬讽，不像基于DNS的調(diào)度會(huì)受到DNS TTL緩存的影響而有延遲蕊连。

? ? 實(shí)時(shí)調(diào)度有什么好處？

? ? ? 》可以快速隔離故障設(shè)備游昼；

? ? ? 》可以精確控制節(jié)點(diǎn)與機(jī)房的帶寬和資源負(fù)載甘苍；

? ? ? 》可以快速對(duì)應(yīng)業(yè)務(wù)的突發(fā)，特殊適合大文件下載類突發(fā)場景烘豌，比如手機(jī)固件载庭、游戲安裝包、大體積資源的分發(fā)；

準(zhǔn)確性高

? ? ?由于可以拿到請(qǐng)求的出口IP囚聚，在不考慮NAT或小運(yùn)營商出口飄移這種奇葩場景時(shí)靖榕，客戶端歸屬地更貼近真實(shí)情況，不受用戶的DNS配置影響顽铸，配錯(cuò)了也沒關(guān)系茁计；

但是也有限制:

業(yè)務(wù)兼容性

要求客戶業(yè)務(wù)的客戶端必須支持302跟隨，比如手機(jī)固定或應(yīng)用下載谓松，如果下載客戶端不識(shí)別http 302響應(yīng)碼簸淀，那下載就會(huì)失敗。

對(duì)延時(shí)敏感業(yè)務(wù)不適用

這種模式的調(diào)度毒返，每個(gè)請(qǐng)求都會(huì)多出一次http交互。比如web靜態(tài)小資源就不太合適舷手，一個(gè)網(wǎng)站加載幾十個(gè)js/css文件拧簸，每個(gè)文件都302跳轉(zhuǎn)一次？那加載時(shí)間會(huì)成倍增加男窟。

所以302只適用于客戶端兼容性好的大文件下載業(yè)務(wù)盆赤。

TCP優(yōu)化

TCP 優(yōu)化在傳統(tǒng)的性能優(yōu)化領(lǐng)域中很容易在應(yīng)用層面被忽略，通常在 CDN 加速服務(wù)中會(huì)

考慮這個(gè)優(yōu)化歉眷。大型網(wǎng)站不僅有圖片還有動(dòng)態(tài)請(qǐng)求牺六， 經(jīng)過 TCP層面優(yōu)化，可以讓網(wǎng)絡(luò)耗時(shí)變短汗捡。而在 CDN層面淑际，由于大型網(wǎng)站還有大量的圖片和 JS等資源，這些靜態(tài)資源占整個(gè)頁面請(qǐng)求的 90%

以上扇住，所以只要性能提升 10%春缕，整體的性能體驗(yàn)改觀就相當(dāng)明顯。特別是提供全球化服務(wù)的大型網(wǎng)站艘蹋，近幾年發(fā)展非常迅速锄贼，買家分布越來越廣泛∨В跨境最大的挑戰(zhàn)是地理距離長 宅荤， 網(wǎng)絡(luò)延遲天然巨大，例如北美洲到歐洲的網(wǎng)絡(luò)距離 RTT 在 250ms 以上浸策。亞洲到北美洲的網(wǎng)絡(luò)距離 RTT 在 200ms 以上冯键。根據(jù)數(shù)據(jù)初步估計(jì)，南美洲的某個(gè)國家到達(dá)北美洲的美國的請(qǐng)求去包率高達(dá) 6%~l0%的榛。一旦丟包琼了，大部分都會(huì)發(fā)生超時(shí)重傳，基于 3 次重復(fù)ACK 的快速丟包發(fā)現(xiàn)算法，在很多情況下沒有起到作用雕薪。減少丟包時(shí)的網(wǎng)絡(luò)延遲昧诱，對(duì)跨境業(yè)務(wù)來說， 比淘寶在國內(nèi)得到的效益將 更加可觀 所袁。 TCP 協(xié)議枝優(yōu)化涉及 的地方非常多盏档，從增大初始擁塞窗 口到減少默認(rèn)的 RTO、 PRR燥爷、 Early Transmit蜈亩。

TCP邊過 “發(fā)送一應(yīng)答(ACK確認(rèn)〕一重傳機(jī)制”來確保傳輸?shù)目煽啃裕?它是端到端進(jìn)行傳輸?shù)摹?duì)于大型網(wǎng)站 前翎， I向應(yīng)報(bào)文從服務(wù)器端給客戶端瀏覽器進(jìn)行報(bào)文 的傳輸稚配， 所以在服務(wù)器端， 可以迦過優(yōu)化來降低客戶端網(wǎng)絡(luò)耗時(shí)港华。傳統(tǒng)的 TCP底層實(shí)現(xiàn)道川， 在很多時(shí)候會(huì)導(dǎo)致 TCP傳輸放率變低， 特別是網(wǎng)絡(luò)刊’寬的擴(kuò)充和整體網(wǎng)綿硬件技術(shù)的提升立宜， 使得網(wǎng)絡(luò)傳輸速度有很大的變化冒萄。

TCP傳輸是分段的，一個(gè) HTTP響應(yīng)拙文會(huì)被操作系統(tǒng)切成多個(gè) MSS大小(一般為 1460B)的段橙数，發(fā)送端每次只會(huì)發(fā)送若干段尊流。 能夠發(fā)送多少個(gè)數(shù)據(jù)包，由擁塞窗口和|接收端窗 口共同決定灯帮， 直到接收端接收到完整的報(bào)文為止崖技。在此過程中，報(bào)文分段按照順序進(jìn)行發(fā)送钟哥， 所以當(dāng) HTTP 的請(qǐng)求響應(yīng)模型將請(qǐng)求發(fā)送給服務(wù)器時(shí)响疚，服務(wù)器響應(yīng)都需要多個(gè) RTT 的傳輸 ， 物理距離越遠(yuǎn) 瞪醋， 總體網(wǎng)絡(luò)耗時(shí)越長忿晕。

滑動(dòng)窗口本質(zhì)上是描述接收方的 TCP數(shù)據(jù)報(bào)緩沖區(qū)大小的數(shù)據(jù)的， 發(fā)送方根據(jù)這個(gè)數(shù)據(jù)來計(jì)算自 己最多能發(fā)送多長的數(shù)據(jù)银受。如果發(fā)送方收到接收方的窗口大小為 0 的 TCP數(shù)據(jù)報(bào)践盼，那么發(fā)送方將停止發(fā)送數(shù)據(jù)， 等到接收方發(fā)送窗口大小不為 0的數(shù)據(jù)報(bào)的到來宾巍。

1.窗口合攏: 當(dāng)窗口 的左邊緣向右邊緣靠近的時(shí)候咕幻， 這種現(xiàn)象發(fā)生在數(shù)據(jù)被發(fā)送和確認(rèn)的時(shí)候.

2.窗口張開：當(dāng)窗口向右邊緣移動(dòng)時(shí)

3.窗口收縮：當(dāng)窗口右邊緣向左移動(dòng)時(shí)

TCP 就是用這個(gè)窗口，慢慢地從數(shù)據(jù)的左邊緣移動(dòng)到右邊緣顶霞，把處于窗口范圍內(nèi)的數(shù)據(jù)發(fā)送出去肄程，只是窗口內(nèi)的數(shù)據(jù)锣吼，這就是窗口的意義。

擁塞窗口一一發(fā)送端流量控制

Linux 內(nèi)核升級(jí)中的 TCP 優(yōu)化技術(shù)

1.初始擁塞窗口調(diào)整

Early Retransmit (Linux 3.5 開始支持 )

前端優(yōu)化技術(shù)

(1) 合并HTTP請(qǐng)求

HTTP 作為無狀態(tài)的應(yīng)用層協(xié)議蓝厌，對(duì)于每 一 次 HTTP 請(qǐng)求玄叠，通信鏈路建立以及數(shù)據(jù)傳輸都是必不可少的，并且需要在服務(wù)器端單獨(dú)啟動(dòng)線程去處理每個(gè) HTTP 請(qǐng)求拓提。這就代表著DNS查詢读恃、 應(yīng)用層重定向以及404等很可能會(huì)在每一次HTTP請(qǐng)求時(shí)發(fā)生，因此代态，可以通過合并 HTTP 請(qǐng)求的數(shù)目來有效提升訪問性能寺惫，避免這些昂貴的通信服務(wù)和開銷。將css蹦疑、 JavaScript和圖片合并成一個(gè)文件是減少HTTP請(qǐng)求的主要方法西雀，這樣只需要一次請(qǐng)求 即可 。

(2) 使用瀏覽器緩存

靜態(tài)內(nèi)容在網(wǎng)站’中通常更新頻率較低 歉摧，如 css蒋搜、 JavaScript 以及圖片等。上文說過判莉，訪問這些文件每次需要進(jìn)行 HTTP 請(qǐng)求，那么育谬，將這些緩存在瀏覽器中券盅，則可以減少 HTTP 請(qǐng)求的次數(shù)，從而提升網(wǎng)站訪問性能 膛檀。 瀏覽器緩存的設(shè)定是通過設(shè)置 HTTP 頭中的 cache-control與 expires 的屬性來實(shí)現(xiàn)的锰镀，設(shè)定的緩存保留時(shí)間可以短到數(shù)天，長到數(shù)月 咖刃。

值得注意的是泳炉，網(wǎng)站在利用瀏覽器緩存策略更新靜態(tài)內(nèi)容時(shí)， 最好能夠一個(gè)個(gè)文件逐一進(jìn)行更新嚎杨，例如需要更新 20個(gè)圖片時(shí)花鹅，不應(yīng)該將 20個(gè)圖片一次全部集中更新，而是需要相隔一定時(shí)間間隔逐一更新枫浙。 否則刨肃，用戶瀏覽器會(huì)發(fā)生大量緩存突然失效，并且會(huì)造成服務(wù)器負(fù)載突發(fā)性加重以及網(wǎng)絡(luò)堵塞的情況箩帚。

(3)壓縮組件減少通信傳輸

在通信傳輸過程中真友，減少通信傳輸?shù)臄?shù)據(jù)量能起到減少傳輸負(fù)載大小的作用。 通常紧帕，在服務(wù)器端對(duì)需要傳輸?shù)奈募M(jìn)行壓縮盔然，而在用戶瀏覽器端再對(duì)文件進(jìn)行解壓縮，達(dá)到壓縮組件減少通信傳輸?shù)哪康?。 對(duì)于提高壓縮率愈案，可以通過將外部的腳本和樣式合并為 一個(gè)實(shí)現(xiàn) 挺尾。 HTML、css 和 JavaScript 文件利用 GZip 壓縮方式使得壓縮率超過 80%刻帚。然而潦嘶，文件壓縮對(duì)服務(wù)器和瀏覽器都會(huì)產(chǎn)生一定 的壓力 ， 在通信帶寬良好崇众，但服務(wù)器資源不足 的狀況下需要權(quán)衡考慮掂僵。

(4)使用外部 JavaScript和 css

由于JavaScript和css能夠被瀏覽器緩存，因此顷歌， 使用外部文件通常會(huì)較快地打開頁面锰蓬。 而在內(nèi)聯(lián)的情況下， 由于 HT!\在L文檔通常不會(huì)被配置為允許緩存的文件眯漩，所以用戶下一次請(qǐng)求內(nèi)聯(lián) HTML 文檔時(shí) 芹扭， JavaScript和 css 需要再次下載。由此得出赦抖，在外部文件中 舱卡， 可以通過瀏覽器緩存 JavaScript ， 并減少 HTML 文檔队萤，達(dá)到避免增加 HTTP 請(qǐng)求數(shù)量的效果 轮锥。 可以說當(dāng) HTML 文檔數(shù)占的比重過大時(shí)，使用外部文件是一個(gè)有效提升頁面訪問性能的手段 舍杜。

(5)減少 cookie 傳輸

對(duì)于每一次請(qǐng)求和響應(yīng) cookie 過大會(huì)對(duì)數(shù)據(jù)傳輸造成極大影響还惠，所 以需要謹(jǐn)慎考慮并決定把哪些數(shù)據(jù)寫入 cookie嚎幸，以達(dá)到減少 cookie 中傳輸數(shù)據(jù)量的目的骑疆。對(duì)于訪問一些靜態(tài)內(nèi)容， 例如， 對(duì)于 css和 JavaScript等發(fā)送 cookie是沒有意義的拍摇。在這種情況下，通過使用獨(dú)立域名訪問靜態(tài)內(nèi)容的方式幕随， 避免請(qǐng)求靜態(tài)內(nèi)容時(shí)發(fā)送 cookie拥知， 并減少 cookie的傳輸次數(shù)襟齿。

(6)避免 css 表達(dá)式

css 表達(dá)式是一種動(dòng)態(tài)設(shè)置 css 屬性的強(qiáng)大且危險(xiǎn) 的方式拷窜。在人們期望中表達(dá)式不只在頁面呈現(xiàn)和值大小改變時(shí)需要利用表達(dá)式求值窄潭，甚至當(dāng)頁面上下滾動(dòng)，包括鼠標(biāo)在頁面上移過時(shí)嫉你，表達(dá)式都要進(jìn)行求值操作月帝。使用 一 次性表達(dá)式能夠減少 css 表達(dá)式求值次數(shù)。如果 css 表達(dá)式必須被求值一次均抽， 可 以在這次中對(duì)它本身進(jìn)行重寫嫁赏。