为何客户端突然出现大量TIME_WAIT堆积

本文介绍了一个在阿里云环境下某客户端ECS机器上突然发现TIME_WAIT突然增高的问题和排查过程。

问题场景：原来客户端直接访问后端Web服务器，TIME_WAIT数量非常少。现在引入了7层SLB来实现对后端服务器的负载均衡。客户端SLB访问后端服务器，但是发现客户端的TIME_WAIT状态的socket很快累积到4000多个，并且客户反映没有修改任何内核参数。

梳理问题

收到这个信息后，基本上可以推断出来的信息：

客户端通过短连接连接SLB(服务器)，客户端是连接的主动关闭方。并且并发比较大。
如果之前没有发现TIME_WAIT堆积，而现在堆积，在访问模式不变的情况下，极有可能之前有TIME_WAIT socket的快速回收或复用。那么基本上可以推断下面几个TCP内核参数设置大概率如下：

net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1
客户确认了如上信息。

排查

在这个案例中我们目前能确认的唯一变化就是引入了SLB，那就需要看下SLB对TIME_WAIT的影响到底是什么。对于客户端来说，如果TCP内核参数tcp_tw_recycle和tcp_timestamps同时为1，正常情况下处于TIME_WAIT状态的socket会被快速回收 (这个描述不严谨，后面可以看看源代码)，客户现在的现象是看起来是TIME_WAIT状态的socket没有被快速回收。

因为tcp_tw_recycle是一个系统参数，而timestamp是TCP option里携带的一个字段，我们主要需要关注下timestamp的变化。如果你足够熟悉SLB࿰