I'm afraid of the goose factory!

A reader came to me last week and said , When he interviewed Tencent , With this problem ：

This belongs to TCP Scenario of abnormal disconnection , This part is in my 「 Graphic network 」 It's not detailed yet , Take this opportunity to make up for it .

Kobayashi csdn Wrote a lot of graphic network articles , A total of 15 swastika And draw 500 Pictures , Yes csdn My friend suggested that I organize the illustrated network articles into electronic files , It's easy for readers to read .

That must be , So Kobayashi spent some time sorting out the graphic network electronic documents , The effect is like the title ：

You can use it as a handbook for interview Raiders , Now open source for everyone to download ： Click download graphic network PDF

Okay , Continue today's theme .

There are several key words to this question ：

It's not turned on keepalive;
There has been no data interaction ;
Process breakdown ;
Host crash ;
Let's first know what is TCP keepalive Well ？

This thing is actually TCP The survival mechanism of , How it works, as I've written in previous articles , Just post the previous content here .

If it's on both ends TCP The connection has never had data interaction , Reached the trigger TCP The conditions for the survival mechanism , So what's in the kernel TCP The protocol stack will send a probe message .

If the peer program works properly . When TCP The live detection message is sent to the opposite end , The opposite end will respond normally , such TCP The hold time will be reset , Wait for the next TCP The arrival of survival time .
If the peer host crashes , Or the message is unreachable due to other reasons . When TCP After the live detection message is sent to the opposite end , Under the , No response , Several times in a row , After reaching the number of live detection ,TCP It will be reported that TCP The connection is dead .
therefore ,TCP The livekeeping mechanism can be used when there is no data interaction between the two parties , By detecting messages , To determine the other person's TCP Is the connection alive .

Be careful , If the application wants to use TCP The survival mechanism needs to go through socket Interface setup SO_KEEPALIVE Options will work , If not set , Then you can't use TCP The survival mechanism .

got it TCP keepalive effect , Let's go back to the topic 「 Host crash 」 This situation .

Before opening TCP keepalive, And there has been no data interaction between the two sides , If the client's 「 Host crash 」 了 , What's going to happen .

The client host crashed , The server cannot perceive it , In addition, the server is not turned on TCP keepalive, Without data interaction , Server side TCP The connection will always be in ESTABLISHED Connection status , Until the server restarts the process .

therefore , We can get a point , Before use TCP Keep the mechanism alive and both parties do not transmit data , One side TCP The connection is in ESTABLISHED state , It does not mean that the other party's connection must be normal .

In that title 「 Process breakdown 」 In the case? ？

I did my own experiment , Use kill -9 To simulate a process crash , Found in kill After dropping the process , The server will send FIN message , Four waves with the client .

therefore , Even if it's not turned on TCP keepalive, And there is no data interaction between the two sides , If one of the processes crashes , This process is perceptible to the operating system , So it's going to send FIN Message to the other party , And then with each other TCP Four waves .

The above is the answer to this interview question , Next let's look at 「 There's data transmission 」 Some anomalies in the scene of ：

The first one is , Client host down , It's going to restart again , What's going to happen ？
The second kind , Client host down , There has been no restart , What's going to happen ？
Client host down , It's going to restart again
After the client host goes down , The message sent by the server to the client will not get any response , After a certain period of time , The server will trigger the timeout retransmission mechanism , Retransmit the unresponsive message .

In the process of retransmission message by server , After the client host restarts , The client's kernel will receive the retransmitted message , Then it is transmitted to the corresponding process according to the message information ：

If there is no process listening on the client host TCP The destination port number of the message , Then the client kernel will ** reply RST message , Reset this TCP Connect *;
If there is a process listening on the client host TCP The destination port number of the message , Due to the client host after restart , Previous TCP The data structure of the connection has been lost , The protocol stack in the client kernel will find that the TCP Connected socket Structure , And I will reply RST message , Reset this TCP Connect .
therefore , As long as one party restarts , Before you receive it TCP Connected message , I'll reply RST message , To disconnect .

Client host down , There has been no restart
This situation , When the number of times of retransmission message reaches a certain threshold , The kernel will determine that TCP There is a problem , And then through Socket The interface tells the application to TCP There's something wrong with the connection , It is commonly ETIMEOUT Status code .

How many retransmissions are there ？

stay Linux In the system , Provide one called tcp_retries2 Configuration item , The default value is 15, Here's the picture ：

This kernel parameter is control , stay TCP When the connection is established , The maximum number of timeout retransmissions .

however tcp_retries2 Set up 15 Time , Doesn't mean TCP Retransmission over time 15 Will notify the application to terminate the TCP Connect , The kernel will also be based on 「 Maximum timeout 」 To determine .

The timeout time of each round increases in multiples , For example, the first time a timeout retransmission is triggered is in 2s after , The second time is in 4s after , The third time is 8s after , And so on .

The kernel will be based on tcp_retries2 Set the value of the , Calculate a maximum timeout .

When the message is retransmitted and no response is received , Arrive first 「 Maximum number of retransmissions 」 perhaps 「 Maximum timeout 」 After one of these two conditions , Will stop retransmission .

Finally ,TCP frigging awesome , Every exception is taken into account .
————————————————
Copyright notice ： This paper is about CSDN Blogger 「 Kobayashi coding」 The original article of , follow CC 4.0 BY-SA Copyright agreement , For reprint, please attach the original source link and this statement .
Link to the original text ：https://blog.csdn.net/qq_34827674/article/details/117922761