有意思的 CDN

Clean
Clean
false

7.8 磅
0
2

false
false
false

EN-US
ZH-CN
AR-SA

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:普通表格;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:none;
font-size:10.5pt;
font-family:等线;
mso-ascii-font-family:等线;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:等线;
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:等线;
mso-hansi-theme-font:minor-latin;
mso-font-kerning:1.0pt;}

简单说明：

众多公有云厂商似乎都是和传统CDN厂商一同合作实现在云下的CDN服务供给。

最近甚至有老牌CDN反攻云厂商（CDN厂商卖私有云）。

借着前段时间护网行动，好多CDN都工作的不太正常，有的经过自我调整之后慢慢的都恢复了。

我也借着这个机会了解了很多关于CDN的知识，这里分享给好奇朋友们。

我平时用的最多的公有云服务就是Azure提供的，作为微软的云品牌，Azure的先进，易用，强壮等特性都是行业首屈一指的。

Azure CDN目前可以提供Standard Microsoft、Standard Akamai、Standard Verizon、Premium Verizon 这四种类型，作为微软自己的多种产品（例如powershellgallery.com的下载通道、Defender的安全更新、Azure的门户等）使用Premium Verizon这个类型的居多。看价格Premium Verizon这个类型也是最贵的，看功能Premium Verizon这个类型也是最全的。

分享时间：

不做特别说明，以下阐述均以Premium Verizon这个类型进行。

Azure CDN 的使用过程

1.      用户（Alice）通过使用具有特殊域名的URL（例如<endpoint name>.azureedge.net）来请求文件（也称为资产）。此名称可以是端点主机名或自定义域。DNS将请求路由到性能最佳的POP位置，该位置通常是地理上最靠近用户的POP。

2.      如果POP中没有边缘服务器（edge Servers）将文件放在其缓存中，则POP会从源服务器请求该文件。源服务器可以是Azure Web App，Azure云服务，Azure存储帐户或任何可公开访问的Web服务器。

3.      源服务器将文件返回到POP中的边缘服务器（edge Servers）。

4.      POP中的边缘服务器（edge Servers）缓存该文件并将该文件返回给原始请求者（Alice）。该文件将缓存在POP中的边缘服务器上，直到其HTTP标头指定的生存时间（TTL）到期为止。如果源服务器未指定TTL，则默认TTL为7天。

5.      然后，其他用户可以使用Alice使用的相同URL来请求相同的文件，也可以定向到同一个POP。

6.      如果文件的TTL未过期，则POP边缘服务器（edge Servers）直接从缓存返回文件。此过程可带来更快，响应更好的用户体验。

查看Azure CDN POP位置的链接 https://docs.microsoft.com/en-us/azure/cdn/cdn-pop-locations

以缩写方式查找POP的链接 https://docs.microsoft.com/en-us/azure/cdn/cdn-pop-abbreviations

POP 是一个逻辑概念，自带区域属性，边缘服务器是在CDN算法之后为用户提供被请求文件本体寄存的服务资源，用户无法看到边缘服务器IP地址，但可以看到被请求POPIP中返回的边缘服务器信息（一般以缩写方式提供）。

Azure CDN 厉害之处他会按照地理位置区域统一POP的暴露IP地址，这对简化基于IP的访问策略很有效果。

用联网测试工具get一下Azure CDN 后，可以发现暴露出的IP数量很少。

图  SEQ 图 \*
ARABIC 1按照全球区域进行POPIP的暴露

表格  SEQ 表格 \*
ARABIC 1对测试站点统计响应IP的结果

响应IP	计数项:响应IP
117.18.232.200（亚太地区 edgecast.com）
152.199.19.161（欧洲 EDGECAST.COM verizon.com）
72.21.81.200（美国 edgecast.com）
2606:2800:133:206e:1315:22a5:2006:24fd（美国 edgecast.com）
2606:2800:11f:17a5:191a:18d5:537:22f9（美国 edgecast.com）
2606:2800:147:120f:30c:1ba0:fc6:265a（美国 edgecast.com）
192.16.48.200（南美 EDGECAST.COM edgecast.com）
2606:2800:157:1508:1539:174:1a75:1191（美国 edgecast.com）
总计

表格中的统计可以证明全球范围内Azure的CDN实际上只有上面的几个POPIP暴露了出来，这样的做法非常简单也很安全，但也……

单一IP是如何支撑起全球如此多的访问？

首先这些IP地址都在一个AS自制域内，他们对应的ASN编号都是AS15133，而该编号的所有者就是EDGECAST，他所拥有全球107,072个IPv4地址和16,515,072个IPv6地址。

图  SEQ 图 \*
ARABIC 2世界范围内AS15133编号所拥有的地址分布情况

图  SEQ 图 \*
ARABIC 3亚太地区以日本分布的IP最多，其次是中国香港

本次测试中还从http headers 头信息中读取到了边缘服务器（edge Servers）的（可能是）物理位置的标记信息ECAcc。

就目前的CDN算法得到来自于中国大陆联通线路会请求到边缘服务器的香港点，电信线路会请求到东京点，但是这个信息在6月份的时候都会请求到香港点，不排除CDN度量算法进行自我调整用以更好的适配请求者网络。

图  SEQ 图 \*
ARABIC 4虽然解析到同一个POPIP（117.18.232.200），但ECAcc的边缘服务器信息是不一样

后来我进一步测试了将请求域名绑定到特定POPIP会有怎样的效果？

测试结果是CDN会根据你指定的POPIP给出对应的边缘服务器。

图  SEQ 图 \*
ARABIC 5我是电信线路，未进行指定主机与POPIP绑定关系，我拿到了东京都的服务器信息

图  SEQ 图 \*
ARABIC 6将72.21.81.200 psg-prod-eastus.azureedge.net进行绑定后，我拿到了来自于洛杉矶的服务器信息

总结几点：

至于更详细的CDN算法这个应该是商业机密了，目前测试到的结果已经颠覆了我对传统CDN的概念：

1、原本以为会有一大堆的反馈IP暴露在互联网上

2、Azure CDN 似乎按照请求者链接的POPIP所在的区域分配合适的边缘服务器

3、对智能DNS的需求还是有的，用错了DNS拿到了错误的POPIP，可能会分配到绕路的边缘服务器

4、本以为单一IP会压力很大，但将其与BGP、ASN自治号、暴露的POPIP联系到一起，剩下的就是CDN自己的算法了，其实压力就在内部分担了

5、这种单一IP也可能出现风险，例如有捣乱者用这个触发了某防火城.墙，将会影响整体这区域的请求者（这个是猜测）

-=EOB=-