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 !

Technology
©2019-2020 Toolsou All rights reserved,
What is a process , Concept of process ? Tang Seng team to lay off staff , Who will you lay off ?Oracle Database access performance optimization JVM Old age garbage collection Full GCweb Two front-end practical games ( Attached source code ) about linux command “iptables -F”, Don't carry it out easily navicat function sql File error 2021-06-03 A man is not born to be defeated Pandas And openpyxl Super combination of Library , bye ,Excel! It is never recommended to spend a lot of time studying for employment python