9

我已经对 Azure 的 CDN 进行了相当多的实验，并且我认为在使用 Web 角色成功设置后我是安全的。

为什么是网络角色？

好吧，我想要压缩和缓存标头的好处，而我使用普通 blob 方式未能成功获得这些好处。作为额外的奖励；区分大小写的约束也被消除了。

选择 CDN 服务就够了；虽然之前的所有内容都来自同一个域，但我现在或多或少地提供来自 cdn.cuemon.net 的所有“静态”内容。从理论上讲，这应该会提高性能，因为与仅一个域相比，并行浏览器可以将内容收集传播到“多个”域上。

不幸的是，这导致性能下降，我认为这与提供内容之前的滚刀数量有关（使用 tracert 命令）：

C:\Windows\system32>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:\Windows\system32>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]

从上面的trace route可以看出，所有外部内容都延迟了相当长的一段时间。值得注意的是，Azure服务设置在北欧，我定居在丹麦，为什么这条trace route有点..hmm..过头了？

另一个问题可能是 web-role 是两个额外的小实例；我还没有时间尝试使用两个小型实例，但我知道 Microsoft 将额外的小型实例限制为 5Mb/s WAN，而小型及以上的实例则为 100Mb/s。

我只是不确定这是否也适用于 CDN。

无论如何-非常感谢任何帮助和/或解释。

让我声明，我对 Azure 平台非常满意——我只是对上述问题感到好奇。

更新

不带 -d 选项的新 tracert。

受到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。

这并不能解释跳数过多的现象，但我希望熟练的网络专业人员可以帮助解决这个问题。

请放心，我会根据我的调查结果及时通知您。

4

2 回答 2

4

不说很明显，但我假设您已将 Cache-Control HTTP 标头设置为一个很大的数字，以便在您进行 Tracert 测试时，您的内容不会从 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/

不确定这是否有帮助，有趣...

于 2012-04-25T00:05:56.977 回答
4

好的，在我实现了公共缓存控制标头之后，CDN 似乎做了预期的事情；从 CDN 集群中的 x 个节点传送内容。

以上具有它所经历的限制 - 它不是为具体验证而测量的。

但是，此链接支持我的理论：http: //msdn.microsoft.com/en-us/wazplatformtrainingcourse_windowsazurecdn_topic3，

Blob 的生存时间 (TTL) 设置控制 CDN 边缘服务器在从 Blob 存储中的源请求新副本之前返回缓存资源副本的时间。一旦此期限到期，新的请求将强制 CDN 服务器再次从原始 blob 中检索资源，此时它将再次缓存它。

这是我假设的挑战；CDN 引用的资源不断汇集原始 blob。

此外，此链接也必须提供学分（由 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-从托管服务.aspx。

现在的最后一个链接：http: //blogs.msdn.com/b/windowsazure/archive/2011/03/18/best-practices-for-the-windows-azure-content-delivery-network.aspx

对于 ASP.NET 页面，默认行为是将缓存控制设置为 private。在这种情况下，Windows Azure CDN 不会缓存此内容。要覆盖此行为，请使用 Response 对象更改默认缓存控制设置。

所以到目前为止，我对这个小谜题的结论是，你必须密切注意你的缓存控制（出于显而易见的原因，它通常设置为私有）。如果您跳过网络角色方法，则 TTL 默认为 72 小时，为什么您可能永远无法体验我所经历的；因此它可以开箱即用。

感谢user728584为我指明了正确的方向。

于 2012-04-27T11:13:46.543 回答