hello everyone , I'm Kobayashi .
I received a reader's question before , about TCP Some questions about three handshakes and four waves ：
First handshake , If the client sends SYN It can't be transmitted to the server , So the client is always retransmitted SYN To forever ? Client stop retransmission SYN What's the timing ?
Third handshake , If the server will never receive ACK, The server will stay forever Syn-Recv Status ? What is the time to exit this state ?
Third wave , If the client never receives FIN,ACK, The client always stays in Fin-Wait-2 Status ? When is the time to exit this state ?
Fourth wave , If the server never receives ACK, The server always stays in Last-Ack Status ? What is the time to exit this state ?
If client stay 2SML Still not received within FIN,ACK, Will the link be closed ? What about the server , How did you close the link ?
Can see , These questions are all about TCP How are these exception scenarios handled , We're learning TCP When the connection is established and disconnected , Always think these processes can be completed on schedule .
Unfortunately, the ideal is full , The reality is very skinny , The facts are predictable .
TCP Of course not , The above exception scenarios are handled .
This time, I will focus on this series of questions asked by readers , Let's talk about it in detail TCP How do you handle these exceptions ?
These abnormal scenarios are divided into two categories , The first category is TCP Exceptions during three handshakes , The second category is TCP Abnormalities during four waves .
<>TCP Exceptions during three handshakes
Let's take a look first TCP The process of shaking hands three times .
<> The first handshake was lost , What happens ?
When the client wants to establish a relationship with the server TCP When connecting , The first one is SYN message , Then go to SYN_SENT state .
After that , If the client fails to receive the information from the server 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 Second , Also 3 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 1 No message from the server was received after seconds SYN-ACK After message , The client will resend SYN message , How many retransmissions ?
stay Linux in , Client 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 5.
usually , The first timeout retransmission is at 1 Seconds later , The second timeout retransmission is at 2 second , The third timeout retransmission is at 4 Seconds later , The fourth timeout retransmission is at 8 Seconds later , The fifth time is retransmission after timeout 16
Seconds later . you 're right , Each timeout is the last time 2 times .
After 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 Minutes or so .
<> The second handshake was lost , What happens ?
After the server receives the first handshake from the client , Will return SYN-ACK Message to client , This is the second handshake , The server will enter SYN_RCVD state .
Second handshake SYN-ACK The message 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 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 （ First handshake ） Lost , Then the client will trigger the timeout retransmission mechanism , Retransmission SYN message .
then , Because the second handshake contains the information of the server SYN message , So when the client receives , It needs to be sent to the server ACK confirmation message （ 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 lower ,SYN-ACK The maximum number of retransmissions of the message is determined by tcp_synack_retries Kernel parameter determination , 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 parameter determination .;
* The server will retransmit SYN-AKC message , That's the second handshake , The maximum number of retransmissions is determined by tcp_synack_retries Kernel parameter determination .
<> The third handshake was lost , What happens ?
The client receives a message from the server SYN-ACK After message , Will return one to the service ACK message , That's the third handshake , At this point, the client status enters ESTABLISH state .
Because of this third handshake ACK It's for the second handshake SYN
Confirmation message of , So when the third handshake was 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 is reached .
be careful ,ACK The message will not be retransmitted , When ACK Lost , The other party retransmits the corresponding message .
<>TCP Abnormalities during four waves
Let's see again TCP The process of four waves .
<> The first wave was lost , What happens ?
When client （ Active shutdown party ） call close After function , It will be sent to the server FIN message , Attempting 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 ） Yes ACK, Will soon become FIN_WAIT2 state .
If the first wave is lost , Then the client can't receive the information from the passive party ACK Words , The timeout retransmission mechanism will also be triggered , Retransmission FIN message , Number of retransmissions by tcp_orphan_retries
Parameter control .
When the client retransmits FIN The number of messages exceeds tcp_orphan_retries after , No longer send FIN message , Direct access to close state .
<> The second wave was lost , What happens ?
When the server receives the first wave of the client , Will return one first ACK confirmation message , At this time, the connection of the server enters CLOSE_WAIT state .
We mentioned it 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 the second wave from the server is received , Or the maximum number of retransmissions is reached .
Let me mention it here , When the client receives a second wave , That is, the message sent by the server is received ACK After 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, on the server side FIN message .
about close Function to close the connection , 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 calls close Closed connection , If in 60 Not received in seconds FIN message , client （ Active shutdown party ） The connection will be closed directly .
<> The third wave was lost , What happens ?
When the server （ Passive Closing Party ） Received client （ Active shutdown party ） Yes FIN After 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 close 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 State time , Called close function , The kernel will issue FIN message , Simultaneous connection entry LAST_ACK state , Waiting for client to return ACK
To confirm that the connection is closed .
If you don't get this later ACK, The server will resend FIN message , The number of retransmissions is still determined by tcp_orphan_retries Parameter control , This is different from client retransmission FIN
The retransmission times of messages are controlled in the same way .
<> The fourth wave was lost , What happens ?
When the client receives the third wave from the server FIN After message , Will return ACK message , That's the fourth wave , The client connection enters TIME_WAIT state .
stay Linux system ,TIME_WAIT The status will continue 60 It will not enter the off state until seconds .
then , Server （ Passive Closing Party ） 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 !