使用 IIS 压缩

2024-03-14

本文概述了如何使用 IIS 压缩。

Compression Level

HTTP 压缩是针对带宽的 CPU 权衡。对于给定的压缩算法，实现更高的压缩比率通常压缩速度较慢，反之亦然。压缩比率与速度之间的平衡由压缩级别控制。 iiszlib.dll、iisbrotli.dll 和 gzip.dll 的压缩级别在范围、压缩比率和速度方面彼此不匹配。下表汇总了三个压缩方案提供程序允许的压缩级别比较。

压缩方案提供程序	压缩级别：无压缩	压缩级别：最高速度	压缩级别：最佳压缩比率
gzip.dll	空值	0	10
iiszlib.dll	0	1	9
iisbrotli.dll	空值	0	11

注意

iiszlib.dll 的级别 0 不指定压缩，而不是最佳速度压缩。 <httpCompression> 元素中的默认 IIS dynamicCompressionLevel 属性值也是 0。因此，dynamicCompressionLevel 需要显式设置为 0 以上，以便 iiszlib.dll 压缩动态生成的内容。

压缩方案优先级

HTTP 压缩方案协商

用户代理和 IIS 服务器之间的压缩方案协商符合征求意见文档 (RFC) 规范 7231：

协商从用户代理开始，指定 Accept-Encoding 请求头中可接受的压缩方案列表。
服务器检查请求中的 Accept-Encoding 标头，并选择服务器支持的方案。
服务器应用相应的算法来压缩响应正文。
当服务器发送回响应时，它将含有所选压缩方案的 Content-Encoding 响应头添加为标头值。
用户代理使用 Content-Encoding 响应头中指示的方案来解压缩响应正文并向用户呈现原始内容。

启用多个压缩方案

HTTP 压缩方案协商背后的其中一个主要思路是可以持新压缩方案，同时保持与旧客户端或服务器的向后兼容性。

虽然 Brotli 压缩具有更高压缩比率的优势，并且受到许多浏览器的支持，但在编写时它仍不像 Gzip 那样被广泛采用。因此，一种可能的优化是同时启用 Brotli 和 Gzip 压缩，但是如果客户端用户代理还支持 Brotli，则优先启用它。

IIS 10.0 版本 1803 或更高版本

IIS 10.0 版本 1803 或更高版本支持压缩方案优先级。每个压缩方案的优先级取决于其在 <httpCompression> 元素的 <scheme> 集合中的顺序：

如果 Accept-Encoding 请求头值中指定的质量值相同，则 <scheme> 集合顶部显示的压缩方案优先于之后出现的压缩方案。
Accept-Encoding 请求头值中具有较高质量值的压缩方案优先于具有较低质量值的压缩方案，而不考虑它们在 <scheme> 集合中的顺序。

IIS 压缩的安装将 iisbrotli.dll 和 iiszlib.dll 分别注册为 br 和 gzip 压缩方案提供程序，并在 <scheme> 集合中将 br 放在 gzip 之前：

<scheme name="br" dll="%ProgramFiles%\IIS\IIS Compression\iisbrotli.dll" />
<scheme name="gzip" dll="%ProgramFiles%\IIS\IIS Compression\iiszlib.dll" />

支持 Brotli 的大部分浏览器使用 Accept-Encoding: gzip, deflate, br 进行压缩方案协商时，此类配置顺序允许 IIS 服务器将 Brotli 优先于 Gzip。

注意

通常，支持 Brotli 压缩的浏览器仅在使用 HTTPS 时，才会在 Accept-Encoding 标头值中播发 br。

IIS 10.0 版本 1803 之前的版本

尽管版本 10.0 版本 1803 之前的 IIS 允许启用多个压缩方案，但它根据 Accept-Encoding 请求标值中显示的方案顺序确定压缩方案优先级：

如果 Accept-Encoding 请求头值中首先出现（从左到右）的压缩方案和其后出现的压缩方案具有相同的质量值，则前者优先于后者。
具有较高质量值的压缩方案优先于具有较低质量值的压缩方案，而不考虑它们在 Accept-Encoding 请求头值中的顺序。

因此，对于浏览器在请求中设置 Accept-Encoding: gzip, deflate, br 标头的典型方案，IIS 始终将 gzip 优先于 br。

可能的解决方法是安装 URL 重写模块并配置重写规则，以修改 Accept-Encoding 标头值。以下配置演示了一个示例重写规则，如果该规则在非零质量值的标头值中找到字符串 br，则重写 Accept-Encoding 标头值，使其仅包含 br 方案。

<rewrite>
    <allowedServerVariables>
        <add name="HTTP_ACCEPT_ENCODING" />
    </allowedServerVariables>
    <rules>
        <rule name="Prioritize Brotli">
            <match url=".*" />
            <conditions>
                <add input="{HTTP_ACCEPT_ENCODING}" pattern="\bbr(?!;q=0)\b" />
            </conditions>
            <serverVariables>
                <set name="HTTP_ACCEPT_ENCODING" value="br" />
            </serverVariables>
        </rule>
    </rules>
</rewrite>

有关如何配置重写规则的更多详细信息，请参阅“为 URL 重写模块创建重写规则”。

测试 IIS 压缩

可以通过以下步骤完成测试 IIS 压缩：

打开浏览器并从 IIS 服务器请求某些内容。
利用浏览器的开发人员工具检查请求和响应。

若要针对静态内容压缩测试 IIS 压缩：

确保在 <httpCompression> 元素的 <staticTypes> 集合中启用请求资源的 MIME 类型。
确保请求的资源大小大于 <httpCompression> 元素中指定的 minFileSizeForComp。
确保达到所请求 URL 的“命中频率”阈值。阈值由 <serverRuntime> 元素中的 frequentHitThreshold 和 frequentHitTimePeriod 属性指定。或者，将 <httpCompression> 元素中 staticCompressionIgnoreHitFrequency 属性的值设置为 true，以仅出于测试目的禁用“命中频率”检查。

若要针对动态内容压缩测试 IIS 压缩：

确保在 <httpCompression> 元素的 <dynamicTypes> 集合中启用请求资源的 MIME 类型。

通过