基于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

上一篇:正品耐克男鞋哪里买便宜


下一篇:提高测试覆盖率的4个步骤