Three-way handshake-start connection
First, the client sends a connection request message, and the server responds with an ACK message after accepting the connection, and allocates resources for this connection. After receiving the ACK message, the Client also sends an ACK message to the Server and allocates resources. This establishes a TCP connection.
Why is it three times instead of two or four times
Let me first talk about why not twice?
For example, the client initiates a Syn packet, but this packet is stuck in the network and does not arrive late. In this way, due to the TCP retransmission mechanism, he will send another Syn packet in the past. At this time, due to the two handshake, this The connection is established. This seems to be okay, but if we disconnect, the Syn packet that we are stuck in the network suddenly arrives at the server. At this time, due to two handshake, the server and the client establish a connection, but the client The terminal has been disconnected. . . . .
So this is an error, so a three-way handshake is required.
Then why not four times?
To be honest, this question is a little bit so. . . I can handle things steadily three times, so why should I do it four times.
Four waves-disconnect
Assume that the client initiates a connection request, that is, sends a FIN message. After the server receives the FIN message, it means "I have no data to send to you on the client", but if you still have data that has not been sent, you don't need to close the Socket in a hurry, and you can continue to send data. So you send an ACK first, "Tell the client that I have received your request, but I am not ready yet, please continue to wait for my message." At this time, the client side enters the FIN_WAIT state, and continues to wait for the FIN message from the server side. When the server side determines that the data has been sent, it sends a FIN message to the client side, "Tell the client side, okay, I have finished sending the data here, and I am ready to close the connection". After receiving the FIN message, the client "knows that the connection can be closed, but he still doesn't believe in the network, because the server does not know to close it, so it enters the TIME_WAIT state after sending the ACK. If the server does not receive the ACK, it can restart Pass." After the server receives the ACK, "it knows that it can be disconnected". The client side waits for 2MSL and still does not receive a reply, it proves that the server side has been closed normally, then, my client side can also close the connection. Ok, the TCP connection is closed like this!