Note-TCP finite state machine analysis

First, TCP state transition diagram

The operation of TCP involving connection establishment and connection termination can be explained by the state Transition diagram (transition diagram):

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/76/C2/wKioL1Zb_J6gV08KAAHRjgX486s686.png "title=" 155543 _9jc0_778466.png "alt=" Wkiol1zb_j6gv08kaahrjgx486s686.png "/>

Chinese illustrations:

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M00/76/C4/wKiom1ZcA_WBfjVXAALhkWgijbk565.jpg "title=" 20140410152125734.jpg "alt=" Wkiom1zca_wbfjvxaalhkwgijbk565.jpg "/>

TCP Status and Description

CLOSED: No connection is active or in progress listen: The server is waiting to enter the call SYN_RECV: A connection request has arrived, wait for confirmation Syn_sent: application has started, open a connection established: Normal data transfer status Fin_ WAIT1: The app says it's done Fin_wait2: the other side has agreed to release itmed_wait: Wait for all the packets to die closing: Both sides simultaneously try to close the time_wait: the other side has initialized a release last_ack: Wait for all the packets to die

TCP defines 11 states for a connection that can be displayed using Netstat, a tool that is useful when debugging client/server applications, and how TCP rules specify how to transition from one state to another based on the current state and the sections received in that state. For example, when an application process executes an active open in the closed state, TCP sends a SYN, and the new state is syn_sent. If this TCP then receives a SYN with an ACK, it sends an ACK, and the new state is established. This final state is the state in which most data transmissions occur.

The two arrows from the established state handle the termination of the connection. If an app process calls close (active shutdown) before it receives a fin, it transitions to the fin_wait_1 state. However, if an application process receives a fin (passive shutdown) during the established state, it transitions to the close_wait state.

We use the thick solid line to represent the usual customer state transitions, and the coarse dashed lines represent the usual server state transitions. There are also two transformations that we have not discussed: one for simultaneous opening (simultaneous open), where the SYN is sent almost simultaneously at both ends and the two SYN is interleaved in the network, and the other is closed at the same time (simultaneous close). Occurs when the fin is sent at both ends at almost the same time.

Two, three times the TCP handshake establishes the connection

The following scenario occurs when a TCP connection is established

1, the client sends a TCP message with a SYN flag to the server. This is the message 1 in the three-time handshake process.
2, the server-side response to the client, this is the 2nd message in three handshake, this message with both an ACK flag and a SYN flag. So it represents the response to the client's SYN message, and it also flags the SYN to the client and asks the client if it is ready for data communication.
3, the customer must again respond to the service section an ACK message, this is the message segment 3.

This exchange requires at least 3 groupings, so it is called the TCP three-way handshake (three-way handshake).

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M00/76/C3/wKiom1Zb-1bhSsrQAAECUogyt_0364.jpg "title=" Qq20151130153033.jpg "alt=" Wkiom1zb-1bhssrqaaecuogyt_0364.jpg "/>

Third, TCP four handshake close connection

Because TCP connections are full-duplex, 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. The TCP client sends a fin to turn off the client-to-server data transfer (message segment 4).
2, the server received this fin, it sent back an ACK, confirm the serial number for the received sequence number plus 1 (message Segment 5). As with Syn, a fin will occupy a sequence number.
3. The server shuts down the client connection and sends a FIN to the client (message segment 6).
4, the customer segment sent back ACK message confirmation, and the confirmation number is set to receive the serial number plus 1 (message segment 7).

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M02/76/C3/wKioL1Zb_mCCYBXFAAEdquxxit4101.jpg "title=" Qq20151130153116.jpg "alt=" Wkiol1zb_mccybxfaaedquxxit4101.jpg "/>

Iv. detailed explanations of TCP 11 states

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 in the 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.

V. Questions

1, why to establish a connection agreement is three handshake, and close the connection is four handshake it?
This is because the server is in the listen state of the socket when the SYN message is received after the connection request, it can be ack and SYN (ACK response, and SYN synchronous function) in a message to send. However, when the connection is closed, when receiving the other's fin message notification, it simply means that no data is sent to you, but not all of your data are sent to the other side, so you may not immediately close the socket, that is, you may also need to send some data to the other side, Send the FIN message to the other side to show that you agree that you can now close the connection, so it is here that the ACK message and fin messages are sent separately in most cases.
2, why time_wait state also need to wait 2MSL to return to closed status?
This is because although both sides agree to close the connection, and the handshake of the 4 messages are also coordinated and sent, it can be directly back to the closed state (like from the Syn_send state to establish state); but because we have to assume that the network is unreliable, You cannot guarantee that the last ACK message you send will be received by the other party, so the socket in the Last_ack state may be re-sending the fin message because the timeout does not receive an ACK message, so this time_wait state is used to resend the possible missing ACK message.

This article is from the "Little Water Drop" blog, please make sure to keep this source http://wangzan18.blog.51cto.com/8021085/1718212

Note-TCP finite state machine analysis