TCP state transition diagram

This 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 map and the process of conversion, not just a smattering of knowledge. The following 11 states of the diagram are explained in detail to enhance memory. Before you do this, however, review the three handshake processes that TCP has established to connect, and the four handshake that closes the connection. 1, establish the Connection agreement (three times handshake)
(1) The client sends a TCP message with a SYN flag to the server.   This is message 1 in the three handshake process. (2) server-side response to the client, this is the three handshake in the 2nd message, this message with both ACK and SYN logo.   It therefore represents a response to a client-side SYN message, while labeling SYN to the client and asking the client if it is ready for data communication. (3) The customer must again respond to the service segment an ACK message, this is the message segment 3. 2, Connection termination protocol (four times handshake)
Because the TCP connection is Full-duplex, each direction must be closed separately. The principle is that when one party completes its data sending task, it can send a FIN to terminate the connection in this direction. Receiving a fin only means that there is no data flow in this direction, and a TCP connection can still send data after receiving a fin. 　The side that first closes will perform the active shutdown while the other side performs the passive shutdown. (1) The TCP client sends a FIN, which is used to turn off client to server data transfer (message segment 4).
(2) The server receives this FIN, it sends back an ACK, confirming that the serial number is the received number plus 1 (message Segment 5). Like SYN, a FIN will occupy an ordinal number.
(3) The server shuts down the client's connection and sends a FIN to the client (message segment 6).
　(4) The customer segment sends back ACK message confirmation, and the confirmation serial number is set to receive the serial number plus 1 (message paragraph 7). CLOSED: There's nothing to say about this, the initial state. LISTEN: This is also very easy to understand a state, indicating that a server side of the SOCKET is in the listening state, you can accept the connection. SYN_RCVD: This state is accepted to the SYN packet, under normal circumstances, this state is a server-side SOCKET in the establishment of TCP connections during the three handshake session in the process of a middle state, very short, basically with netstat you are very difficult to see this state, Unless you deliberately write a client test program, intentionally three times TCP handshake process of the last ACK message is not sent. Therefore, when the client's ACK message is received, it will enter the established state. Syn_sent: This state echoes with SYN_RCVD, when the client SOCKET performs connect connection, it first sends the SYN message, so it then enters the syn_sent state and waits for the 2nd message in the service side to send a handshake of three times. 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. Fin_wait_1: This state to explain, in fact, the real meaning of fin_wait_1 and fin_wait_2 state is to represent the FIN message waiting for each other. And the difference between the two states is: fin_wait_1 state is actually when the socket in the established state, it wants to actively shut down the connection, sent the FIN message to the other side, when the socket is entered into the fin_wait_1 state. And when the other side response ACK message, then into the fin_wait_2 state, of course, in the actual normal circumstances, regardless of what the other side of the case, should immediately respond ACK message, so fin_wait_1 state is generally difficult to see, and fin_wait_2 state sometimes can often use netstat see. Fin_wait_2: This state is explained in detail above, in fact, the SOCKET in the state of fin_wait_2, which means that a half connection, that is, one side requires a close connection, but also told the other side, I have some data to be sent to you, and then close the connection. Time_wait: said that received the other side FIN message, and sent an ACK message, and so on 2MSL can return to CLOSED available state. If the fin_wait_1 state, received the other side with the FIN flag and ACK sign message, you can go directly to the TIME_WAIT state, without the fin_wait_2 state. CLOSING: This state is more special, the actual situation should be very rare, belong to a relatively rare exception state. Normally, when you send a fin message, it is supposed to receive (or simultaneously receive) the other's ACK message, and then receive the other's fin message. But the CLOSING state means that after you send the FIN message, you do not receive an ACK message from the other side, but you also receive a fin message from the other side. Under what circumstances would such a situation arise? In fact, it is not difficult to draw a conclusion: that is, if the two sides close at the same time a SOCKET, then there are both sides send FIN message, also will appear CLOSING state, that both sides are closing the socket connection. Close_wait: The meaning of this state is actually that it is waiting to be closed. How to understand it. When the other side close a SOCKET and send FIN message to yourself, your system will undoubtedly respond to an ACK message to the other side, then into the close_wait state. The next thing you really need to consider is whether you still have data to send to each other, and if not, then you can close the SOCKET, send a FIN message to the other, or turn off the connection. So what you need to do in the close_wait state is to wait for you to close the connection. Last_ack: This state is relatively easy to understand, it is a passive closed side in the sending FIN message, the last wait for the other ACK message. When the ACK message is received, it can be entered into the CLOSED available state. Finally there are 2 questions to answer, my own analysis after the conclusion (not necessarily 100% correct) 1,   Why the establishment of the Connection Agreement is three times handshake, and closed the connection is four times handshake. This is because the SOCKET in the LISTEN state of the server when the SYN message is received, it can send ack and SYN (ACK to respond, and SYN to sync) in a message. But when you close the connection, when receiving a fin message from each other, it simply means that the other party has no data to send to you, but not all of your data is sent to each other, so you may not be able to immediately close the SOCKET, that is, you may also need to send some data to the other side, then send FINMessage to each other to indicate that you agree you can now close the connection, so its ACK and FIN messages here are in most cases sent separately. 2,   Why TIME_WAIT state also need to wait 2MSL to return to the CLOSED state. This is because: although both sides agreed to close the connection, and the handshake of the 4 messages are also coordinated and sent over, can reasonably be directly back to the CLOSED state (as from the Syn_send state to the establish state), but because we have to pretend that the network is unreliable, You can not guarantee that your final ACK message will be received by the other side, so the other side in the Last_ack state of the SOCKET may be due to timeout did not receive an ACK message, and resend FIN message, so the role of this time_wait state is used to resend may be lost ACK message 。