TCP three handshakes and four waves dialysis

TCP Transmission control protocol （Transmission Control Protocol, Abbreviation ：TCP） It's a connection oriented 、 reliable 、 Transport layer communication protocol based on byte stream .---- Wikipedia

TCP The purpose of three handshakes is to establish ** Safe and reliable full duplex 【 Both can be sent and received 】** Communication channel . Three handshakes confirm that the double transmission link is smooth , And agree on the initial data communication serial number , Ensure data integrity and feasible retransmission mechanism .

TCP Why do I need three handshakes Not once or twice ？

Only through the other side to A Message Feedback , To know A—Message Whether received 【 Refer to texting 】, Unable to get A-Message The previous information confirms , Both sides of the communication confirm information with each other , The minimum interaction path to reach a consensus is three times .

TCP Any message that consumes the serial number in the protocol needs ACK Confirm that it was sent successfully , otherwise , It's going to be retransmitted .

A handshake is not acceptable ： A handshake is not a handshake at all , Equal to zero times

Through only one handshake, the client doesn't know whether the server is turned on , It's like shouting at the people in the next house ： I'll go to your house tomorrow , If you don't consider the response , You have no idea whether the neighbors agree , In this case , Handshake means nothing to oneself , Unable to determine whether the link is smooth .

You can't shake hands twice ： Although the client can determine the sending and receiving capacity of the server , But the server cannot determine the sending and receiving capacity of the client 【 For example, the firewall of the other party cannot accept overseas data 】

Each end is in formal Established In state , Be sure that the other party can receive their own information , Otherwise, at this point , This communication link is not reliable . Two handshakes Established When , The server cannot confirm whether the sending and receiving ability of the client at this point is normal 【 Unable to determine whether the client can receive the second handshake 】, If mandatory , After exception , It can lead to Server Establish false links on the end , waste Server resources . Personally, there may be two situations ：

The above scenario is as follows ：

*  The client sends SYN
*  Server received SYN, And reply to the client , At the same time, make sure to establish links 
*  The data replied by the server is lost 
*  Client retransmission SYN, And lost 
*  Client retransmission SYN, And lost 
*  The client abandons the link , And the server may not receive any response 
*  The server waits for nothing 

In this case , The server wasted a link resource , because ： When unconfirmed information is received , The server privately established a link , In this case , The client may give up establishing links , But two handshakes , There is no problem for the client to send data individually .

Another scenario is SYN The message arrives after , as follows ：

*  The client sends SYN
* SYN Overtime , Client retransmission 
*  Server received SYN, And reply to the client , At the same time, make sure to establish links 
*  The client received a response , Make sure to establish a link 
*  The client and server transmit data 
* SYN Delayed arrival at the server 
*  Server received SYN, And the reply , At the same time, make sure to establish links 
*  The client has closed the link channel , There will be no response 
*  The server waits for nothing 

The two scenes above unreliable The ultimate reason is ： When the server does not receive feedback , Establish links privately , To avoid this , We must wait for the second time for the information to be confirmed by the customer , This is the necessity of adding a third handshake .

Three handshakes can

Three handshakes ： Three handshakes guarantee Both parties can receive feedback from each other about the information they send . Correction of the first error scenario ：

The client does not receive the second handshake , In the scenario of abandoning the link server , The server cannot receive the client ACK Of , At this time , The server will not successfully establish a link . For the second scenario .

In delay SYN After arriving at the server , The server needs to wait Client Terminal ACK, Will confirm the link establishment , On the premise that the link has been closed , It should not be effective ACK Back to , The server will resend several times , Close semi open links . For the delay when the link is alive SYN, Theoretically, it can be solved by discarding , Don't consider this scenario .

From a client point of view , send out SYN after , Never received ACK It'll be reissued , From the perspective of the server , send out SYN-ACK after , Have not received ACK It'll be reissued , In theory, both can happen at the same time , The server is resending SYN-ACK When , The client may also be resending SYN, But the client will not resend ACK, Once the customer order is received SYN-ACK Think the link has been established . Can send data , If the server does not receive ACK Received first DATA（ The retransmission logic has not been triggered ）, What will happen? ？ in other words ACK What will happen if lost , Personal understanding , The server can also be seen as link building ,TCP Under the protocol framework, it supports the third handshake to carry user data , It's just that some systems need configuration to be enabled . Reference resources

The serial number confirmed during handshake ensures the accurate determination of the first data , At the same time, it also ensures that the subsequent data is not out of order .

TCP Different noun concepts

• Synchronization segment ： carry SYN Message segment marked , Used with the initial sequence ISN
• Confirm message segment ： carry ACK Message segment marked , After the connection is established, all transmitted message segments will send ACK Set to 1【 In fact, only initiate SYN It was not set when 】
• Reset message segment ： carry RST Message segment marked , It is generally enabled when an exception occurs
• End segment ： carry FIN Message segment , It indicates that the data of the sender has been sent , Demand release TCP Connect
• Sequence Number It's the serial number of the package , It is used to solve the network packet disorder problem .
• Acknowledgement Number Namely ACK—— Used to confirm receipt of , Used to solve the problem of packet loss .ACK Messages can carry data . If you don't carry data , No serial number is consumed , The sequence number of the next data message segment is still seq=x+1.

Handling of various exceptions in handshake

• If the first one SYN lost

  Client resend SYN, The server is not aware

• If second SYN-ACK lost

  client SYN Retransmission , Server side SYN-ACK Retransmission

• If the third ACK lost

  The server does not have to retransmit SYN-ACK, The client does not have to retransmit ACK【 Data first 】

The third ACK Lost in the network ,Server End according to TCP Timeout retransmission mechanism of , Will wait for 3 second 、6 second 、12 Seconds to resend SYN+ACK package , The number of times can be set /proc/sys/net/ipv4/tcp_synack_retries modify , The default value is 5. If after a specified number of resends , Still not received client Of ACK The reply , After a while ,Server Automatically close this connection .

client connect() stay TCP After the second handshake of the three handshakes, it will return to success . in other words client On receiving SYN+ACK package , its TCP The connection state is established （ Connected ）, Indicates that the connection has been established . In the third handshake ACK In case of package loss ,Client towards server End send data ,Server The end will be RST Package response , To feel Server Error of .

Close why wave four times

Four waves are better than three handshakes 【 The three step handshake. 】 One more time , as a result of ： Full duplex data transmission is in progress , At the same time, ensure that the data transmission is completed . Three handshakes , No data transmission , therefore Server Back to ACK And the second SYN Can be merged into one , But when you wave , In fact, there is data transmission , The transmission cannot be completed at the same time 【 Or a certain time 】, The timing of the completion of double transmission is random , So the completion notification will also be out of sync , Only separate notices ACK, Cannot merge like three handshakes , That's why there was one more time , The client or the server can take the initiative to wave , Either party Socket perform close() The operation can produce a wave action .