How TCP handles exceptions during three handshakes and four waves

1、TCP Exceptions during three handshakes

Let's take a look first TCP How about three handshakes .

1.1、 The first handshake was lost , What's going to happen ？

When the client wants to establish with the server TCP When connecting , First of all, the first one is SYN message , And then into SYN_SENT state .

After this , If the client fails to receive the information from the server for a long time SYN-ACK message （ The second handshake ）, The timeout retransmission mechanism will be triggered .

Different versions of operating systems may have different timeout times , yes , we have 1 Of a second , Also have 3 Of a second , This timeout is written dead in the kernel , If you want to change, you need to recompile the kernel , More trouble .

When the client is in 1 Seconds later, I didn't receive the message from the server SYN-ACK After the message , The client will resend SYN message , How many times do you resend it ？

stay Linux in , Client's SYN The maximum number of retransmissions of the message is determined by tcp_syn_retries Kernel parameter control , This parameter can be customized , The default value is usually 5.

Usually , The first timeout retransmission was in 1 Seconds later , The second timeout retransmission was in 2 second , The third timeout retransmission was in 4 Seconds later , The fourth timeout retransmission was in 8 Seconds later , The fifth time was retransmission over time 16 Seconds later . you 're right , Each timeout is the last time 2 times .

When the fifth timeout retransmission , Will continue to wait 32 second , If the server still does not respond ACK, The client will no longer send SYN package , Then disconnect TCP Connect .

therefore , The total time is 1+2+4+8+16+32=63 second , about 1 About minutes .

1.2、 The second handshake was lost , What's going to happen ？

When the server receives the first handshake from the client , It will come back to SYN-ACK Message to client , This is the second handshake , At this point, the server will enter SYN_RCVD state .

The second handshake SYN-ACK The message actually has two purposes ：

• In the second handshake ACK, It is a confirmation message for the first handshake ;
• In the second handshake SYN, The server initiates the establishment of TCP Connected message ;

therefore , If the second handshake is lost , Will send more interesting things , What will happen ？

Because the second handshake message contains the first handshake to the client ACK Confirmation message , therefore , If the client does not receive the second handshake , Then the client may feel that its own SYN message （ The first handshake ） lost , therefore The client will trigger the timeout retransmission mechanism , Retransmission SYN message .

then , Because the second handshake contains the server's SYN message , So when the client receives , You need to send to the server ACK Confirmation message （ The third handshake ）, The server will think that SYN The message was received by the client .

that , If the second handshake is lost , The server cannot receive the third handshake , therefore The server side will trigger the timeout retransmission mechanism , Retransmission SYN-ACK message .

stay Linux Next ,SYN-ACK The maximum number of retransmissions of the message is determined by tcp_synack_retries Kernel parameters determine , The default value is 5.

therefore , When the second handshake is lost , Both client and server will retransmit ：

• The client will retransmit SYN message , That's the first handshake , The maximum number of retransmissions is determined by tcp_syn_retries Kernel parameters determine .;
• The server will retransmit SYN-AKC message , That's the second handshake , The maximum number of retransmissions is determined by tcp_synack_retries Kernel parameters determine .

1.3、 The third handshake was lost , What's going to happen ？

The client receives... From the server SYN-ACK After the message , The server will receive a ACK message , That's the third handshake , At this point, the client state enters ESTABLISH state .

Because of this third handshake ACK It's for the second handshake SYN Confirmation message of , So when the third handshake is lost , If the server fails to receive the confirmation message for a long time , The timeout retransmission mechanism will be triggered , Retransmission SYN-ACK message , Until the third handshake , Or the maximum number of retransmissions .
Be careful ,ACK The message will not be retransmitted , When ACK lost , The other party retransmits the corresponding message .

2、TCP Abnormal during four waves

Let's see TCP The process of waving four times .

2.1、 The first wave was lost , What's going to happen ？

When the client （ Active Closing Party ） call close After the function , Will send... To the server FIN message , Trying to disconnect from the server , At this point, the client's connection enters FIN_WAIT_1 state .

Under normal circumstances , If you can receive it from the server in time （ Passive Closing Party ） Of ACK, It will soon become FIN_WAIT2 state .

If you lose your first wave , So the client can't receive the passive Party's ACK Words , It will also trigger the timeout retransmission mechanism , Retransmission FIN message , The number of retransmissions is determined by tcp_orphan_retries Parameter control .

When the client retransmits FIN The number of messages exceeds tcp_orphan_retries after , No more sending FIN message , Direct access to close state .

2.2、 The second wave lost , What's going to happen ？

When the server receives the client's first wave , You'll go back to one first ACK Confirmation message , At this time, the connection of the server enters CLOSE_WAIT state .

We also mentioned earlier ,ACK Messages are not retransmitted , So if the second wave of the server is lost , The client will trigger the timeout retransmission mechanism , Retransmission FIN message , Until receiving the second wave from the server , Or the maximum number of retransmissions .

Just to mention here , When the client receives a second wave , That is, the message sent by the server is received ACK After the message , The client will be in FIN_WAIT2 state , In this state, you need to wait for the server to send a third wave , That is, the server FIN message .

about close Function to close the connection , Because data can no longer be sent and received , therefore FIN_WAIT2 The state cannot last too long , and tcp_fin_timeout Controls the duration of the connection in this state , The default value is 60 second .

This means that for calling close Closed connection , If in 60 I haven't received it in seconds FIN message , client （ Active Closing Party ） The connection will be closed directly .

2.3、 The third wave lost , What's going to happen ？

Be a server （ Passive Closing Party ） Client received （ Active Closing Party ） Of FIN After the message , The kernel will reply automatically ACK, At the same time, the connection is in CLOSE_WAIT state , seeing the name of a thing one thinks of its function , It means waiting for the application process to call close Function to close the connection .

here , The kernel has no right to replace the process to close the connection , Must be actively invoked by the process close Function to trigger the server to send FIN message .

The server is in CLOSE_WAIT In the state of , Called close function , The kernel will emit FIN message , Also connect into LAST_ACK state , Waiting for client to return ACK To confirm that the connection is closed .

If you don't get this ACK, The server will resend FIN message , The number of retransmissions is still by tcp_orphan_retries Parameter control , This is similar to client retransmission FIN The number of retransmissions of the message is controlled in the same way .

2.4、 The fourth wave lost , What's going to happen ？

When the client receives the server's third wave FIN After the message , It will come back to ACK message , The fourth wave , At this point, the client connection enters TIME_WAIT state .

stay Linux System ,TIME_WAIT The state will last 60 Seconds before it goes off .

then , Server side （ Passive Closing Party ） Have not received ACK Before message , Still in LAST_ACK state .

If you wave for the fourth time ACK The message did not reach the server , The server will resend FIN message , The number of retransmissions is still as described above tcp_orphan_retries Parameter control .

Is that so? ,TCP Smart ！