从 CLOSE_WAIT 状态说起（一）

近期，接到线上反馈，在某些机器上，TCP 连接状态会有 CLOSE_WAIT，并且一直挂着，不会自动关闭，同时出现的问题是，任何尝试 connect 的应用都无法连接成功，tcp 的 backlog 溢出，抓包与之前文章很相似，是不是可以合并成一个问题呢？这个问题虽然可以用重启解决，但是，找不到问题根源，是不行的。

之前那篇文章已经将能得到的现象进行了很多猜测，最后发现在 tokio 1.x 上不重现，于是就没有深究问题在哪，这次花了很多时间去追究问题的起源在哪。

CLOSE_WAIT 状态是什么？

不要将 CLOSE_WAIT 和 FIN_WAIT(1 or 2) 混淆了，这三个状态是完全不一样的行为导致的：

CLOSE_WAIT 是被动接到第一个 FIN 时，被动接收方会进入的一个状态，如果一切正常，被动方会响应 ACK + FIN，迁移到 LAST_ACK，然后正常关闭
FIN_WAIT_1 主动发出 FIN 时，主动方进入的等待 ACK 的状态
FIN_WAIT_2 主动发出 FIN 后，接到 ACK 后，等待对方发出 FIN 的状态

那么，是什么原因可能导致大量连接卡在 CLOSE_WAIT 无法关闭呢？这是一个很神奇的问题，正常来说，接到 FIN 就进入了关闭流程，TCP 整个协议是在内核中实现的，正常不会被上层应用影响，除非发生了一些奇怪的操作导致了 OS 端流程的卡死。我的目标是找到这个奇怪的操作，虽然我无法接触到环境，但可以通过截图等问题手段看到一些想看的东西，抓包已经不起作用了，需要看看 os 提供的其他信息。

结合 backlog 定位问题

回到最开始的现象描述，backlog 溢出了，这个东西很关键，backlog 是内核的 accept queue，用来存放等待用户端获取的已经完成连接握手的崭新 TCP stream，它的溢出，可以大胆猜测：用户端没有及时进行 accept 操作。

导致没有及时 accept 操作的可能性会有很多：

应用是在 tokio 异步运行时内的，是否存在大量代码执行 blocking 操作占用了 worker，导致调度失灵，无法进行 accept 操作，进而导致 backlog 被塞满
是否因为业务任务过多，而端口被 dos，导致 backlog 的插入速度远大于获取速度，进而导致一直无法恢复正常状态
是否可能存在 bug，导致 backlog 的插入事件无法通知到 accept 操作进行，进而导致了 backlog 无法清理的问题

前两个可能性因为我无法接触到生产环境，无法做准确判断，最后一个我倒是可以确认，在旧版本中存在一个这样的 bug 触发概率，并且已经在两个月之前已经修复了，那么，是否有可能该环境的库版本没有升级导致了这个问题呢？

经过确认，该环境确实没有升级网络库的版本，现在暂定是这个 bug 导致的问题。那么用户端不获取 backlog 内的 stream 与 CLOSE_WAIT 有什么关系呢？

之前说过，CLOSE_WAIT 是被动接到 FIN 的一端产生的状态，如果握手成功后，该 stream 一直呆在 backlog 中，对端会因为超时不响应强行断开该连接，就是主动发送 FIN，那么在 backlog 中的 stream 接到就自然进入了 CLOSE_WAIT 状态，并且一直停留在该状态，直到用户从队列中取出，尝试 write 的时候，会报错 Broken pipe，这时候，该 FD 才会被丢弃，如果一直不拿出来，那 FD 占用就一直无法删除，也就是最开始接到的反馈现象。

小结

下一篇说一下这个 bug 的产生原因，是怎么修复的，如何通过 bug 代码复现该问题，为什么能在本地测试中藏匿那么久没有被发现。