apache - 流式传输数据时 gzip 压缩率如何变化？

Question

我一直在尝试在 HTTP 流式连接(SSE 和各种 comet 技术)的上下文中理解 gzip 算法。我用这些文件大小测试了一些替代的数据表示:

40 csv.txt
63 json-short.txt
80 json-readable.txt

27 rawbin.txt

46 sse.csv.txt
69 sse.json-short.txt
86 sse.json-readable.txt

当使用 gzip -9v 压缩时，我得到:

csv.txt:     25.0%
json-readable.txt:   16.2%
json-short.txt:  20.6%
rawbin.txt:  18.5%
sse.csv.txt:     25.0%
sse.json-readable.txt:   15.1%
sse.json-short.txt:  18.8%

这些压缩率不是很好，但也与预期相反:越冗长的 JSON 格式似乎压缩得越差。

我的问题是:随着越来越多的数据被流式传输，压缩会变得更好吗？它是否动态地和隐式地学习哪些位是脚手架，哪些位是可变数据？如果它是一种学习算法，是否存在停止学习的点，或者理论上它总是适应数据流？如果是这样，是否对更新的数据给予了额外的权重？

我通过 cat 将 25 个 sse.json-readable.txt 放入一个文件中，进行了粗略测试。 Gzip 然后给了我 95.7% 的压缩率。但出于两个原因，我将其描述为粗糙。首先，每一行数据都是相同的，而在实际数据中，数字和时间戳会略有不同，只有脚手架是相同的。第二个原因是 gzip 被赋予了单个文件:gzip 算法是对数据进行预扫描以了解它，还是在文件中跳来跳去？如果是这样，这些结果将不适用于 Apache 流数据(因为它在看到第二行之前已经压缩并发送了第一行数据)。

作为次要问题，我可以假设时间不是一个因素吗？例如。假设不涉及套接字重新连接，每行数据之间可能有 1 秒的间隔，或者 60 秒的间隔。

关于 gzip 如何工作的有用引用:http://www.infinitepartitions.com/art001.html

(顺便说一下，我目前的理解是流式传输时的压缩将完全基于对第一 block 数据的分析；所以我想知道是否可以通过发送几行虚拟数据来获得更好的压缩，让它有机会学习更好的压缩？!？)

http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/filters/mod_deflate.c 15 给出了 32KB。

http://www.zlib.net/zlib_how.html http://www.zlib.net/zlib_tech.html

更新:有用的链接

这是 Apache 模块代码: http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/filters/mod_deflate.c

15 的窗口大小就是 Mark Adler 在他的回答中提到的 32KB 窗口的原因。

以下是一些有助于理解 Apache 代码的页面: http://www.zlib.net/zlib_how.html http://www.zlib.net/zlib_tech.html

---

以下是上面的测试文件，以备不时之需:

csv.txt

2013-03-29 03:15:24,EUR/USD,1.303,1.304

json-short.txt

{"t":"2013-03-29 06:09:03","s":"EUR\/USD","b":1.303,"a":1.304}

json-readable.txt

{"timestamp":"2013-03-29 06:09:03","symbol":"EUR\/USD","bid":1.303,"ask":1.304}

sse.csv.txt

data:2013-03-29 03:15:24,EUR/USD,1.303,1.304

sse.json-short.txt

data:{"t":"2013-03-29 06:09:03","s":"EUR\/USD","b":1.303,"a":1.304}

sse.json-readable.txt

data:{"timestamp":"2013-03-29 06:09:03","symbol":"EUR\/USD","bid":1.303,"ask":1.304}

注意:sse.* 版本以两个 LF 结尾，其他版本以一个 LF 结尾。

rawbin.txt 是用这个 PHP 脚本制作的:

$s=pack("la7dd",time(),"USD/JPY",1.303,1.304);
file_put_contents("rawbin.txt",$s);

Answer 1

gzip 使用最后 32K 数据的滑动窗口来搜索匹配的字符串。它将累积 16K 文字和匹配字符串，这些字符串可能会返回其中几个窗口，以生成具有一组霍夫曼代码的 block 。这与 gzip 看起来一样远，它从不“跳来跳去”，而只是维护一个滑动历史，一旦旧数据从后端丢失，它就会忘记。

zlib(不是 gzip)有一种方法可以提供一个“启动”字典，当压缩实际数据的前 32K 时，该字典最多可用于匹配字符串的 32K 数据。这对于压缩少量数据很有用，有时非常有用，例如远小于 32K。没有那个 zlib 或 gzip 将无法压缩短字符串。他们确实需要几倍于 32K 的数据才能滚动。

对于您正在测试的极短文件，您得到的是扩展，而不是压缩。