Status of each step in the TCP communication process

Status Diagram 1

Status Diagram 2

for the above figure N many people know that it helps to troubleshoot and locate network or system failures, but how to firmly engrave this picture in the brain? Then you must have a deep understanding of each state of the graph and the process of conversion, and not just stay in the smattering. Below is a detailed analysis of the 11 states of this graph in order to enhance the memory! But before this, review the TCP three handshake process to establish a connection, as well as the four handshake process to close the connection, see "Talking about the TCP three handshake and four waves".

CLOSED: This is nothing to say, it means the initial state.

LISTEN: This is also very easy to understand a state, indicating that a server side of a SOCKET in the listening state, you can receive the connection.

SYN_RCVD: This status indicates that a SYN message is received, under normal circumstances, this state is the server side of the socket in the establishment of a TCP connection during the three handshake session process of an intermediate state, very short, basically with netstat you are very difficult to see this state of , unless you specifically write a client-side test program that intentionally sends the last ACK message during the three TCP handshake. Therefore, when the ACK message is received from the client, it goes into the established state.

syn_sent: This state echoes the SYN_RCVD, and when the client SOCKET performs a connect connection, it sends the SYN message first, so it then goes into the syn_sent state and waits for the server to send the 2nd of the three-time handshake. Message. The Syn_sent status indicates that the client has sent a SYN message.

established: This is easy to understand, indicating that the connection has been established.

fin_wait_1: This state should be well explained, in fact, the real meaning of fin_wait_1 and fin_wait_2 state is to wait for each other's FIN message. The difference between the two states is : The fin_wait_1 state is actually when the socket in the established state, it would like to actively close the connection, send a FIN message to the other side, when the socket is entered into the fin_wait_1 state. And when the other party responds to the ACK message, then into the fin_wait_2 state, of course, under the actual normal circumstances, regardless of the circumstances of each other, should immediately respond to the ACK message, so the fin_wait_1 state is generally more difficult to see, and fin_wait_2 state is sometimes often used netstat see.

fin_wait_2: Above has explained in detail this state, actually fin_wait_2 the SOCKET in the state, indicates the half connection, also namely has the party request close connection, but also tells the other side, I temporarily also some data need to transmit to you, later closes the connection again.

time_wait: Said to receive the other side of the FIN message, and sent out an ACK message, just wait for 2MSL to return to the CLOSED usable state. If the fin_wait_1 state, received the other side with the FIN flag and the ACK flag message, you can directly into the time_wait state, without having to go through the fin_wait_2 state.

CLOSING (There is no sign of this state): This state is relatively special, the actual situation should be very rare, belonging to a relatively rare exception state. Normally, when you send a fin message, it is supposed to receive (or receive) the other's ACK message before receiving the other's fin message. But CLOSING status indicates that you send fin message, and did not receive the other's ACK message, but also received the other side of the fin message. under what circumstances will this happen? in fact, it is not difficult to come to a conclusion: that is, if the two sides close a socket at the same time, then there is a situation where both sides send the FIN message, there will be a CLOSING state, indicating that both sides are shutting down the socket connection.

close_wait: The meaning of this state is actually expressed in waiting to be closed. How do you understand it? When the other side close a SOCKET to send FIN message to yourself, you will undoubtedly respond to an ACK message to each other, then enter into the close_wait state. Next, the real thing you really need to consider is whether you still have the data sent to the other person, if not, then you can close the SOCKET, send FIN messages to each other, that is, close the connection. So what you need to accomplish in the close_wait state is waiting for you to close the connection.

Last_ack: This state is still relatively easy to understand, it is the passive close side after sending FIN messages, and finally wait for each other's ACK message. When an ACK message is received, it is also possible to enter the CLOSED available state.

Transferred from: http://www.cnblogs.com

Status of each step in the TCP communication process