现象：MeterSphere更换压力机后，压测出现出现HttpHostConnectException

解决方案：

net.ipv4.tcp_tw_reuse默认是0或者2，更改为1

net.ipv4.tcp_tw_reuse，表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接；那么，当连接被复用了之后，延迟或者重发的数据包到达，新的连接怎么判断，到达的数据是属于复用后的连接，还是复用前的连接呢？这就需要依赖net.ipv4.tcp_timestamps字段了。复用连接后，这条连接的时间被更新为当前的时间，当延迟的数据达到，延迟数据的时间是小于新连接的时间，所以，内核可以通过时间判断出，延迟的数据可以安全的丢弃掉了。

背景介绍

为了摸底项目的性能，需要进行性能测试。经过一番调研之后，决定使用基于腾讯云TKE的分布式jmeter进行压测，好处是有jmeter-suite可用，搭建环境方便；容器化部署可以方便的增加pod来提升压力。

但是在实际施压的时候，发现请求量上不去，达不到压测效果。经定位发现，容器pod上存在大量TIME_WAIT，而实际在传输数据的连接远小于设置的并发线程数：

netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}'

复制

为什么会有TIME_WAIT

这是TCP连接释放的4次挥手的过程：

主动关闭连接的一方，调用close()；协议层发送FIN包
被动关闭的一方收到FIN包后，协议层回复ACK；然后被动关闭的一方，进入CLOSE_WAIT状态，主动关闭的一方等待对方关闭，则进入FIN_WAIT_2状态；此时，主动关闭的一方
等待
被动关闭一方的应用程序，调用close操作
被动关闭的一方在完成所有数据发送后，调用close()操作；此时，协议层发送FIN包给主动关闭的一方，等待对方的ACK，被动关闭的一方进入LAST_ACK状态；
主动关闭的一方收到FIN包，协议层回复ACK；此时，主动关闭连接的一方，进入TIME_WAIT状态；而被动关闭的一方，进入CLOSED状态
等待2MSL时间，主动关闭的一方，结束TIME_WAIT，进入CLOSED状态

这个过程可以得到一下几个信息：

比如并行的线程数上万，由于一般是施压方主动断开连接，因此会积累大量的TIME_WAIT。建议解决方案：

Ramp-up时间（秒），这个配置表示多长时间把线程全部生成，需要根据业务情况做好配置，避免一次性生成太多配置，直接把施压机器搞垮，积累较多TIME_WAIT
Same user on each iteration，在 JMeter 中，user 就是线程，此选项的意思是说每个迭代都用相同的线程。它的影响就是单个线程多次迭代使用同一个线程，因为销毁和创建线程本身就会占用资源，可能会影响性能测试结果。建议开启

如第二节中所述，TIME_WAIT状态的连接，需要2MSL时间后才能回收端口用于创建新的连接，但是实际Linux内核配置支持快速回收TIME_WAIT状态的连接，配置可查看：

cat /etc/sysctl.conf

复制

net.ipv4.tcp_tw_recycle，该配置表示快速回收TIME_WAIT连接，但在NAT网络下，会导致连接失败（刚好使用的就是NAT），另外Linux 从4.12内核版本开始移除了 tcp_tw_recycle 配置，我这里的机器是4.14，因此直接注释掉
net.ipv4.tcp_tw_reuse，表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接；那么，当连接被复用了之后，延迟或者重发的数据包到达，新的连接怎么判断，到达的数据是属于复用后的连接，还是复用前的连接呢？这就需要依赖net.ipv4.tcp_timestamps字段了。复用连接后，这条连接的时间被更新为当前的时间，当延迟的数据达到，延迟数据的时间是小于新连接的时间，所以，内核可以通过时间判断出，延迟的数据可以安全的丢弃掉了。
net.ipv4.tcp_timestamps，在重用连接的情况下，该配置能帮助操作系统识别新来的数据是旧连接的还是新连接的

使用百度来实验压测，实测相同的线程下，压出来的QPS大幅提升。