OkHttp透明壓縮的優點有哪些

本篇內容介紹了“OkHttp透明壓縮的優點有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

要使用OkHttp，一定要知道它的透明壓縮，否則死都不知道怎么死的;或者活也不知道為什么活的不舒坦。

反正不是好事。

什么叫透明壓縮呢?OkHttp在發送請求的時候，會自動加入gzip請求頭Accept-Encoding:gzip。所以，當返回的數據帶有gzip響應頭時Content-Encoding=gzip，OkHttp會自動幫我們解壓數據。(Accept-Encoding和Content-Encoding是一對請求頭，分別對應著請求和返回)

為什么要進行壓縮呢?因為它能大幅減少傳輸的容量。像一些CPU資源占用不高的服務，比如Kafka，我們就可以開啟gzip壓縮，加快信息的流轉。

這個壓縮比有多高呢?可以看下下面實實在在的截圖，對于普通的xml或者json，數據可以由9MB壓縮到350KB左右，壓縮比足足達到了26。

它讓系統性能飛起來

SpringCloud微服務體系，現在有非常多的公司在用。即使是一些傳統企業，一些大數據量的toB企業，也想嘗一嘗螃蟹。

對于一個簡單的SpringBoot服務，我們只需要在yml文件中配置上相應的壓縮就可以了。這樣，我們就打通了瀏覽器到Web服務的這一環。這種壓縮方式，對于大數據量的服務來說，是救命式的!

具體配置如下。

server:   port: 8082   compression:     enabled: true     min-response-size: 1024     mime-types: ["text/html","text/xml","application/xml","application/json","application/octet-stream"]

它所對應的Spring配置類是org.springframework.boot.web.server.Compression。

但是不要高興太早。由于是分布式環境，這里面調用鏈就會長一些。即使是在內網，動輒十幾MB的網絡傳輸，也會耗費可觀的時間。

如上圖，一個請求從瀏覽器到達真正的服務節點，可能要經過很多環節。

• nginx轉發請求到微服務網關zuul

• zuul轉發到具體的微服務A

• 微服務A通過Feign接口調用微服務B

如果我們的數據，大多數是由微服務B提供的，那么上面的任何一個環節傳輸效率慢，都會影響請求的性能。

所以，我們需要開啟Feign接口的gzip壓縮。使用OkHttp的透明代理是最簡單的方式。

首先，在項目中引入feign的jar包。

dependency>             <groupId>io.github.openfeign</groupId>             <artifactId>feign-okhttp</artifactId> </dependency>

其次，在yml文件中啟用OkHttp作為feign的客戶端請求工具包。穩妥起見，我們同時屏蔽了httpclient，這個東西太重太老了。

feign:   httpclient:     enabled: false   okhttp:     enabled: true

到此為止，我們就可以享受OkHttp的透明代理帶來的便捷性了。

假如你的應用數據包大，調用鏈長，這種方式甚至會給你的服務帶來數秒的性能力提升。xjjdog就曾經靠調整幾個參數，就讓一個蝸牛系統飛了起來。大家驚呼：原來B端也可以C一下。

OkHttp是如何實現透明壓縮的?

OkHttp對于透明壓縮的處理，是通過攔截器來做的。具體的類，就是okhttp3.internal.http.BridgeInterceptor。

具體代碼如下，當判斷沒有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"); }

最關鍵的代碼在下面。

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語句里，有三個條件。

• 程序沒有設置Accept-Encoding，啟用了透明壓縮

• 服務端有Content-Encoding頭，并啟用了gzip壓縮

• 有數據包

只有同時滿足這三個條件，OkHttp的透明壓縮才會起作用，幫我們自動解壓。

它挖的坑有點深

可惜的是，上面的關鍵代碼，只有if，沒有else，也就是當其中的任何一個條件不滿足，后端的數據包將原封不動的返回。

2、3兩個條件是沒有什么問題的，原樣返回后端數據并沒有什么損害，問題就出在第一個條件里。

如果你在代碼中，使用了下面的代碼：

Request.Builder builder = chain.request()                 .newBuilder()                 .addHeader("Accept", "application/json")                 .addHeader("Accept-Encoding", "gzip");

也就是手動設置了Accept-Encoding頭信息。這很常見，因為這體現了程序員思維的嚴謹。

正是這種嚴謹，造成了問題。

假如你的后端應用剛開始是沒有開啟gzip壓縮的，這時候兩者相安無事;但如果你的后端應用突然有一天開啟了gzip壓縮，你的這段代碼將全部over。

原因就是，服務端gzip數據包會原樣返回，你需要手動處理gzip數據包。

所以，不加是好事，加了反而會壞事，除非你想自己處理gzip數據。

由于OkHttp在Android上應用也非常廣泛，如果你不知道這個細節，造成的后果就是災難性的。客戶端更新慢，只能老老實實回退服務端了。

智能的背后，總有些肉眼不可見的細節。就像是xjjdog純情的背后，總有一份羞澀。只有深入了解，你才會知道它的美。

“OkHttp透明壓縮的優點有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！