Reduced TIME_WAIT Connection Status

Reduce time_wait connection status. There are already a lot of relevant introductions on the network, most of which are suggestions:

shell> sysctl net.ipv4.tcp_tw_reuse=1shell> sysctl net.ipv4.tcp_tw_recycle=1

Note: The kernel parameters are modified by the SYSCTL command, which is restored after reboot, so you can refer to the previous method if you want to persist.

These two options can be said to be immediate in terms of reducing the number of time_wait, but if you feel that the problem has been done perfectly then it is wrong to actually introduce a more complex network failure.

For a detailed description of the kernel parameters, refer to the official documentation. Here's a brief description of the tcp_tw_recycle parameter. It is used to quickly reclaim time_wait connections, but it can cause problems in a NAT environment.

RFC1323 is described in the following paragraph:

An additional mechanism could is added to the TCP, a per-host cache of the last timestamp received from any connection. This value could then is used in the PAWS mechanism to reject old duplicate segments from earlier incarnations of the Conn Ection, if the timestamp clock can be guaranteed to has ticked at least once since the old connection is open. This would require the time-wait delay plus the RTT together must is at least one tick of the sender ' s timestamp cloc K. Such an extension are not part of the proposal of this RFC.

Presumably, TCP has a behavior that caches the latest timestamp for each connection, and if the timestamp is less than the cached timestamp in subsequent requests, it is considered invalid and the corresponding packet is discarded.

Whether Linux enables this behavior depends on Tcp_timestamps and tcp_tw_recycle, because the tcp_timestamps default is on, so when the tcp_tw_recycle is turned on, the behavior is actually activated.

Now many companies use LVS to do load balancing, usually the front of a LVS, behind multiple back-end servers, built in a NAT, when the request reaches the LVS, after it modifies the address data is forwarded to the back-end server, but does not modify the timestamp data, for the backend server, the source address of the request is the LVS address , plus the port will be reused, so from the perspective of the back-end server, the original request of different clients through the LVS forwarding, it may be considered the same connection, combined with different client time may be inconsistent, so there will be a time stamp disorder, so the data packets behind are discarded, the specific The performance is usually a SYN sent by the client, but the service side is not responding to the ACK, you can also use the following command to confirm that the packet is constantly discarded phenomenon:

Shell> Netstat-s | grep timestamp ... packets rejects in established connections because of timestamp

If the server is in a NAT environment, for security reasons, it is usually forbidden to tcp_tw_recycle, as for the problem of too many time_wait connections, it can be mitigated by activating the Tcp_tw_reuse.

Further thinking, since Tcp_timestamps and tcp_tw_recycle must be activated at the same time to trigger this phenomenon, as long as the ban tcp_timestamps, while activating tcp_tw_recycle, you can avoid the problem of NAT packet loss, and reduce the number of time_wait connections. If the server does not rely on RFC1323, then this method should be feasible, but it is better to do more testing, in case there are other side effects.

shell> sysctl net.ipv4.tcp_timestamps=0shell> sysctl net.ipv4.tcp_tw_recycle=1

To address these issues, it is recommended that you turn off the tcp_tw_recycle option instead of timestamp, because tcp_tw_recycle is not working if the TCP timestamp is turned off, and the TCP The timestamp can be opened and functioning independently.

Reduce time_wait Connection status