Web 服务响应压缩
我正在尝试了解启用 Web 服务响应压缩的后果。 Web 服务被实现为具有 http 绑定的 IIS 托管 WCF 服务。 我想在 http 级别添加压缩，因此对于客户端来说应该是无缝的。 Soap 响应大小在 100kb - 1Mb 范围内。 我们这样做是为了改善低带宽网络上的用户体验。 有什么缺点？
i'm trying understand what are consequences of enabling compression for web service response.
Web service is implemented as IIS hosted WCF service with http binding. I would like to add compression on http level, so it should be seamless for clients. Soap response size is in 100kb - 1Mb range. We do this to improve user experience on low-bandwidth network. What are drawbacks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
100kb - 1Mb：您是否在响应中发送某种形式的二进制数据（例如文件）？ 在这种情况下，您可以考虑使用 MTOM 这将优化响应。
如果它只是文本，那么您可以通过压缩响应来获得相当多的带宽。 我能想到的唯一缺点是它不能互操作（服务器和客户端都需要实现它）并且可能会产生一些 CPU 开销。
100kb - 1Mb : Are you sending some form of binary data in your response such as files? In this case you can consider using MTOM which will optimize responses.
If it is only text then you could gain pretty much bandwidth by compressing the response. The only drawback I can think of is that it will not be interoperable (both server and clients need to implement it) and it will probably incur some CPU overhead.
在我对这个主题的阅读中，您所建议的只有当 WCF 客户端是 Silverlight 时才是无缝的，因为浏览器随后会实现压缩握手的客户端部分。 对于标准 .net 客户端，您需要额外的代码才能完成此工作。
In my reading on this topic, what you are proposing is only seamless when the WCF client is Silverlight, because the browser then implements the client-side portion of the compression handshake. With a standard .net client, you would need additional code in place to make this work.