我一直在尝试在 HTTP 流连接（SSE 和各种彗星技术）的上下文中理解 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 格式似乎压缩得更差。
我的问题是：随着越来越多的数据流式传输，压缩是否会变得更好？它是否动态地和隐式地了解哪些位是脚手架，哪些位是可变数据？如果是学习算法，是否存在停止学习的点，还是理论上总是适应数据流？如果是这样，是否对最近的数据给予了额外的重视？
我做了一个粗略的测试，将cat25 个 sse.json-readable.txt 放入一个文件中。Gzip 然后给了我 95.7% 的压缩率。但我将其描述为粗糙有两个原因。首先，每一行数据都是相同的，而在现实数据中，数字和时间戳会略有不同，只有脚手架是相同的。第二个原因是 gzip 被赋予一个文件：gzip 算法是对数据进行预扫描以学习它，还是在文件中跳转？如果是这样，这些结果将不适用于 Apache 流数据（因为它在看到第二行之前已经压缩并发送了第一行数据）。
作为第二个问题，我可以假设时间不是一个因素吗？例如，假设不涉及套接字重新连接，则每行数据之间可能存在 1 秒的间隙，或 60 秒的间隙。
关于 gzip 如何工作的有用参考：http: //www.infinitepartitions.com/art001.html
（顺便说一句，我目前的理解是流式传输时的压缩将仅基于对第一个数据块的分析；所以我想知道是否可以通过发送几行虚拟数据来获得更好的压缩，以给出这是一个学习更好压缩的机会？！？）
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-可读.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-可读.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);