TCP/IP state diagram && TIME_WAIT role
In the TCP/IP state diagram, there are many kinds of states, some of which can be converted to each other, that is to say, from one state to another state, but this conversion is not sent casually, it is to satisfy certain conditions. The TCP/IP state diagram looks more like an automaton. The figure below shows the TCP/IP state.
As can be seen from the above figure, there are a total of 11 different states. The 11 states are described as follows:
CLOSED: closed state, no connection activity or in progress;
LISTEN: listening state, the server is waiting for a connection to enter;
SYN_RCVD: Received a connection request, not yet confirmed;
SYN_SENT: A connection request has been issued, waiting for confirmation;
ESTABLISHED: Connection established, normal data transmission status;
FIN_WAIT 1: (active shutdown) a shutdown request has been sent, waiting for confirmation;
FIN_WAIT 2: (active close) Receive the closing confirmation of the other party and wait for the closing request of the other party;
TIME_WAIT: Complete the two-way shutdown, waiting for all groups to die;
CLOSING: Both parties try to close at the same time and wait for the other party to confirm;
CLOSE_WAIT: (passive close) The close request from the other party has been received and it has been confirmed;
LAST_ACK: (passive shutdown) Wait for the last shutdown acknowledgment, and wait for all packets to die.
Among these 11 states, the state of TIME_WAIT is the most important and the most difficult to understand.
1. CLOSED: The starting point, which enters this state when it times out or when the connection is closed.
2. LISTEN: The state when the server is waiting for the connection to come, the server needs to call the socket, bind, and listen functions to enter this state. This is called passive opening of the application (waiting for a client to connect).
3.SYN_SENT: The client initiates a connection and sends SYN to the server. If the server cannot be connected, it will directly enter the CLOSED state.
4. SYN_RCVD: Corresponding to 3, the server accepts the SYN request from the client, and the server enters the SYN_RCVD state from the LISTEN state. At the same time, the server should respond with an ACK and send a SYN to the client at the same time; in another case, when the client initiates SYN and receives a SYN request from the server, the client will change from SYN_SENT to SYN_RCVD state.
5. ESTABLISHED: The server and client enter the state after completing the three-way handshake, indicating that data transmission can already be started.
The above is a description of the state transition generated by the server and the client when the connection is established. Relatively speaking, it is relatively simple and clear. If you are familiar with the three-way handshake, the state transition when establishing a connection is easy to understand.
Next, let's take a look at the state transition description when the connection is closed. The closure requires 4 interactions between the two parties, and also includes some aftermath work (TIME_WAIT state). Note that the party that is actively closed or the party that is passively closed here does not refer to special Refers to the server side or the client side, which is relative to who initiates the shutdown request first:
6. FIN_WAIT_1: The party that actively closes, enters this state from state 5. The specific action is to send FIN to the other party.
7. FIN_WAIT_2: The party that actively closes, receives the other party's FIN-ACK (that is, the response packet of the fin packet), and enters this state.
8. CLOSE_WAIT: After receiving the FIN, the passively closed party enters this state. The specific action is to receive FIN and send ACK at the same time. (The reason why it is called close_wait can be understood as the passive closing party is waiting for the upper-layer application to issue a command to close the connection)
9.LAST_ACK: The passive shutdown party initiates a shutdown request and enters this state from state 8. The specific action is to send FIN to the other party and enter the CLOSED state when receiving ACK.
10. CLOSING: When both sides initiate a close request at the same time, FIN_WAIT_1 will enter this state. The specific action is to receive a FIN request and respond with an ACK.
11.TIME_WAIT: The most tangled state is here. As can be seen from the state diagram, there are 3 states that can be transformed into it. Let's analyze them one by one:
a. This state is entered by FIN_WAIT_2: when the two parties do not initiate FIN at the same time, the active closing party receives the FIN of the passive closing party after completing the closing request initiated by itself.
b. Entering from the CLOSING state: both parties initiate a shutdown at the same time, and both make a request to initiate a FIN, and at the same time receive a FIN and do an ACK, enter from the CLOSING state.
c. Entered from the FIN_WAIT_1 state: FIN (initiated by the other party) and ACK (the FIN response initiated by itself) are received at the same time. The difference from b is that the ACK of the FIN response initiated by itself arrives before the other party's FIN request, and b is the FIN first. arrive. This situation is the least likely.
Why the TIME_WAIT state is needed
Assuming that the final ACK is lost, the server will resend the FIN, and the client must maintain the TCP state information so that the final ACK can be resent, otherwise an RST will be sent, and the server thinks an error has occurred. TCP implementations MUST reliably terminate connections in both directions (full-duplex shutdown), and the client MUST enter the TIME_WAIT state because the client may face a situation where the final ACK is resent. The party that calls close() first will enter the TIME_WAIT state
Why does the TIME_WAIT state need to be kept for 2MSL
If the TIME_WAIT state is not kept long enough (eg less than 2MSL), the first connection is terminated normally. A second connection with the same associated quintuple appears, and a duplicate packet of the first connection arrives, interfering with the second connection. TCP implementations must prevent duplicate messages for a connection from appearing after the connection is terminated, so keep the TIME_WAIT state long enough (2MSL), and the TCP messages in the corresponding direction of the connection are either completely responded or discarded. When establishing the second connection, there is no confusion.
According to the explanation about "TCP termination" in the establishment and termination of TCP in "TCP/IP Detailed Explanation"
The termination of TCP is achieved through a four-way handshake between the two parties. The party that initiates the termination performs an active shutdown, and the other party that responds performs a passive shutdown.
The initiator changes the state to FIN_WAIT_1, closes the application process, and sends a TCP FIN segment;
The receiver receives the FIN segment, returns an ACK with an acknowledgment serial number, and sends an end-of-file EOF to its corresponding process, and changes the state to CLOSE_WAIT, and the initiator changes the state to FIN_WAIT_2 after receiving the ACK;
The receiver closes the application process, changes the state to LAST_ACK, and sends a TCP FIN segment to the other party;
After the initiator receives the FIN, the state changes to TIME_WAIT and sends an ACK confirmation of the FIN. After the ACK is sent successfully (within 2MSL), the TCP state of both parties changes to CLOSED.
It is not difficult to see the meaning of the results shown above. According to the TCP protocol, the party that initiates the shutdown will enter the TIME_WAIT state (the TCP implementation must reliably terminate both directions of the connection (full-duplex shutdown)) for 2*MSL (Max Segment Lifetime), which defaults to 240 seconds.
The role of the TIME_WAIT state
The actively closed Socket end will enter the TIME_WAIT state and last for 2MSL time. MSL is the maximum segment lifetime (maximum segment lifetime), which is the longest time that an IP packet can survive on the Internet. disappeared from the network. MSL recommends 2 minutes in RFC 1122, while TCP implementations from berkeley traditionally use 30 seconds, so the TIME_WAIT state is generally maintained at 1-4 minutes.
The raison d'être of the TIME_WAIT state
1) Reliable termination of TCP full-duplex connections
When closing the connection four-way handshake protocol, the final ACK is sent by the active closing end. If this final ACK is lost, the server will resend the final FIN, so the client must maintain state information to allow it to resend the final ACK . If this state information is not maintained, the client will respond with an RST section, which the server interprets as an error (a connection reset SocketException will be thrown in java). Therefore, in order to realize the normal termination of the TCP full-duplex connection, the loss of any one of the four subsections of the termination sequence must be handled, and the client that actively closes must maintain the state information and enter the TIME_WAIT state.
2) Allow old duplicate sections to disappear in the network
The TCP segment may be "lost" due to router exception. During the lost time, the TCP sender may retransmit the segment due to the confirmation timeout. The lost segment will also be sent to the final destination after the router is repaired. This original A lost section is called a lost duplicate. After closing a TCP connection, a TCP connection between the same IP address and port is immediately re-established. The latter connection is called the incarnation of the previous connection. This may happen. A stray repeat grouping of connections occurs after the previous connection is terminated and thus is misinterpreted as belonging to the new incarnation. To avoid this, TCP does not allow a connection in the TIME_WAIT state to start a new incarnation, because the TIME_WAIT state lasts for 2MSL, which ensures that when a TCP connection is successfully established, the duplicate packets from the connection's previous incarnation have disappeared in the network.
This blog post is original unless otherwise stated!
Respect originality, please indicate: Reprinted from past memory (http://www.iteblog.com/)
The link address of this article: "The role of TIME_WAIT in the TCP/IP state diagram" (http://www.iteblog.com/archives/169)
Reference: http://www.cricode.com/3568.html
https://my.oschina.net/xinxingegeya/blog/483922