您好,登錄后才能下訂單哦!
這篇文章主要介紹了OkHttp如何實現(xiàn)透明壓縮的相關(guān)知識,內(nèi)容詳細(xì)易懂,操作簡單快捷,具有一定借鑒價值,相信大家閱讀完這篇OkHttp如何實現(xiàn)透明壓縮文章都會有所收獲,下面我們一起來看看吧。
什么叫透明壓縮
呢?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)著請求和返回)
為什么要進(jìn)行壓縮呢?因為它能大幅減少傳輸?shù)娜萘?。像一?CPU 資源占用不高的服務(wù),比如 Kafka ,我們就可以開啟 gzip 壓縮,加快信息的流轉(zhuǎn)。
這個壓縮比有多高呢?對于普通的xml
或者json
,數(shù)據(jù)可以由9MB
壓縮到350KB
左右,壓縮比足足達(dá)到了26
。
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一下。
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ù)端了。
關(guān)于“OkHttp如何實現(xiàn)透明壓縮”這篇文章的內(nèi)容就介紹到這里,感謝各位的閱讀!相信大家對“OkHttp如何實現(xiàn)透明壓縮”知識都有一定的了解,大家如果還想學(xué)習(xí)更多知識,歡迎關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。