Solve a large number of TIME_WAIT problems on the web

 

Since the launch of a new set of Apache servers, I used the netstat-an command to find a large number of TCP connections in the TIME-WAIT Status on the server, so I used/sbin/sysctl-a to view Linux kernel parameters, read the relevant information, and decided to modify the two parameters, to reduce the TIME-WAIT sockets in TCP connections.

 

Vi/etc/sysctl. conf

Edit the/etc/sysctl. conf file and add four lines:

Reference

 

Net. ipv4.tcp _ syncookies = 1

Net. ipv4.tcp _ tw_reuse = 1

Net. ipv4.tcp _ tw_recycle = 1

Net. ipv4.tcp _ fin_timeout = 30

Note:

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 process is disabled;

Net. ipv4.tcp _ tw_reuse = 1 # indicates enabling reuse. Allow TIME-WAIT sockets to be re-used for a New TCP connection. The default value is 0, indicating that the TCP connection is disabled;

Net. ipv4.tcp _ tw_recycle = 1 # indicates to enable quick recovery of TIME-WAIT sockets in TCP connections. The default value is 0, indicating to disable it.

Net. ipv4.tcp _ fin_timeout = 30 # indicates that if the socket is disabled by the local end, this parameter determines the time it remains in the FIN-WAIT-2 state.

 

Run the following command to make the modification take effect immediately:

/Sbin/sysctl-p

 

Use the following statement to check the TCP status of the server:

　

Netstat-n | awk '/^ tcp/{++ S [$ NF]} END {for (a in S) print a, S [a]}'

The returned results are as follows:

ESTABLISHED 1423

FIN_WAIT1 1

FIN_WAIT2 262

SYN_SENT 1

TIME_WAIT 962

 

Effect: the number of sockets in the TIME_WAIT status is reduced from more than 10000 to about 1000. Sockets in the SYN_RECV waiting for processing status is 0, and the original value is 50 ~ 300.

The meanings of the TIME_WAIT status are attached below:

 

The port connected to the server after the client establishes a TCP/IP connection with the server and closes the SOCKET

Status: TIME_WAIT

 

Is it true that all sockets that execute active shutdown will enter the 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

It will enter the TIME_WAIT status and stay in the 2MSL (max segment lifetime) Time

This is essential for TCP/IP, that is, it cannot be solved.

 

That is, the TCP/IP designer was designed like this.

There are two main reasons:

1. Prevent the package in the last connection from appearing again after getting lost, affecting the New Connection

(After 2MSL, all repeated packets in the last connection will disappear)

2. Close TCP connection reliably

The last ack (fin) sent by the active shutdown party may be lost, and the passive party will resend the ack (fin ).

Fin. If the active Party is in the CLOSED state, it will respond to the rst instead of ack. So

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.

 

This article is from the "cheer for life" blog