Time_wait Effect of TCP/IP state graph

Time_wait Effect of TCP/IP state graph

In the TCP/IP state graph, there are many kinds of states, there are some can be converted to each other, that is, from one state to another state, but this conversion is not randomly sent, is to meet certain conditions. The TCP/IP state diagram looks more like a self-motive. is the TCP/IP state.

As can be seen, a total of 11 different states. These 11 states are described below:

CLOSED: Off state, no connection activity or in progress;

LISTEN: Listening status, the server is waiting for the connection to enter;

SYN_RCVD: Received a connection request, not confirmed;

Syn_sent: A connection request has been made, waiting for confirmation;

Established: connection establishment, normal data transmission status;

Fin_wait 1: (active shutdown) has been sent off the request, waiting for confirmation;

Fin_wait 2: (active close) received close confirmation, waiting for the other side to close the request;

Time_wait: Complete two-way shutdown, waiting for all packets to die;

CLOSING: Both sides try to close and wait for the other party to confirm;

Close_wait: (passive close) received close request, has been confirmed;

Last_ack: (passive off) wait for the last shutdown acknowledgement and wait for all packets to die.

In these 11 states, the state of time_wait is the most important and the most difficult to understand.

Why do I need time_wait status

Assuming that the final ACK is lost, the server will resend the FIN, the client must maintain the TCP status information so that the final ACK can be re-sent, or the RST will be sent, resulting in the server thinking an error has occurred. The TCP implementation must reliably terminate the two-direction (full-duplex shutdown) of the connection, and the client must be in the TIME_WAIT state because the client may face a situation where the final ACK is re-issued. A party that calls close () first will enter the TIME_WAIT state

Why time_wait status needs to stay 2MSL for such a long time

If the TIME_WAIT state hold time is not long enough (for example, less than 2MSL), the first connection terminates normally. A second connection with the same related five-tuple appears, and the first concatenated duplicate message arrives, interfering with the second connection. The TCP implementation must prevent a duplicate message of a connection from appearing after the connection is terminated, so that the time_wait state is kept long enough (2MSL), and the TCP message in the corresponding direction is either completely unresponsive or discarded. When a second connection is established, it is not confused.

Explanation of "Termination of TCP" in the establishment and termination of TCP in TCP/IP detailed

The termination of TCP is achieved by a four-time handshake between the two parties. The party initiating the termination executes the active shutdown, and the other side of the response performs a passive shutdown.

The initiator changes the status to Fin_wait_1, closes the application process, and emits a TCP fin segment;

The receiver receives the fin segment, returns an ACK with a confirmation number, and sends a file terminator EOF to its corresponding process, changing the status to Close_wait, and the initiator receives the ACK status to Fin_wait_2;

The receiver closes the application process, changes the status to Last_ack, and sends a TCP fin segment to the other party;

The initiator receives a fin status change to time_wait and emits an ACK confirmation of this fin. After the ACK is sent successfully (within 2MSL) the TCP status of both sides becomes 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 the two direction of the connection (full-duplex off)), 2*MSL (Max Segment Lifetime), and the default is 240 seconds.

The role of the TIME_WAIT state

The active shut-off socket will enter the TIME_WAIT state and lasts for 2MSL of time, andMSL is maximum segment Lifetime (maximum subsection life), which is the longest time an IP packet can survive on the internet, will disappear over the network. The MSL is recommended for 2 minutes on RFC 1122, whereas TCP implementations originating from Berkeley traditionally use 30 seconds, so the time_wait state is typically maintained at 1-4 minutes.

Reasons for the existence of the TIME_WAIT state

1) reliable termination of TCP full-duplex connections

When the four-way handshake protocol is closed, the final ACK is issued by the active shutdown, and if the final ACK is lost, the server will re-send the final fin, so the client must maintain state information to allow it to re-send the final ack. If this status information is not maintained, then the client responds to the RST sub-section, which the server interprets as an error (Connection Reset's socketexception is thrown in Java). Therefore, to achieve the normal termination of TCP full-duplex connection, you must handle the loss of any one of the four sub-sections of the termination sequence, the active shutdown client must maintain state information into the TIME_WAIT state.

2) Allow old repeating sections to fade out of the network

TCP sub-section may be due to router anomalies and "lost", during the lost, the TCP sender may be due to confirm time-out and resend the sub-section, the Lost sub-section after the router repair will also be sent to the final destination, this original stray section is called lost Duplicate. After a TCP connection is closed, a TCP connection between the same IP address and port is immediately re-established, and the latter connection is called the avatar of the previous connection (incarnation), it is possible that the previous connection's stray repeat group appears after the previous connection has terminated. Thereby being misunderstood to belong to the new incarnation. To avoid this situation, TCP does not allow a connection in the TIME_WAIT state to start a new avatar, because the TIME_WAIT state continues to 2MSL, which guarantees that when a TCP connection is successfully established, the repeating grouping from the previous avatar is lost in the network.

This blog post except special statement, all are original!

Respect the original, reproduced please specify: Reproduced from the past memory (http://www.iteblog.com/)

This article link address: "The TIME_WAIT function of TCP/IP state graph" (http://www.iteblog.com/archives/169)

Time_wait Effect of TCP/IP state graph