WCF通信及通信压缩总结

　　近期研究发现WCF的压缩或加密方式有多种途径实现，实现的细节网上有很多，不再赘述，这里只做一个总结，以便之后回顾：

　　

　　WCF压缩的主要解决方法主要有以下四种：

1. 通过自定义MessageEncoder和MessageEncodingBindingElement 来完成。具体的实现，可以参阅文章《WCF进阶:将编码后的字节流压缩传输》和MSDN的文章《Custom Message Encoder: Compression Encoder》。
2. 直接创建用于压缩和解压缩的信道，在CodePlex中具有这么一个WCF Extensions；
3. 自定义MessageFormatter实现序列化后的压缩和反序列化前的解压，详见Artech博客《通过WCF扩展实现消息压缩》
4. 自定义MessageInspector实现这就是我们今天将要讨论的解决方案。参见 WCF 消息压缩性能问题及解决方法

　　总结:

　　从这些方案来看wcf在客户端与服务端交互的生命周期，从信息处理上说至少经历了 ... ->信息格式化(Formatter)->信息编码(Encoder)->创建信道->信道通信(信道中有拦截器Inspector)->解码-> ... 在这几个阶段都可以对数据进行压缩与解压。目前我的

项目中实现用的第四种方案，通过自定义Behavior端点级别的拦截(就是在通信的终结点上),因为我的项目主要是文本通信，这种方式比较简单。这里附上微软官方给出的wcf通信模型。

　　原图

 

 　　补充：测试效果来看，压缩在编码器那地方做比较好，而且最好用流的形式处理，可以根据传输内容进行压缩。如果在通信管道的末端拦截所有的传输内容，性能上会有些问题特别是高并发大消息（比如大文件），内存会暴涨，因为二进制文件的压缩效率很低甚至有反作用。通过Wireshark抓包发现基于gzip等通用算法文本消息压缩效率能达到80%左右，二进制文件消息压缩效率几乎可以忽略或是压缩后消息更大。

　　

　　 --- 来自我的云笔记 ---

 

转载于:https://www.cnblogs.com/joseph_zheng/p/6703586.html