我有一个非常典型的场景：
浏览器 – > Web服务器 – > Web服务
我见过很多关于压缩从Web服务器发送到浏览器的数据以节省带宽的好处的文章/文档，但是我想知道在Web服务和Web服务器之间压缩数据是否有类似的好处？
XML应该压缩得非常小，所以我们当然会在带宽方面获得相同的好处，但是我特别想知道，如果这将被Web服务器上所需的处理能力所抵消，解密它接收到的SOAP消息。
有没有人为web服务启用gzip，并有任何性能改善？
对于这个问题，Web服务客户甚至会首先理解 gzip吗？ 或者启用encryption是浪费时间，永远不会被Web服务客户端利用。
问题归结为你的服务器必须要有多less空间 – CPU或带宽？ 如果你一直在等待networking，但你的CPU空闲，那么你可能应该考虑压缩。 如果你的CPU繁忙，但你没有发送太多的数据，那么压缩可能不适合你。
XML是一个非常冗长（更重要的是重复性）的语言，所以压缩可能会在传输的数据量上有相当大的差异。
压缩只有在双方都支持时才有用，否则翻转开关将无能为力。 如果压缩没有实际使用，那么您支持压缩的广告几乎没有什么区别。
最后，如果你是一个传输者，那么它不一定是全部或者全部。 Gzip压缩（LZ77）是可调的，以优化速度，大小，或之间的东西。 如何进行调整取决于您的实施，但只有发送数据的一方可以决定。 解压缩高度压缩的gzip格式的数据比解压缩仅轻微压缩的数据占用的资源更less，因此接收者不应该在意。
正如您所说，服务器在内容压缩时发送标题，浏览器将其解密。
如果你想在你的web服务器和web服务之间做，因为你的服务不是一个浏览器，你可以自己读取头文件（或者假设所有的东西都是gzip），你可以在发送请求到SOAP处理程序之前使用gzipdecode 。
除非你不传输大量数据（这是值得压缩的），否则我不会看到任何好处。 即使在有益的压缩方式下，如果没有足够的CPU和RAM来支持它，也可能是致命的。
希望它有帮助，D
看到用户浏览器如何处理gZip，另一端的web客户端需要能够理解如何解压缩gzip。 您可以通过查看标题来了解这一点。 IIRC这是“接受”头，你正在寻找“gzip”和“deflate”。
gzip的编码/解码开销是相当有名的，但它在那里。 它在浏览器中很有用，因为它不是特别及时 – 用户只会坐在那里被激怒，直到页面加载。 Web服务有点不同，通常要快得多，否则整个应用程序往往会挂起。
我build议gzip的唯一时间是在Web服务中是有用的，如果这是一个每天要重复数千次的微不足道的服务，从10kb到2kb的XML节省将是值得的处理开销。 假设另一端的Web服务首先可以接受gzip。
顺便说一句，记住，gzipping二进制数据可以导致更多的信息不less。 所以无论如何，你必须知道被压缩的数据的types。