TCP protocol status analysis, super complete~

Today I will talk to you about the state analysis of the TCP protocol. You can see the figure below, and then we will explain it in detail.

Initiate handshake phase

CLOSED: Indicates the initial state.

LISTEN: Indicates that a SOCKET on the server is in listening state and can accept connections.

SYN_RCVD: Indicates that a SYN message has been received. Under normal circumstances, this state is an intermediate state of the server-side SOCKET in the three-way handshake session when establishing a TCP connection. It is very short-lived and it is difficult to see this state with netstat, unless you have specially written a client test program to deliberately not send the last ACK message in the three-way TCP handshake process. Therefore, in this state, after receiving the client's ACK message, it will enter the ESTABLISHED state.

SYN_SENT: This state corresponds to SYN_RCVD. When the client SOCKET executes CONNECT, it first sends a SYN message, so it immediately enters the SYN_SENT state and waits for the server to send the second message in the three-way handshake. The SYN_SENT state indicates that the client has sent a SYN message.

ESTABLISHED: Indicates that the connection has been established, which is the state in which both parties communicate normally.

Active Closure Phase

• FIN_WAIT_1: After the local sends a FIN (used to end the connection) packet, it enters this state and waits for the other party's response. Generally, after one end has sent the data it wants to send, it can send a FIN packet. At this time, the sending channel is closed, but it can still continue to receive packets sent by the remote end. After receiving the ACK response to the FIN packet sent by the remote end, it will enter the FIN_WAIT_2 state.
• FIN_WAIT_2: Entering this state means that the local has received the ACK response to the FIN data packet sent by the remote end. After entering this state, the local can still continue to receive data packets sent by the remote end. After receiving the FIN data packet sent by the remote end (indicating that the remote end has also sent the data), the local will send a response data packet and enter the TCP_TIME_WAIT state. The time that the TIME_WAIT state exists is called the 2MSL time. This is to avoid the loss of the response data packet sent by the local, and to avoid a newly created socket receiving the data packet left in the old socket.

In fact, the real meaning of FIN_WAIT_1 and FIN_WAIT_2 states is that they both mean waiting for the other party's FIN message (active closing phase).

The difference between these two states is:

The FIN_WAIT_1 state is actually when the SOCKET is in the ESTABLISHED state, it wants to actively close the connection and sends a FIN message to the other party. At this time, the SOCKET immediately enters the FIN_WAIT_1 state. When the other party responds with an ACK message, it enters the FIN_WAIT_2 state. Of course, in actual normal circumstances, no matter what the other party is, it should immediately respond to the ACK message, so the FIN_WAIT_1 state is generally difficult to see, while the FIN_WAIT_2 state can often be seen with netstat.

• FIN_WAIT_2: This state has been explained in detail above. In fact, a SOCKET in the FIN_WAIT_2 state indicates a half-connection, that is, one party requests to close the connection, but also tells the other party that I still have some data to send to you and will close the connection later.
• TIME_WAIT:: Indicates that the FIN message from the other party has been received and the ACK message has been sent. After 2MSL (twice the message segment lifespan), it can return to the CLOSED available state. If in the FIN_WAIT_1 state, a message with both the FIN flag and the ACK flag is received from the other party, it can directly enter the TIME_WAIT state without going through the FIN_WAIT_2 state.

This state is called the 2MSL waiting state. If a FIN packet is received from the remote end during this period, it means that the ACK packet sent in the TCP_FIN_WAIT_2 state was lost or delayed for a long time during transmission, causing the remote end to resend the FIN packet, and then repeat the ACK packet. Once the 2MSL time expires, it will enter the TCP_CLOSED state, completing the closing operation.

• CLOSING: This state is quite special and should be rarely seen in actual situations. It is a relatively rare exception state. Under normal circumstances, after you send a FIN message, you should receive (or receive at the same time) the other party's ACK message first, and then receive the other party's FIN message. However, the CLOSING state means that after you send a FIN message, you did not receive the other party's ACK message, but instead received the other party's FIN message.

Under what circumstances will this happen? In fact, if you think about it carefully, it is not difficult to draw the conclusion: if both parties close a SOCKET almost at the same time, then both parties will send FIN messages at the same time, and the CLOSING state will appear, indicating that both parties are closing the SOCKET connection.

Passive closing phase

CLOSE_WAIT: When the other party sends a FIN message to you first, the local system will undoubtedly respond with an ACK message to the other party. At this time, the socket state changes from ESTABLISED to CLOSE_WAIT. Next, what you really need to consider is whether you have data to send to the other party. If not, then you can close the SOCKET and send a FIN message to the other party, that is, close the connection. So when you are in CLOSE_WAIT state, what you need to do is wait for you to close the connection.

This state exists at the passively closed (late closed) end. After receiving the FIN packet sent by the remote end, the local end sends an ACK response packet and sets the socket state from ESTABLISED to CLOSE_WAIT. The local end can continue to send data packets to the remote end. After sending all the data, the local end will send a FIN packet to close the local sending channel and set the state to LAST_ACK state, waiting for the remote end's response packet to the FIN packet.

LAST_ACK: This state is relatively easy to understand. It is the passive closing party that waits for the other party's ACK message after sending the FIN message. When the ACK message is received, it can enter the CLOSED available state.