流数据时gzip压缩率如何变化？

Question

在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-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字面值和匹配字符串,这些字符串可能会返回其中一些窗口,以便生成具有一组霍夫曼代码的块.这可以追溯到gzip看起来,并且它永远不会"跳转",而只是维持一个滑动历史,一旦旧数据从后端掉落就会忘记它.

zlib(不是用gzip)有一种方法可以提供一个"启动"字典,它只需要高达32K的数据,可以在压缩实际数据的前32K时用于匹配字符串.这对于压缩少量数据是有用的,有时非常有用,例如远低于32K.如果没有zlib或gzip,压缩短字符串会很糟糕.他们真的需要几次32K的数据才能滚动.

对于您正在测试的极短文件,您正在进行扩展,而不是压缩.