post - 为什么 POST 方法期间请求正文的 GZIP 压缩不常见？

Question

我最近在玩 GZIP 压缩以及我理解以下内容的方式:

客户端从 Web 服务器请求一些文件或数据。客户端还发送一个 header ，上面写着“Accept-Encoding,gzip”

Web Server 检索文件或数据，对其进行压缩，然后将它们以 GZIP 压缩格式发送回客户端。 Web 服务器还发送一个标题为“Content-Encoded,gzip”，以通知客户端数据已被压缩。

客户端然后解压缩数据/文件并为用户加载它们。

我知道这是常见的做法，当您需要加载一个需要大量 HTML、CSS 和 JavaScript 的页面时，这很有意义，这些页面可能相对较大，并且会增加浏览器的加载时间。

但是，我试图进一步研究这一点，为什么在进行 POST 调用时 GZIP 压缩请求正文并不常见？是不是因为通常请求主体很小，所以在 Web 服务器上解压缩文件所需的时间比简单地发送请求所需的时间长？是否有关于此的某种文件或引用资料？

谢谢!

Answer 1

这是不常见的，因为在客户端 - 服务器关系中，服务器将所有数据发送到客户端，正如您提到的，来自客户端的数据往往很小，因此压缩很少带来任何性能提升。

在 REST API 中，我会说大请求负载很常见，但显然以 REST 工具而闻名的 Spring Framework 不同意——他们明确地说 in their docs here你可以设置servlet容器做回复 压缩，没有提到请求压缩。由于 Spring Framework 的运作方式是提供他们认为很多人会使用的功能，因此他们显然觉得不值得提供 ServletFilter我们用户可以用来读取压缩请求正文的实现。

为类似的讨论搜索 tomcat、struts、jackson、gson 等的用户邮件列表会很有趣。

如果您想编写自己的解压过滤器，请尝试阅读以下内容:How to decode Gzip compressed request body in Spring MVC

或者，将您的 servlet 容器置于提供更多功能的 Web 服务器之后。人们显然确实需要足够的请求压缩，以便 Apache 等 Web 服务器提供它 - 这个 SO 答案已经很好地总结了它:HTTP request compression - 您也可以在那里找到对 HTTP 规范的引用。