Azure CDN - 启用 HTTP 压缩 - 托管 Web 角色

Posted 2023-03-06

【中文标题】Azure CDN - 启用 HTTP 压缩 - 托管 Web 角色

【英文标题】：Azure CDN - Enabling HTTP Compression - Hosted Web Role

【发布时间】：2012-05-12 07:07:08

【问题描述】：

有没有人成功configured Azure CDN for HTTP compression 使用他们的托管网络角色？我们在 Azure 边缘服务器上压缩 HTTP 内容时遇到问题。 CDN 仅缓存内容的未压缩版本。

如果我们从非 Azure 方法中点击我们的资源链接 (webresource.axd)，它会通过 gzip 进行压缩（使用 xxxx.cloudapp.net/cdn/webresource.axd em>) 符合预期。但是，只要我们将资源链接指向 Azure CDN (xxxx.vo.msecnd.net)，尽管浏览器告诉 Azure CDN 它接受 gzip，内容仍会以未压缩的形式提供。

我posted this same issue to Azure Forums，但目前还没有人回复。

在对问题进行故障排除时，Azure CDN 似乎正在剥离 Accept-Encoding HTTP 标头。只是好奇其他人是否有同样的问题。

Azure CDN Best Practices states...

Windows Azure CDN 如何处理压缩内容？

Windows Azure CDN 不会修改（或添加）对您的对象的压缩。 Windows Azure CDN 尊重源基于“Accept-Encoding”标头提供的任何压缩。从 1.4 开始，Azure 存储不支持压缩。如果您使用托管服务对象交付，您可以将 IIS 配置为返回压缩对象。

我们看到的是 CDN 不尊重源 Accept-Encoding，它被剥离了。

【参考方案1】：

通过反复试验发现，Azure CDN 目前存在一个限制，即它不会通过 Accept-Encoding HTTP 标头，除非它找到包含可压缩文件名类型的 QueryString 参数（.js、.cs），或者您正在使用原始名称（jquery.js、site.css 等）请求文件。

这意味着如果您使用AXD resource handler（WebResource.axd 等），则不会执行 HTTP 压缩。如果您附加一个带有 .cs 或 .js 扩展名的 QueryString 参数，Azure CDN 只会传递 Accept-Encoding。

我们使用了一个自定义的 AXD 资源处理程序，所以这对我们来说很容易实现。我们刚刚为我们的组合缩小资源应用了&group=core.js 和&group=core.css，并且压缩按预期工作。很遗憾，当前的Azure CDN documentation 中不存在这个。

简而言之，我们必须从以下位置转换我们的 URI：

https://xxxx.vo.msecnd.net/resourceManager.axd?token=HL80vX5hf3lIAAA

到这里：

https://xxxx.vo.msecnd.net/resourceManager.axd?token=HL80vX5hf3lIAAA&group=core.js

一旦 Azure CDN 在查询字符串中看到.js，它将返回资源的压缩版本。

希望这有助于其他人使用通过 Azure CDN 提供的 Web 资源 (AXD)。

【讨论】：

感谢您的信息。我将接受此反馈并尝试将其包含在文档中。

感谢您的信息。我一直有这个问题。

【参考方案2】：

CDN 从源中获取压缩，而 Windows Azure 存储不直接支持压缩，因此如果您从 Azure 存储源获取 CDN 内容，它将不会被压缩。因此，如果您将内容托管在 Windows Azure 存储中，您将无法拥有压缩内容。要拥有压缩内容，您需要将内容托管在托管服务中，例如作为源的 Web 角色。由于这种类型的来源是基于 IIS 的，因此是一种使用压缩的受支持方式。

Windows Azure CDN 支持 HTTP1.0 上的压缩内容，而且我看到的大多数问题都与 HTTP 1.0 与 HTTP 1.1 的问题有关。因此，当您通过 HTTP 1.0（使用 wget 命令）直接从您的 Web 角色请求您的 CDN 对象时，如果一切正确，您应该获得压缩内容。如果您获得未压缩的内容，那么您就知道问题出在哪里。请确保您已将应用程序和 IIS 本身配置为向 HTTP 1.0 客户端和 HTTP 1.1 客户端提供压缩内容。

我写了一篇详细的博客文章，通过 Web 角色使用 Azure CDN 精确添加 HTTP 压缩：

http://blogs.msdn.com/b/avkashchauhan/archive/2012/03/05/enableing-gzip-compression-with-windows-azure-cdn-through-web-role.aspx

【讨论】：

我确实关注了您的博文（参见上面的问题链接）。检查 IIS 日志时，Azure CDN 流量以 HTTP 1.1 的形式传入。当我们记录 CDN 请求标头时，我们找不到 Accept-Encoding 的源标头。请参阅 Azure 论坛中的 IIS Web Role - CDN Translated Request Headers，其中说明了用于 CDN 转换请求的 HTTP 协议。

如果您在源代码中正确设置了编码，CDN 不会剥离任何标头。我建议使用基本工具，即 WGet 和 Fiddler 来查看使用 CDN 和 blob 端点设置的内容类型，这也将验证您最终实际获得的内容。如果您可以向我提供端点，我肯定可以仔细检查实际设置。

这里是CDN endpoint - 未压缩，这里是dynamically generated resource - 压缩。

当您使用 HTTPS 并且嵌入了域证书和 CNAME 设置时，您需要使用 domainname.com URL 进行 CDN 标头验证。由于缺少域名，我无法验证基于 Web 角色的 HTTPS 端点。您是否还为您的 Web 角色启用了 HTTP 端点？最好先使用 HTTP/HTTPS 端点来验证 SSL 是否存在任何问题。

我们的 Web 角色 (80/443) 中都有启用 HTTP/HTTPS 的端点。在我们的 Web 角色 IIS 日志中，Azure CDN 进入端口 80，而不是 443。 80 - 207.46.206.107 HTTP/1.1 Wget/1.11.4 (cds102.ord9.msecn.net)。为什么 SSL 会影响 HTTP 压缩 - 仍会检索响应？这是否意味着如果我们点击CDN endpoint non-SSL，它会起作用？它仍然没有使用端口 80 进行压缩。

【参考方案3】：

这些关于添加 .css/.js 扩展的答案似乎不再适用于最近（2014 年第一季度）更新的 Azure CDN 服务后端。

我今天用一个新的云服务 Web 角色项目和一个新的 CDN 实例运行了一个独立的测试。

我在我的网络角色（单个实例）中放置了一个 /cdn/style-1.css 文件并通过 CDN 访问它。它没有被压缩。直接访问WAS压缩。

我的 Web 角色服务 gzip 内容的修复是确保 IIS 配置选项 noCompressionForProxies 为“false”（默认为 true）。

这使得 Azure CDN 然后将 gzip 内容发送给我。

附加 css/js 扩展没有任何区别。

请注意，在测试此更改时，它是主机配置更改，因此您必须通过 IIS 管理器（而不是 iisreset）重新启动 IIS 才能使其生效。最后，要测试更改，请务必创建一个新文件（例如 style-2.css）并通过 CDN 请求，以便再次从源服务器获取它。