簡單說明：
眾多公有云廠商似乎都是和傳統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數量很少。
圖 1按照全球區域進行POPIP的暴露
表格 1對測試站點統計響應IP的結果
表格中的統計可以證明全球范圍內Azure的CDN實際上只有上面的幾個POPIP暴露了出來，這樣的做法非常簡單也很安全，但也……
單一IP是如何支撐起全球如此多的訪問？
首先這些IP地址都在一個AS自制域內，他們對應的ASN編號都是AS15133，而該編號的所有者就是EDGECAST，他所擁有全球107,072個IPv4地址和16,515,072個IPv6地址。
圖 2世界范圍內AS15133編號所擁有的地址分布情況
圖 3亞太地區以日本分布的IP最多，其次是中國香港
本次測試中還從http headers 頭信息中讀取到了邊緣服務器（edge Servers）的（可能是）物理位置的標記信息ECAcc。
就目前的CDN算法得到來自于中國大陸聯通線路會請求到邊緣服務器的香港點，電信線路會請求到東京點，但是這個信息在6月份的時候都會請求到香港點，不排除CDN度量算法進行自我調整用以更好的適配請求者網絡。
圖 4雖然解析到同一個POPIP（117.18.232.200），但ECAcc的邊緣服務器信息是不一樣
后來我進一步測試了將請求域名綁定到特定POPIP會有怎樣的效果？
測試結果是CDN會根據你指定的POPIP給出對應的邊緣服務器。
圖 5我是電信線路，未進行指定主機與POPIP綁定關系，我拿到了東京都的服務器信息
圖 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也可能出現風險，例如有搗亂者用這個觸發了某防火城.墻，將會影響整體這區域的請求者（這個是猜測）
