一、timewait出现在客户端还是服务端以及什么情况下出现

我是做性能测试的。在压测过程中遇到了timewait过多的情况，下面来看一下timewait产生的原因及解决办法，我自己在服务器起了一个很简单的springboot应用来验证自己的猜想及解决办法。

说到产生原因就要提到断开连接的挥手过程了，挥手过程已经说明了，客户端和服务端都可以主动断开连接，谁主动断开连接，timewait状态就发生在哪一端。这个过程很好复现，你在本地打开一个浏览器然后访问你部署的应用，这个时候在命令行窗口netstat -a|find "目标ip" 就能看到和目标ip建立连接了，然后你把浏览器关闭，这个时候的状态就变成timewait了。

当时我在用jmeter做压测，由于tps过高，导致处于timewait状态的连接很多，然后一直报错。后面研究了下，jmeter有个默认的配置httpclient.reset_state_on_thread_group_iteration，它的值默认是true，表示每次请求都创建一个新的连接来请求，超过了系统可创建连接的限制。

这是httpclient.reset_state_on_thread_group_iteration=true，我用jmeter创建一个线程请求10次的效果，每一次都会创建一个连接。

这是httpclient.reset_state_on_thread_group_iteration=false，我用jmeter创建一个线程请求10次的效果，10次请求就创建了一个连接。

 接下来我们研究下一个长连接可以接收多少次请求，超过一定次数后连接由哪一方主动断开？

1、在jmeter设置单线程请求99次，这是请求99次后windows和linux端的状态

请求99次后，jmeter主动断开连接，timewait发生在windows端。

2、在jmeter设置单线程请求100次，这是请求100次后windows和linux端的状态

请求100次后，服务端主动断开连接，timewait发生在linux端。

3、在jmeter设置单线程请求101次，这是请求101次后windows和linux端的状态

 请求101次后，windows端和linux端都发生了timewait，这是为什么呢。这是因为在100次的时候达到了长连接的请求次数上限，linux端主动断了连接产生timewait，在第101次的时候，jmeter主动断了连接，windows端产生了timewait。

所以从上面可以看出，一个长连接的请求次数上限是100

4、再在jmeter设置单线程请求501次，看看windows和linux端的状态，验证我们上述的结论

 可以看到，服务端有5个timewait，刚好对应jmeter请求的500次，而windows端的timewait刚好对应jmeter的第501次。

5、我们再来看看一个有意思的问题，同一个连接有可能出现两端同时主动断开的情况，这种情况只会出现在100次请求的倍数场景下，比如200次，300次，但是也不一定保证每次两端都会出现同时主动断开的情况。下面是我请求1000次的情况。

可以看到，56267端口 对应的连接在windows和linux都出现了timewait

 二、服务端如何避免过多的timewait

1、网上的很多文章都说修改以下配置

net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle 
net.ipv4.tcp_fin_timeout 

net.ipv4.tcp_max_tw_buckets

经过我自己的实际压测，只有改net.ipv4.tcp_max_tw_buckets这个配置有用，这个配置可以限制你的处于timewait的连接能有多少个，而且不会对你的压测结果有影响，因为在我改之前和改之后压测，jmeter体现的tps几乎没有变化。当然你还可以改ip_local_port_range来缓解你的连接不够用的情况。

2、实在不行，那就做负载均衡来分担你的压力吧