Shulou(Shulou.com)06/01 Report--

As shown in the following figure, the TCP communication process consists of three steps: establishing a TCP connection channel (three-way handshake), data transmission, and disconnecting the TCP connection channel (four waves).

This paper further explores the state changes and data transmission process in the process of three-way handshake and four waves of TCP. First look at the TCP state transition diagram.

The first part is the state transition of the three-way handshake process of TCP, and the second part is the state transition of the four-wave process of TCP.

CLOSED: the starting point, entering this state when the connection is closed or timed out, is not a real state, but the imaginary starting point and end point of the state diagram. LISTEN: the state of the server waiting for a connection. The server enters this state after the socket,bind,listen function and begins to listen for connection requests sent by the client. This is called an application opening passively (waiting for a client connection request). SYN_SENT: when the first handshake occurs, the client initiates the connection. The client calls connect, sends SYN to the server, then enters the SYN_SENT state and waits for the server to confirm (the second message in the three-way handshake). If the server side cannot connect, it goes directly to the CLOSED state. SYN_RCVD: the second handshake occurs, corresponding to 3. Here, the server receives the SYN of the client. At this time, the server enters the SYN_RCVD state from LISTEN, and the server responds with an ACK, and then sends a SYN, that is, SYN+ACK, to the client. The state diagram also depicts a situation in which when the client sends SYN, it also receives a SYN request from the server, that is, two connection requests are initiated at the same time.

SYN_SENT transitions to SYN_REVD state. ESTABLISHED: during the third handshake, after the client receives the ACK packet (ACK,SYN) on the server, it will also send an ACK acknowledgement packet. The client enters the ESTABLISHED status, indicating that the client is ready, but TCP needs to be ready on both sides before data transmission can be carried out. After receiving the ACK from the client, the server transitions from the SYN_RCVD state to the ESTABLISHED state, indicating that the server is also ready for data transfer. So that both the client and the server are

In the ESTABLISHED state, the data can be transferred later. So ESTABLISHED can also be said to be a state of data transfer. Above is the state change of the TCP three-way handshake. Combined with the first three-way handshake process diagram, the state transition is seen from the point of view of the message: the SYN_SENT status indicates that the client has sent the SYN message, and the SYN_RCVD status indicates that the server has received the SYN message.

Let's take a look at the state changes in the four-wave process of TCP. Combined with the first four-wave process diagram to understand.

FIN_WAIT_1: wave for the first time. The party who actively shuts down (the party who performs the active shutdown can be either the client or the server. Here, take the client performing an active shutdown as an example), when terminating the connection, send FIN to the other party, and then wait for the other party to return ACK. Call close () to enter this state the first time you wave. 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 party who passively shuts down is waiting for the upper application to issue a closed connection instruction at this time. As mentioned earlier, TCP shutdown is a full-duplex process, where the client performs an active shutdown and the passive server receives the FIN

After that, you also need to call close to close. This CLOSE_WAIT is in this state, waiting for FIN to be sent. If FIN is sent, it will enter LAST_ACK state. FIN_WAIT_2: the active end (in this case, the client) first executes the active shutdown of sending FIN, and then receives the ACK returned by the passive party and then enters this state. LAST_ACK: the passive party (server side) initiates a shutdown request and enters this state from status 2. The specific action is to send FIN to the other party and enter the CLOSED state when the ACK is received. CLOSING: when both parties initiate a shutdown request at the same time (that is, the active party sends FIN, waiting for the passive party to return ACK, and the passive party also sends FIN, and after the active party receives the FIN, the active party sends ACK to the passive party), the active party will enter this state by FIN_WAIT_1 and wait for the passive party to return ACK. TIME_WAIT: as you can see from the state transition diagram, four waving operations will eventually pass through such a state and then enter the CLOSED state. A total of three states enter this state by CLOSING: in the case of initiating a shutdown at the same time, when the active end receives the ACK, it enters this state. In fact, this is the case here: the client initiates a shutdown request and waits for the server to respond to ACK after sending FIN. But at this time, the server also initiates a shutdown request and sends FIN, which is received by the client before ACK. Entering by FIN_WAIT_1: after initiating a shutdown, a FIN is sent. While waiting for ACK, the passive party (server side) also initiates a shutdown request and sends FIN. At this time, the client receives the previous ACK and the other party's FIN, and then sends ACK (response to the other party's FIN). Different from the state in which CLOSING enters, it receives FIN and ACK in sequence. Enter by FIN_WAIT_2: this is a different situation. After completing its own active shutdown request, the active party receives the FIN sent by the other party, and then responds to the ACK. Let's take a look at this seemingly superfluous TIME_WAIT state: judging from the above three state actions that entered the TIME_WAIT state (you can directly look at the state transition diagram), the active party responded to an ACK (the previous FIN_WAIT_1 state of CLOSING actually responded to ACK).

First consider such a situation, if the last response ACK is lost, that is, the server cannot receive the ACK, then the server will continue to send its final FIN, so the client must maintain the status message (TIME_WAIT) to allow it to resend the last ACK. If the client is in the CLOSED state without this TIME_WAIT state (it is said at the beginning that the CLOSED state does not actually exist, it is for the convenience of describing the hypothesis), then the client will respond to the RST, and the server will interpret the RST section as an error, which will not be able to achieve the final full-duplex shutdown (which may be the unilateral shutdown of the active party). Therefore, in order to achieve the normal termination of a TCP full-duplex connection (both parties close the connection), we must deal with the loss of any of the four sections in the termination process, then the active end of actively closing the connection must maintain the TIME_WAIT state, and the last one that responds to ACK is the one that actively closes the connection. As can be seen from the transition diagram, if there is no TIME_WAIT state, we will not have any mechanism to ensure that the last ACK can arrive properly. The normal arrival of the previous FIN,ACK has a corresponding state.

There is also such a situation, if both sides of the current communication have called close () and have reached the CLOSED state, and when there is no TIME_WAIT state, there will be such a situation. Now a new connection has been established, using the same IP address and port as the one that previously reached the CLOSED state. It is assumed that there are still Datagram residues in the original connection. In this way, the data transferred after the new connection is established is most likely to be the Datagram of the original connection. To prevent this, TCP does not allow socket from the TIME_WAIT state.

Establish a connection. A socket in the TIME_WAIT state will transition to the CLOSED state after waiting for twice as much MSL time. Here the duration of the TIME_WAIT state is 2MSL (MSL is the longest any IP Datagram can survive on the Internet), enough for packets in both directions to be dropped (the longest is 2MSL). By implementing this rule, we can ensure that every time a TCP connection is successfully established, the old duplicate packets from the previous avatar of the connection have disappeared in the network.

To sum up: the two reasons for the existence of TIME_WAIT are

Reliably terminates TCP full-duplex connections; allows old repetitive segments (datagrams) to disappear in the network.

This article comes from selfimpr1991's CSDN blog. The full text address can be found at https://blog.csdn.net/wenqian1991/article/details/40110703?utm_source=copy.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.