Analysis of the state transition depth of TCP connections

For peacetime I need to observe the TCP connection between LVS and client and RS, you need to get a closer look at the four handshake that establishes the connected TCP three handshake and closes the connection, for example, do you know what these states represent, and the following TCP connection state diagram allows you to understand all this, Look down.

1 2 3 4 5 6 7 8 9 ten 13

root@lg181:/usr/local/lvs# ipvsadm-l-C | grep syn_recv TCP 00:54 syn_recv 117.24.44.192:40171 58 .61.166.143:http 172.16.62.98:http TCP 00:28 syn_recv 116.25.96.121:foliocorp 58.61.166.143:http TCP 00:59 syn_recv 121.11.248.233:13447 58.61.166.143:http 172.16.62.73:http root@lg181:/usr/local/lvs# ipvsadm-l-C | grep fin|head-n 3 tcp 01:43 fin_wait 61.154.119.42:kazaa 58.61.166.143:http 172.16.62.98:http TCP 01:41 FIN_WAIT 220.16 9.169.255:eli 58.61.166.143:http 172.16.62.98:http TCP 01:18 fin_wait 59.39.127.15:10487 172.16.62.97:http root@lg181:/usr/local/lvs# Ipvsadm-l-C | grep esta| Head-n 3 TCP 01:21 established 124.230.6.91:sybasedbsynch 58.61.166.143:http 172.23.151.167:http TCP 09:11 ESTABLISHED 116.21.129.16:19043 58.61.166.143:http 172.23.151.167:http TCP 14:35 established 124.229.50.133:49139 58.61.166.143: HTTP 172.16.62.98:http tcps.gif

Status: 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, waiting for confirmation
Syn_sent: Application has started, open a connection
Established: Normal data transfer status
FIN_WAIT1: Application says it's done
Fin_wait2: The other side has agreed to release
Itmed_wait: Waiting for all groups to die
CLOSING: Both sides try to close at the same time
Time_wait: The other side has initialized a release
Last_ack: Waiting for all groups to die

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 more difficult to see, and Fin_wait_ 2 states can also sometimes be seen with netstat.

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 the 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 guaranteed 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 each other after the Send fin message to each other to indicate that you agree that the connection can now be closed, so it's ACK and fin messages are sent in most cases separately.

2, why the TIME_WAIT state also need to wait 2MSL before 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 the fin message, so the role of this time_wait state is to resend the likely loss of the ACK message.

TCP Message Segment Header format:

Ordinal number: The ordinal number of the first byte of the data sent by this paragraph.

Acknowledgment number ACK: expecting to receive the number of the first data byte of the next message segment

Confirm ACK: 1 digits, the confirmation Number field is valid only when ack=1. Ack=0, the confirmation number is invalid

Synchronous SYN: Used to synchronize serial numbers when the connection is established. When Syn=1,ack=0 is said: This is a connection request message segment.

If the connection is agreed, the syn=1,ack=1 is made in the response message segment. Therefore, syn=1 indicates that this is a connection request, or a connection acceptance message.

End fin: Used to free a connection. Fin=1 said: "The sender of this segment of the data has been sent to complete, and request the release of transport links

Three times handshake (three contact)

Another confirmation is needed to prevent a failed connection request message segment from suddenly being passed to B, resulting in an error.

Invalid message segment: Normally: A makes a connection request, but because it is lost, no confirmation of B is received. So a re-issue the request, and then receive confirmation, establish the connection, after the data transfer, release the connection, a issued 2, one lost, one arrived, no "broken message segment"

However, in some cases, the first of a is stranded at a certain node, delay arrived, originally this is a long defunct message segment, but in a send a second, and get a B response, established a connection, the message segment unexpectedly arrived, so B thought, a and sent a new request, then sent a confirmation message segment, Agreed to establish a connection, if not three times to shake hands, so the connection is established (with a request and a response), at which point a receives a confirmation from B, but a knows that it does not send a request to establish a connection, because it ignores this acknowledgment of B, so that a does not send any data, and b but thought the new connection establishes, waits for a to send the data to oneself, at this time B's resource is wasted. But with a handshake of three times, a will not send a confirmation, then B because of not receiving confirmation, also know not to ask to establish a connection.

Four times shaking hands (two two times handshake)

b Send a confirmation immediately after receiving the connection release message segment, then enter the Close-wait state, at which time the TCP server process notifies the high-level application process, so the connection from A to B is released. This is a "half off" state. That is, a cannot be sent to B, but B can be sent to a.

At this point, if B does not have a datagram to send to a, its application process notifies TCP to release the connection, and then sends to a connection release message segment, and waits for confirmation.

A send a confirmation, enter the time-wait, note that the TCP connection has not been released, and then after a time waiting for the timer set 2MSL, a to enter the close state.

Why wait?

①, in order to ensure that a send the last ACK message segment can reach B. That is, the final confirmation segment is likely to be lost, then B will time out the retransmission, and then a again to confirm, and start the 2MSL timer, so go on. If there is no wait time, send the confirmation message segment immediately release the connection, B can not be retransmission (the connection has been released, no data can be passed out), and therefore can not receive confirmation, you can not follow the steps into the close state, that is, must receive confirmation to close.

②, prevent "Invalid connection request segment" from appearing in the connection. After 2MSL, all of the message segments generated during the duration of the connection can be removed from the network. That is, in the process of releasing the connection will have some invalid message segment stranded in the pavilion, but, after 2MSL these invalid message segments can certainly be sent to the destination, not stranded in the network. In this way, the last connection will not have the requested message segment left over in the next connection.

As you can see, b ends the TCP connection earlier than a, because B is disconnected from the confirmation, and a has to wait for 2MSL. Disclaimer: This article adopts BY-NC-SA for authorization | Copyright ©enjoydiy
Reprint need to note the transfer from: "TCP connection state transition depth Analysis"