网络优化之net.ipv4.tcp_tw_recycle参数

一、概述

 

 

二、案例分享

【案例分析1】
 最近发现几个监控用的脚本在连接监控数据库的时候偶尔会连不上，报错：
  Couldn't connect to host:3306/tcp: IO::Socket::INET: connect: Cannot assign requested address
 查看了一下发现系统中存在大量处于TIME_WAIT状态的tcp端口
 $netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
 TIME_WAIT 50013
 ESTABLISHED 27
 SYN_RECV 1
 由于要监控的主机太多，监控的agent可能在短时间内创建大量连接到监控数据库(MySQL)并释放造成的。在网上查阅了一些tcp参数的相关资料，最后通过修改了几个系统内核的tcp参数缓解了该问题：
 #vi /etc/sysctl.conf
 
 net.ipv4.tcp_tw_reuse = 1
 net.ipv4.tcp_tw_recycle = 1
 
 #sysctl -p
 其中：
 net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
 net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
 修改完成并生效后，系统中处于TIME_WAIT状态的tcp端口数量迅速下降到100左右：
 $netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
 TIME_WAIT 82
 ESTABLISHED 36
————————————————

案例分析2】

 网上的帖子，大多都写开启net.ipv4.tcp_tw_recycle这个开关，可以快速回收处于TIME_WAIT状态的socket（针对Server端而言）。

 

而实际上，这个开关，需要net.ipv4.tcp_timestamps（默认开启的）这个开关开启才有效果。
更不为提到却很重要的一个信息是：当tcp_tw_recycle开启时（tcp_timestamps同时开启，快速回收socket的效果达到），对于位于NAT设备后面的Client来说，是一场灾难——会导到NAT设备后面的Client连接Server不稳定（有的Client能连接server，有的Client不能连接server）。也就是说，tcp_tw_recycle这个功能，是为“内部网络”（网络环境自己可控——不存在NAT的情况）设计的，对于公网，不宜使用。

通常，“回收”TIME_WAIT状态的socket是因为“无法主动连接远端”，因为无可用的端口，而不应该是要回收内存（没有必要）。即，需求是“Client”的需求，Server会有“端口不够用”的问题吗？除非是前端机，需要大量的连接后端服务——即充当着Client的角色。
正确的解决这个总是办法应该是：
net.ipv4.ip_local_port_range = 9000 6553 #默认值范围较小
net.ipv4.tcp_max_tw_buckets = 10000 #默认值较小，还可适当调小
net.ipv4.tcp_tw_reuse = 1 #
net.ipv4.tcp_fin_timeout = 10 #
————————————————