我有一个在tomcat 7上运行的Spring MVC应用程序，它返回一个大的（4 Mb）JSON响应到REST API请求。使用Chrome开发人员工具，我跟踪到下载平均需要大约2.9秒。为了加快速度并减少数据使用，我启用了gzip编码，首先使用tomcat压缩（后来使用apache mod_deflate）。
在这两段时间里，我看到文件大小减少到大约250Kb。请求头设置了gzip和chunked编码标志。然而，网络传输时间并没有减少（实际上平均而言，我认为我看到了非常小的增加）。
这对你有意义吗？我试图弄清楚为什么传输速度随着文件大小的变化而不变。如果这是不够的信息，让我知道什么数据会让这个问题更有建设性。我应该使用GZipOutputStream的自定义servlet吗？（我想知道为什么如果这是正确的方法）
3条答案
按热度按时间vuv7lop31#
所以，如果数据包的大小较小，那么这两个时间都应该减少.然而，我猜Chrome的开发者工具从您发出请求的第二秒开始计算“传输时间”，因为浏览器无法知道服务器开始传输的时刻.因此，您计算的传输时间包括服务器需要压缩文件的时间，这就是它没有显著减少的原因。
一般来说，压缩（gzipping）或不压缩Web服务器的响应是一个需要仔细研究的权衡。特定元素在压缩时提供了大量的时间收益（例如css文件），而对于其他元素，浪费的CPU时间超过了时间收益（例如JPG或PDF）。
mzmfm0qo2#
硬件网络压缩可以在网络堆栈的较低级别透明地发生，使得gzip压缩在某些情况下几乎无用。
为了验证这一点，您可以尝试这个小实验：在Tomcat和Apache中禁用gzip压缩。（如mpg或zip文件），并注意所花费的时间。接下来，使用文本编辑器创建一个新文件，并使用重复的字符串序列填充它，例如“00000”或“123123123”，直到它有4 Mb。现在通过Tomcat下载该文件，并将时间与压缩文件的时间进行比较。它很可能比相同大小的压缩文件下载快得多，即使gzip压缩被禁用。这是因为现代网络设备通常具有内置压缩功能。
但是这种低级别的压缩在很大程度上取决于所使用的硬件，您所使用的网络等，所以我仍然建议启用gzip压缩。它可以为某些用户缩短下载时间，尽管不是所有用户。
jtjikinw3#
如果您使用Tomcat或Apache压缩，它将在下载活动时被压缩。这种压缩需要（cpu）时间，因此会减慢您的下载速度。在移动的连接等慢速连接上，它仍然会快得多。
如果你使用一个预压缩的文件，并根据请求的
Accept-Encoding来提供它，速度会快得多。Tomcat（https：//tomcat.apache.org/tomcat-9.0-doc/default-servlet.html#where）和Apache都可以做到这一点，如果你告诉他们的话。