three-way handshake
The first handshake: Host A sends a bit code of syn=1, and randomly generates a data packet with seq number=10001 to the server. Host B is known by SYN=1, and A requests to establish a connection, and the status is SYN_SENT at this time;
the second handshake : Host B needs to confirm the online information after receiving the request, and sends ack number=(seq+1 of host A),syn=1,ack=1 to A, and randomly generates a packet of seq=20001, at this time the status changes from LISTEN to SYN_RECV;
the third handshake: After host A receives it, check whether the ack number is correct, that is, whether the seq number+1 sent for the first time, and whether the bit code ack is 1, if it is correct, host A will send the ack number=(host B's seq+1), ack=1, after the host B receives it and confirms the seq value and ack=1, the connection is successfully established, and both parties are in the ESTABLISHED state.
After completing the three-way handshake, host A and host B begin to transmit data
-
Each state name and meaning
CLOSED: There is nothing to say about this, it represents the initial state.
LISTEN: This is also a very easy to understand state, indicating that a SOCKET on the server side is in a listening state and can accept connections.
SYN_RECV: This state indicates that a SYN message has been received. Under normal circumstances, this state is an intermediate state during the three-way handshake session of the server-side SOCKET when establishing a TCP connection. In this state, unless you specially write a client test program, the last ACK message in the three-way TCP handshake process will not be sent on purpose. Therefore, in this state, after receiving the ACK message from the client, it will enter the ESTABLISHED state.
SYN_SENT: This state echoes the SYN_RECV vision. When the client SOCKET performs a CONNECT connection, it first sends a SYN message, so it will immediately enter the SYN_SENT state and wait for the server to send the second message in the three-way handshake. The SYN_SENT state indicates that the client has sent a SYN message.
ESTABLISHED: This is easy to understand, indicating that the connection has been established.waved four times
FIN_WAIT_1: This state needs to be explained well. In fact, the real meaning of the FIN_WAIT_1 and FIN_WAIT_2 states is to wait for the other party's FIN message. The difference between these two states is: the FIN_WAIT_1 state is actually when the SOCKET is in the ESTABLISHED state, it wants to actively close the connection and sends a FIN message to the other party. At this time, the SOCKET enters the FIN_WAIT_1 state. When the other party responds to the ACK message, it enters the FIN_WAIT_2 state. Of course, under normal circumstances, the other party should immediately respond to the ACK message no matter what the situation is. Therefore, the FIN_WAIT_1 state is generally more difficult to see. The FIN_WAIT_2 status can sometimes be seen with netstat.
FIN_WAIT_2: This state has been explained in detail above. In fact, SOCKET in the state of FIN_WAIT_2 represents a semi-connection, that is, one party requests to close the connection, but also tells the other party that I still have some data to send to you for the time being. Close the connection.
TIME_WAIT: Indicates that the FIN message from the other party is received and an ACK message is sent. After 2MSL, it can return to the CLOSED available state. If in the FIN_WAIT_1 state, when receiving a message with both the FIN flag and the ACK flag from the other party, you can directly enter the TIME_WAIT state without going through the FIN_WAIT_2 state.
CLOSING: This state is quite special, it should be rare in actual situations, and it belongs to a relatively rare exception state. Under normal circumstances, when you send a FIN message, it stands to reason that you should first receive (or simultaneously receive) the other party's ACK message, and then receive the other party's FIN message. However, the CLOSING state means that after you send the FIN message, you did not receive the ACK message from the other party, but instead received the FIN message from the other party. Under what circumstances does this happen? In fact, after thinking about it, it is not difficult to come to a conclusion: that is, if both parties are closing a SOCKET at the same time, then there will be a situation where both parties send FIN messages at the same time, that is, the CLOSING state will appear, indicating that both parties are closing the SOCKET connection. .
CLOSE_WAIT: The meaning of this state actually means that it is waiting to close. How to understand it? When the other party closes a SOCKET and sends a FIN message to itself, your system will undoubtedly respond with an ACK message to the other party, and then enter the CLOSE_WAIT state. Next, in fact, what you really need to consider is to see if you still have data to send to the other party. If not, then you can close the SOCKET and send a FIN message to the other party, that is, close the connection. So you are in the CLOSE_WAIT state, what needs to be done is to wait for you to close the connection.
LAST_ACK: This state is relatively easy to understand. It is a passive shutdown party that waits for the other party's ACK message after sending the FIN message. When the ACK message is received, it can enter the CLOSED available state.Why is the establishment of the connection protocol a three-way handshake, and the closing of the connection is a four-way handshake ?
This is because when the SOCKET in the LISTEN state of the server receives the connection establishment request of the SYN message, it can send ACK and SYN (ACK acts as a response, and SYN acts as a synchronization) in one packet to send. But when closing the connection, when receiving the other party's FIN message notification, it just means that the other party has no data to send to you; but not all your data is sent to the other party, so you may not close SOCKET immediately, That is, you may also need to send some data to the other party, and then send a FIN message to the other party to indicate that you agree that the connection can now be closed, so the ACK message and the FIN message here are sent separately in most cases.Why does the TIME_WAIT state need to wait 2MSL before returning to the CLOSED state ?
Because although both parties agree to close the connection, and the 4 messages of the handshake have been sent, it is reasonable to return to the CLOSED state directly (just like from the SYN_SENT state to the ESTABLISH state), but we must imagine that the network is unreliable, You cannot guarantee that the last ACK message sent by you (the client) will be received by the other party, that is to say, the SOCKET in the LAST_ACK state of the other party may resend the FIN message due to the timeout and fail to receive the ACK message, so this The role of the TIME_WAIT state is to retransmit ACK messages that may be lost.Does it take 4 waves to close a TCP connection ?
Not necessarily, 4 waves to close a TCP connection is the safest way. But sometimes, we don't like the TIME_WAIT state (for example, when the MSL value is set too large, there are too many TCP connections in the TIME_WAIT state on the server side, reducing the number of these entries can close the connection faster and release more resources for new connections), At this time, we can prevent SOCKET from entering the TIME_WAIT state after close() by setting the SO_LINGER flag of the SOCKET variable. At this time, the TCP connection will be forcibly terminated by sending RST (replacing the normal TCP four-way handshake termination method). But this is not a very good idea, TIME_WAIT is often beneficial for us.