聊聊HTTP gzip压缩与常见的Android网络框架
进入主题之前，我们先来看一下客户端与服务器通信过程中，如果服务器支持，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中，看起来较为方便）
// 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。
2. 自动添加的request，response是否支持自动解压
By default, this implementation of HttpURLConnection requests that servers use gzip compression and it automatically decompresses the data for callers of getInputStream().
即返回的数据是已经自动解压缩的。
3. 手动添加是否负责解压缩
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，只要是显式声明过，都不会再处理，即：手动添加不会负责解压缩。
4. 自动解压时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后，表现一致（利用这个特点，可以做一个在三者之上的网络框架，随意切换三种通道）。
