我刚刚发现 WCF 中添加了压缩功能，支持 Deflate 和 GZip 压缩方案。文档在操作细节上似乎很模糊。
我想知道是否有人有关于压缩如何工作的详细信息。
它是在每条消息的基础上完成的（每条消息的处理和压缩独立于之前的消息吗？）或者它已经完成了（或者可以配置) 以自适应方式？ （下一条消息利用了从前一条消息中收集的可压缩性信息？）
基本上，我想知道启用这个新的压缩功能是否可以使聊天应用程序受益，该应用程序传输小块实时数据，已知这些数据在分组时非常可压缩，但如果单独处理则压缩非常差。遗憾的是，实时约束不允许我们将多个消息分组以帮助压缩过程。
【问题讨论】：
标签： .net performance wcf compression wcf-configuration
否
WCF 压缩是使用自定义消息编码器完成的。它与 WCF 示例中包含的 Gzip Message Encoder 背后的概念基本相同。
您可以查看System.ServiceModel.Channels.MessageEncoder。基本上，大部分编码工作发生在读/写方法中（流/消息，异步/同步，...）还有一个非常具体的会话优化，但我认为这对你没有帮助。
不特定于 WCF，平均使用 Gzip reduce，内容编码节省了 75% 的文本文件（HTML、CSS 和 JavaScript），总体节省了 37%。 Gzipping 仅对更大的资源有益。由于压缩和解压缩的开销和延迟，您应该只 gzip 超过一定大小阈值（几 KB）的文件；压缩下面的文件实际上可以使它们变大。
因此，如果网络带宽是瓶颈（发送大消息或带宽受限），压缩最有用。在 CPU 是瓶颈的情况下，压缩会降低吞吐量。对于每项优化，必须在模拟环境中进行适当的测试，以确定这是否有利于应用程序。
如果服务在 IIS 中托管在 Web 上，则可以将服务配置为使用动态压缩模块（使用 HTTP 标头 Content-Encoding）发送压缩响应，而无需使用 WCF 内容
【讨论】：