问题

公司用浏览器访问线上服务一会失败一会成功，通过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