linux TIME_WAIT 个数过多

kaede_1

背景：写了一个线程池，有数据过来后发送http push，实现上调用的是libcurl。可是运行一段时间后，执行命令netstat，发现有好多个TIME_WAIT，多的时候有1000多个，但是几分钟后又缩小为几个（可能是数据来时占的比较多，数据处理后就close了）

从网上查了一下，有人说通过修改配置文件/etc/sysctl.conf
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
然后执行命令：/sbin/sysctl -p是配置生效。但是我配置了TIME_WAIT的数量基本上没变化。。。

再次检查了代码，发现在线程函数内，每发送一条数据后会调用curl_easy_cleanup清空句柄，后来想一下，既然是线程池，可不用每发送一条数据后就cleanup。可是注释掉后查看数量仍然没什么变化。。。


请问：
1.如果能使TIME_WAIT的数量下降？
2.就算TIME_WAIT的个数有1000多个，应该不会对系统有什么影响吧？

多谢！

kaede_1

哪位仁兄给指点一下

lxyscls

TIME_WAIT应该表示TCP连接资源还没有回收，资源多了不回收，就...

seanking1987

/etc/sysctl.conf这个文件参数的修改是为了能够快速复用tcp的端口吧。
但是TIME_WAIT过多的原因是什么，静等大神回复~

lxyscls

关于TIME_WAIT数量太多。从上面的描述我们可以知道，TIME_WAIT是个很重要的状态，但是如果在大并发的短链接下，TIME_WAIT 就会太多，这也会消耗很多系统资源。只要搜一下，你就会发现，十有八九的处理方式都是教你设置两个参数，一个叫tcp_tw_reuse，另一个叫tcp_tw_recycle的参数，这两个参数默认值都是被关闭的，后者recyle比前者resue更为激进，resue要温柔一些。另外，如果使用tcp_tw_reuse，必需设置tcp_timestamps=1，否则无效。这里，你一定要注意，打开这两个参数会有比较大的坑——可能会让TCP连接出一些诡异的问题（因为如上述一样，如果不等待超时重用连接的话，新的连接可能会建不上。正如官方文档上说的一样“It should not be changed without advice/request of technical experts”）。
关于tcp_tw_reuse。官方文档上说tcp_tw_reuse 加上tcp_timestamps（又叫PAWS, for Protection Against Wrapped Sequence Numbers）可以保证协议的角度上的安全，但是你需要tcp_timestamps在两边都被打开（你可以读一下tcp_twsk_unique的源码 ）。我个人估计还是有一些场景会有问题。
关于tcp_tw_recycle。如果是tcp_tw_recycle被打开了话，会假设对端开启了tcp_timestamps，然后会去比较时间戳，如果时间戳变大了，就可以重用。但是，如果对端是一个NAT网络的话（如：一个公司只用一个IP出公网）或是对端的IP被另一台重用了，这个事就复杂了。建链接的SYN可能就被直接丢掉了（你可能会看到connection time out的错误）（如果你想观摩一下Linux的内核代码，请参看源码 tcp_timewait_state_process）。
关于tcp_max_tw_buckets。这个是控制并发的TIME_WAIT的数量，默认值是180000，如果超限，那么，系统会把多的给destory掉，然后在日志里打一个警告（如：time wait bucket table overflow），官网文档说这个参数是用来对抗DDoS攻击的。也说的默认值180000并不小。这个还是需要根据实际情况考虑。
Again，使用tcp_tw_reuse和tcp_tw_recycle来解决TIME_WAIT的问题是非常非常危险的，因为这两个参数违反了TCP协议（RFC 1122）

其实，TIME_WAIT表示的是你主动断连接，所以，这就是所谓的“不作死不会死”。试想，如果让对端断连接，那么这个破问题就是对方的了，呵呵。另外，如果你的服务器是于HTTP服务器，那么设置一个HTTP的KeepAlive有多重要（浏览器会重用一个TCP连接来处理多个HTTP请求），然后让客户端去断链接（你要小心，浏览器可能会非常贪婪，他们不到万不得已不会主动断连接）。

我要报BUG，居然引用不算我的输入字符

kaede_1

研究了一下午，得出结论，这不是一个问题lol

1.首先，我的time_wait数量最多时不到5000，而我的端口范围是1024~65000（参见参数ip_local_port_range），因此5000多和6万多可用端口相比没啥问题。
2.此外，程序内部是短连接，这些time_wait过2mls后自动close。而且，我配置了参数reuse=1，因此，就算峰值量到了，也会重用这些time_wait占用的端口。况且峰值时的量也不大。
3.网上很多人都说配置这四个参数
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fin_timeout = 30

其实我觉得没必要，主要是不一定有效果！
如果要效果明显的解决问题，只需要配置下面两个参数（记得执行 sysctl -p是配置生效）
1.net.ipv4.tcp_tw_recycle = 1
2.net.ipv4.tcp_max_tw_buckets = 3000
第一个参数是快速回收机制的开关
第二个参数是触发点，也就是到这个量了才会触发回收，因此对于我的情况，time_wait的量在4K+，因此按照别人写的5000或者10000都没有效果，写3000效果明显。
不过按照官网上说的，可能会有隐患

如果考虑潜在的问题，那么在配置如下三个参数
1.net.ipv4.tcp_tw_reuse = 1
2.net.ipv4.ip_local_port_range = 1024 65000
3.net.ipv4.tcp_max_syn_backlog
第一个参数是复用的开关，如果服务器上还有其他的程序占用端口，导致端口不够，那么就复用那些time_wait状态的端口
第二个参数是扩大端口的范围，避免端口不够
第三个参数是最大SYN队列，可以容纳更多等待连接的网络连接数，避免影响接收。

至于其他的参数都是在某一方面提升性能的，结合自己实际情况添加


多谢二位的回答

何必抱怨

TIME_WAIT无法避免，只能重用socket对。

csumck

设置SO_LINGER选项的值为0秒可以解决这个问题

kaede_1

回复 8# csumck


    这是一个什么配置？