流數據時gzip壓縮率如何變化？

Question

我一直在嘗試瞭解HTTP流式連接（SSE和各種彗星技術）中的gzip算法。我測試數據的一些替代表示，這些的filesizes：

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 -ing 25 of 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

UPDATE：有用的鏈接

這裏是Apache模塊代碼： http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/filters/mod_deflate.c

的15窗口的大小是什麼讓馬克·阿德勒提到的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短。 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} 

注：上證所*版本結束兩個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的數據來滾動。

對於您正在測試的極短文件，您將得到擴展，而不是壓縮。