从一篇关于尝试提高我的网站性能的文章中，我一直在研究HTTP压缩。我已阅读关于在IIS中设置它，但它似乎是所有IIS应用程序池的全局事物，我可能不允许这样做，因为还有另一个站点在运行。然后，我看到一些代码放在global.asax中，以在每个网站的基础上实现相同的事情。ASP.NET压缩
See Herehttp://www.stardeveloper.com/articles/display.html?article=2007110401&page=1]1
这是因为在IIS中设置为好？效果如何显着？任何已知的问题？
如果你继续这样做，我会建议实施一个HttpModule与global.asax。 HttpModule允许您通过配置更改与重建来禁用压缩功能，并允许您将独立于Web应用程序的压缩程序集与猴子配合使用。
富起重机在这里有一个相当不错的2.0模块：http://www.codeplex.com/httpcompression/如果你想快速起床和运行。
blowery项目史蒂文罗杰斯提到的也是一个HttpModule。
否则，编写自己的代码非常简单。 HttpModule为您提供与global.asax相同的事件 - BeginRequest，EndRequest和PostReleaseRequestState和PreSendRequestHeaders等更细粒度的事件，您可能需要消除所有的皱纹。
就IIS压缩verus HttpModule而言，IIS绝对容易一些，因为您不必担心另一个Assembly。我已经将这两种方法与业务应用程序一起使用，并且都在负载测试下同样执行。如果IIS可用，我会说使用它。
针对HTML，JS，CSS和XML文件的60％到80％压缩对gzip来说很常见。请记住，您的许多有效负载可能是图像和多媒体对象，这些对象很难压缩。
我认为如果您处于共享主机环境（例如，您无权访问IIS配置）的情况下，Global.asax选项将非常有用。
IIS 6提供基本的压缩支持，但如果你在IIS 7中是已经，它为您提供了很大的支持HTTP compression，您可以定义哪些文件会根据他们的MIME类型的配置文件压缩...
它实现了与IIS压缩基本相同的功能 - 两者最终都会使用gzip压缩发送响应。我最近实现了这种方法，并且它始终将响应大小减少了60％，没有性能影响值得担心。
有几个可能的问题。首先，你需要注意输出缓存。您需要使用自定义的VaryBy来确保为具有不同Accept-Encoding标头的请求缓存不同的版本。否则，如果压缩版本被缓存，则所有用户都会收到它，无论他们的浏览器是否可以接受它。
其次，如果您使用Response.End或Response.Flush，GZipStream有时会截断响应中的最后几个字符，因为流迟迟不会关闭。我不知道有什么好的解决方案。
最后，这只会压缩你的HTML。任何CSS或Javascript文件将正常提供。例如，您需要通过自定义IHttpHandler来提供这些文件来压缩它们。
http://blowery.org/httpcompress/
我们已经在我的工作了一段时间使用这个压缩实用程序。非常好。
JavaScript和VBScript存在问题。 JavaScript问题已在codinghorror article的xxldaniel评论中得到确认，并且我使用带有“Microsoft.XMLHTTP”请求的类似JSON的“Scripting.Dictionary”与VBScript（用于M $ Office自动化）有问题。
您可以尝试mod_gzip模块。它使用托管的ZLib版本并允许高度可调的配置。语法与同一个已命名的Apache模块兼容，甚至可以扩展。因此，例如，您可以为不同的MIME类型设置不同的压缩级别等等。