TCP state transition diagram

    TCP operations involving connection establishment and termination can be illustrated by the following state transition diagrams.

    TCP defines 11 states for a connection that can be displayed using netstat, and TCP rules specify how to transition from one state to another based on the current state and the segments received in that state. For example, when an application process performs an active open in the CLOSED state, TCP will send a SYN, and the new state is SYN_SENT. If the TCP then receives a SYN with an ACK, it will send an ACK and the new state is ESTABLISHED. This final state is the state in which the vast majority of data transfers occur. The two arrows from the ESTABLISHED state handle the termination of the connection. If an application process calls close (active close) before receiving a FIN, it transitions to the FIN_WAIT_1 state. But if an application process receives a FIN (passive close) during the ESTABLISHED state, it transitions to the CLOSE_WAIT state.
    The following figure shows the actual packet exchange that occurs in a complete TCP connection, including the three phases of connection establishment, data transfer, and connection termination, as well as the TCP states experienced by each endpoint. The client in this example advertises an MSS value of 536 (indicating that the client implements only the minimum reassembly buffer size), the server advertises an MSS value of 1460 (typical for IPv4 over Ethernet), and the MSS values ​​in the different directions can be Are not the same.

    There is a TIME_WAIT state in the figure. Generally, the duration of the active shutdown end in this state is 2MSL (maximum segment liftime, MSL), that is, between 1 minute and 4 minutes (RFC 1122 recommends that the MSL value is 2 minutes, and the source 30 seconds has traditionally been used since Berkeley's implementation). The MSL is the maximum time any IP datagram can survive on the Internet. This value is limited because each datagram contains an 8-bit field called the hop limit, which has a maximum value of 255. Although this is a hop limit rather than a real time limit, we still assume that the packet with the largest hop limit cannot exist in the network for longer than MSL seconds. The TIME_WAIT state has two reasons for existence:
    1. To reliably terminate the TCP full-duplex connection.
    2. Allow old duplicate sections to disappear in the network.
    The first reason can be explained by assuming that the last ACK in the above figure is lost. At this point the server will resend its FIN, so the client must maintain state information to allow it to resend the final ACK, otherwise it will respond with an RST and the subsection will be interpreted by the server as an error. If TCP is to perform a full-duplex shutdown cleanly, it must properly handle the loss of any of the four segments of the connection termination sequence. This example also illustrates why it is the end that is in the TIME_WAIT state that performed the active shutdown, because it is the end that may have to retransmit the final ACK.
    For the second reason, we can assume that we intend to close a connection gracefully and then re-establish a connection on the same socket (the latter connection is called the incarnation of the former). TCP must prevent old duplicate packets from a connection from reappearing after the connection has terminated. For this reason, TCP will not initiate new incarnations for connections in the TIME_WAIT state. Since the duration of the TIME_WAIT state is 2MSL, it is enough to allow packets in one direction to survive at most MSL seconds before being discarded, and responses in the other direction to survive at most MSL seconds. It is thus guaranteed that each time a TCP connection is successfully established, the duplicate packets from the previous incarnation of that connection have been lost in the network (with one exception: if the SYN arrives with a sequence number greater than the previous incarnation's end sequence number, The Berkeley-derived implementation will start a new incarnation for a connection that is currently in TIME_WAIT state. It requires the server to perform an active close because the end that receives the next SYN must be in TIME_WAIT state).

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326182503&siteId=291194637