Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to realize transparent Compression in OkHttp

2025-02-27 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/01 Report--

This article mainly introduces OkHttp how to achieve transparent compression related knowledge, the content is detailed and easy to understand, the operation is simple and fast, has a certain reference value, I believe you will have something to gain after reading this OkHttp article on how to achieve transparent compression, let's take a look at it.

What is transparent compression? OkHttps automatically adds the gzip request header Accept-Encoding:gzip when sending the request. Therefore, when the returned data has a gzip response header, Content-Encoding=gzip,OkHttps will automatically decompress the data for us. (Accept-Encoding and Content-Encoding are a pair of request headers, corresponding to request and return, respectively)

Why should it be compressed? Because it can greatly reduce the capacity of transmission. Like some services with low CPU resource consumption, such as Kafka, we can turn on gzip compression to speed up the flow of information.

How high is this compression ratio? For ordinary xml or json, the data can be compressed from 9MB to 350KB, with a compression ratio of 26.

It makes the system performance fly.

SpringCloud micro-service system is now used by many companies. Even some traditional enterprises, some toB enterprises with a large amount of data, also want to taste the crabs.

For a simple SpringBoot service, we only need to configure the corresponding compression in the yml file. In this way, we have opened up the link from the browser to the Web service. This compression method, for a large amount of data services, is life-saving!

The specific configuration is as follows.

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

Its corresponding Spring configuration class is org.springframework.boot.web.server.Compression.

But don't be happy too soon. Because it is a distributed environment, the call chain will be longer. Even in the intranet, network transmission of more than ten MB will take a considerable amount of time.

It may take a lot of steps for a request to go from the browser to the real service node.

Nginx forwards the request to the microservice gateway zuul

Zuul is forwarded to specific microservice A

Micro service An invokes micro service B through Feign interface

If most of our data is provided by microservice B, then the slow transmission efficiency of any of the above links will affect the performance of the request.

Therefore, we need to enable gzip compression on the Feign interface. Using OkHttps's transparent proxy is the easiest way.

First, introduce feign's jar package into the project.

Io.github.openfeign feign-okhttp

Second, enable OkHttps as the client request kit for feign in the yml file. To be on the safe side, we also blocked httpclient, which is too heavy and old.

Feign: httpclient: enabled: false okhttp: enabled: true

At this point, we can enjoy the convenience of OkHttps's transparent proxy.

If your application packet is large and the call chain is long, this approach may even improve the performance of your service for a few seconds. Xjjdog used to make a snail system fly by adjusting a few parameters. Everyone exclaimed: it turns out that the B end can also be C once.

How does OkHttp achieve transparent compression?

OkHttps handles transparent compression through interceptors. The concrete class is okhttp3.internal.http.BridgeInterceptor.

The specific code is as follows, when it is judged that there is no Accept-Encoding header, add one on your own.

/ 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");}

The most critical code is below.

If (transparentGzip & & "gzip" .equals IgnoreCase (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));}

You can see that there are three conditions in the if statement.

The program does not set Accept-Encoding and transparent compression is enabled

The server has a Content-Encoding header and gzip compression is enabled

There is a packet

Only when these three conditions are met at the same time, the transparent compression of OkHttps will work and help us decompress automatically.

The hole it dug is a little deep.

Unfortunately, the key code above is only if, not else, that is, when any of these conditions are not met, the back-end packet will be returned intact.

2 and 3 there is no problem with the two conditions, and there is no harm in returning the back-end data as it is. The problem lies in the first condition.

If you are in the code, use the following code:

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

That is, the Accept-Encoding header information is set manually. This is common because it reflects the rigour of the programmer's mind.

It is this rigor that creates problems.

If your back-end application does not enable gzip compression at first, the two are fine, but if your back-end application suddenly turns on gzip compression one day, your code will be all over.

The reason is that the server-side gzip packets will be returned as is, and you need to process the gzip packets manually.

So, not adding is a good thing, but it will be bad, unless you want to deal with gzip data yourself.

Because OkHttp is also widely used on Android, if you don't know this detail, the consequences can be catastrophic. The client updates slowly, so you can only honestly go back to the server.

This is the end of the article on "how to achieve transparent compression in OkHttp". Thank you for reading! I believe you all have a certain understanding of the knowledge of "how to achieve transparent compression in OkHttp". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report