"Dare not doubt the code, but have to doubt the code" a network request timeout analysis

Abstract ： This positioning , Quite complicated , And sometimes people don't have ideas , Because the same interface , It's good to change the environment , Dare not doubt the code ; But the problematic environment , It's easy to change the interface , You have to doubt the code

This article is shared from Huawei cloud community 《 Analysis of a network request timeout 》, author ：xiewenci .

Problem phenomenon

launch http request , Back end service interface /v5/iot/11c9c88e6fb26bead43b75514dc380eb/routing-rule/rules?limit=10&marker=ffffffffffffffffffffffff&offset=0, Have been waiting for , A response is returned after one minute , And the Chinese garbled code shows

The analysis process

1. First delimitation , Change the same version code in normal environment and abnormal environment , Test the same interface , But the normal environment is normal , Abnormal environment or waiting 1 minute , So I think it's an environmental problem , So the next step , Grab the bag

2. Capture packets in abnormal environment and normal environment respectively , See the following figure for specific flow information ：

Flow information of abnormal environment

Flow information of normal environment

It can be seen from the picture that the normal environment is , After the server sends the response , Returned by the client normally ACK, Then the client initiates FIN Chain break request . The exception environment is after the server sends the response , The client also returns ACK, However, it did not initiate the chain breaking request , Until more than keep-alive After time , The server initiates the chain breaking request （ Active chain breaking due to timeout ）. The phenomenon is that the client is waiting for the server to send a response （ May not have been sent ）, Therefore, it is suspected that the server has a cache , The response stream was not sent out in time , So keep looking at the code

3. Look at the code , When returning to the client , No, flush and close operation , The code is as follows

Then I thought I had found the cause of the problem , Just try to modify the code , as follows ：

Added flush Operation and close operation （ On the try Yukuaizhong ）, Finally, test execution , It is consistent with the original phenomenon , Still waiting 1 The response will not be returned until minutes . At this time, I was a little puzzled , And analyze the indecency again , In fact, it can be seen from the flow , The response from the server is immediately returned to the client , Here's the picture

Now that the response is given , So why should the client continue to wait ？ Notice here that there are several question marks in the figure , This is actually Chinese character garbled , Therefore, it is doubtful whether the encoding format causes the client to receive Content-Length The length does not match the length of the response received , That is, the length of the response actually received by the client is less than Content-Length The length of , And then wait for it all the time , So continue to modify the code

4. Modify the code , Specify the encoding format as UTF-8, The code is as follows ：

Replace environment version , The test execution , The response immediately returns , Sure enough, it is the pot of this coding format

Cause review

1. Inconsistent encoding formats will lead to inconsistent actual length of response stream ？ The answer is certain , The coding format is inconsistent , The actual length will be inconsistent , The test results are as follows ：

2. Why hasn't this problem occurred before ？ What causes the loss of encoding format

View back-end services jar package , Find out spring Version has been upgraded to 5.2.21.RELEASE, The default encoding format is not specified in this version UTF-8

Therefore, the back-end service is required to specify the encoding format , Or the gateway service handles it uniformly

Summary and reflection

This positioning , Quite complicated , And sometimes people don't have ideas , Because the same interface , It's good to change the environment , Dare not doubt the code ; But the problematic environment , It's easy to change the interface , You have to doubt the code ; Another is to call the interface in the container , It's the same thing , So I feel that it has nothing to do with the Internet . In fact, we should calm down and think about why The client has been waiting , There is no initiative to initiate chain breaking , It still shows that HTTP Details of the agreement , Not proficient in , That led to some misunderstanding in the middle , We need to consolidate and deepen our understanding of http Understanding of the agreement .

 

Click to follow , The first time to learn about Huawei's new cloud technology ~