TCP Shutdown Status Explained

The TCP shutdown connection does not differentiate between the client and the server, which port can proactively initiate a close connection request. Therefore, in order to describe the convenience, the description of the "active side" means to initiate the shutdown of the connection side, "passive side" indicates the passive closed connection side.

1. TCP Shutdown Connection state transition

is the state transition diagram for the active shutdown of the TCP connection:

(1) Application layer calls the close function to initiate a close connection request

(2) Send fin to the peer, close the write channel, and enter the FIN_WAIT1 state yourself

(3) Wait for the acknowledgment ack of the end to arrive, receive the ACK to enter the FIN_WAIT2 state, if not received within the time-out confirmation ack directly into the closed state

(4) If the fin_wait1 is received at the end of the fin to the closing state (both send a close connection request)

(5) Enter the TIME_WAIT state after the fin_wait2 is connected to the fin, and if the fin is not received within the time-out period, enter the closed state directly.

(6) Enter closed state after waiting for 2 MSL (2 messages maximum survival period) in Time_wait state

is the state transition diagram of the passive shutdown side of the TCP connection

(1) After receiving the end fin, turn off the read channel into the close_wait state

(2) Waiting for application layer to call close function in Close_wait state closes the connection

(3) If Close is called within the timeout period, enter the Last_ack state; otherwise go directly to the closed state.

(4) in the Last_ack state, send the fin to the peer and wait for confirmation ack on the end

(5) If a confirmation ACK is received within the timeout period, it enters the closed state or enters the closed state directly.

2. State analysis

2.1 Fin_wait1

This state is rare in the actual work. The active party calls the close function to close the connection and immediately enters the FIN_WAIT1 state, at which point it will enter the Fin_wait2 state as soon as the ACK acknowledgement is received. Because the peer acknowledgment ACK is controlled by the TCP stack itself, it will be issued shortly. Scene: The active side waits for the ACK process network to break, causes the long time to receive the ACK, the active party will stay in the CLOSE_WAIT1 state (timeout time: The general default 60s timeout). At this point we can see this state using the NETSTAT-ANPT command.

Note: If this state times out, it will go directly to the closed state. You may need to know about the time-out: tcp_fin_timeout This configuration parameter.

2.2 Fin_wait2

This state is more common. While the active side is waiting for the end fin to arrive, you will be kept in this state (time-out: typically 60s by default). The active end is in a fin_wait2 state for a long time because of a network outage, or if the end is too busy to send fin, or if there is a bug on the side that forgets to close the connection. If the active party discovers a large number of fin_wait2 state, should arouse the attention of the relevant personnel, this may be network instability, the performance of the terminal program bug.

Note: If this state times out, it will go directly to the closed state. You may need to know about the time-out: tcp_fin_timeout This configuration parameter.

2.3 time_wait

This state is most common. The active party receives the fin on the end and enters the TIME_WAIT state. Then send the last acknowledgment ack to the peer. After waiting for the 2 maximum message survival period, the normal shutdown process client TCP connection will go through this state, eventually into the closed state. So we use the NETSTAT-ANPT command to find that the client has a lot of time_wait, generally this is normal phenomenon.

Note:

* The connection to this state is not actually closed, so resources such as the file handle and port number used are not released. If the TIME_WAIT state has too many connections, it will cause insufficient resources such as file handles or port numbers. If you want to control the number of connections in this state, you may need to know more about: Tcp_max_tw_buckets tcp_tw_recycle tcp_tw_reuse three system configurations.

* For servers with a large number of short-link services, the server actively shuts down the connection will generate a lot of time_wait, if not timely recovery of these connections will cause serious waste of resources. However, an application-tier system has its own maximum number of concurrent connections, and the operating system has a maximum time_wait connection limit. So there is usually no big problem.

* Reasons to wait for 2MSL:

(1) Ensure that the residual network report will not be received by the new connection to generate data confusion. Since the last packet you sent may still remain in the network, waiting for 2MSL time guarantees that all remaining network datagrams have timed out before they are shut down.

(2) Make sure your final ACK is sent to the peer. Because the ACK send may also fail, this is the peer will resend the fin, if it has been closed, then the peer will receive the RST instead of the ACK, which does not conform to the TCP reliable shutdown policy.

2.4 CLOSING

The double-hair almost simultaneously calls the close interface to actively close the connection, at which point the Fin_wait1 state is entered. If the FIN_WAIT1 state expects to receive the other's ACK but receives the other's fin, both sides enter the closing state. Then give each other an ACK confirmation, received the ACK will enter the closed state.

Note: If this state times out, it will go directly to the closed state. I haven't found the setting for this time-out yet?

2.5 close_wait (emphasis on this state)

This status indicates that the TCP connection wait is closed. May only appear on the passive side. If the passive side has a large number of close_wait states need because of our special attention. We need to study carefully to determine why the passive side is reluctant to close the connection (perhaps the bug in our program has connected, but forgot to close it)

In the current development process encountered the following this scenario causes the passive side has a lot of close_wait state:

A is an application and B is a Tomcat server

A opens a connection conn and sends a request to B

A after accepting the corresponding data, the conn.close is not called to close the connection, and these connections remain in front of the Conn objects before the A-end garbage collection.

b End of the connection timeout will be initiated to close the connection request to a, at this time a entered the close_wait state, B entered the Fin_wait2 state, due to a delay in sending fin to b,b end trigger timeout directly into the closed state.

Such a scenario B-side because there is a timeout set to 60s, there will not be a large number of fin_wait2 state

However, a side will remain a large number of close_wait state (close_wait state also has a timeout, but too large, the default is 43200s, details see tcp_timeout_close_wait system Configuration). Fortunately, a-side Java Virtual machine's maximum memory configuration is small, because the close_wait state connection also takes up memory resources, a lot of will trigger garbage collection, at this time the end of a CLOSE_WAIT connection Conn objects will be destroyed (at the same time memory and handle, Ports and other resources have been released.)

It is obvious that this is a bug caused by the problem, if not timely recovery, will be memory, handle or port and other resources to run out, resulting in the program crash out.

2.6 Last_ack

This state can only appear on the passive side. When the passive side calls the close interface to close the connection, it enters this state and sends a fin to the peer. After accepting the ACK acknowledgment of the end, it will enter the closed state, which is generally not easy to appear, unless the network is interrupted, the general end will respond quickly.

2.7 Status Summary

Possible states of the active side: Fin_wait1, Fin_wait2, CLOSING, time_wait

The status of the passive side may appear: close_wait last_ack

The time-out mentioned in the narrative has a specific analysis in my other article about TCP connection timeouts.

Note:

(1) The active end of a large number of fin_wait1 need to pay attention to whether the network is unblocked, there are a large number of fin_wait2 need to carefully check why the process is not receiving the end of the fin (may be active or passive side of the bug), a large number of time_wait need to pay attention to the concurrency of the system/ Socket handle resource/memory usage/port number resource, etc.

(2) A large number of close_wait on the passive side need to be carefully checked why you are reluctant to call close to close the connection (maybe Bug,socket is open and not closed)

TCP Shutdown Status Explained