Recv-Q 填满后,Netcat 停止监听

Recv-Q 填满后,Netcat 停止监听

我在 Ubuntu 18.04.3 LTS 服务器上运行 Netcat,监听端口 469。此服务器频繁从其他计算机接收对端口 469 的 TCP 请求,我使用该端口来监控服务器的正常运行时间。我使用以下命令启动 Netcat:

nc -kl 469

我可以看到这个过程正在进行:

$ ps -aux | grep 469输出结果如下:

根 11041 0.0 0.1 13596 1060 ? S 8 月 31 日 0:21 nc -kl 469`

该系统运行良好,大约 24 - 28 小时,但随后 Netcat 停止响应。经过调查,我认为问题在于 Recv-Q 缓冲区“填满”。通常,Recv-Q 缓冲区为零,直到 Netcat 停止响应。停止响应后,Recv-Q 缓冲区为常数 2(而不是正常的 0)。我可以用“ss”检查这一点,如下所示。

$ ss -tnl然后我看到了这个,其中可以看到异常的 Recv-Q 2。

$ ss -tnl
状态 Recv-Q Send-Q 本地地址:端口 对等地址:端口
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 64 0.0.0.0:42587 0.0.0.0:*
LISTEN 0 128 0.0.0.0:46663 0.0.0.0:*
LISTEN 0 128 0.0.0.0:111 0.0.0.0:*
侦听 2 1 0.0.0.0:469 0.0.0.0:*
侦听 0 128 127.0.0.53%lo:53 0.0.0.0:*
侦听 0 128 [::]:22 [::]:*
侦听 0 64 [::]:44057 [::]:*
侦听 0 128 [::]:55085 [::]:*
侦听 0 128 [::]:111 [::]:*

我们还有其他几台 Ubuntu 服务器,它们也以完全相同的方式运行 Netcat 监听端口 469。它们没有出现故障 - 它们已经运行了数周。但是这台服务器一次又一次出现故障,即使重新启动后也是如此,而且总是在大约 24 小时后。这台服务器与其他服务器(我能想到的)之间的唯一区别是,这台服务器还挂载了一个 nfs 卷(从上面监听端口 111 可以看出)。

这可能是什么原因造成的?我能以某种方式(从 bash)清除 Recv-Q 吗,以便我可以定期清除它(作为临时解决方案)?任何帮助都非常感谢。

答案1

我现在已经找到了这个问题的答案,我想把它发布在这里,以防它可以帮助其他人。

问题是该服务器还安装了 Strongswan,并且传入到端口 469 的 TCP 请求通过来自另一台服务器的 IPSec 连接发送。发生的情况是,当 IPSec 连接重新密钥时(大约每 24 小时一次),IPSEC 连接有时会中断很短的时间。如果这种情况发生在正在进行的 TCP Syn/Ack 到端口 469 的中间,它将处于不确定状态。因此,“nc -kl”会卡住,数据包在 Recv-Q 缓冲区中。

解决方案是配置 Strongswan,以便重新密钥化不会中断。经验是,与其寻找 Recv-Q 缓冲区或 Netcat 的问题,不如了解根本原因 - 在本例中是了解 TCP Syn/Ack 无法完成的原因。

相关内容