The following are several important kernel parameters configured in the /etc/sysctl.conf file. The settings of these parameters are related to system performance:
net.ipv4.tcp_syncookies
#This parameter should be set to 1 to prevent SYN Flood.
A TCP connection in SYN_RECV is called a semi-connection and is stored in the SYN queue. A large number of SYN_RECV will cause the queue to overflow, and subsequent requests will be directly discarded by the kernel, which is a SYN Flood attack. After syncookies are enabled, when the SYN queue is full, TCP will create a special Sequence Number (also called cookie) through the original address port, destination address port and time stamp (sent back, if it is an attacker, there will be no response, if it is normal The connection sends the SYNCookie back, and then the server can establish a connection through the cookie (even if it is not in the SYN queue).
net.ipv4.tcp_fin_timeout
#The default value of this parameter is 60, the time that TCP stays in the FIN_WAIT2 state, and it will be in CLOSED directly after timeout, so reducing tcp_fin_timeout will help reduce the number of TIME_WAIT. Note: Although shutdown(SHUD_WR) will also be in FIN_WAIT2 state, timeout does not work.
net.ipv4.tcp_tw_recycle
#The default value of this parameter is 0, enabling fast TIME_WAIT socket recycling.
If tcp_timestamps is enabled, the latest timestamp of each connection will be cached. If the subsequent request timestamp is smaller than the cached timestamp, it will be considered invalid and the corresponding packet will be discarded. Therefore, if it is under a NAT (Network Address Translation) network, data packets may be discarded, which will cause a large number of TCP connection establishment errors.
net.ipv4.tcp_tw_resue
#The default value of this parameter is 0, whether to reuse the socket in TIME_WAIT state for new connections.
This option is safer than net.ipv4.tcp_tw_recycle. From the perspective of the protocol, multiplexing is safe. Reuse conditions:
1) The net.ipv4.tcp_timestamps option must be turned on (the client must also be turned on);
2) The condition for reusing TIME_WAIT is more than 1 second after receiving the last packet;
net.ipv4.tcp_keepalive_time = 1200
#This parameter indicates the interval time (seconds) for TCP to send keepalive detection messages, which is used to confirm whether the TCP connection is valid. How often TCP sends keepalive messages when keepalive is enabled. The default is 2 hours, which can be changed to 20 minutes.
#################################################### ##############
###### Reasons and solutions for a large number of CLOSE-WAIT generated by Linux servers #####
############## #################################################### #
The reason for the close_wait state is that the passive closing party did not close the socket.
When the client sends a FIN signal before the server for some reason, the server will be closed passively. If the server does not actively close the socket and send FIN to the client, this At this time, the server Socket will be in the CLOSE_WAIT state (instead of the LAST_ACK state). Generally speaking, a CLOSE_WAIT will last for at least 2 hours (the system default timeout is 7200 seconds, which is 2 hours). If the server program causes the system to cause a bunch of CLOSE_WAIT to consume resources for some reason, then the system usually crashes before it is released.
Here you need to first understand the three parameters of tcp keepalive :
the default value of tcp_keepalive_time is 7200, the timeout period (the idle time of keepingalive enabled); the
default value of tcp_keepalive_intvl is 75, the tcp check interval time (the interval for sending keepalive detection packets); the
default The value of tcp_keepalive_probes is 9, the number of tcp checks (if the other party does not respond, the number of times the probe packet is sent);
To adjust these three parameters according to your own business, there are three ways:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|