文章來源于公眾號：小姐姐味道 ，作者小姐姐養(yǎng)的狗
要使用OkHttp，一定要知道它的透明壓縮，否則死都不知道怎么死的；或者活也不知道為什么活的不舒坦。
反正不是好事。
什么叫透明壓縮呢？OkHttps 在發(fā)送請求的時候，會自動加入 gzip 請求頭Accept-Encoding:gzip。所以，當(dāng)返回的數(shù)據(jù)帶有 gzip 響應(yīng)頭時Content-Encoding=gzip，OkHttps 會自動幫我們解壓數(shù)據(jù)。（Accept-Encoding和Content-Encoding是一對請求頭，分別對應(yīng)著請求和返回）
為什么要進行壓縮呢？因為它能大幅減少傳輸?shù)娜萘?。像一?CPU 資源占用不高的服務(wù)，比如 Kafka ，我們就可以開啟 gzip 壓縮，加快信息的流轉(zhuǎn)。
這個壓縮比有多高呢？可以看下下面實實在在的截圖，對于普通的xml或者json，數(shù)據(jù)可以由9MB壓縮到350KB左右，壓縮比足足達(dá)到了26。
它讓系統(tǒng)性能飛起來
SpringCloud微服務(wù)體系，現(xiàn)在有非常多的公司在用。即使是一些傳統(tǒng)企業(yè)，一些大數(shù)據(jù)量的toB企業(yè)，也想嘗一嘗螃蟹。
對于一個簡單的 SpringBoot 服務(wù)，我們只需要在 yml 文件中配置上相應(yīng)的壓縮就可以了。這樣，我們就打通了瀏覽器到 Web 服務(wù)的這一環(huán)。這種壓縮方式，對于大數(shù)據(jù)量的服務(wù)來說，是救命式的！
具體配置如下。
server:
port: 8082
compression:
enabled: true
min-response-size: 1024
mime-types: ["text/html","text/xml","application/xml","application/json","application/octet-stream"]
它所對應(yīng)的 Spring 配置類是org.springframework.boot.web.server.Compression。
但是不要高興太早。由于是分布式環(huán)境，這里面調(diào)用鏈就會長一些。即使是在內(nèi)網(wǎng)，動輒十幾MB的網(wǎng)絡(luò)傳輸，也會耗費可觀的時間。
如上圖，一個請求從瀏覽器到達(dá)真正的服務(wù)節(jié)點，可能要經(jīng)過很多環(huán)節(jié)。
- nginx轉(zhuǎn)發(fā)請求到微服務(wù)網(wǎng)關(guān)zuul
- zuul轉(zhuǎn)發(fā)到具體的微服務(wù)A
- 微服務(wù)A通過Feign接口調(diào)用微服務(wù)B
如果我們的數(shù)據(jù)，大多數(shù)是由微服務(wù)B提供的，那么上面的任何一個環(huán)節(jié)傳輸效率慢，都會影響請求的性能。
所以，我們需要開啟 Feign 接口的 gzip 壓縮。使用 OkHttps 的透明代理是最簡單的方式。
首先，在項目中引入 feign 的 jar 包。
<dependency>
<groupId>io.github.openfeign</groupId>
<artifactId>feign-okhttp</artifactId>
</dependency>其次，在 yml 文件中啟用 OkHttps 作為 feign 的客戶端請求工具包。穩(wěn)妥起見，我們同時屏蔽了 httpclient ，這個東西太重太老了。
feign:
httpclient:
enabled: false
okhttp:
enabled: true到此為止，我們就可以享受 OkHttps 的透明代理帶來的便捷性了。
假如你的應(yīng)用數(shù)據(jù)包大，調(diào)用鏈長，這種方式甚至?xí)o你的服務(wù)帶來數(shù)秒的性能提升。 xjjdog 就曾經(jīng)靠調(diào)整幾個參數(shù)，就讓一個蝸牛系統(tǒng)飛了起來。大家驚呼：原來B端也可以C一下。
OkHttp是如何實現(xiàn)透明壓縮的？
OkHttps 對于透明壓縮的處理，是通過攔截器來做的。具體的類，就是okhttp3.internal.http.BridgeInterceptor。
具體代碼如下，當(dāng)判斷沒有Accept-Encoding頭的時候，就自行加入一個。
// 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 && userRequest.header("Range") == null) {
transparentGzip = true;
requestBuilder.header("Accept-Encoding", "gzip");
}最關(guān)鍵的代碼在下面。
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);
String contentType = networkResponse.header("Content-Type");
responseBuilder.body(new RealResponseBody(contentType, -1L, Okio.buffer(responseBody)));
}
可以看到if語句里，有三個條件。
- 程序沒有設(shè)置
Accept-Encoding，啟用了透明壓縮 - 服務(wù)端有
Content-Encoding頭，并啟用了gzip壓縮 - 有數(shù)據(jù)包
只有同時滿足這三個條件，OkHttps 的透明壓縮才會起作用，幫我們自動解壓。
它挖的坑有點深
可惜的是，上面的關(guān)鍵代碼，只有if，沒有else，也就是當(dāng)其中的任何一個條件不滿足，后端的數(shù)據(jù)包將原封不動的返回。
2、3兩個條件是沒有什么問題的，原樣返回后端數(shù)據(jù)并沒有什么損害，問題就出在第一個條件里。
如果你在代碼中，使用了下面的代碼：
Request.Builder builder = chain.request()
.newBuilder()
.addHeader("Accept", "application/json")
.addHeader("Accept-Encoding", "gzip");
也就是手動設(shè)置了Accept-Encoding頭信息。這很常見，因為這體現(xiàn)了程序員思維的嚴(yán)謹(jǐn)。
正是這種嚴(yán)謹(jǐn)，造成了問題。
假如你的后端應(yīng)用剛開始是沒有開啟gzip壓縮的，這時候兩者相安無事；但如果你的后端應(yīng)用突然有一天開啟了gzip壓縮，你的這段代碼將全部over。
原因就是，服務(wù)端gzip數(shù)據(jù)包會原樣返回，你需要手動處理gzip數(shù)據(jù)包。
所以，不加是好事，加了反而會壞事，除非你想自己處理gzip數(shù)據(jù)。
由于OkHttp在Android上應(yīng)用也非常廣泛，如果你不知道這個細(xì)節(jié)，造成的后果就是災(zāi)難性的?？蛻舳烁侣荒芾侠蠈崒嵒赝朔?wù)端了。
智能的背后，總有些肉眼不可見的細(xì)節(jié)。就像是xjjdog純情的背后，總有一份羞澀。只有深入了解，你才會知道它的美。
以上就是W3Cschool編程獅關(guān)于OkHttp透明壓縮，收獲性能10倍，外加故障一枚的相關(guān)介紹了，希望對大家有所幫助。
