Solve the problem of too many TIME_WAIT statuses viewed by netstat under 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 in progress
LISTEN: The server is waiting for an incoming call
SYN_RECV: A connection request has arrived, waiting for confirmation
SYN_SENT: Application has started, open a connection
ESTABLISHED: Normal data transfer status
FIN_WAIT1: The app says it's done
FIN_WAIT2: The other side has agreed to release
ITMED_WAIT: wait for all packets to die
CLOSING: Both sides try to close at the same time
TIME_WAIT: The other side has initiated a release
LAST_ACK: wait for all packets to die
 
 
If it is found that there are a large number of connections in the TIME_WAIT state in the system, it can be solved by adjusting the kernel parameters.
vim /etc/sysctl.conf
Edit the file and add the following:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
Then execute /sbin/sysctl -p to make the parameters take effect.
 
net.ipv4.tcp_syncookies = 1 means enable SYN cookies. When the SYN waiting queue overflows, enable cookies to deal with it, which can prevent a small number of SYN attacks. The default value is 0, which means it is closed;
 
net.ipv4.tcp_tw_reuse = 1 means to enable reuse. Allow TIME-WAIT sockets to be reused for new TCP connections, the default is 0, which means close;
 
net.ipv4.tcp_tw_recycle = 1 means to enable fast recycling of TIME-WAIT sockets in TCP connections, the default is 0, which means close.
 
net.ipv4.tcp_fin_timeout Modify the default TIMEOUT time of the system
 
The meaning of the TIME_WAIT state is attached below:
 
After the client establishes a TCP/IP connection with the server and closes SOCKET, the port connected to the server
 
Status is TIME_WAIT
 
Will all sockets that are actively closed enter the TIME_WAIT state?
 
Is there any situation that makes the actively closed socket directly enter the CLOSED state?
 
The party that actively closes will enter the TIME_WAIT state after sending the last ack and stay for 2MSL (max segment lifetime) time. This is essential for TCP/IP, that is, it cannot be "solved".
 
That's what the TCP/IP designers originally designed
 
There are two main reasons
 
1. Prevent the packets in the previous connection from reappearing after getting lost, affecting the new connection (after 2MSL, all duplicate packets in the previous connection will disappear)
 
2. Reliably close TCP connections
 
The last ack(fin) sent by the active closing party may be lost. At this time, the passive party will resend the fin. If the active party is in the CLOSED state at this time, it will respond to rst instead of ack. So the active party should be in TIME_WAIT state, not CLOSED.
 
TIME_WAIT is not very resource-intensive unless attacked.
 
Also, if one party's send or recv times out, it will directly enter the CLOSED state
 
 
 

netstat -tunlp |grep 80

Check port usage

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326069322&siteId=291194637