.net WCF流压缩-它是自适应的吗？

我刚刚发现压缩已经添加到WCF中，支持Deflate和GZip压缩方案。文件在操作细节上似乎很模糊

我想知道是否有人有关于压缩工作原理的详细信息

它是基于每条消息完成的（每条消息独立于以前的消息进行处理和压缩？），还是以自适应方式完成的（，或者可以配置）？（下一条消息利用了从上一条消息中收集的压缩性信息？）

基本上，我想知道启用这个新的压缩功能是否有利于一个闲聊的应用程序，该应用程序传输小块实时数据，已知这些数据在分组时非常可压缩，但如果单独处理，则压缩效果非常差。不幸的是，实时限制不允许我们将多条消息分组以帮助压缩过程。

否

WCF压缩是使用自定义消息编码器完成的。这与WCF示例中包含的概念基本相同

您可以查看

System.ServiceModel.Channels.MessageEncoder

。基本上，大多数编码工作都是在读/写方法（流/消息、异步/同步等）中进行的。对于会话也有非常具体的优化，但我认为这对您没有帮助

不特定于WCF，使用Gzip reduce平均而言，内容编码节省了75%的文本文件（HTML、CSS和JavaScript），总体节省了37%。Gzipping只对较大的资源有利。由于压缩和解压缩的开销和延迟，您应该只使用大于某个大小阈值（几KB）的gzip文件；压缩下面的文件实际上可以使它们变大

因此，如果网络带宽是一个瓶颈（发送大消息或带宽受限），压缩最有用。在CPU是瓶颈的情况下，压缩将降低吞吐量。对于每个优化，必须在模拟环境中进行适当的测试，以确定这是否有利于应用程序

---

如果该服务是在IIS中通过Web托管的，则可以将服务配置为使用动态压缩模块（使用HTTP头

内容编码

）发送压缩响应，而无需使用WCF工具

谢谢！我正要开始编写一些自定义消息传递，这些消息传递可以处理压缩适应性（准确地说是自适应算术编码），但没有什么比花几个小时在某些东西上，然后发现它是现成的更令人沮丧的了！我发现WCF流一次最多发送64KB。看起来我可以从流中提取第一个64KB，反序列化并使用它。这告诉我.NET正在压缩64KB的块，这实际上非常可怕。