阿里雲內容分發網絡(Content Delivery Network,簡稱CDN)是創建並覆蓋在承載網之上,由分佈在不一樣區域的邊緣節點服務器羣組成的分佈式網絡。阿里雲CDN分擔源站壓力,避免網絡擁塞,確保在不一樣區域、不一樣場景下加速網站內容的分發,提升資源訪問速度。javascript
阿里雲CDN將源站資源緩存至阿里雲遍及全球的加速節點上,當終端用戶請求訪問和獲取該資源時,無需回源,系統自動調用離終端用戶最近的CDN節點上已緩存的資源。接入阿里雲CDN的方法,請參考快速入門。html
目前,CDN部分節點已支持IPv6進行訪問vue
內容分發網絡 CDN https://cloud.baidu.com/doc/CDN/index.htmljava
內容分發網絡CDN(Content Delivery Network)將源站內容分發至遍及全國的加速節點,縮短用戶查看內容的延遲,提升用戶訪問網站的響應速度與網站的可用性,解決網絡帶寬小、用戶訪問量大、網點分佈不均等問題。nginx

CDN系統可以實時地根據網絡流量和各節點的鏈接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求從新導向離用戶最近的服務節點上。其目的是使用戶可就近取得所需內容,解決 Internet網絡擁擠的情況,提升用戶訪問網站的響應速度。算法
內容分發網絡CDN - 產品優點 | 百度智能雲文檔 https://cloud.baidu.com/doc/CDN/s/Ojwvydwwlapi
-
精確調度瀏覽器
根據訪問用戶的網絡接入狀況(地區、運營商),結合用戶的訪問資源地址,實時計算出質量最佳的邊緣節點地址,保證用戶請求能以最快速度到達百度CDN網絡,獲取到所需的網站內容。緩存
-
高性能緩存安全
- 百度CDN採用自研高性能緩存系統
- 單機配備萬兆網卡、SSD等高性能硬件設施,並配有HTTPS專用加速設備
- 多級分片緩存,熱點資源智能分級存儲,最大程度提高單機命中率
- 低延遲、高吞吐量
-
自助式管理
平臺化接入,自助配置加速;配置項豐富,支持緩存策略、緩存Key計算、回源、視頻、防盜鏈、HTTPS等相關的配置項;一鍵刷新緩存。
-
安全防禦
- 百度自研高性能負載均衡設備
- 有效抵禦DDOS、CC攻擊
- 無縫接入WAF產品,有效過濾惡意請求
-
實時監控
自動分析業務數據,業務狀態一目瞭然;監控數據延時在5分鐘之內,提供分鐘粒度的實時監控數據報表;支持用戶進行日誌下載和轉儲,分析其業務數據。
-
高效回源
- 視頻僞流處理技術保障視頻拖拽無需請求所有數據
- 併發回源請求合併處理,有效收斂回源流量,下降源站訪問壓力
- 根據用戶讀取數據行爲決定回源行爲,可實現用戶讀多少即回源多少,用戶中止則回源中止。有效下降回源率
-
鏈路優化
- 中心節點多線接入,智能選擇回源鏈路
- 骨幹網接入,豐富的專線資源
- 深度優化的TCP/IP協議,有效保障用戶訪問質量
回源跟隨302
回源配置中,CDN還支持回源跟隨302功能。當用戶發送請求且節點未緩存時,節點會請求源站獲取資源。若源站返回狀態碼爲302,則說明資源仍存在、但臨時改變了位置。
- 開啓回源跟隨302後,當用戶發起請求獲取A地址資源時,若節點收到302狀態碼,會跳轉至新的地址B並獲取資源。獲取資源後,緩存至節點,並返回資源給用戶。當其餘用戶也向A地址資源發起請求時,則在節點命中。
- 若不開啓「回源跟隨302」功能,當用戶發起請求且節點收到302狀態碼後,會將HTTP Response返回給用戶。當其餘用戶也向該資源發起請求時,則重複上述步驟。
說明:開啓回源跟隨302功能以後,最多僅限3跳,不然直接返回302給用戶。
Range回源
CDN 爲客戶提供 Range 回源配置功能,Range 是 Http 請求頭,用於文件指定部分的請求。如:Range: bytes=0-999 就是請求該文件的前 1000 個字節。開啓 Range 回源配置可以有效提升大文件分發效率,提高響應速度。此功能須要源站支持 range 請求,不然會致使回源失敗。
協議跟隨回源
回源設置中,CDN還支持協議跟隨回源。默認狀況下,CDN節點以HTTP協議回源。開啓此功能,CDN節點回源協議與客戶端訪問協議保持一致。即若客戶端採用HTTP協議請求源站資源,且CDN節點未緩存該資源,則節點採用相同的HTTP協議方式回源請求資源;同理,若客戶端採用HTTPS協議且節點未緩存,則節點採用相同的HTTPS協議回源。
私有Bucket回源
源站爲BOS且Bucket設置爲私有,開啓CDN加速時,用戶沒法經過訪問CDN加速域名來訪問該Bucket資源。若須要實現CDN可訪問私有BOS Bucket,可在「回源配置」中開啓「私有Bucket回源」功能對CDN進行受權,便可實現CDN回源至私有BOS Bucket。此功能可實現用戶保護源站資源同時達到使用CDN加速的效果。
移動訪問配置
百度智能雲CDN將經過對請求中User-Agent的判斷,使得CDN用戶能夠經過開啓移動訪問開關來有針對性及差別性的管理移動端/PC端的資源內容分發。
回源HOST配置
更新時間:
2019/08/26
回源HOST是CDN節點在回源過程當中,在源站訪問的站點域名,即HTTP請求頭中的HOST信息。配置回源HOST後,CDN在回源過程當中會根據HOST信息去對應站點獲取資源。
背景信息
源站與回源HOST的區別以下所示:
- 源站:源站的IP地址或域名指引CDN節點回源到對應的源站服務器。
- 回源HOST:源站服務器上可能存在多個站點,回源HOST指明瞭資源所在的具體站點域名。
注意事項
- 域名添加後,CDN默認回源HOST爲您的加速域名。若您的源站綁定了多個站點域名,且加速域名不是您指望CDN在回源時請求的站點域名時,您須要自定義回源HOST來指明站點域名。
- 若您的源站類型爲IP地址或域名,您的回源HOST類型默認爲加速域名。
- 若使用華爲雲OBS桶做爲源站時,默認使用OBS域名做爲回源HOST,不可修改。
- 若您以源站域名形式將華爲雲OBS桶或其餘雲廠商的對象存儲桶接入CDN做爲源站,請將回源HOST自定義爲您的對象存儲桶域名,不然會形成回源失敗。
Range回源配置
更新時間:
2019/08/26 GMT+08:00
Range回源是指源站在收到CDN節點回源請求時,根據http請求頭中的Range信息返回指定範圍的數據給CDN節點。
背景信息
- Range信息的做用是在http請求頭中指定返回數據的範圍,即第一個字節的位置和最後一個字節的位置。如:Range: bytes=0-100就是請求該文件的前101個字節的數據內容。
- Range回源能有效縮短大文件的分發時間,提高回源效率,減小回源消耗。
注意事項
開啓Range回源的前提是您的源站支持Range請求,不然可能致使回源失敗。
302回源跟隨配置_CDN_用戶指南_配置管理_回源配置_華爲雲 https://support.huaweicloud.com/usermanual-cdn/cdn_01_0028.html
302回源跟隨配置
更新時間:
2019/08/26 GMT+08:00
開啓302回源跟隨配置後,當CDN節點回源請求源站返回302狀態碼時,CDN節點會先跳轉到302對應地址獲取資源,緩存後再返回給用戶。
背景信息
若您的源站地址因業務需求作了302 重定向,當CDN節點向源站發起回源請求時,源站會向CDN節點返回302狀態碼,CDN節點後續處理以下:
- 未開啓302回源跟隨:CDN節點會將302對應跳轉地址直接返回給用戶,讓用戶本身去請求跳轉地址的資源。若該跳轉地址域名未加入CDN,則該請求過程不會有CDN加速效果。
- 已開啓302回源跟隨:CDN節點會先跳轉到302對應地址獲取用戶所需資源後緩存至節點並返回給用戶,當其餘用戶再次請求一樣資源時會直接命中節點緩存。
協議跟隨回源是指回源使用的協議和客戶端訪問資源的協議保持一致。若是客戶端使用HTTPS方式請求資源,當節點上未緩存該資源時,會使用相同的HTTPS方式回源獲取資源。同理,若是客戶端使用HTTP協議,CDN節點也將使用HTTP協議回源。
修改源站信息_CDN_用戶指南_配置管理_華爲雲 https://support.huaweicloud.com/usermanual-cdn/zh-cn_topic_0064907810.html
更新時間:
2019/08/26 GMT+08:00
源站是您的網站服務器,是CDN加速分發數據的來源。若您的源站信息須要修改(如源站IP,源站域名或OBS桶域名),您能夠經過源站配置頁面修改源站信息。
背景說明
- 您在添加加速域名時配置的源站會被CDN默認爲主源站,您也能夠在源站配置頁面添加熱備源站。熱備源站添加後,當主源站發生故障時,回源請求將分配到熱備源站。配置了熱備源站後能夠有效下降回源失敗率。
- 主源站存在多個IP地址時,CDN回源時會採用輪詢機制,若主源站的全部IP地址輪詢都失敗,則開始備源站IP地址的輪詢。 輪詢時間的機制以下:
- 當某個IP地址鏈接超時,2秒超時後會切換到下一個IP地址。
- 當收到4xx、5xx錯誤碼時,會當即切換到下一個IP地址。
教程示例:使用自定義域名設置靜態網站託管_靜態網站託管_開發指南_對象存儲 OSS-阿里雲 https://help.aliyun.com/document_detail/67323.html
步驟 5:(可選)使用阿里雲 CDN 加快網站速度
您可使用阿里雲 CDN 改善網站性能。CDN 讓您的網站文件(如 HTML、圖像和視頻)可供全球各地的數據中心(即,邊緣節點)使用。當訪問者從您的網站請求文件時,CDN 自動將請求重定向到最近邊緣節點上的文件副本。所以下載速度要快於訪問者從較遠的數據中心請求內容。
CDN 在邊緣節點緩存內容的時間長度由您指定。若是訪問者請求的內容的緩存時間超過了到期日期,CDN 會檢查源服務器,看看是否有新版本的內容可用。若是有新版本,CDN 將新版本複製到邊緣節點。您對原始內容所作的更改會在訪問者請求內容時複製到邊緣節點。但在到期日期前,內容仍爲以前的版本。咱們建議打開CDN 緩存自動刷新開關,以便您對原始內容所作的更改能夠在 CDN 緩存中自動實時刷新。

https://cloud.baidu.com/doc/CDN/s/Zjwvydyev/
如何判斷CDN的預熱任務是否執行完成

Via的後半部分表明一級節點的狀態,「M」表示一級節點上沒有緩存,須要向二級節點回源。
Via的前半部分表明二級節點狀態,其中的「H」表示命中,說明文件已經預熱到二級節點了,不須要再回源站了。
源站文件目錄上傳文件後第一次請求
Via: cache38.l2cn1813[34,200-0,M], cache10.l2cn1813[36,0], kunlun10.cn1361[171,200-0,M], kunlun1.cn1361[175,0]
X-Cache: MISS TCP_MISS dirn:-2:-2
X-Swift-CacheTime: 10
X-Swift-SaveTime: Tue, 24 Sep 2019 07:51:53 GMT
以後請求
Via: cache38.l2cn1813[17,304-0,H], cache49.l2cn1813[18,0], kunlun10.cn1361[84,200-0,H], kunlun3.cn1361[86,0]
X-Cache: HIT TCP_REFRESH_HIT dirn:-2:-2
X-Swift-CacheTime: 10
X-Swift-SaveTime: Tue, 24 Sep 2019 07:52:10 GMT

- 當終端用戶(北京)向
www.a.com
下的某資源發起請求時,首先向LDNS(本地DNS)發起域名解析請求。
- LDNS檢查緩存中是否有
www.a.com
的IP地址記錄。若是有,則直接返回給終端用戶;若是沒有,則向受權DNS查詢。
- 當受權DNS解析
www.a.com
時,返回域名CNAME www.a.tbcdn.com
對應IP地址。
- 域名解析請求發送至阿里雲DNS調度系統,併爲請求分配最佳節點IP地址。
- LDNS獲取DNS返回的解析IP地址。
- 用戶獲取解析IP地址。
- 用戶向獲取的IP地址發起對該資源的訪問請求。
- 若是該IP地址對應的節點已緩存該資源,則會將數據直接返回給用戶,例如,圖中步驟7和8,請求結束。
- 若是該IP地址對應的節點未緩存該資源,則節點向源站發起對該資源的請求。獲取資源後,結合用戶自定義配置的緩存策略,將資源緩存至節點,例如,圖中的北京節點,並返回給用戶,請求結束。配置緩存策略的操做方法,請參見緩存配置。
http://test.com/img.jpg 已經能夠經過cdn訪問;
上傳新同名文件覆蓋
從新訪問,發現已經更新;
Server: Tengine
Timing-Allow-Origin: *
Via: cache30.l2cn1829[59,200-0,M], cache31.l2cn1829[89,0], kunlun7.cn556[169,200-0,M], kunlun1.cn556[192,0]
X-Cache: MISS TCP_MISS dirn:-2:-2
X-Swift-CacheTime: 10
X-Swift-SaveTime: Tue, 24 Sep 2019 09:01:56 GMT
Server: Tengine
Timing-Allow-Origin: *
Via: cache30.l2cn1829[30,304-0,H], cache31.l2cn1829[31,0], kunlun7.cn556[46,200-0,H], kunlun9.cn556[47,0]
X-Cache: HIT TCP_REFRESH_HIT dirn:-2:-2
X-Swift-CacheTime: 10
X-Swift-SaveTime: Tue, 24 Sep 2019 09:02:15 GMT
請問:
刷新機制是自動的嗎?cdn經過什麼原理判斷同名文件已經被覆蓋修改?
CDN提供資源的刷新和預熱功能。經過刷新功能,您能夠強制CDN節點回源並獲取最新文件;經過預熱功能您能夠在業務高峯期預熱熱門資源,提升資源訪問效率。本文檔爲您介紹了刷新和預熱功能的原理、生效時間及可參考的API接口。
CDN提供的資源的刷新和預熱功能的概念以下:
- 刷新功能是指提交URL刷新或目錄刷新請求後,CDN節點的緩存內容將會被強制過時,當您向CDN節點請求資源時,CDN會直接回源站獲取對應的資源返回給您,並將其緩存。刷新功能會下降緩存命中率。
- 預熱功能是指提交URL預熱請求後,源站將會主動將對應的資源緩存到CDN節點,當您首次請求時,就能直接從CDN節點緩存中獲取到最新的請求資源,無需再回源站獲取。預熱功能會提升緩存命中率。
刷新和預熱功能的詳細說明以下表所示。
加入CDN前
業務A:vue-->靜態文件+api
1.2.3.4:8080
1.2.3.4:8080/a.js
1.2.3.4:8080/api/users
/api/ nginx轉發至 api地址1.2.3.4:8002
加入cdn後
加速域名提交CDN服務商-->test.a.com ,獲取域名別名cname test.a.com.cname.com,將回原設置爲1.2.3.4:8080
去域名服務商將test.a.com解析爲cname test.a.com.cname.com
瀏覽器訪問
test.a.com/a.js
test.a.com/api/users
http://test.a.com/refresh.js
HTTP/1.1 200 OK
Server: NWS_SP
Connection: keep-alive
Date: Thu, 17 Oct 2019 04:24:38 GMT
Cache-Control: max-age=600
Expires: Thu, 17 Oct 2019 04:34:38 GMT
Last-Modified: Thu, 17 Oct 2019 03:21:10 GMT
Content-Type: application/javascript
Content-Length: 9941
Content-Encoding: gzip
X-NWS-LOG-UUID: 5814350013937829399 9c94fcf93ba51a78d603327a03ba59b8
X-Cache-Lookup: Hit From Disktank3 Gz
https://cloud.tencent.com/document/product/228/11207
- X-Cache-Lookup:Hit From MemCache 表示命中 CDN 節點的內存。
- X-Cache-Lookup:Hit From Disktank 表示命中 CDN 節點的磁盤。
【檢查源站是否能正常訪問】
接入 CDN 以後網站打不開,如何排查?
請先檢查接入域名的 CDN 狀態是否爲「已關閉」,若爲「已關閉」狀態則對應網頁沒法打開。若非「已關閉」狀態時,可按照下列步驟進一步檢查:
- 經過 ping 或 nslookup 檢查該域名的 CNAME 解析是否已生效。若未綁定 CNAME,您能夠參考 CNAME 配置 文檔中的操做說明,在您的 DNS 服務商處綁定 CNAME。
- 待 CNAME 生效後,檢查源站是否能正常訪問。
C:\Users\test>tracert test-tx.a.com
經過最多 30 個躍點跟蹤
到 2012345.dispatch.spcdntip.com [101.71.72.192] 的路由:
1 <1 毫秒 <1 毫秒 <1 毫秒 192.168.10.1
2 2 ms 4 ms 3 ms 119.139.196.1
3 3 ms 3 ms 3 ms 202.105.153.225
4 8 ms 9 ms 9 ms 183.56.65.18
5 24 ms 25 ms 27 ms 202.97.85.126
6 34 ms 28 ms 29 ms 202.97.78.193
7 * * * 請求超時。
8 33 ms 36 ms 30 ms 219.158.45.161
9 38 ms 38 ms 38 ms 219.158.108.125
10 30 ms 29 ms 30 ms 101.71.68.146
11 30 ms 28 ms 29 ms 101.71.68.86
12 28 ms 31 ms 29 ms 101.71.72.192
跟蹤完成。
您查詢的 IP:101.71.72.192
所在地理位置:浙江省寧波市 聯通
GeoIP: Hangzhou, Zhejiang, China
C:\Users\test>tracert test-tx.a.com
經過最多 30 個躍點跟蹤
到 2012345.dispatch.spcdntip.com [59.80.39.110] 的路由:
1 <1 毫秒 <1 毫秒 <1 毫秒 192.168.10.1
2 4 ms 3 ms 16 ms 119.139.196.1
3 * 3 ms 2 ms 121.35.14.177
4 7 ms 6 ms 14 ms 183.56.65.6
5 9 ms 6 ms 6 ms 202.97.18.245
6 * * * 請求超時。
7 7 ms 6 ms 6 ms 219.158.9.29
8 40 ms 44 ms 82 ms 219.158.8.106
9 27 ms 27 ms 33 ms 43.254.100.2
10 39 ms 29 ms 29 ms 43.254.100.34
11 28 ms 28 ms 28 ms 59.80.9.250
12 27 ms 27 ms 27 ms 59.80.39.110
跟蹤完成。
您查詢的 IP:59.80.39.110
所在地理位置:貴州省貴陽市 聯通沃雲
GeoIP: China
[root@offical ~]# traceroute www.baidu.com
traceroute to www.baidu.com (14.215.177.38), 30 hops max, 60 byte packets
1 * * *
2 11.220.37.13 (11.220.37.13) 8.126 ms 7.993 ms 11.220.36.13 (11.220.36.13) 4.751 ms
3 * 11.220.37.54 (11.220.37.54) 4.641 ms 4.774 ms
4 11.217.38.234 (11.217.38.234) 2.059 ms 11.217.38.202 (11.217.38.202) 1.876 ms 11.217.38.234 (11.217.38.234) 2.092 ms
5 42.120.253.9 (42.120.253.9) 2.142 ms 42.120.253.1 (42.120.253.1) 2.120 ms 116.251.117.150 (116.251.117.150) 2.284 ms
6 116.251.113.137 (116.251.113.137) 2.886 ms 2.667 ms 42.120.242.221 (42.120.242.221) 2.502 ms
7 183.61.45.13 (183.61.45.13) 92.184 ms 183.61.45.9 (183.61.45.9) 3.171 ms 183.61.45.5 (183.61.45.5) 3.620 ms
8 183.2.182.125 (183.2.182.125) 3.091 ms 183.2.182.117 (183.2.182.117) 3.176 ms 58.61.162.153 (58.61.162.153) 4.305 ms
9 119.147.221.245 (119.147.221.245) 3.921 ms 119.147.221.237 (119.147.221.237) 4.087 ms 119.147.221.197 (119.147.221.197) 6.758 ms
10 113.96.0.18 (113.96.0.18) 10.069 ms 113.96.4.242 (113.96.4.242) 6.450 ms 113.96.4.254 (113.96.4.254) 13.947 ms
11 113.96.11.78 (113.96.11.78) 39.365 ms 39.523 ms 38.338 ms
12 14.215.32.130 (14.215.32.130) 8.034 ms 14.29.121.194 (14.29.121.194) 8.729 ms 14.29.121.198 (14.29.121.198) 7.778 ms
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[root@offical ~]# traceroute test-tx.a.com
traceroute to test-tx.a.com (113.105.165.138), 30 hops max, 60 byte packets
1 * * *
2 11.220.36.13 (11.220.36.13) 6.365 ms 11.220.37.77 (11.220.37.77) 6.949 ms 11.220.37.13 (11.220.37.13) 6.773 ms
3 11.220.36.118 (11.220.36.118) 5.129 ms 11.220.36.138 (11.220.36.138) 5.972 ms 11.220.37.138 (11.220.37.138) 5.740 ms
4 11.217.38.222 (11.217.38.222) 1.632 ms 11.217.38.254 (11.217.38.254) 1.929 ms 11.217.38.218 (11.217.38.218) 1.708 ms
5 42.120.253.13 (42.120.253.13) 2.413 ms 119.38.215.78 (119.38.215.78) 2.380 ms 116.251.117.154 (116.251.117.154) 1.926 ms
6 116.251.113.157 (116.251.113.157) 2.355 ms 42.120.242.229 (42.120.242.229) 3.029 ms 116.251.113.137 (116.251.113.137) 11.729 ms
7 183.61.45.5 (183.61.45.5) 3.201 ms 183.2.184.129 (183.2.184.129) 2.566 ms 183.2.184.141 (183.2.184.141) 2.726 ms
8 58.61.162.141 (58.61.162.141) 4.098 ms * *
9 119.147.221.185 (119.147.221.185) 7.210 ms 119.147.221.233 (119.147.221.233) 3.654 ms 119.147.221.241 (119.147.221.241) 4.024 ms
10 14.108.36.59.broad.dg.gd.dynamic.163data.com.cn (59.36.108.14) 8.521 ms 10.108.36.59.broad.dg.gd.dynamic.163data.com.cn (59.36.108.10) 12.332 ms 50.107.36.59.broad.dg.gd.dynamic.163data.com.cn (59.36.107.50) 10.170 ms
11 113.105.160.222 (113.105.160.222) 6.588 ms 6.860 ms 183.60.171.2 (183.60.171.2) 8.351 ms
12 183.6.238.194 (183.6.238.194) 16.148 ms 183.6.236.18 (183.6.236.18) 12.546 ms 183.6.238.186 (183.6.238.186) 13.272 ms
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[root@offical ~]# traceroute www.a.com
traceroute to www.a.com (120.79.10.111), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[root@offical ~]# traceroute test-tx.a.com
traceroute to test-tx.a.com (14.215.85.239), 30 hops max, 60 byte packets
1 * * *
2 11.220.36.13 (11.220.36.13) 5.907 ms 11.220.37.77 (11.220.37.77) 8.643 ms 8.377 ms
3 11.220.37.118 (11.220.37.118) 8.787 ms 11.220.37.130 (11.220.37.130) 11.450 ms *
4 11.217.38.250 (11.217.38.250) 1.910 ms 11.217.38.254 (11.217.38.254) 30.349 ms 11.217.38.202 (11.217.38.202) 5.620 ms
5 119.38.215.138 (119.38.215.138) 2.210 ms 116.251.117.158 (116.251.117.158) 5.359 ms 119.38.215.142 (119.38.215.142) 2.392 ms
6 42.120.242.233 (42.120.242.233) 2.922 ms 116.251.113.153 (116.251.113.153) 3.437 ms 42.120.242.233 (42.120.242.233) 2.897 ms
7 183.61.45.9 (183.61.45.9) 3.590 ms 183.2.184.141 (183.2.184.141) 22.111 ms 183.61.45.13 (183.61.45.13) 3.683 ms
8 * * 183.2.182.129 (183.2.182.129) 3.574 ms
9 119.147.221.173 (119.147.221.173) 7.452 ms * *
10 183.59.15.182 (183.59.15.182) 3.460 ms 183.59.12.6 (183.59.12.6) 6.091 ms 183.2.253.102 (183.2.253.102) 6.981 ms
11 183.59.15.122 (183.59.15.122) 7.472 ms 183.59.14.14 (183.59.14.14) 12.142 ms 183.59.14.226 (183.59.14.226) 10.448 ms
12 59.33.39.229 (59.33.39.229) 8.249 ms 59.33.39.73 (59.33.39.73) 12.236 ms 59.33.39.42 (59.33.39.42) 7.563 ms
13 59.33.39.126 (59.33.39.126) 7.226 ms 9.532 ms 12.243 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[root@offical ~]#
注意www.a.com是A記錄至
您查詢的 IP:120.79.10.111
所在地理位置:廣東省深圳市 阿里雲
GeoIP: Hangzhou, Zhejiang, China
C:\Users\test>tracert test-cdn-ali.a.com
經過最多 30 個躍點跟蹤
到 test-cdn-ali.a.com.w.kunlungr.com [47.246.23.232] 的路由:
1 <1 毫秒 <1 毫秒 <1 毫秒 192.168.110.1
2 4 ms 3 ms 2 ms 119.139.196.1
3 * 3 ms 2 ms 121.34.247.69
4 8 ms 9 ms 6 ms 183.56.65.54
5 280 ms 20 ms 11 ms 202.97.91.30
6 16 ms 18 ms 15 ms 202.97.91.198
7 199 ms 198 ms 196 ms 202.97.89.138
8 181 ms 182 ms 181 ms 202.97.50.78
9 177 ms 177 ms 177 ms ae-63.a01.snjsca04.us.bb.gin.ntt.net [129.250.9.73]
10 180 ms 180 ms * ae-5.r02.snjsca04.us.bb.gin.ntt.net [129.250.3.162]
11 180 ms 180 ms * ae-1.a02.snjsca04.us.bb.gin.ntt.net [129.250.3.103]
12 180 ms 182 ms 182 ms ae-0.taobao.snjsca04.us.bb.gin.ntt.net [129.250.195.194]
13 * * * 請求超時。
14 180 ms * 180 ms 47.246.23.232
跟蹤完成。
C:\Users\test>tracert test-cdn-ali.a.com
經過最多 30 個躍點跟蹤
到 test-cdn-ali.a.com.w.kunlungr.com [47.246.23.233] 的路由:
1 <1 毫秒 <1 毫秒 <1 毫秒 192.168.110.1
2 3 ms 2 ms 2 ms 119.139.196.1
3 3 ms 3 ms 3 ms 202.105.153.229
4 45 ms 12 ms 6 ms 183.56.65.2
5 * 7 ms * 202.97.94.134
6 7 ms 11 ms 8 ms 202.97.12.9
7 * 166 ms 171 ms 202.97.62.66
8 172 ms 174 ms 173 ms 202.97.50.54
9 175 ms 167 ms 168 ms ae-63.a01.snjsca04.us.bb.gin.ntt.net [129.250.9.73]
10 166 ms 167 ms 167 ms ae-2.r01.snjsca04.us.bb.gin.ntt.net [129.250.2.49]
11 273 ms 214 ms * ae-0.a02.snjsca04.us.bb.gin.ntt.net [129.250.2.3]
12 171 ms 170 ms 172 ms ae-0.taobao.snjsca04.us.bb.gin.ntt.net [129.250.195.194]
13 * * * 請求超時。
14 172 ms * 180 ms 47.246.23.233
跟蹤完成。
C:\Users\test>
您如今的 IP:119.139.198.147
所在地理位置:廣東省深圳市 電信
GeoIP: Shenzhen, Guangdong, China
您查詢的 IP:47.246.23.232
所在地理位置:香港特別行政區 阿里雲
GeoIP: San Mateo, California, United States
您查詢的 IP:47.246.23.232
所在地理位置:香港特別行政區 阿里雲
GeoIP: San Mateo, California, United States
很多客戶但願阿里雲CDN提供回源的節點IP,而後在源站設置IP白名單,只讓CDN回源的節點訪問,以此防止源站被攻擊。
- 可是CDN回源時會智能分配節點訪問您的服務器源站,所以回源的IP是不固定的,因此源站服務器不推薦設置回源策略設置爲固定的節點IP列表,這樣可能會有回源失敗狀況發生。
- 若是有特殊場景,源站上有安全狗等防禦軟件確實須要配置白名單,請使用接口 DescribeL2VipsByDomain( 目前只支持日峯值帶寬爲1Gbps以上的用戶提 工單申請 ),獲取CDN回源的IP列表並添加到您服務器的白名單中,以避免影響CDN回源獲取資源

騰訊雲全站加速網絡(Enterprise Content Delivery Network,ECDN),爲您提供全新的高性能一站式加速服務體驗,實現了動靜態混合型資源極速、穩定的海量傳輸。將靜態邊緣緩存與動態回源路徑優化相融合,智能調度最優服務節點,自動識別動靜態資源,結合騰訊自研最優鏈路算法及協議層優化技術,一鍵操做,即刻全站加速!
ECDN 接入簡單,您無需調整自身業務結構,或是進行復雜的操做配置,便可享受全球鏈路加速服務。您能夠經過 快速入門,輕鬆開啓您的 ECDN 加速服務。
加速原理
假設您的業務源站域名爲www.test.com
,當域名接入 ECDN 開始使用加速服務後,您的用戶發起 HTTP 請求,實際的處理流程以下圖所示:

詳細說明以下:
- 用戶向
www.test.com
下的某動態資源(如:.asp) 或靜態(如:文本、圖片等)資源發起請求,先要向 Local DNS 發起域名解析請求。
- 當 Local DNS 解析
www.test.com
時,會發現已經配置了 CNAME 記錄 www.test.com.dsa.dnsv1.com
,解析請求會發送至 Tencent DNS(GSLB),GSLB 爲騰訊雲自主研發的調度體系,會爲請求分配最佳節點 IP。
- Local DNS 獲取 Tencent DNS 返回的解析 IP。
- 用戶側獲取解析 IP。
- 用戶向獲取的 IP 發起對資源的訪問請求。
- 邊緣節點若緩存了所需的靜態資源,可直接返回給用戶。
- 針對動態資源請求,節點經過智能探測算法,探測到內部網絡到源站之間的最優路徑,經過最優路徑將請求轉發至源站。
- 源站收到請求後,根據請求內容,將動態數據返回給全站加速節點。
- 全站加速網絡經過內部最優鏈路,將源站返回的動態內容透傳給用戶。
https://tig.qpic.cn/doc/2018騰訊移動遊戲技術評審標準與實踐案例.pdf
CDN的問題主要是和各個CDN廠商相關,好比有些CDN廠商的CDN池分兩種:
小資源CDN池:總體帶寬相對小,支持頻繁更新(回源頻率快),邊緣節點多,離用戶近,下載更快。
大資源CDN池:總體帶寬大,不支持頻繁更新(大資源對回源服務器壓力大),邊緣節點少,主要集中在大城市,下載相對較慢。
這裏就要注意:
1.大的整包資源儘可能不要放在小資源CDN池,假如該CDN每十分鐘清理文件併到回源服務器去拉取最新文件,會致使每十分鐘你的整包資源會被刪掉,而且在回源完成的過程當中沒法下載成功。
2.圖片、配置文件、公告等小資源可放在小資源CDN池,這樣配置文件,公告等常常更新的資源更新後會更快速及時的被用戶下載到。
3.通常CDN邊緣節點會有LRU(Least Recently Used)近期最少使用算法,若是你的資源老被淘汰到磁盤上而非內存中,必然致使下載速度相對較慢,若是CDN邊緣節點負載太高,也會致使下載較慢或者失敗,這些須要找CDN廠商幫你定位解決。