Transport connection management of TCP

TCP Transportation connection management

Refer to Xie Xiren's 《 computer network 》 The Seventh Edition 5.9 section

TCP The connection is established ——“ Three handshakes ”

Refer to Xie Xiren's 《 computer network 》 The seventh edition 5.9.1 This section is about “ Three handshakes ” This paper ,TCP When establishing a connection “three way handshake”, That is to say “ Three message handshake ”, That is, one handshake exchanges three messages , This is equivalent to a handshake , His hands shook up and down three times , Instead of shaking hands three times

Even if the above explanation is so , But for the convenience of subsequent description , I still use “ Three handshakes ” That's what I'm saying

I'm not right here “ Three handshakes ” The specific sequence number and signal bit change in the process are too elaborated , Instead, focus on explaining why “ The third handshake ”

The client A Want to communicate with the server B establish TCP Connect , therefore A towards B Sent a connection request message （ The first handshake ）, here B The request message is normally received , So she asked A Send a connection confirmation message （ The second handshake ）,A After receiving the confirmation message, send it to B Send a confirmation message （ The third handshake ）, Used to B Confirm that you have received B Confirm connection message

That's all “ Three handshakes ” The general process of

actually “ Three handshakes ” It can also be practiced as “ Four handshakes ”, Also is to “ The second handshake ” The confirmation connection message sent at is divided into two messages ： The confirmation connection message includes confirmation message and synchronization message , Then this message can be split into confirmation messages and sent once , Send the synchronization message again （ This is equivalent to one transmission , So since three times can solve the problem, there is no need to divide it into four times ）

When A Received it from B Confirm connection message , Will enter ESTABLISHED state , That is, confirm the status , that Why should I ask B Send another confirmation message ？
This is to avoid “ Invalid connection request message ” Resulting errors
This means to be A towards B When sending connection request message , The connection request message may be lost in the network （ Messages that completely fail without affecting subsequent connections ）, such A If the message confirming the connection is not received after a period of time, you can choose to resend the connection request message , So when the connection request message is B When received ,B towards A The connection can be established by sending a confirmation message . No at this time “ The third handshake ” It's fine too .
But there is a situation where A The sent request message has been stuck at a node in the network for too long , Lead to A Thought this message had been lost （ This is it. “ Invalid connection request message ”）, And then A Without sending a new connection request . After a period of time , The stranded connection request message may eventually arrive B, Now B It's very natural to A Send a connection confirmation message , But this time A Not to B Send a connection request , Not waiting for B The confirmation of , So ignore B Confirmation connection message sent . And if it doesn't exist at this time “ The third handshake ”, This will lead to B Always set aside some resources to maintain the connection , wait for A Transmit data , This will lead to a waste of server resources ; But if there is “ The third handshake ”, that B After waiting for a period of time, I didn't wait for you “ The third handshake ” Bring the confirmation message , You know that A Not waiting for B The connection of ,B You can release the occupied resources without waiting for nothing

Because an interaction requires a request and a response ” Two handshakes “, And in order to avoid ” Invalid connection request “ Resulting errors , need A towards B Send another confirmation , Another time is needed “ handshake ”, So the common needs “ Three handshakes ”

TCP The connection release ——“ Four waves ”

I'm not right here “ Four waves ” The specific sequence number and signal bit change in the process are too elaborated , Instead, focus on explaining why “ Four waves ” To complete the connection release , And after the last wave 2 MSL The role of time （MSL,Maximum Segment Lifetime, Maximum segment life ）

You need to know why “ Four waves ” To release the connection , Just know this “ Four waves ” It's OK to play any role

When the client A Want to release with the server B The connection of , You need to take the initiative to B Send a connection release request （ First wave ） And stop sending data ,B After receiving this message, send it to A Send a confirmation release message （ Second wave ）. Pay attention at this time A And B The connection between is not completely closed , It is in a semi closed state , That is to say A There is no data to send , and B You can also go to A send data . When one end of time B No more to A When sending data ,B As to the A Send connection release message （ Third wave ）, At this time A If you receive the message, send it to B Send confirmation release message （ Fourth wave ）, When B About after entering the closed state 2 MSL After time A Also enter the closed state , At this point, the connection is completely released
So the reason why you need to wave four times is A and B The release of the connection between them is divided into two sections , A half released connection , Release first A towards B Direction data transmission connection , Re release B towards A Direction data transmission connection , This is because when A When actively requesting disconnection ,A Data transmission has been definitely stopped here , but B There may be data that hasn't been sent yet , So we need to A Wait a little longer and release the connection further .
and An interaction will naturally have a request and a response “ Two waves ”, The release of connection is divided into two sections , There are two interactions , Naturally, we need “ Four waves ” 了

It can be noted that A stay “ Fourth wave ” It did not enter the closed state directly after , It's just waiting 2 MSL Time for , There are two reasons for this ：

1. prevent A“ Fourth wave ” When the confirmation message sent is lost, it leads to B Unable to enter the closed state normally
   A The confirmation message sent may be lost , If A Enter the closed state immediately after sending the confirmation message , Then if the message is lost ,B It cannot normally enter the closed state . Because we can't receive from A The confirmation of ,B Will keep repeating “ Third wave ”, And has been unable to enter the closed state . If A Do not immediately enter the closed state , But wait 2 MSL Time , be B You can resend the connection release request when you cannot get confirmation , here A Did not enter the closed state , Can receive B Request , that A Retransmit the confirmation release message （ The waiting time is reset to 2 MSL）; If B received A The confirmation of will enter the closed state , that A stay 2 MSL Time will not be received again B New release request for , such A You can enter the closed state
2. prevent “ Invalid connection request message ” Appears in a new connection
   stay A and B When the connection , There may be some message segments stranded in the network , after 2 MSL Entering the shutdown state after time can make these message segments disappear from the network , Without affecting subsequent new connections

The server B In fact, a keep alive timer will be set （keepalive timer） To avoid clients A Failure to maintain and close the connection normally . This keep alive timer is generally set to 2 Hours , When A towards B send data , The timer will be reset to 2 Hours , And when A I didn't go to... For more than two hours B send data ,B Every once in a while 75 Second direction A Send a probe message , When 10 Such a probe message has not received a response since it was sent ,B You think A Something goes wrong , Actively disconnect , Recycle resources