TCP three handshakes and four waves

1、 Why? TCP use 3 It's a handshake, not 2 Time or 4 The second handshake

reason 1： Two way connection , Shake hands at least three times

In fact, the essence of the problem is that the channel is unreliable , But both sides of the communication need to reach an agreement on a certain issue , And to solve this problem , No matter what message is included in the message , Triple communication is the theoretical minimum . So three handshakes is not TCP The demands of itself , But to satisfy “ Reliable transmission of information over unreliable channels ” This demand leads to . Three times to , You can shake hands later , It's good to send data , It has nothing to do with the need for reliable information transmission .

Premise 1:TCP The agreement should ensure that both parties can communicate

That is, the sender and the receiver should confirm that the information they send can be received by the other party , The information sent by the other party can be received by oneself

Premise 2: On the premise 1 The less you send, the better

hypothesis 1: One handshake That is, the sender sends a packet to the receiver Conclusion : The sender cannot confirm whether the other party has received the message it sent

hypothesis 2: Two handshakes The sender Send a bag The receiving end returns a packet Conclusion ： The sender can make sure that the message it sends can be received by the other party It can also ensure that the package sent by the other party can be received by itself , But the receiving end can only determine You can receive the package sent by the other party Undetermined The package sent by oneself can be received by the other party hypothesis 3: Three handshakes The sender Send a Receiving end returns one The sender sends another message after receiving it Conclusion In this way, the sending end and the receiving end can determine that both sides can communicate So three times is the minimum value that meets the requirements , It's not good to shake hands three times , In fact, both sides shake hands once , Once for each , One handshake and confirmation are combined .

In principle, no data transmission can guarantee absolute reliability , Three handshakes are just a basic need to ensure reliability . Both parties need to confirm that their sending and receiving functions are normal , The receiving function is confirmed by receiving the other party's information , The sending function needs to send a message -》 The other party's reply has been confirmed . The reason for a third handshake is Server At the end of the second handshake （ Send a message ） Later, I don't know whether the other party can accept 、 Whether your sending function is normal . But at this time, the one-way channel of data has been established , about Client Come on , It has been confirmed that Server The terminal can receive signals , So you can give one way to Server Sent data .

reason 2:

In order to prevent the invalid connection request message segment from suddenly transferring to the server , So there's a mistake . If you shake hands twice , The client may send multiple request messages due to network congestion , Then the server will establish a connection , Waste a lot of server resources .

2、 Why? tcp Making a connection is three handshakes , Closing the connection is four waves ？

reason ： Guarantee tcp The full duplex connection of the protocol can be reliably closed

This we can see and TCP The reasons for establishing the connection are the same , The essence is the same , because TCP It's full duplex communication , Just three handshakes SYN + ACK It is put in a message , And four waves , Own side ACK and FIN Messages are sent separately .

This is because the server is in LISTEN State, , Received a request to establish a connection SYN After the message , hold ACK and SYN Put it in a message and send it to the client . And when you close the connection , When receiving from the other party FIN When the message , It simply means that the other party is no longer sending data but can still receive data , You may not have sent all your data to the other party , So we can immediately close, You can also send some data to the other party , Send again FIN Message to the other party to agree to close the connection now , therefore , Own side ACK and FIN It's usually sent separately .

3. Why is it TCP The actively closed end of four waves TIME-WAIT Status must be wait for 2MSL Time for ?

There are two reasons ：

• One 、 Guarantee TCP The full duplex connection of the protocol can be reliably closed
• Two 、 Ensure that duplicate data segments of this connection disappear from the network

First of all , If Client direct CLOSED 了 , So because of IP Protocol unreliability or other network reasons , Lead to Server Have not received Client Last reply ACK. that Server It will continue to send after the timeout FIN, At this time due to Client already CLOSED 了 , Can't find and resend FIN The corresponding connection , Last Server Will receive RST instead of ACK,Server You think it's a connection error that reports the problem to the top . This situation will not cause data loss , But it leads to TCP Protocol does not meet the requirements of reliable connection . therefore ,Client Not directly into CLOSED, But to keep TIME_WAIT, When received again FIN When , Can guarantee that the other party receives ACK, Finally close the connection correctly . Say the second thing , If Client direct CLOSED, And then to Server Initiate a new connection , We can't guarantee that this new connection is different from the port number of the connection just closed . That is to say, it is possible that the port number of the new connection and the old connection are the same . Generally speaking, nothing will happen , But there are still special cases ： Suppose the new connection has the same port number as the old connection that has been closed , If some data from the previous connection is still stuck in the network , The delay data doesn't arrive until a new connection is established Server, Because the port number of the new connection and the old connection is the same , Again because TCP The protocol judges different connections on the basis of socket pair, therefore ,TCP The protocol assumes that the delayed data belongs to the new connection , This is confused with the actual newly connected packets . therefore TCP The connection is still in TIME_WAIT Status waiting 2 times MSL, This can ensure that all data connected this time will disappear from the network .