CLOSE_WAIT 和TCP_KEEPALIVE

之前面试 曾经被问到 CLOSE_WAIT 状态意味这什么（服务端收到FIN 包后 还没有close fd，存在fd 泄漏的风险）

问题现象：
代理报错 too many open files, ulimit 设置为100W（/proc/pid/limits），使用ss 命令才几千，lsof 有很多 socket（不显示 ESTAB 等TCP 状态，仅显示 SOCK），查看进程 /proc/pid/fd/ 确实有100w (大量不显示状态的socket), 达到了ulimit 上限.

经过排查，代理由于请求hang 住， 没有close accept 的socket，出现了 fd 泄漏的问题，本地可以复现。
问题是：为什么ss 不显示这些tcp 的状态：CLOSE_WAIT

使用bcc 工具的 tcplife， tcpstates 工具（-L port）发现 连接居然从 CLOSE_WAIT =》 CLOSE 状态，且时间是15秒以后。

/usr/share/bcc/tools/tcpstates -L xxx
SKADDR           C-PID C-COMM     LADDR           LPORT RADDR           RPORT OLDSTATE    -> NEWSTATE    MS
ffff8801c5c5a340 2558058 curl       ::ffff:127.0.0.1 xxx  ::ffff:127.0.0.1 46124 ESTABLISHED -> CLOSE_WAIT  0.000
ffff8801c5c5a340 0     swapper/1  ::ffff:127.0.0.1 xxx  ::ffff:127.0.0.1 46124 CLOSE_WAIT  -> CLOSE       15004.867

既然应用层没有 close fd，那么肯定是内核干的事情了，在网上搜索了 TCP_KEEPALIVE 可以。

抓包：这里很明显 服务端发送了一个keep-alive 包，客户端RST ，内核回收连接。
tcpdump -nnvvv -A -s0 -i lo -w tcp.pacp

为什么是15秒呢？ setKeepAlivePeriod default golang 自带 accept 会设置。如果fint_timeout(TIME_WAIT) 少于这个值，回收了fd，此时对收到的包进行rst了。

内核完成了连接清理，所以ss 已经看不到ESTAB 或者CLOSE_WAIT, 只剩下fd 目录下一堆 未 关闭的 socket 文件描述符