基于WCF的RESTFul WebAPI如何对传输内容实现压缩

前言

WCF作为通迅框架可以很容易地实现对消息的压缩，且方法不止一种，主要解决方法主要有以下四种：

1、通过自定义MessageEncoder和MessageEncodingBindingElement 来完成。具体的实现，可以参阅张玉彬的文章《WCF进阶:将编码后的字节流压缩传输》；

2、直接创建用于压缩和解压缩的信道，在CodePlex中具有这么一个WCF Extensions；

3、自定义MessageFormatter实现序列化后的压缩和反序列化前的解压，详见WCF大师Artech中的博客有《通过WCF扩展实现消息压缩》；

4、自定义MessageInspector实现，详见博客园似若流云的文章《WCF 消息压缩性能问题及解决方法》。

这几种方法实现、配置都很简单。后两种方法的内部实现方法很类似，区别在于第三种方法通过自定义MessageFormatter中对消息进行压缩和解压缩，而第四种方法是在自定义MessageInspector中对消息进行压缩和解压缩。比较而言最后一种是最简单粗暴的。

几种方案的适用场景

那么，这几种方法都适用于什么场景呢？从技术上看，这4种方案基本可以分为两类。一种是在消息编码器上动手脚，另一种是在消息上做文章。

第一种是属于在消息编码器上动手脚的，实现稍复杂。应用场景比较广泛，基本上所有的场景都是适用的。

后面三种都是在消息上做文章的，只适合有WCF客户端的情况，因为如果没有客户端压缩时在消息中加入的压缩标志，服务端就没法正确解压，反之亦然。虽然原理相同，但三种方法的切入点各不相同。同时，第二种方法是可以改成在消息编码器上进行压缩/解压的。

因为RESTFul的WCF的客户端不仅仅是WCF，所以暂时只能选第一种方案了。

一个问题

虽然有现成的方案可用，但是，如果要完美支持多种客户端的话，这里面还有几个问题需要解决。

按照Http协议的规范，客户端发送/服务端返回一个压缩的数据，需要在协议头部加上Content-Encoding，并设置其值为gzip或者deflate。告诉对方数据的压缩方法，好让对方能够正确解压。

如果客户端希望返回的数据是压缩的，那么就在头部加上Accept-Encoding，并设置其值为gzip或者deflate服务器收到这个信息后，就知道客户端选择的压缩方法，就可以按照客户端指定的方法去压缩数据。

然而，无论哪种方案，都是需要事先配置压缩方式的。也就是说，需要双方事前约定，无法实现用Content-Encoding的值来告知对方压缩方式！这不优雅！！在很多时候，这是个大问题！！！

解决的办法

我们知道，第四种方案的切入点在消息检查器上，在这个点上，通常会实现一些自定义的拦截功能。一个自定义的消息检查器需要继承IDispatchMessageInspector，这个接口类定义了两个接口：

object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
void BeforeSendReply(ref Message reply, object correlationState)

AfterReceiveRequest作用在收到消息后，BeforeSendReply作用在发送响应消息前。

我们可以通过下面的代码，来根据请求头的Accept-Encoding的值，给消息加上对应的压缩标示，以便消息编码器选择正确的压缩方式；并在返回响应前在响应头部加上Content-Encoding并设置相应的值，以便客户端正确解压。

using System.Linq;
using System.Net;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Dispatcher;
namespace Insight.WCF.CustomEncoder
{
    public class CompressInspector : IDispatchMessageInspector
    {
        public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
        {
            var property = request.Properties[HttpRequestMessageProperty.Name] as HttpRequestMessageProperty;
            var accept = property?.Headers[HttpRequestHeader.AcceptEncoding];
            switch (accept)
            {
                case "gzip":
                   OperationContext.Current.Extensions.Add(new GzipExtension());
                    break;
                case "deflate":
                    OperationContext.Current.Extensions.Add(new DeflateExtension());
                    break;
            }
            return null;
        }
        public void BeforeSendReply(ref Message reply, object correlationState)
        {
            var property = reply.Properties[HttpResponseMessageProperty.Name] as HttpResponseMessageProperty;
            var exts = OperationContext.Current.Extensions;
            if (exts.OfType(GzipExtension).Any())
            {
                property?.Headers.Add(HttpResponseHeader.ContentEncoding, "gzip");
            }
            else if (exts.OfType(DeflateExtension).Any())
            {
                property?.Headers.Add(HttpResponseHeader.ContentEncoding, "deflate");
            }
        }
    }
    public class GzipExtension : IExtension
    {
        public void Attach(OperationContext owner)
        {
        }
        public void Detach(OperationContext owner)
        {
        }
    }
    public class DeflateExtension : IExtension
    {
        public void Attach(OperationContext owner)
        {
        }
        public void Detach(OperationContext owner)
        {
        }
    }
}

未彻底解决的问题

因为消息检查器的AfterReceiveRequest作用在收到消息后，也就是说，对于POST/PUT/DELETE这三类请求，它们如果对提交的数据进行了压缩的话，我们无法在消息编码器中根据Content-Encoding的值进行解压。消息编码器中的ReadMessage方法是这样的：

public override Message ReadMessage(Stream stream, int maxSizeOfHeaders, string contentType)

所以，如果要实现由客户端来决定POST/PUT/DELETE数据的压缩方式的话，只有在Content-Type上面搞点小动作。

这。。。。。。

不够优雅呀！

看来得研究下改造第二种解决方案了。生命不止，折腾不息

源代码在这里：https://github.com/xuanbg/Utility/tree/master/CustomEncoder