最近使用WCF作为通迅框架开发一套信息系统,系统使用传统C/S框架,系统有可能会部署在互联网上,因此决定对传输的数据进行GZIP压缩,原来在使用.NET Remoting时,可以使用插入自定义的ChannelSink来实现数据压缩,作为.NET Remoting的替代方案的WCF,实现起来也很容易，且方法不止一种，主要解决方法主要有以下四种：
- 通过自定义MessageEncoder和MessageEncodingBindingElement 来完成。具体的实现，可以参阅张玉彬的文章《WCF进阶:将编码后的字节流压缩传输》和MSDN的文章《Custom Message Encoder: Compression Encoder》。
- 直接创建用于压缩和解压缩的信道，在CodePlex中具有这么一个WCF Extensions；
- 自定义MessageFormatter实现序列化后的压缩和反序列化前的解压，详见WCF大师Artech中的博客有《通过WCF扩展实现消息压缩》
- 自定义MessageInspector实现这就是我们今天将要讨论的解决方案。
相比较，第三和第四实现相对简单，配置很简单，它们的内部实现方法很类似，我的消息压缩类也来源于WCF大师Artech的博客《通过WCF扩展实现消息压缩》的消息压缩类，区别在于第三在自定义MessageFormatter中对消息进行压缩和解压缩，而第四是在自定义MessageInspector中对消息进行压缩和解压缩。下面给出第四种实现方法(网络上也很多)：
一、Compress－压缩与解压缩类
压缩与解压缩类
二、MessageCompressor—消息压缩与解压类
消息压缩与解压缩类
三、ClientCompressionInspector-客户端对消息进行压缩与解压缩的消息检查器
客户端对消息进行压缩与解压缩的消息检查器
客户端用于插入压缩消息检查器的终节点行为器
四、ServiceCompressInspector-服务端对消息进行压缩与解压缩的消息检查器
服务端对消息进行压缩与解压缩的消息检查器
服务端用于插入压缩消息检查器和服务端行为器
五、服务端配置
在system.serviceModel节点下添加：
<extensions> <behaviorExtensions> <add name="compressBehavior" type="ServiceCompressBehavior, Service, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> </behaviorExtensions> </extensions>
<behaviors> <serviceBehaviors> <behavior> <compressBehavior /> </behavior> </serviceBehaviors> </behaviors>
好了，上面的基本的实现，可以通过在客户端行为器中添加AcceptEncoding=gzip的消息头来确定服务端返回的消息是否也可以（需要）进行压缩，实际运行结果也正常，但后来发现在进行大量byte[]类型数据传输时，发现有延时，几百K有数据，在局域网（排除网络问题）内，尽然达到2秒左右延时，开始怀疑的GZIP压缩类有问题，后发现，压缩类的对数据进行压缩时，耗时极小，一般几毫秒到几十毫秒之间，最后，只能逐语句进行排查，发现问题在消息压缩类中的：
using (XmlDictionaryReader reader1 = sourceMessage.GetReaderAtBodyContents())
{
sourceBody = reader1.ReadOuterXml();
buffer = Encoding.UTF8.GetBytes(sourceBody);
}
Message在经过每一层消息检查器时，都是以Message方法进行传递，只有到达TransportBinding上编码器时，才会对Message进行编码，或文本，或二进制，但在我上面的消息压缩中，先从原Message中获取Body内容，然后对Body进行压缩，再把压缩Body封装进新的Message中,问题就出在获取Body内容中，XmlDictionaryReader 的ReadOuterXml()方法相当对Body进行了XML的编码，所以导致了性能问题。解决问题的根本在于找到一个能获取到Body内容，又能避免提前对Body内容进行XML编码的方法。
将上述代码改为以下代码后，性能得以大幅提升：
MemoryStream ms = new MemoryStream();
XmlDictionaryWriter writer = XmlDictionaryWriter.CreateTextWriter(ms, Encoding.UTF8);
sourceMessage.WriteBodyContents(writer);
writer.Flush();
buffer=ms.ToArray();
但最终获取到的buffer是一致的，是什么原因导致它们之间有巨大的性能差异就不得而知了……
