Transferred from: http://www.cnblogs.com/cy568searchx/p/3711670.html
BecauseTCP connections are full-duplex, so each direction must be closed separately. The principle is that when a party completes its data sending task, it can send a fin to terminate the connection in this direction. Receiving a fin only means there is no data flow in this direction, and a TCP connection can still send data after receiving a fin. The first party to close will perform an active shutdown, while the other side performs a passive shutdown. (1) Client A sends a FIN to turn off customer A to server B data transfer (message Segment 4). (2) server B receives this FIN, which sends back an ACK, confirming that the serial number is received plus 1 (message Segment 5). as with Syn, a fin will occupy a sequence number. (3) Server B closes the connection to client A and sends a fin to client A (message segment 6). (4) Client A sends back ACK message confirmation and sets the confirmation serial number to receive the serial number plus 1 (message segment 7). State of the explanation:
CLOSED:This is nothing to say, the initial state. LISTEN: This is also very easy to understand a state, that the server side of a socket is listening state, can accept 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 in the process of an intermediate state, very short, basically with netstat you are very difficult to see this state, unless you specifically wrote a client test program, Intentionally the last ACK message in the three-time TCP handshake is not sent. Therefore, when the ACK message is received from the client, it goes into the established state.
syn_sent:This state echoes the SYN_RCVD thinking back, when the client socket performs a connect connection, it sends the SYN message first, so it then enters the syn_sent state and waits for the server to send the 2nd message in the three-time handshake. 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 fin_wait_1 state is generally more difficult to see, and Fin_wait_ 2 states can also sometimes be seen with netstat.
fin_wait_2:The above has explained in detail this state, in fact, the fin_wait_2 state of the socket, that is, the semi-connection, that is, one side requires close connection, but also tell the other side, I have a little data to send to you, and then close the connection later.
time_wait:Indicates received the other side's fin message, and sent out an ACK message, and so on 2MSL can return to the closed available 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:This kind of state is 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 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 the other side of the ACK message. When an ACK message is received, it is also possible to enter the closed available state.
Summary:
1. Why is a connection agreement a three-time handshake, and a four-time handshake when the connection is closed? This is because the server-sidesocket in Listen state when a request for a SYN message is received, it can send the ack and syn (ack response, and syn synchronously) in a message. However, when the connection is closed, when the other side of the fin message notification, it only means that no data sent to you, but not all of your data are sent to each other, so you may not immediately close the SOCKET, that is, you may also need to send some data to the other side, then send fin message to the other side to show that you agree that you can now close the connection, so it is here the ACK message and fin messages are sent separately in most cases.
2. Why does the TIME_WAIT state need to wait 2MSL before returning to the closed state? This is because although both sides agree to close the connection, and the handshakeclosed state (as from syn_ Send status to establish state); But because we have to assume that the network is unreliable, you cannot guarantee that you will finally send last_ack socket may not receive ack messages, and re-sent fin message, so this time_ The wait state is used to re-send potentially lost ack messages. ------------------ --------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------- turn from: blog.csdn.net/whuslei
Suppose the client side initiates an interrupt connection request, which is to send a fin message. After the server receives the fin message, it means " my client has no data to send to you ", but if you have data that is not sent, you do not need to close the socket, you can continue to send data. So you first send an ACK, " tell the client that your request I received, but I am not ready, please continue to wait for my message ." At this point the client enters the fin_wait state and continues to wait for Fin messages on the server side. When the server side determines that the data has been sent, the fin message is sent to the client side, " tell the client side, OK, my side of the data is finished, ready to close the connection ." Client side received fin message, " I know can shut down the connection, but he still do not believe the network, afraid the server side do not know to shut down, so send an ACK into the time_wait state, if the server does not receive an ACK can be re-transmitted . "When the server side receives an ACK," You know you can disconnect . " Client side waiting for 2MSL still not received a reply, the server side has been properly shut down, well, I can also close the client terminal connection . The OK,TCP connection is closed like this!
The server side is experiencing the following process:
TCP Four Breakup