HttpUrlConnection之gzip相关

最新推荐文章于 2024-08-29 11:21:57 发布

DevilNoV

最新推荐文章于 2024-08-29 11:21:57 发布

阅读量3.8k

点赞数 1

分类专栏：移动开发-Android

本文链接：https://blog.csdn.net/devilnov/article/details/53540585

版权

移动开发-Android 专栏收录该内容

62 篇文章 1 订阅

订阅专栏

进入主题之前，我们先来看一下客户端与服务器通信过程中，如果服务器支持，HTTP gzip压缩是如何实现的？

如图所示：

HTTP compression：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。

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是否还继续成立呢？

实测后发现：