TCP three-way handshake.
The first handshake: When the connection is established, the client sends a syn packet ( syn=j) to the server , and enters the SYN_SENT state, waiting for the server to confirm;
syn: Synchronize Sequence Numbers ( Synchronize Sequence Numbers )
The second handshake: The server receives the syn packet sent by the client , and must confirm the client's ACK (ack=j+1) , and at the same time, it also sends a SYN packet ( seq=k ), that is, the SYN+ACK packet. At this time, the server Enter the SYN_RECV state;
seq: (sequence)
ack: confirm
The third handshake: the client receives the SYN+ACK packet from the server and sends an acknowledgment packet ACK (ack=k+1) to the server . After the packet is sent, the client and server enter the ESTABLISHED (TCP connection is successful) state and complete three times shake hands.
established: established successfully
*******************************************************************************************************************************
Why three times and not two?
Then we must understand one thing, what problem is the handshake to solve?
The problem to be solved by the handshake is actually: I hope that the server will only open one connection for the client to use. Two handshakes are not necessarily unsuccessful
Suppose a sends a letter to b (the first time).
b receives the letter and writes again to tell a that she has received it! (the second time)
At this time, a did not write to b again (no third time).
On the surface, the communication between a and b has been successful, but there are actually two possibilities here:
1. A has no letter to b.
2. a can receive letter from b.
Herein lies the problem, assuming there are only two handshakes
a sends a letter to b, and b writes to a again after receiving the letter (the two handshakes are completed).
However, when b's letter is sent to a, the letter is lost (the network from b to a is unavailable).
At this time, if a does not receive the letter, it will think that the letter has not been sent to b. (Because it is a two-way handshake, b at this time just assumes that a has received the package)
The state of b at this time is that a channel has been opened, waiting for a to write again.
The state of a at this time is that because no reply is received, the letter is resent to b. (In fact, if a receives the packet, the two handshakes also successfully establish the connection)
Then b will open a new channel after receiving the letter and wait for a to send the letter, repeating the cycle, which causes a waste of network resources! ! !
Is there no such problem after the 3-way handshake?
The 3-way handshake is successful, which proves that the network from a to b and b to a is connected. a sends information to b, there is a timeout period at this time, if b's information cannot be sent to a (it will time out at this time), then a will resend a new request logically, until b receives the information and returns it to a .
Why not send the text message directly during the handshake, because if the network is disconnected and the text is sent to the server, the server will easily be congested and hang up.
Summary: The 3-way handshake is to reduce unnecessary waste of resources due to network or other reasons (when a does not receive the packet of b)