IIS7：静态和动态内容压缩的区别

Question

IIS支持两种压缩方式：静态内容压缩和动态内容压缩。根据applicationHost.config，它们由不同的模块处理：DynamicCompressionModule（compdyn.dll）和StaticCompressionModule（compstat.dll），并配置为压缩不同类型的请求。此外，我猜测动态压缩不会像静态压缩那样缓存已压缩的请求（默认情况下，压缩文件保存在%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files中）。

但是，除了这些明显的差异外，我怀疑还有其他方面。我认为它们以稍微不同的方式连接到IIS管道。有人是否能提供更多细节信息？

我发现这一点是因为我正在尝试自定义模块以实时修改CSS文件。当启用静态压缩（并设置为处理默认的文件集，即text/css），在使用缓存的请求时，我的自定义模块将服务于已经gzip压缩的内容。当我将text/css移动到动态压缩请求列表中时，它开始正常工作。但我想要更可靠的证明，确保这确实是正确的方法。是否存在其他已知的后果/问题？

更新：我认为我可能有一个理论来解释这是为什么。它可能不是100％正确的，但至少可以解释观察到的行为。我认为静态压缩模块注册了以下事件（还有其他一些）：

RQ_MAP_REQUEST_HANDLER
RQ_EXECUTE_REQUEST_HANDLER

当服务器请求静态文件时，静态压缩模块在OnMapRequestHandler中检查文件是否被压缩过，以及实际文件是否没有发生变化。如果是这样，它将重新将请求映射到自身（使用IMapHandlerProvider返回适当的重定向）。当它在OnExecuteRequestHandler中实际提供响应时，它会发送压缩文件。另一方面，如果文件以前没有被压缩过或者已经改变，则不进行映射重定向，并允许静态内容模块提供请求，然后稍后在OnPostExecuteRequestHandler中压缩内容（并更新其缓存）。如上所述，我并不是说这就是正在发生的事情（我不知道源代码），可能只是一个近似值。此外，动态压缩模块很可能不会执行任何操作。它仅仅在RQ_EXECUTE_REQUEST_HANDLER之后有时压缩输出响应。

- Jan Zich

Answer 1

你的问题不太清楚，因此我会回答一个问题，希望它是你想要问的问题。

静态压缩的目的是压缩本来直接从硬盘上提供服务的文件（Css/images/javascript），因此它只对每个文件进行一次压缩，并将压缩后的文件保存到磁盘中。这样可以非常快速、非常便宜地为变化不频繁的静态文件提供压缩内容。可以很有把握地说，大多数网站都应该启用静态压缩。

动态压缩的目的是压缩ISS模块（asp、asp.net、php等）的动态响应。由于每个请求的响应可能是不同的，所以压缩输出无法被缓存。虽然这个功能是从IIS6开始新增的，但在一些环境中也可以实现类似的效果，例如通过在ASP.Net中实现HttpFilter。由于每个请求都需要即时压缩，因此这比静态压缩更加消耗CPU资源。因此，如果服务器已经CPU受限，这可能不是一个好的选择。大多数网站通常受制于网络和/或数据库，这种情况下通常是一个不错的选择。

因此，动态和静态是针对内容的，以及它们所产生的效果，从而决定了可以使用哪些策略。

一些参考

• http://www.iis.net/overview/DynamicCachingAndCompression
• http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/92f627a8-4ec3-480c-b0be-59a561091597.mspx?mfr=true

- David Waters

Answer 2

尝试使用IIS压缩功能后，我发现动态模块和静态模块与动态或静态内容并没有太大关系（特别是对于动态模块）。

在动态模块上激活text/html（或text/*）mime类型的压缩，而不是在静态模块上。访问一个.html文件。在浏览器中检查http响应：它被压缩了。（在2008R2服务器上测试了IIS 7.5。）

似乎动态压缩模块并不仅限于动态内容。只要符合其mime类型列表并且尚未压缩，它就可以提供压缩的静态内容。因此，我认为它应该被理解为一个动态的“压缩模块”，在每个响应上都会触发它（基于其mime类型标准以及accept-encoding请求头）。

虽然静态压缩模块有点像工作在文件上的后台进程，并且一旦将它们放入缓存中，它就开始提供压缩输出。由于静态压缩模块在模块堆栈中执行得更远，因此它在动态压缩模块之前处理响应，并且如果它有压缩输出要提供，则优先于动态压缩模块。

因此，针对您的特定用例，您应该在text/css MIME类型上禁用静态压缩模块（如果存在，请注意不要删除text\*），以避免缓存问题破坏您的自定义CSS修补模块。

您还可以在动态压缩模块中激活text/css的压缩，以替换此情况下的静态压缩模块。但是，当然，它将无法利用静态压缩模块的缓存能力。

不幸的是，我没有找到任何支持上述说法的文档。

另一个选择可能是尝试更改IIS模块执行顺序。您需要在站点配置中将它们全部删除，然后重新添加它们，在静态压缩模块之前插入您的自定义模块。但这可能是一条棘手的路。

- Frédéric