TCP status transition diagram

Note: There is no clear correspondence between active and passive traffic and servers and clients. N people know that this figure is helpful for troubleshooting and locating network or system faults. But how can we keep it in mind? Then, you must have a deep understanding of every state of the image and the conversion process.
You can't just stay in the dark. Next, we will analyze the 11 statuses of this image in detail to enhance the memory! But before that, let's review the three-way handshake process of TCP connection establishment and
Disconnect the four handshakes.

1. Establish a connection protocol (three-way handshake)
(1) the client sends a TCP packet with SYN flag to the server. This is packet 1 during the three-way handshake.
(2) The server responds to the client. This is the first packet in the three-way handshake. This packet carries both the ACK mark and SYN sign. Therefore, it indicates the response to the client SYN Packet. It also marks the SYN message to the client and asks whether the client is ready for data communication.
(3) The customer must re-respond to an ACK packet in the service segment, which is packet segment 3.
2. Connection termination protocol (four handshakes)

Because the TCP connection is full-duplex, each direction must be closed separately. This principle is that when one party completes its data sending task, it can send a fin to terminate the connection in this direction. Receive
Fin only means that there is no data flow between the two parties. a tcp connection can still send data after receiving a fin. First, the party that closes the service will take the initiative to close the service, and the other party will passively close the service.
(1) The tcp client sends a fin to disable data transmission from the client to the server (packet segment 4 ).
(2) When the server receives the fin, it sends back an ACK and confirms that the serial number is 1 (packet segment 5 ). Like SYN, a fin occupies a sequence number.
(3) The server closes the client connection and sends a fin to the client (packet segment 6 ).
(4) The customer segment sends back the ACK message for confirmation, and sets the confirmation sequence number to receive the serial number plus 1 (packet segment 7 ).
Closed: this is nothing to say, indicating the initial state.
Listen: this is also an easy-to-understand state, indicating that a socket on the server is in the listening state and can accept connections.
Syn_rcvd:

This status indicates that the SYN packet is received. Normally, this status is an intermediate status of the server socket during the three-way handshake session when a TCP connection is established. It is short and basic.
It's hard to see this status with netstat unless you write a client to testProgramThe last ACK packet in the three TCP handshakes will not be sent. So this status
When receiving the ACK packet from the client, it enters the established status.
Syn_sent:
This status echo syn_rcvd. When the client socket executes the connect connection, it first sends the SYN Packet and then enters the syn_sent state.
And wait for the server to send the 2nd messages in the three-way handshake. Syn_sent status indicates that the client has sent Syn packets.
Established: This is easy to understand, indicating that the connection has been established.
Fin_wait_1:

In fact, the true meanings of fin_wait_1 and fin_wait_2 indicate waiting for the fin message of the other party. The difference between the two states
Yes: The fin_wait_1 status is actually when the socket is in the established status, it wants to take the initiative to close the connection and send the FIN packet to the other party. At this time, the socket is
Enter the fin_wait_1 status. When the other Party responds to the ACK packet, it enters the fin_wait_2 state. Of course, under normal circumstances, regardless of the other party's circumstances
So the fin_wait_1 status is generally difficult to see, while the fin_wait_2 status is often seen using netstat.
Fin_wait_2: The above has explained in detail this status. In fact, the socket in the fin_wait_2 status indicates a semi-connection, that is, either party requires a close connection, but also tells the other party, I have some data to send to you, and close the connection later.
Time_wait:

It indicates that the other party's FIN packet is received, and the ACK packet is sent concurrently. After 2msl is sent, it can return to the available state of closed. If fin_wait_1 is in the fin_wait_1 status
The fin and ACK packets can directly enter the time_wait status without passing through the fin_wait_2 status.
Closing:
This status is special and should be rare in actual situations. It is a rare exception status. Normally, when you send a fin message, you should first (or simultaneously) receive the other party's
ACK packets, and then receive the FIN packets from the other party. However, the closing status indicates that after you send the FIN packet, you have not received the ACK packet from the other party, but have also received the FIN packet from the other party. What
In this case? In fact, it is not difficult to come to the conclusion that if both parties close a socket almost simultaneously, then both parties send a fin message at the same time.
The closing status indicates that both parties are closing the socket connection.
Close_wait:
The meaning of this state is actually that it is waiting to be closed. How can this problem be solved? When the other party closes a socket and sends a FIN packet to itself, your system will undoubtedly respond to an ACK packet to
And then enters the close_wait status. Next, you actually need to check whether you have any data to send to the other party. If not, you can
Close this socket, send the FIN packet to the other party, that is, close the connection. So what you need to do in close_wait is to wait for you to close the connection.
Last_ack: this status is easy to understand. It passively closes a side and waits for the other side's ACK packet after sending the fin message. After receiving the ACK message, you can enter the closed available status.
Finally, I have two answers. I have analyzed the results (not necessarily 100% correct)
1. Why is the three-way handshake while the four-way handshake when the connection is closed?
This
The reason is that when the socket in the listen status of the server receives the SYN Packet connection request, it can put ack and Syn (ACK responds, and SYN plays a synchronous role) in
Packets. However, when the connection is closed, when the other party receives the fin Message notification, it only indicates that the other party has no data to send to you; but not all your data may have been sent to the other party, so you can
The socket will be closed immediately, that is, you may need to send some data to the other party, and then send the fin message to the other party, indicating that you agree to close the connection now, so the ACK packet here
And Fin messages are sent separately in most cases.
2. Why does the time_wait status still need to be 2 MSL before it can be returned to the closed status?
This is because:
Although both parties agree to close the connection, and the four handshake packets are also coordinated and sent, it is reasonable to directly return to the closed status (like from syn_send
Establish status), but because we must assume that the network is unreliable, you cannot guarantee that the last ACK message you send will be received by the other party, so the other party is in
The socket in the last_ack status may fail to receive the ACK packet because of timeout, And the FIN packet is resold. Therefore, the time_wait status is used to resend the packets that may be lost.
ACK packets.

Open at the same time

It is possible for two applications to execute active opening at the same time, although it is less likely to happen. Each end sends a SYN to the other end, and each end uses the port known to the end as the local port. For example:

An application in host a uses port 7777 as the local port and connects to port 8888 of host B for active access.

An application in host B uses port 8888 as the local port and connects to host a port 7777 for active access.

In this case, only one connection is opened.

This connection requires four data exchanges, while a typical connection requires only three exchanges (that is, three handshakes)

However, most Berkeley TCP/IP implementations do not support simultaneous enabling.

Syn_rcvd andSyn_send is the intermediate state to be converted to established, with the goal of converting both endsEstablished status.

Disable at the same time

If the application sends fin at the same time, the fin_wait_1 status will first be entered after sending. After receiving the fin from the peer end, an ACK will be returned, which will enter the closing status. After receiving the ACK from the peer end, it enters the time_wait status. This situation is called "Disable at the same time.

At the same time, there are also four packet exchanges required for disabling, which is the same as the typical disabling.

This
N people know that it is helpful in troubleshooting network or system faults, but how can we keep this figure in our minds? Then, you must have a deep understanding of every state of the image and the conversion process.
You can't just stay in the dark. Next, we will analyze the 11 statuses of this image in detail to enhance the memory! But before that, let's review the three-way handshake process of TCP connection establishment and
Disconnect the four handshakes.

1. Establish a connection protocol (three-way handshake)
(1) the client sends a TCP packet with SYN flag to the server. This is packet 1 during the three-way handshake.
(2) The server responds to the client. This is the first packet in the three-way handshake. This packet carries both the ACK mark and SYN sign. Therefore, it indicates the response to the client SYN Packet. It also marks the SYN message to the client and asks whether the client is ready for data communication.
(3) The customer must re-respond to an ACK packet in the service segment, which is packet segment 3.
2. Connection termination protocol (four handshakes)

Because the TCP connection is full-duplex, each direction must be closed separately. This principle is that when one party completes its data sending task, it can send a fin to terminate the connection in this direction. Receive
Fin only means that there is no data flow between the two parties. a tcp connection can still send data after receiving a fin. First, the party that closes the service will take the initiative to close the service, and the other party will passively close the service.
(1) The tcp client sends a fin to disable data transmission from the client to the server (packet segment 4 ).
(2) When the server receives the fin, it sends back an ACK and confirms that the serial number is 1 (packet segment 5 ). Like SYN, a fin occupies a sequence number.
(3) The server closes the client connection and sends a fin to the client (packet segment 6 ).
(4) The customer segment sends back the ACK message for confirmation, and sets the confirmation sequence number to receive the serial number plus 1 (packet segment 7 ).
Closed: this is nothing to say, indicating the initial state.
Listen: this is also an easy-to-understand state, indicating that a socket on the server is in the listening state and can accept connections.
Syn_rcvd:

This status indicates that the SYN packet is received. Normally, this status is an intermediate status of the server socket during the three-way handshake session when a TCP connection is established. It is short and basic.
It is difficult for you to see this status with netstat unless you write a client test program and deliberately disable the last ACK packet from the three TCP handshakes. So this status
When receiving the ACK packet from the client, it enters the established status.
Syn_sent:
This status echo syn_rcvd. When the client socket executes the connect connection, it first sends the SYN Packet and then enters the syn_sent state.
And wait for the server to send the 2nd messages in the three-way handshake. Syn_sent status indicates that the client has sent Syn packets.
Established: This is easy to understand, indicating that the connection has been established.
Fin_wait_1:

In fact, the true meanings of fin_wait_1 and fin_wait_2 indicate waiting for the fin message of the other party. The difference between the two states
Yes: The fin_wait_1 status is actually when the socket is in the established status, it wants to take the initiative to close the connection and send the FIN packet to the other party. At this time, the socket is
Enter the fin_wait_1 status. When the other Party responds to the ACK packet, it enters the fin_wait_2 state. Of course, under normal circumstances, regardless of the other party's circumstances
So the fin_wait_1 status is generally difficult to see, while the fin_wait_2 status is often seen using netstat.
Fin_wait_2: The above has explained in detail this status. In fact, the socket in the fin_wait_2 status indicates a semi-connection, that is, either party requires a close connection, but also tells the other party, I have some data to send to you, and close the connection later.
Time_wait:

It indicates that the other party's FIN packet is received, and the ACK packet is sent concurrently. After 2msl is sent, it can return to the available state of closed. If fin_wait_1 is in the fin_wait_1 status
The fin and ACK packets can directly enter the time_wait status without passing through the fin_wait_2 status.
Closing:
This status is special and should be rare in actual situations. It is a rare exception status. Normally, when you send a fin message, you should first (or simultaneously) receive the other party's
ACK packets, and then receive the FIN packets from the other party. However, the closing status indicates that after you send the FIN packet, you have not received the ACK packet from the other party, but have also received the FIN packet from the other party. What
In this case? In fact, it is not difficult to come to the conclusion that if both parties close a socket almost simultaneously, then both parties send a fin message at the same time.
The closing status indicates that both parties are closing the socket connection.
Close_wait:
The meaning of this state is actually that it is waiting to be closed. How can this problem be solved? When the other party closes a socket and sends a FIN packet to itself, your system will undoubtedly respond to an ACK packet to
And then enters the close_wait status. Next, you actually need to check whether you have any data to send to the other party. If not, you can
Close this socket, send the FIN packet to the other party, that is, close the connection. So what you need to do in close_wait is to wait for you to close the connection.
Last_ack: this status is easy to understand. It passively closes a side and waits for the other side's ACK packet after sending the fin message. After receiving the ACK message, you can enter the closed available status.
Finally, I have two answers. I have analyzed the results (not necessarily 100% correct)
1. Why is the three-way handshake while the four-way handshake when the connection is closed?
This
The reason is that when the socket in the listen status of the server receives the SYN Packet connection request, it can put ack and Syn (ACK responds, and SYN plays a synchronous role) in
Packets. However, when the connection is closed, when the other party receives the fin Message notification, it only indicates that the other party has no data to send to you; but not all your data may have been sent to the other party, so you can
The socket will be closed immediately, that is, you may need to send some data to the other party, and then send the fin message to the other party, indicating that you agree to close the connection now, so the ACK packet here
And Fin messages are sent separately in most cases.
2. Why does the time_wait status still need to be 2 MSL before it can be returned to the closed status?
This is because:
Although both parties agree to close the connection, and the four handshake packets are also coordinated and sent, it is reasonable to directly return to the closed status (like from syn_send
Establish status), but because we must assume that the network is unreliable, you cannot guarantee that the last ACK message you send will be received by the other party, so the other party is in
The socket in the last_ack status may fail to receive the ACK packet because of timeout, And the FIN packet is resold. Therefore, the time_wait status is used to resend the packets that may be lost.
ACK packets.