背景

gzip解壓縮在http請求里面經(jīng)常聽到從來沒有真正的處理過，今天終于遇到個問題。先描述一下問題，hiproxy是一個代理服務器。在給hiproxy寫一個插件的時候，需要拿到所有請求的數(shù)據(jù)，包括http協(xié)議字段和數(shù)據(jù)部分。重點在數(shù)據(jù)部分，hiproxy作為一個代理，其實并不關心請求是否是gzip解壓縮的。因為解壓是瀏覽器來做，壓縮是服務器來做。但是我的數(shù)據(jù)是在代理的節(jié)點去拿到數(shù)據(jù)。這時候悲劇就來了，怎么去解壓數(shù)據(jù)。

http chunk

http chunk見的比較多。bigpipe應該就算http chunk傳輸數(shù)據(jù)的一種。http請求不停的輸出chunk數(shù)據(jù)，直到結束。那第一個問題來了。所有的數(shù)據(jù)是先拆chunk后gzip，還是先gzip后拆chunk的呢？我猜是第一種，google了一下，說是兩種方式都支持！麻痹，我相信了。

查了node的zlib包，發(fā)現(xiàn)解壓有兩種方式。第一種stream流管道解壓。另外一種就是直接解壓buffer。然后我就在response的data事件回調(diào)中開始操作了。拿到chunk一看是buffer，判斷一下encodeing，直接調(diào)用zlib.upzip解壓了，不幸的是拋異常了:Z_DATA_ERROR。這不應該呀，那換種姿勢吧，buffer轉stream用管道的方式去解壓。麻痹，還是不行。這時候開始懷疑人生了。

開始google, 都是一些gz文件解壓，或者response用管道解壓返回gz數(shù)據(jù)。終于我開始懷疑第一個問題了，到底是先gzip還是先拆chunk。最后換種姿勢吧，data事件里面緩存chunk，chunk用Buffer.concat拼接起來。end事件里面再判斷encoding，選擇zlib.gunzip解壓。窩草，成功了。。。

到底發(fā)生了什么事情

查看了一下http協(xié)議，寫的明明白白，先gzip再拆分。想一下，先拆chunk再gzip好像也沒啥問題呀。那為什么這么搞呢？猜測一下，首先，先拆包再gzip的話，勢必數(shù)據(jù)量會變大。gzip也是有數(shù)據(jù)寫入的呀！窩草，又想到一個問題。不是說瀏覽器解析html是回一個chunk數(shù)據(jù)就開始解析了嗎？我開始懷疑這個說法了。如果沒有gzip那我能理解，你瀏覽器可以提前渲染，但是gzip了你都沒辦法解壓，渲染個屁啊！