Http gzip的壓縮原理

進入主題之前，我們先來看一下客戶端與服務器通信過程中，如果服務器支持，HTTP gzip壓縮是如何實現的？

如圖所示：

request header中聲明Accept-Encoding: gzip，告知服務器客戶端接受gzip的數據。
服務器支持的情況下，返回gzip後的response body，同時加入以下header：

Content-Encoding: gzip：表明body是gzip過的數據
Content-Length:117：表示body gzip壓縮後的數據大小，便於客戶端使用。
或
Transfer-Encoding: chunked：分塊傳輸編碼
OK，HTTP gzip壓縮的基本流程我們理清楚了，來看在Android各網絡框架中表現有什麼差異。

OkHttp

OkHttp作爲目前Android最火的網絡庫，應用範圍較廣，相比於Android自帶的HttpUrlConnection、Apache坑也少很多。
我們首先來看這個庫的實現：
（注：以下代碼基於OkHttp 3.4.1, 之前的版本邏輯也是一樣的，但3.4.0開始將這些邏輯抽離到了內置的interceptor中，看起來較爲方便）

BridgeInterceptor.java

// If we add an “Accept-Encoding: gzip” header field we’re responsible for also decompressing
// the transfer stream.
boolean transparentGzip = false;
if (userRequest.header(“Accept-Encoding”) == null) {
transparentGzip = true;
requestBuilder.header(“Accept-Encoding”, “gzip”);
}
如果header中沒有Accept-Encoding，默認自動添加 ，且標記變量transparentGzip爲true。

if (transparentGzip
&& “gzip”.equalsIgnoreCase(networkResponse.header(“Content-Encoding”))
&& HttpHeaders.hasBody(networkResponse)) {
GzipSource responseBody = new GzipSource(networkResponse.body().source());
Headers strippedHeaders = networkResponse.headers().newBuilder()
.removeAll(“Content-Encoding”)
.removeAll(“Content-Length”)
.build();
responseBuilder.headers(strippedHeaders);
responseBuilder.body(new RealResponseBody(strippedHeaders, Okio.buffer(responseBody)));
}
針對返回結果，如果同時滿足以下三個條件：

transparentGzip爲true，即之前自動添加了Accept-Encoding
header中標明瞭Content-Encoding爲gzip
有body
移除 Content-Encoding、Content-Length，並對結果進行解壓縮。

可以看到以上邏輯完成了：

開發者沒有添加Accept-Encoding時，自動添加Accept-Encoding: gzip
自動添加的request，response支持自動解壓
手動添加不負責解壓縮
自動解壓時移除Content-Length，所以上層Java代碼想要contentLength時爲-1
自動解壓時移除 Content-Encoding
自動解壓時，如果是分塊傳輸編碼，Transfer-Encoding: chunked不受影響。
以上6點是我們通過OkHttp源碼得出的結論，我們以此來繼續看下其他框架。

HttpUrlConnection

1. 是否自動添加Accept-Encoding: gzip

官網有過說明：

In Gingerbread, we added transparent response compression. HttpURLConnection will automatically add this header to outgoing requests, and handle the corresponding response:
Accept-Encoding: gzip
Take advantage of this by configuring your Web server to compress responses for clients that can support it. If response compression is problematic, the class documentation shows how to disable it.
即：2.3後默認是gzip，不加Accept-Encoding會被自動添加上Accept-Encoding: gzip。

1. 自動添加的request，response是否支持自動解壓

By default, this implementation of HttpURLConnection requests that servers use gzip compression and it automatically decompresses the data for callers of getInputStream().
即返回的數據是已經自動解壓縮的。

1. 手動添加是否負責解壓縮

By default, this implementation of HttpURLConnection requests that servers use gzip compression and it automatically decompresses the data for callers of getInputStream(). The Content-Encoding and Content-Length response headers are cleared in this case. Gzip compression can be disabled by setting the acceptable encodings in the request header:
urlConnection.setRequestProperty(“Accept-Encoding”, “identity”);
Setting the Accept-Encoding request header explicitly disables automatic decompression and leaves the response headers intact; callers must handle decompression as needed, according to the Content-Encoding header of the response.
例子中只提到設置爲identity時可以禁止gzip壓縮。
但是請注意最後一段提到，顯式聲明會禁止自動解壓，同時保留header完整性，需要根據Content-Encoding來自己處理response。

實測4.1 - 6.0 版本之後發現，並不是非要指定identity才能屏蔽，指定gzip一樣也不會解壓縮。so，只要是顯式聲明過，都不會再處理，即：手動添加不會負責解壓縮。

1. 自動解壓時Content-Length問題

Since HTTP’s Content-Length header returns the compressed size, it is an error to use getContentLength() to size buffers for the uncompressed data. Instead, read bytes from the response until InputStream.read() returns -1.
即：getContentLength() 值爲gzip壓縮時的數據大小。

之前提到OkHttp在處理gzip壓縮時會把Content-Length移除，contentLength在Java層獲取爲-1，而HttpURLConnection 在Android 4.4以後底層是由OkHttp實現的，那文檔中提到的getContentLength()是compressed size是否還繼續成立呢？

實測後發現 ：

4.4之後的版本，Content-Length被移除，getContentLength() = -1
2.3- 4.3之間，Content-Length 沒有移除，getContentLength() = compressed size
5. 自動解壓時的Content-Encoding

與Content-Length對應：

4.4之後的版本，Content-Encoding被移除
2.3- 4.3之間，Content-Encoding存在，無變化。
6. 自動解壓時的分塊編碼傳輸

與OkHttp相同，Transfer-Encoding: chunked不受影響。

Apache

這裏不再贅述，僅闡述結論：
無自動添加、解壓機制。

總結

1、是否支持自動添加Accept-Encoding與數據自動解壓？

name transparent response compression
OkHttp yes
HttpUrlConnection yes
Apache no
2、支持自動後，response header的表現如何？

name Content-Encoding: gzip Header : Content-Length Java : ContentLength
OkHttp 被移除 被移除 -1
HttpUrlConnection(2.3 ~ 4.3) 不變 不變 compressed size
HttpUrlConnection(4.4 ~ ?) 被移除 被移除 -1
或

name Content-Encoding: gzip Transfer-Encoding: chunked
OkHttp 被移除 不變
HttpUrlConnection(2.3 ~ 4.3) 不變 不變
HttpUrlConnection(4.4 ~ ?) 被移除 不變
3、自動模式啓動後，在Java中獲取contentLength無論是哪個版本的HttpUrlConnection還是OkHttp都是不可信的，都不是解壓縮之後的值（可能爲-1或compressed size），因此最好不要通過contentLength來做什麼操作。

4、HttpUrlConnection、OkHttp均是手動添加不自動解壓縮，Apache沒有自動添加自動解壓功能。三者在手動添加Accept-Encoding後，表現一致（利用這個特點，可以做一個在三者之上的網絡框架，隨意切換三種通道）。

參考資料

Android’s HTTP Clients
HttpURLConnection
HTTP 協議中的 Transfer-Encoding