与TIME_WAIT相关的几个内核参数

问题

公司用浏览器访问线上服务一会失败一会成功，经过ssh链接服务器排查时发现ssh也是这样；

检查

抓包后发现创建链接的请求已经到了服务器，但它没有响应；

纠结了很久，后来在腾讯云技术支持及查了相关资料后发现是开启了net.ipv4.tcp_tw_recycle致使的，将其设为0便可解决；

缘由

收集了几个与TIME_WAIT相关的内核参数：

net.ipv4.tcp_timestamps　　　　 默认开启（1），数据包加时间戳，须要两端都开启，能够防止高速率宽带时引发的序号回绕（序号不够用从新开始了），能够精确计算出RTT(往返时延）
net.ipv4.tcp_tw_reuse　　　　　　默认关闭（0），容许TIME_WAIT的socket在超过1秒后重用，做用于发起链接的client端
net.ipv4.tcp_tw_recycle　　　　　默认关闭（0），容许快速回收处于TIME_WAIT的socket，做用于接受链接的server端
net.ipv4.ip_local_port_range　　默认（32768 61000），可用的端口范围
net.ipv4.tcp_max_tw_buckets　　 默认（180000），容许处于TIME_WAIT状态socket的最大数量

若TIME_WAIT过多，能够开启reuse和recycle来快速回收，值得注意的一点是，reuse和recycle须要timestamps开启才会生效，固然timestamps通常都是开启的；

上面问题的缘由是，当多个client经过nat方式联网时（一个局域网）它们的源ip相同但发出的时间戳极可能是乱的，而开启了recycle的server端就会丢弃这些混乱的数据包，因而现象就是有时能连上有时不行；

至于reuse，开启可能致使端口重用后还会收到上个socket延迟到达的数据，这个通常问题不大，应用程序都会校验；

虽然reuse在client端配置有效，而recycle在server端，但如今不少机器都是接受链接后再去链接别人，因此视状况而定吧。

总结

官方文档是不建议开启reuse和recycle的，由于违反了tcp协议，因此临时开启来解决异常状况后应及时关闭；

若TIME_WAIT过多致使系统很慢（Linux对其优化很好，且如今不缺这点内存，因此通常不会），能够下降tcp_max_tw_buckets，阿里云和腾讯云分别默认设置为了5000、65536；

若端口不足能够考虑加大 ip_local_port_range，最大不超过：1024  65535；

TIME_WAIT过多长远的解决方式仍是经过程序开发方面：

1. 代码中及时正确的调用socket的close；

2. 让client端主动断开链接，而不是server端；

3. 尽可能使用长链接，而不是短链接；

 

over