我已经从Azure尝试了很多CDN，我认为在使用Web角色成功设置后，我是安全的。
为什么选择网络角色？
好吧，我想要压缩和缓存标头的好处，这是我使用普通 blob 方式无法成功获得的。并作为额外的奖励;区分大小写的限制也被取消了。
选择CDN服务就足够了;虽然之前的所有内容都来自同一域，但现在我或多或少地提供来自 cdn.cuemon.net 的所有"静态"内容。从理论上讲，这应该会提高性能，因为与仅一个域相比，并行浏览器可以将内容收集分散到"多个"域上。
不幸的是，这导致了性能下降，我认为这与提供内容之前的炉灶数量有关（使用 tracert 命令）：
C:Windowssystem32>tracert -d cdn.cuemon.net
Tracing route to az162766.vo.msecnd.net [94.245.68.160]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 21 ms 21 ms 21 ms 87.59.99.217
3 30 ms 30 ms 31 ms 62.95.54.124
4 30 ms 29 ms 29 ms 194.68.128.181
5 30 ms 30 ms 30 ms 207.46.42.44
6 83 ms 61 ms 59 ms 207.46.42.7
7 65 ms 65 ms 64 ms 207.46.42.13
8 65 ms 67 ms 74 ms 213.199.152.186
9 65 ms 65 ms 64 ms 94.245.68.160
C:Windowssystem32>tracert cdn.cuemon.net
Tracing route to az162766.vo.msecnd.net [94.245.68.160]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 21 ms 22 ms 20 ms ge-1-1-0-1104.hlgnqu1.dk.ip.tdc.net [87.59.99.217]
3 29 ms 30 ms 30 ms ae1.tg4-peer1.sto.se.ip.tdc.net [62.95.54.124]
4 30 ms 30 ms 29 ms netnod-ix-ge-b-sth-1500.microsoft.com [194.68.128.181]
5 45 ms 45 ms 46 ms ge-3-0-0-0.ams-64cb-1a.ntwk.msn.net [207.46.42.10]
6 87 ms 59 ms 59 ms xe-3-2-0-0.fra-96cbe-1a.ntwk.msn.net [207.46.42.50]
7 68 ms 65 ms 65 ms xe-0-1-0-0.zrh-96cbe-1b.ntwk.msn.net [207.46.42.13]
8 65 ms 70 ms 74 ms 10gigabitethernet5-1.zrh-xmx-edgcom-1b.ntwk.msn.net [213.199.152.186]
9 65 ms 65 ms 65 ms cds29.zrh9.msecn.net [94.245.68.160]
从上面的跟踪路由中可以看出，所有外部内容都会延迟相当长的一段时间。值得注意的是，Azure服务是在北欧设置的，我在丹麦定居，为什么这条跟踪路线有点..嗯。。过火的？
另一个问题可能是 Web 角色是两个额外的小实例;我还没有找到时间尝试使用两个小实例，但我知道Microsoft将额外的小实例限制在 5Mb/s 的 WAN，其中小型及以上的实例具有 100Mb/s。
我只是不确定这是否也适用于 CDN。
无论如何 - 任何帮助和/或解释都非常感谢。
让我声明一下，我对Azure平台非常满意 - 我只是对上述问题感到好奇。
更新
没有 -d 选项的新跟踪。
受到user728584的启发，我研究并发现了这篇文章，http://blogs.msdn.com/b/scicoria/archive/2011/03/11/taking-advantage-of-windows-azure-cdn-and-dynamic-pages-in-asp-net-caching-content-from-hosted-services.aspx，我将进一步研究公共缓存控制和CDN。
这并不能解释跳数过多的现象，但我希望熟练的网络专业人员可以帮助解决这个问题。
请放心，我会根据我的调查结果及时通知您。
不是说显而易见的，但我假设您已将缓存控制 HTTP 标头设置为大量，以便在您进行跟踪测试时，您的内容不会从 CDN 缓存中删除并从 Blob 存储中提供？
您附近有很多边缘服务器，因此我希望它的性能更好："Windows Azure CDN 节点位置"http://msdn.microsoft.com/en-us/library/windowsazure/gg680302.aspx
Maarten Balliauw有一篇关于CDN的使用和用例的好文章（这可能会有所帮助？）： http://acloudyplace.com/2012/04/using-the-windows-azure-content-delivery-network/
不知道这是否有帮助，有趣...
好的，在我实现公共缓存控制标头之后，CDN 似乎做了预期的事情; 从 CDN 群集中的 x 个节点交付内容。
以上具有它所经历的限制 - 它不是为了具体验证而测量的。
但是，这个链接支持我的理论：http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_windowsazurecdn_topic3，
Blob的生存时间 （TTL） 设置控制 CDN 边缘服务器在从 Blob 存储中的源请求新副本之前返回缓存资源副本的时间。此期限到期后，新请求将强制 CDN 服务器再次从原始 blob 中检索资源，此时它将再次缓存该资源。
这是我假设的挑战;CDN 引用的资源不断汇集原始 blob。
此外，还必须为此链接提供信用（由用户728584提供）;http://blogs.msdn.com/b/scicoria/archive/2011/03/11/taking-advantage-of-windows-azure-cdn-and-dynamic-pages-in-asp-net-caching-content-from-hosted-services.aspx。
现在的最后一个链接：http://blogs.msdn.com/b/windowsazure/archive/2011/03/18/best-practices-for-the-windows-azure-content-delivery-network.aspx
对于 ASP.NET 页，默认行为是将缓存控制设置为私有。在这种情况下，Windows Azure CDN 将不会缓存此内容。若要重写此行为，请使用 Response 对象更改默认缓存控制设置。
因此，到目前为止，我对这个小难题的结论是，您必须密切关注缓存控制（由于显而易见的原因，缓存控制通常设置为私有）。如果您跳过 Web 角色方法，TTL 默认为 72 小时，为什么您可能永远不会体验到我所经历的;因此，它只是开箱即用。
感谢用户728584为我指出正确的方向。