解决Tengine健康检查引起的TIME_WAIT堆积问题

1. 问题背景

“服务上云后，我们的TCP端口基本上都处于TIME_WAIT的状态”、“这个问题在线下机房未曾发生过” 这是客户提交问题的描述。

客户环境是自建Tengine作为7层反向代理，后端接约1.8万台NGINX。Tengine上云之后，在服务器上发现大量的TIME_WAIT状态的TCP socket；由于后端较多，潜在可能影响业务可用性。用户对比之前的经验比较担心是否可能是接入阿里云之后导致，所以希望我们对此进行详细的分析。

注：TIME_WAIT状态的监听带来的问题在于主机无法为往外部的连接请求分配动态端口。此时，可以配置net.ipv4.ip_local_port_range，增加其端口选择范围（可以考虑 5000 - 65535），但依然存在 2 MSL 时间内被用完的可能。

2. TIME_WAIT原因分析

首先，如果我们重新回顾下TCP状态机就能知道，TIME_WAIT状态的端口仅出现在主动关闭连接的一方（跟这一方是客户端或者是服务器端无关）。当TCP协议栈进行连接关闭请求时，只有【主动关闭连接方】会进入TIME_WAIT状态。

而客户的顾虑也在这里。

一方面，健康检查使用 HTTP1.0 是短连接，逻辑上应该由后端NGINX服务器主动关闭连接，多数TIME_WAIT应该出现在NGINX侧。

另一方面，我们也通过抓包确认了多数连接关闭的第一个FIN请求均由后端NGINX服务器发起，理论上，Tengine服务器的socket 应该直接进入CLOSED状态而不会有这么多的TIME_WAIT 。
抓包情况如下，我们根据Tengine上是TIME_WAIT的socket端口号，进行了过滤。