边缘节点 如何判断CDN的预热任务是否执行完成刷新 路由追踪 近期最少使用算法

阿里云内容分发网络（Content Delivery Network，简称CDN）是建立并覆盖在承载网之上，由分布在不同区域的边缘节点服务器群组成的分布式网络。阿里云CDN分担源站压力，避免网络拥塞，确保在不同区域、不同场景下加速网站内容的分发，提高资源访问速度。

阿里云CDN将源站资源缓存至阿里云遍布全球的加速节点上，当终端用户请求访问和获取该资源时，无需回源，系统自动调用离终端用户最近的CDN节点上已缓存的资源。接入阿里云CDN的方法，请参考快速入门。

目前，CDN部分节点已支持IPv6进行访问

内容分发网络 CDN https://cloud.baidu.com/doc/CDN/index.html

内容分发网络CDN（Content Delivery Network）将源站内容分发至遍布全国的加速节点，缩短用户查看内容的延迟，提高用户访问网站的响应速度与网站的可用性，解决网络带宽小、用户访问量大、网点分布不均等问题。

CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。

内容分发网络CDN - 产品优势 | 百度智能云文档 https://cloud.baidu.com/doc/CDN/s/Ojwvydwwl

• 精确调度

  根据访问用户的网络接入情况（地区、运营商），结合用户的访问资源地址，实时计算出质量最佳的边缘节点地址，保证用户请求能以最快速度到达百度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

查看PDF

分享

源站是您的网站服务器，是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

1. 当终端用户（北京）向www.a.com下的某资源发起请求时，首先向LDNS（本地DNS）发起域名解析请求。
2. LDNS检查缓存中是否有www.a.com的IP地址记录。如果有，则直接返回给终端用户；如果没有，则向授权DNS查询。
3. 当授权DNS解析www.a.com时，返回域名CNAME www.a.tbcdn.com对应IP地址。
4. 域名解析请求发送至阿里云DNS调度系统，并为请求分配最佳节点IP地址。
5. LDNS获取DNS返回的解析IP地址。
6. 用户获取解析IP地址。
7. 用户向获取的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节点缓存中获取到最新的请求资源，无需再回源站获取。预热功能会提高缓存命中率。

刷新和预热功能的详细说明如下表所示。

分类	原理	生效时间	API接口
URL刷新	通过提供目录下文件的方式，强制CDN节点回源获取最新文件。	5分钟内	RefreshObjectCaches
目录刷新	通过提供目录及目录下所有文件的方式，强制CDN节点回源获取最新文件。		RefreshObjectCaches
URL预热	将指定的资源主动预热到CDN的二级节点上，用户首次访问即可直接命中缓存。		PushObjectCache

加入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

https://help.aliyun.com/knowledge_detail/40205.html

更新时间：2018-10-26 12:07:07

   

不少客户希望阿里云CDN提供回源的节点IP，然后在源站设置IP白名单，只让CDN回源的节点访问，以此防止源站被攻击。

• 但是CDN回源时会智能分配节点访问您的服务器源站，因此回源的IP是不固定的，所以源站服务器不推荐设置回源策略设置为固定的节点IP列表，这样可能会有回源失败情况发生。
• 如果有特殊场景，源站上有安全狗等防护软件确实需要配置白名单，请使用接口 DescribeL2VipsByDomain（ 目前只支持日峰值带宽为1Gbps以上的用户提 工单申请 ），获取CDN回源的IP列表并添加到您服务器的白名单中，以免影响CDN回源获取资源

腾讯云全站加速网络（Enterprise Content Delivery Network，ECDN），为您提供全新的高性能一站式加速服务体验，实现了动静态混合型资源极速、稳定的海量传输。将静态边缘缓存与动态回源路径优化相融合，智能调度最优服务节点，自动识别动静态资源，结合腾讯自研最优链路算法及协议层优化技术，一键操作，即刻全站加速！

ECDN 接入简单，您无需调整自身业务结构，或是进行复杂的操作配置，即可享受全球链路加速服务。您可以通过 快速入门，轻松开启您的 ECDN 加速服务。

加速原理

假设您的业务源站域名为www.test.com，当域名接入 ECDN 开始使用加速服务后，您的用户发起 HTTP 请求，实际的处理流程如下图所示：

详细说明如下：

1. 用户向 www.test.com 下的某动态资源(如：.asp) 或静态（如：文本、图片等）资源发起请求，先要向 Local DNS 发起域名解析请求。
2. 当 Local DNS 解析 www.test.com 时，会发现已经配置了 CNAME 记录 www.test.com.dsa.dnsv1.com，解析请求会发送至 Tencent DNS（GSLB），GSLB 为腾讯云自主研发的调度体系，会为请求分配最佳节点 IP。
3. Local DNS 获取 Tencent DNS 返回的解析 IP。
4. 用户侧获取解析 IP。
5. 用户向获取的 IP 发起对资源的访问请求。
6. 边缘节点若缓存了所需的静态资源，可直接返回给用户。
7. 针对动态资源请求，节点通过智能探测算法，探测到内部网络到源站之间的最优路径，通过最优路径将请求转发至源站。
8. 源站收到请求后，根据请求内容，将动态数据返回给全站加速节点。
9. 全站加速网络通过内部最优链路，将源站返回的动态内容透传给用户。

 

 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厂商帮你定位解决。