聊聊HTTP gzip压缩与常见的Android网络框架

版权声明：

欢迎转载，但请保留文章原始出处

做者：GavinCT

出处：http://www.cnblogs.com/ct2011/p/5835990.html

进入主题以前，咱们先来看一下客户端与服务器通讯过程当中，若是服务器支持，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，并对结果进行解压缩。

能够看到以上逻辑完成了：

1. 开发者没有添加Accept-Encoding时，自动添加Accept-Encoding: gzip
2. 自动添加的request，response支持自动解压
3. 手动添加不负责解压缩
4. 自动解压时移除Content-Length，因此上层Java代码想要contentLength时为-1
5. 自动解压时移除 Content-Encoding
6. 自动解压时，若是是分块传输编码，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

这里再也不赘述，仅阐述结论：
无自动添加、解压机制。

总结

一、是否支持自动添加Accept-Encoding与数据自动解压？

name	transparent response compression
OkHttp	yes
HttpUrlConnection	yes
Apache	no

二、支持自动后，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 ~ ?)	被移除	不变

三、自动模式启动后，在Java中获取contentLength不管是哪一个版本的HttpUrlConnection仍是OkHttp都是不可信的，都不是解压缩以后的值（可能为-1或compressed size），所以最好不要经过contentLength来作什么操做。

四、HttpUrlConnection、OkHttp均是手动添加不自动解压缩，Apache没有自动添加自动解压功能。三者在手动添加Accept-Encoding后，表现一致（利用这个特色，能够作一个在三者之上的网络框架，随意切换三种通道）。

参考资料

• Android’s HTTP Clients
• HttpURLConnection
• HTTP 协议中的 Transfer-Encoding