IIS7：静态和动态内容压缩之间的差异
IIS 支持两种类型的压缩：静态内容压缩和动态内容压缩。根据 applicationHost.config，它们由不同的模块处理：DynamicCompressionModule (compdyn.dll) 和 StaticCompressionModule (compstat.dll)，并且它们被配置为压缩不同类型的请求。另外，我猜测动态压缩不会缓存压缩请求，与静态压缩相反（默认情况下，压缩文件保存到 %SystemDrive%\inetpub\temp\IIS Temporary compressed Files ）。
但是，除了这些明显的差异之外，我怀疑还有其他东西。我认为它们连接 IIS 管道的方式略有不同。有人会了解更多细节吗？
我发现的方式是我正在玩弄一个自定义模块来动态修改CSS文件。当静态压缩打开（并设置为处理默认文件集，即文本/css）时，根据缓存的请求，我的自定义模块将提供已压缩的内容。当我将 text/css 移动到动态压缩请求列表时，一切都开始工作。但我希望有更确凿的证据证明这确实是正确的做法。还有其他已知的后果/问题吗？
更新：我想我可能有一个关于为什么会发生这种情况的理论。它可能不是 100% 正确，但至少可以解释观察到的行为。我认为静态压缩模块将自身注册到以下事件（以及其他一些事件）：
RQ_MAP_REQUEST_HANDLER
RQ_EXECUTE_REQUEST_HANDLER
然后，当服务静态文件的请求时， OnMapRequestHandler 检查文件之前是否被压缩过以及实际文件是否未被压缩过改变了。如果是这样，它会将请求重新映射到自身（使用 返回适当的重定向IMapHandlerProvider）。当它稍后实际在 OnExecuteRequestHandler，它发送压缩文件。另一方面，如果文件之前未压缩或已更改，则它不会执行映射重定向并让静态内容模块服务请求，然后在 OnPostExecuteRequestHandler 压缩内容（并更新其缓存）。如上所述，我并不是说这正是正在发生的事情（我不知道源代码），它可能只是一个近似值。而且，动态压缩模块很可能不会执行这些操作。有时它只是在 RQ_EXECUTE_REQUEST_HANDLER 之后压缩传出响应。
IIS supports two types of compression: static content compression and dynamic content compression. According to applicationHost.config, they are handled by different modules: DynamicCompressionModule (compdyn.dll) and StaticCompressionModule (compstat.dll), and they are configured to compress different types of requests. Also, I’m guessing that the dynamic compression does not cache the compressed requests as opposed the static compression (by default, the compressed files are saved to %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files).
However, besides those obvious differences, I suspect that there is something else. I think that they hook to the IIS pipeline to a slightly different way. Would anybody have an inside into the some more details?
The way I found out was that I was toying with a custom module for modifying CSS files on fly. When the static compression was turned on (and set to handle the default set of files, i.e. also text/css), on cached request my custom module was served the already gzipped content. When I moved text/css to the list of dynamically compressed request, it all started working. But I would like to have a more solid proof that it is really the correct way to do it. Are there some other known consequences / problems?
Update: I think I may have a theory as to why it’s happening. It may not be 100% correct, but it at least it may explain the observed behavior. I think that the static compression module registers itself to the following events (among some others):
RQ_MAP_REQUEST_HANDLER
RQ_EXECUTE_REQUEST_HANDLER
Then when a request for a static file is served, the static compression module in OnMapRequestHandler checks whether the file has been compressed before and whether the actual file has not been changed. If so, it will re-map the request to itself (returning the appropriate redirection using IMapHandlerProvider). When it later actually serves the response in OnExecuteRequestHandler, it sends the compressed file. If, on the other hand, the file has not been compressed before or if it has changed, it does not do the mapping redirect and lets the static content module serve the request and then later in OnPostExecuteRequestHandler compresses the content (and updates its cache). As mentioned above, I'm not saying that this is exactly what's happening (I don't know the source code), it may be only an approximation. Also, the dynamic compression module does not most likely do any of this. It simply compresses the outgoing responses sometimes after RQ_EXECUTE_REQUEST_HANDLER.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你的问题不太清楚，所以我来回答一个问题，希望是你的问题。
静态压缩的目的是压缩直接从硬盘驱动器（Css/图像/javascript）提供的文件，因此它会压缩每个文件一次并将压缩文件保存到磁盘。这使得能够非常快速、非常便宜地为不经常更改的静态文件提供压缩内容。大多数网站都应该启用静态压缩，这是一个非常安全的建议。
动态压缩的目的是压缩来自 ISS 模块（asp、asp.net、php 等）的动态响应。由于每个请求的响应可能不同，因此无法缓存压缩输出。此功能是 IIS6 中的新功能，尽管在某些环境中已经可以实现该效果，例如通过在 ASP.Net 中实现 HttpFilter。由于每个请求都需要动态压缩，这比静态压缩需要更多的 CPU 资源。因此，如果服务器受 CPU 限制，这可能不是一个好的选择。大多数站点都是网络和/或数据库绑定的，因此这通常是一个好主意。
所以动态和静态是指采用什么策略的内容和效果。
一些参考
Your question is not quite clear, so I will answer a question and hope that it is your question.
The intent of static compression is to compress files that would otherwise be served direct from the hard drive (Css/images/javascript) and as such it compresses each file once and saves the compressed file to disk. This enables very quick very cheap serving of compressed content for static files that change infrequently. It is a pretty safe recommendation to say most website should have static compression enabled.
The intent of dynamic compression is to compress the dynamic responses from ISS modules (asp, asp.net, php, etc.). As this response can be different for each request the compressed output can not be cached. This feature is new from IIS6, though the effect has been achievable in some environments, e.g. by implementing a HttpFilter in ASP.Net. As each request needs to be compressed on the fly this is far more CPU intensive then static compression. So if a server is CPU bound this may not be a good option. Most sites are network and/or database bound so the is often a good idea.
So the dynamic and static refer to the content and effect what strategies can be used.
Some References
通过尝试 IIS 压缩功能，我发现动态模块和静态模块与动态或静态内容的联系并不那么紧密（尤其是对于动态模块）。
在动态模块上激活
text/html（或text/*）mime 类型的压缩，而不是在静态模块上。访问 .html 文件。检查浏览器中的 http 响应：它是压缩的。 （在 2008R2 服务器上的 IIS 7.5 上测试。）看来动态压缩模块不仅限于动态内容。它会压缩静态内容，前提是它与其 mime 类型列表匹配并且尚未压缩。因此，我认为它应该被理解为动态“压缩模块”，从某种意义上说，它会在每个响应上触发（基于其 mime 类型标准和
accept-encoding请求标头）。虽然静态压缩模块的触发有点像处理文件的后台进程，并且仅在将压缩输出放入缓存后才开始提供压缩输出。由于静态压缩模块确实在模块堆栈中执行得更远，因此它确实先于动态压缩模块处理响应，因此如果它有压缩输出要提供服务，则优先于动态压缩模块。
因此，对于您的特定用例，您应该禁用
text/cssmime 类型上的静态压缩模块（如果存在，请注意删除text\*）以避免缓存问题击败你的自定义 CSS 修补模块。在这种情况下，您还可以在动态压缩模块中激活
text/css压缩来替换静态压缩模块。但当然，它不会利用静态压缩模块的缓存能力。不幸的是，我没有找到任何支持上述说法的文档。
另一种选择可能是尝试改变 IIS 模块的执行顺序。您必须在站点配置中将它们全部删除，然后重新添加它们，可能在静态压缩模块之前插入自定义模块。但这可能是一条棘手的道路。
Experimenting with IIS compression feature, it appeared to me that dynamic module and static module are not so tied to dynamic or static content (especially for dynamic module).
Activate compression for
text/html(ortext/*) mime type on dynamic module, and not on static module. Access a .html file. Checks the http response in browser: it is compressed. (Tested on IIS 7.5 on 2008R2 server.)It appears dynamic compression module is not limited to dynamic content. It does compressed static content providing it matches its mime types list and is not already compressed. So I consider it should be understood as a dynamic "compression module", in the sense it gets triggered on each response (based on its mime type criteria, and on
accept-encodingrequest header).While the static compression module gets triggered a bit like a background process working on files, and starts serving compressed output only once it has them in its cache. Since static compression module does execute farer in the modules stack, it does handle the response prior to dynamic compression module, and so take precedence over dynamic one if it has compressed output to serve.
So for your specific use case, you should disable static compression module on
text/cssmime type (beware of removingtext\*too if present) in order to avoid caching issues defeating your custom css patching module.You may in addition activate compression of
text/cssin dynamic compression module for replacing static compression module on this case. But of course, it will then not leverage the static compression module caching ability.Unfortunately, I have not found any documentation for backing up above statements.
Another option could be trying to alter IIS module execution order. You would have to remove them all in your site configuration, then re-add them, inserting your custom module maybe before the static compression one. But this could be a tricky path.