我有一个非常典型的场景：
浏览器 -> Web 服务器 -> Web 服务
我已经看到很多关于压缩从 Web 服务器发送到浏览器的数据以节省带宽的好处的文章/文档，但我想知道压缩 Web 服务和 Web 服务器之间的数据是否有类似的好处？
XML 应该压缩得非常小，因此我们当然会在带宽方面获得相同的好处，但我特别想知道这是否会被 Web 服务器上解密收到的 SOAP 消息所需的处理能力所抵消。
有人为网络服务启用过 gzip 吗？性能有没有得到改善？
就此而言，Web 服务客户端是否理解gzip 吗？或者启用加密只是浪费时间，Web 服务客户端永远不会利用它？
答案1
问题归结为你的服务器有哪些空闲空间——CPU 还是带宽？如果你一直在等待网络，但你的 CPU 却处于空闲状态，那么你可能应该考虑压缩。如果你的 CPU 很忙，但你没有发送太多数据，那么压缩可能不适合你。
XML 是一种非常冗长（更重要的是重复）的语言，因此压缩可能会对传输的数据量产生很大的影响。
只有双方都支持压缩，压缩才有用，否则切换开关无济于事。如果压缩从未真正使用过，那么宣传您支持压缩也没有什么意义。
最后，如果您是传输方，则不一定非此即彼。Gzip 压缩 (LZ77) 可以调整以优化速度、大小或介于两者之间的某个值。如何进行调整取决于您的实现，但只有发送数据的一方才能决定。解压高度压缩的 gzip 数据不会比解压仅轻度压缩的数据占用更多资源，因此接收方无论如何都不必担心。
答案2
正如您所说，服务器在压缩内容时发送标头，然后浏览器对其进行解密。
如果你想在你的 web 服务器和 web 服务之间执行此操作，因为你的服务不是浏览器，所以你需要自己读取 headers（或者假设所有内容都是 gzip 压缩的），然后使用gzip 解码在将请求发送到 SOAP 处理程序之前。
除非您不来回传输大量数据（值得压缩），否则我看不出它有什么好处。即使压缩有益，如果您没有足够的 CPU 和 RAM 来支持它，它也可能致命。
希望有帮助，D
答案3
鉴于用户浏览器如何处理 gZip，另一端的 Web 客户端需要能够理解如何解压 gzip。您可以通过查看标头来判断这一点。如果我没记错的话，这是“accept”标头，而您要查找的是“gzip”和“deflate”。
gzip 的编码/解码开销相当小，但它确实存在。它在浏览器中很有用，因为浏览器不是特别及时 - 用户会坐在那里烦躁地等待页面加载。Web 服务有点不同，它们通常必须非常快，否则整个应用程序经常出现挂起的情况。
我建议在 Web 服务中使用 gzip 的唯一情况是，如果 Web 服务很简单，但每天要处理数千次，那么从 10kb 到 2kb 的 XML 节省就值得付出处理开销。而且，前提是另一端的 Web 服务可以接受 gzip。
答案4
顺便说一句，请记住，对二进制数据进行 gzip 压缩可能会导致更多信息，而不是更少。因此，无论如何，您都必须了解被 gzip 压缩的数据类型。