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