wcf - 使用 .net 4 进行 WCF 压缩

Question

我已经阅读了这篇WCF 压缩文章，我知道对于 .net 4.0，WCF 压缩是开箱即用的。

我找不到任何关于如何使用它的明确解释，我是否需要定义任何设置或更改绑定？还是自动压缩？

我在 IIS7 中使用 basicHttpBinding。“启用动态压缩”选项设置为 true，但我不明白客户端如何知道压缩请求和解压缩响应？

任何解释，包括设置绑定以减小消息大小，都将不胜感激。在具有 4MB 带宽的远程服务器上工作时，我遇到了非常糟糕的性能。

Answer 1

但我不明白客户端如何知道压缩请求和解压缩响应？

这都是 HTTP 规范的一部分。由于 WCF 使用 HTTP 和 IIS，它可以利用 Web 服务器和客户端 HTTP 堆栈的内置压缩。

查看第 14.3 节： http ://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

基本上，您的客户端需要发送一个标头，说明它支持压缩。示例： Accept-Encoding: gzip, deflate。您可以按照 WCF 客户端部分的文章中的说明进行设置。然后，您的客户端将向服务器发送正确的标头。

现在在服务器端，IIS 将看到该标头，并将压缩响应...如果配置为这样做。您链接的文章告诉您如何设置 IIS 以压缩 WCF 服务。然后，服务器将向客户端发送回一个标头，告诉它内容已压缩：Content-Encoding: gzip。然后客户端将解压缩响应并继续其愉快的方式。

差不多就是这样；只需正确获取客户端标头并将服务器配置为发送回压缩响应即可。这篇文章告诉你如何做到这一点。希望有帮助

Answer 2

请注意，压缩已添加到 WCF 4.5。它在这里介绍：http: //msdn.microsoft.com/en-us/library/aa751889 (v=vs.110).aspx

您必须使用自定义绑定来启用它：

<customBinding>
  <binding name="BinaryCompressionBinding">
    <binaryMessageEncoding compressionFormat="GZip"/> 
    <httpTransport /> 
  </binding> 
</customBinding>

它仅适用于二进制编码。此外，您必须了解您的情况。如果您托管在 IIS 中，则压缩可能已经打开。见这里：http: //blogs.msdn.com/b/dmetzgar/archive/2011/04/29/automatic-decompression-in-wcf.aspx

Answer 3

使用 http 编码时，启用响应压缩（仅）的一个好方法是使用IIS7 和更高版本内置的动态压缩。

但我不明白客户端如何知道压缩请求和解压缩响应？

下面是对 HTTP 开箱即用的描述，它可以与 WCF HTTP(S) 编码一起使用。除此之外，WCF 4.5 还提供了gzip 和 deflate 对其二进制编码的压缩。

压缩响应是 HTTP 标准的一部分。在其请求中，客户端通过以下标头向服务器发送其支持的压缩方法（gzip、deflate、...）的信号：

Accept-Encoding: gzip, deflate

服务器自行决定，无限智慧和神秘的方式，可以自由地忽略该标头并发送未压缩的响应，或者它可以选择客户端提供的任何一种算法，例如回答以下标头并压缩响应体。

Content-Encoding: gzip

更复杂的是，服务器可能还会设置以下标头：

Transfer-Encoding: chunked

这允许服务器省略其他强制性的Content-Length标头，作为一般的 HTTP 标头，必须在 HTTP 正文之前。（设置chunked编码会影响正文的编码方式。）所以现在它可以即时压缩响应正文，即在压缩时吐出字节，而不必等待整个正文的压缩完成，只是为了能够确定压缩结果的内容长度。这可以在服务器端节省大量内存。（然而，客户端现在对压缩响应的总大小一无所知，直到它完成接收整个响应，使其解压效率略低）

---

但是请注意，正如我刚刚描述的那样，使用Accept-Encodingand来透明地压缩响应实际上是一个愚蠢的想法，根据 http 共同作者 Roy Fielding 的说法，应该使用的是请求中的以下标头：Content-Encoding

TE: gzip, deflate

如果服务器选择执行压缩，则会将以下标头添加到其响应中：

Transfer-Encoding: gzip, chunked

和以前一样，chunked如果服务器想要省略Content-Length.

否则，TE/Transfer-Encoding组合在语法上与Accept-Encoding/组合相同，但含义不同，从这个冗长的讨论Content-Encoding中可以看出。

问题的要点：TE/Transfer-Encoding 使压缩成为传输细节，而 Accept-Encoding/Content-Encoding 将压缩版本表示为实际数据（ HTTP 术语中的实体），对于请求的缓存有许多不幸的后果, 代理等。

但是，TE/Transfer-Encoding的船很久以前就开船了，我们卡在AE/CE组合上，大多数客户端和服务器都支持这个组合，实际上更接近于TE/TE

---

当涉及到HTTP 中的压缩请求时，它们在实践中很少使用，并且客户端没有标准的方法来确定服务器是否支持它。要么你告诉客户端带外（例如硬编码）服务器理解压缩请求（并适当地配置服务器）。或者您让您的客户端主动尝试压缩一次，如果它产生一个400 Bad Request（至少这是 IIS 7.5 会返回的结果），您就会退回到非压缩请求。

Answer 4