Solve the Problem of too many netstat views of TIME_WAIT status in LINUX.

Solve the Problem of too many netstat views of TIME_WAIT status in LINUX.
# Netstat-an | awk '/tcp/{print $6}' | sort | uniq-c 16 CLOSING 130 ESTABLISHED 298 FIN_WAIT1 13 FIN_WAIT2 9 LAST_ACK 7 LISTEN 103 SYN_RECV 5204 TIME_WAIT status: description CLOSED: No connection is active or LISTEN is in progress: the server is waiting for the incoming call SYN_RECV: a connection request has arrived. Wait to confirm that SYN_SENT: The application has started and open a connection ESTABLISHED: normal data transmission status FIN_WAIT1: The application says it has completed FIN_WAIT2: the other side has agreed to release ITMED_WAIT: Wait for all groups to die CLOSING: both sides attempt to disable TIME_WAIT: the other side has initialized a release LAST_ACK: wait for all groups to die. If you find that the system has a large number of connections in the TIME_WAIT status, adjust the Kernel Parameter solution. Definitely, vim/etc/sysctl. edit the conf file and add the following content: net. ipv4.tcp _ syncookies = 1net. ipv4.tcp _ tw_reuse = 1net. ipv4.tcp _ tw_recycle = 1net. ipv4.tcp _ fin_timeout = 30 and then run/sbin/sysctl-p to make the parameter take effect. Net. ipv4.tcp _ syncookies = 1 indicates enabling SYN cookies. When a SYN wait queue overflows, cookies are enabled to prevent a small number of SYN attacks. The default value is 0, indicating that the service is disabled. net. ipv4.tcp _ tw_reuse = 1 indicates that reuse is enabled. Allow TIME-WAIT sockets to be re-used for a New TCP connection. The default value is 0, indicating that it is disabled. net. ipv4.tcp _ tw_recycle = 1 indicates that fast recovery of TIME-WAIT sockets in TCP connections is enabled. The default value is 0, indicating that the quick recovery is disabled. Net. when 4.tcp _ fin_timeout is used to modify the default TIMEOUT time of the system, the value of TIME_WAIT state is attached below: after the client establishes a TCP/IP connection with the server and closes the SOCKET, is the port status of the server connection TIME_WAIT? Will all the socket that is actively closed go to TIME_WAIT status? Is there any situation in which the socket that is automatically CLOSED directly enters the CLOSED state? After the last ack is sent, the active closing party enters the TIME_WAIT status and stays in the 2MSL (max segment lifetime) time. This is necessary for TCP/IP, that is, it cannot be solved. That is, the TCP/IP designer was originally designed for two reasons: 1. Prevent the packets in the last connection from appearing again after they get lost, and affect the new connection (after 2MSL, all the repeated packets in the last connection will disappear) 2. The reliable closing of the TCP connection may be lost in the last ack (fin) sent by the active closing party. In this case, the passive party resends the fin. If the active Party is in the CLOSED state, it will respond to rst instead of ack. Therefore, the active party must be in the TIME_WAIT state, not the CLOSED state. TIME_WAIT does not occupy a large amount of resources unless it is attacked. Also, if one side sends or recv timeout, it will directly enter the CLOSED status