wcf 条件压缩答案

【问题标题】：wcf conditional compressionwcf 条件压缩
【发布时间】：2011-06-05 14:55:06
【问题描述】：

我最近插入了一个自定义编码器（使用二进制编码器进行实际编码，使用 Gzip 压缩器压缩字节数组）。它工作正常。现在的问题是对于小消息大小它实际上膨胀了字节数组。我想知道是否有办法避免这种情况。特别是如果有办法我可以应用条件压缩和解压缩。

我确实尝试过做类似的事情 - 放置一个条件

if(buffer.Count <= 5000)
 skip compression

但问题是即使字节没有被压缩，另一端也会发生解压缩。我希望这是有道理的。

以下是发生压缩和解压缩的函数（来自 CompactMessageEncoder 的代码 sn-p）

public override Message ReadMessage(ArraySegment<byte> buffer, BufferManager bufferManager, string contentType)
        {

            ArraySegment<byte> decompressedBuffer = DecompressBuffer(buffer, bufferManager);
            LogWrite("Decompressed from {0} bytes to {1} bytes", buffer.Count, decompressedBuffer.Count);

            Message returnMessage = _innerEncoder.ReadMessage(decompressedBuffer, bufferManager);

            returnMessage.Properties.Encoder = this;
            return returnMessage;
        }



public override ArraySegment<byte> WriteMessage(Message message, int maxMessageSize, BufferManager bufferManager, int messageOffset)
        {
            var buffer = _innerEncoder.WriteMessage(message, maxMessageSize, bufferManager, messageOffset);

            var compressedBuffer = CompressBuffer(buffer, bufferManager, messageOffset);
            LogWrite("Compressed from {0} bytes to {1} bytes", buffer.Count, compressedBuffer.Count);

            return compressedBuffer;
        }

【问题讨论】：

你能在那些被压缩的邮件中添加一个客户标头吗？ stackoverflow.com/questions/964433/…
@Mitch：这可能行不通。因为我必须添加假设我将自定义标头添加到 Message 类并在 WriteMessage() 函数中压缩它。在 ReadMessage() 中，我必须在获取 Message 类并读取标题之前对其进行解压缩。

标签： c# wcf c#-4.0

【解决方案1】：

如果您使用 http 并且使用 IIS 7 或更高版本（6 也可以，但配置显然更难），您可以使用内置的 gzip / deflate 压缩。

见http://www.iis.net/ConfigReference/system.webServer/httpCompression

该链接还解释了诸如“minFileSizeForComp”之类的参数，这些参数正好解决了您的问题。它还有很多其他不错的参数，例如“dynamicCompressionDisableCpuUsage”，一旦超过某个 cpu 负载就会禁用压缩。

http 压缩的好处是它是一个标准，客户端和服务器可以根据请求确定他们是否可以或想要使用标准的 http 请求和响应标头进行压缩。此外，压缩格式可以从 gzip 更改为 deflate，后者有几个优点，尽管使用得不多。看 http://madskristensen.net/post/Compression-and-performance-GZip-vs-Deflate.aspx 和http://www.vervestudios.co/projects/compression-tests/

一个潜在的缺点 - 根据您的应用程序，http 压缩仅从服务器 -> 客户端完成，因此如果您的请求很大，这可能会成为一个问题，但在大多数情况下，服务器响应可能会更大比客户要求。 编辑：如果你愿意添加custom IHttpModule，你甚至可以让请求压缩工作。

我刚刚成功地将一个使用频繁的 20 台服务器场从 GZIPMessageEncoder 迁移到 IIS 7.5 的 http 压缩。

附带说明，请不要在缓冲传输模式下使用 MS 的 GzipMessageEncoder 示例，这是默认设置。 GzipMessageEncoder 只会浪费大量内存——在我的特殊情况下是数百兆字节，请在此处查看我的答案：WCF HttpTransport: streamed vs buffered TransferMode

【讨论】：

【解决方案2】：

你能写一个字节来指示数据是否被压缩吗？ 0 = 未压缩，1 = Gzip 压缩，2 - 255 = 未来的压缩算法？

您可以编写未压缩的长度，但这将依赖于服务器和客户端使用相同的截止长度来进行不压缩。你可以写一个布尔值来指示它是否被压缩，但这仍然需要一个完整的字节，你可以通过写一个 0-255 的值来为将来的扩展保持开放。（也许您会发现，对于您的数据，不同的压缩算法可以提供更好的压缩。）

【讨论】：