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

This article introduces the relevant knowledge of "what are the advantages of OkHttp transparent compression". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

To use OkHttp, you must know its transparent compression, otherwise you don't know how to die, or you don't know why you don't live comfortably.

It's not a good thing.

What is transparent compression? when OkHttp sends a request, it automatically adds the gzip request header Accept-Encoding:gzip. Therefore, when the returned data has a gzip response header, Content-Encoding=gzip,OkHttp 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? You can take a look at the real screenshot below. 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.

As shown in the figure above, it may take many 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 OkHttp's transparent proxy is the easiest way.

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

Dependency > io.github.openfeign feign-okhttp

Second, enable OkHttp 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 OkHttp's transparent proxy.

If your application packet is large and the call chain is long, this approach may even bring a few seconds of sexual improvement to your service. 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?

OkHttp 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 OkHttp 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.

Behind intelligence, there are always some details invisible to the naked eye. Just like behind the pure feelings of xjjdog, there is always a shyness. Only with a deep understanding will you know its beauty.

This is the end of the content of "what are the advantages of OkHttp transparent compression". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.