TCP status transition diagram (learning summary)

This is the basis of network programming. The status transition diagram of TCP is essentially the Conversion Relationship between different States of a state machine and the conditions required to trigger these States. There are 11 statuses in total. Let's analyze them one by one:

1. Closed: The starting point. It enters this status when the connection times out or is closed.

2. Listen: the status of the SVR end when it is waiting for the connection. The SVR end can enter this status by calling socket, bind, and listen functions. This is called an applicationProgramPassively open (wait for the client to connect ).

3. syn_sent: the client initiates a connection and sends SYN to the server. If the server cannot be connected, it directly enters the closed state.

4. syn_rcvd: corresponds 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 must respond to an ACK and send a SYN to the client. In another case, the client receives the SYN request from the server while initiating the syn, the client will be changed from syn_sent to syn_rcvd.

5. Established: After three handshakes are performed between the server and the client, data transmission can be started.

The above describes the status transfer between the server and the client when the connection is established. It is relatively simple and clear. If you are familiar with the three-way handshake, it is easy to understand the status transfer during connection establishment.

Next, the server and the client will transmit data..., of course, there is a lot of knowledge in it, so stop it and try again later.

Next, let's take a look at the status transfer description when the connection is closed. to close the connection, we need to perform interaction between the two parties four times. We also need to handle some aftermath (time_wait Status). Note, here, either the active or passive closing side does not refer to the server or client, but is relative to who initiates the closing request first:

6. fin_wait_1: The party that proactively closes the service. Status 5 changes to this status. Send fin to the other party during specific actions.

7. fin_wait_2: The party that closes the ticket, receives the fin ACK from the other party, and enters this status. Therefore, you cannot receive data from the other party. However, data can be sent to the other party.

8. close_wait: After receiving the fin, the passively closed party enters this status. The specific action receives fin and sends ack.

9. last_ack: The party that passively closes the request and initiates a close request. The request enters this status from status 8. Send fin to the other party during the specific action, and enter the closed status when Ack is received.

10. Closing: when both sides initiate a close request, fin_wait_1 enters this status. The specific action is to receive a fin request and respond to an ACK at the same time.

11. time_wait: The most tangled state is coming. From the status chart, we can see that three States can be converted into one. Let's analyze them one by one:

A. the fin_wait_2 enters this state: when both parties initiate fin at the same time, the party that closes the request will complete the request, the status after receiving the fin from the passive closing side.

B. switch from the closing status to the status: Both Parties initiate both close requests, both initiate fin requests, and switch from the closing status when fin and ACK are received.

C. the status enters from fin_wait_1: Both fin (initiated by the other party) and ACK (Fin response initiated by itself) are received ), the difference with B is that the ACK in the fin response initiated by itself comes prior to the fin request of the other party, while B is in the fin first. In this case, the probability is the least.

The most difficult to understand the four closed connections is time_wait. There are two reasons for time_wait:

1. Reliable termination of TCP full-duplex connections.

2. Allow the old duplicate segments to disappear in the network.

This is the basis of network programming. The status transition diagram of TCP is essentially the Conversion Relationship between different States of a state machine and the conditions required to trigger these States. There are 11 statuses in total. Let's analyze them one by one:

1. Closed: The starting point. It enters this status when the connection times out or is closed.

2. Listen: the status of the SVR end when it is waiting for the connection. The SVR end can enter this status by calling socket, bind, and listen functions. This is called passive opening of an application (waiting for the client to connect ).

3. syn_sent: the client initiates a connection and sends SYN to the server. If the server cannot be connected, it directly enters the closed state.

4. syn_rcvd: corresponds 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 must respond to an ACK and send a SYN to the client. In another case, the client receives the SYN request from the server while initiating the syn, the client will be changed from syn_sent to syn_rcvd.

5. Established: After three handshakes are performed between the server and the client, data transmission can be started.

The above describes the status transfer between the server and the client when the connection is established. It is relatively simple and clear. If you are familiar with the three-way handshake, it is easy to understand the status transfer during connection establishment.

Next, the server and the client will transmit data..., of course, there is a lot of knowledge in it, so stop it and try again later.

Next, let's take a look at the status transfer description when the connection is closed. to close the connection, we need to perform interaction between the two parties four times. We also need to handle some aftermath (time_wait Status). Note, here, either the active or passive closing side does not refer to the server or client, but is relative to who initiates the closing request first:

6. fin_wait_1: The party that proactively closes the service. Status 5 changes to this status. Send fin to the other party during specific actions.

7. fin_wait_2: The party that closes the ticket, receives the fin ACK from the other party, and enters this status. Therefore, you cannot receive data from the other party. However, data can be sent to the other party.

8. close_wait: After receiving the fin, the passively closed party enters this status. The specific action receives fin and sends ack.

9. last_ack: The party that passively closes the request and initiates a close request. The request enters this status from status 8. Send fin to the other party during the specific action, and enter the closed status when Ack is received.

10. Closing: when both sides initiate a close request, fin_wait_1 enters this status. The specific action is to receive a fin request and respond to an ACK at the same time.

11. time_wait: The most tangled state is coming. From the status chart, we can see that three States can be converted into one. Let's analyze them one by one:

A. the fin_wait_2 enters this state: when both parties initiate fin at the same time, the party that closes the request will complete the request, the status after receiving the fin from the passive closing side.

B. switch from the closing status to the status: Both Parties initiate both close requests, both initiate fin requests, and switch from the closing status when fin and ACK are received.

C. the status enters from fin_wait_1: Both fin (initiated by the other party) and ACK (Fin response initiated by itself) are received ), the difference with B is that the ACK in the fin response initiated by itself comes prior to the fin request of the other party, while B is in the fin first. In this case, the probability is the least.

The most difficult to understand the four closed connections is time_wait. There are two reasons for time_wait:

1. Reliable termination of TCP full-duplex connections.

2. Allow the old duplicate segments to disappear in the network.