1 Flag bit and sequence number in TCP connection
1.1 Flag
- SYN: Synchronize Sequence Numbers Synchronize sequence number, SYN is the handshake signal when TCP establishes a connection, which means to initiate a new connection
- ACK: Confirm that the serial number is valid, used for response
- FIN: release a connection
- RST: reset connection
1.2 Serial number
- seq: Randomly generated 32-bit sequence number, used to identify the byte stream sent by the client
- ack: 32-bit confirmation character sequence number, the confirmation sequence number is valid only when ACK=1, ack=seq+1
2 Three handshake
The three-way handshake refers to the process in which the client and server send a total of three data packets when a TCP connection is successfully established.
The purpose of the three-way handshake is to confirm that the sending and receiving capabilities of the client and the server are normal, and to ensure the reliability of the TCP connection.
The establishment process of the three-way handshake is as follows:
Initial stage: the
client is in the CLOSED state, and the server is in the LISTEN state
- The first handshake: The
client sends the synchronization flag SYN=1 to the server, and the sequence number seq=x The
client enters the SYN_SENT state - The second handshake: the
server sends SYN=1 to the client, the sequence number seq=y, the confirmation identifier ACK=1, and the confirmation sequence number ack=x+1 the
server enters the SYN_RECV state - The third handshake: the
client sends the sequence number seq=x+1 to the server, the confirmation identifier ACK=1, and the confirmation sequence number ack=y+1
(note that the client and the server only send the first request to the other party Send the synchronization identifier SYN, the third handshake does not need to be sent again)
Connection status: After the
third handshake, both the client and the server enter the connected state established, and the TCP three-way handshake process is completed
2.1 Connection queue and retransmission mechanism packet loss problem
In the first handshake, when the server receives the message from the client, it enters the SYN_RCVD state. At this time, it has not yet entered the fully connected state. It will put the connection request in the semi-connected queue and send SYN- to the client at the same time. The ACK packet starts the second handshake. At this time, if the client's acknowledgment packet is not received, the server will retransmit for the first time. After a certain period of time, it will retransmit the subsequent times. This time generally increases exponentially. If the maximum number of retransmissions is exceeded, the system will delete the connection information from the semi-connection queue.
If the three-way handshake has been successfully completed and entered the connected state, the connection will be added to the fully connected queue. If the fully connected queue is full, packet loss may occur
2.2 Why is there a three-way handshake? Why can't it work twice?
1. A three-way handshake is required to ensure that the connection is reliable
To carry out reliable communication, it is necessary to confirm that the sending and receiving capabilities of both the client and the server are correct
. The first handshake, the server receives the client's message, can confirm that the client's sending ability is correct. The
second handshake. When the client receives the message from the server, it can confirm that there is no problem with the receiving and sending capabilities of the server.
However, after the second handshake, the server does not know whether there is any problem with the receiving capabilities of the client. In the third handshake, the client is receiving the service. After the message from the client, a new message is sent to the server. At this time, the server confirms that there is no problem with the receiving ability of the client, and the two enter the established connection state.
So far, the sending and receiving capabilities of the client and server have been confirmed, and the reliability of this TCP connection has also been guaranteed
2. Only two handshake may cause a waste of resources
If the connection request sent by the client does not receive the confirmation from the server, the client sends a connection request to the server after a period of time, the connection is successfully established, and the data transmission is completed. There may be a situation where the first connection is not lost, but the arrival of the server is delayed due to a network node. At this time, the server mistakenly believes that the client initiates a new connection, so it sends a confirmation to the client. Complete the two-stage handshake, while waiting for the client to send data, but the client does not pay attention to it, resulting in a waste of resources on the server side.
3 wave four times
Initial state, both the
client and the server are in an established connection state
-
Wave for the first time
When the client's data transmission is completed, the client sends a connection release message to the server, the flag bit is FIN=1, and the sequence number is seq=x. The
client enters the FIN_WAIT state -
The second wave of the
server after receiving the FIN message from the client, the client will reply to the client with a confirmation message ACK=1, the confirmation number ack=x+1, the sequence number seq=y, and the server enters the closed waiting state CLOSE-WAIT , Because there may be data that has not been sent, the FIN flag will not be sent immediately. The
server enters the CLOSE_WAIT state -
Waving for the third time, the
server sends the confirmation message to the client again after sending the final data ACK=1, FIN=1, seq=z, ack=x+1 and the
client enters the LAST_ACK state -
Waves four times
. After receiving the FIN message from the server, the client sends an acknowledgement message ACK=1, the acknowledgement number ack=z+1, seq=w to the server. The client releases the TCP connection after 2MSL (Maximum Segment Lifetime, 2 maximum message survival time), the server will release the TCP connection immediately after receiving the confirmation message sent by the client, so the time for the server to end the TCP connection is longer than The client is earlier and the
server releases the connection after receiving the confirmation message and enters the CLOSED state. The
client enters the CLOSED state after waiting for 2MSL
3.1 Why do I have to wave four times, but not three times?
The premise of disconnecting the TCP connection is that neither the client nor the server has any data to send.
The first waved, the client sends a FIN, indicating that it has no data to send. The
second waved, the server first replies with a confirmation message that it has received the client's message, but it still has some data that has not been sent. The FIN message can be
waved for the third time. The server ensures that its data has been sent, and gives the FIN message a
fourth wave. The client receives the FIN message from the server, sends a confirmation message, and waits for 2MSL to release the TCP connection. , And the server immediately releases the TCP connection after receiving the confirmation message from the client
In short, it is not possible for three times because the server may still have some data to send during the second wave, so it cannot give a FIN message immediately. You can only give the client a confirmation message to complete the second wave and wait. After sending my own data, the FIN message is given at the third wave of the hand, so there is another wave of the process.
3.2 Why does the client need to wait for 2MSL for the fourth wave to release the TCP connection?
Taking into account the problem of packet loss in the fourth wave, if the server does not receive the confirmation message returned after the third wave, it will resend the third wave message. MSL is the maximum message survival time, and 2MSL is the message. It takes the longest time for the text to go back, the client needs to wait so long to confirm that the server has received the fourth wave of hand message