当 close-wait 出现, 这一般意味着, 应用程序出现了问题.

为了解决这个问题, epoll 引入了 EPOLLRDHUP 事件, 用于即时通知应用层, 当收到 fin 的情况下.

但是一些情况下, 还是会出现 close-wait 一些逻辑上的问题.

当 close-wait 出现的情况下, 理论上这个情况会一直这样下去. 因为 tcp 是双工的,
一端不再向你发送数据了, 但是你不能不让我发送数据. 所以我可以一直占用着这个 tcp fd.

但是事实又有一些出入, 我观察到一些情况下, close-wait 还是会消失的.
但是程序的并没有调用 close. 细细思考这个问题: 在对端 fin 之后, 我还可以
向对方发送数据, 但是内核就不能知道对方可能完全不再接收数据了吗.
基于一些其它的方式比如 keepalive, 内核还是可以知道, 就算上层再发送数据,
这个时候, 数据也是会发送失败的. 内核可以先释放这个端口.

这个时候去看 lsof 就会发现如下的信息.

can't identify protocol

我理解, 由于内核已经完全闭关了连接, 现在只有应用层占用了一个 fd.
fd 下的连接相关的资源已经加收了.

当然这样, 最后虽然没有 close-wait, 但是还是有可能出现句柄不够用的情况.

这个过程中, 内核如何探知可以完全 shutdown 连接的, 这个还不清楚.

以上是 close-wiat 在线上的一些发现.