我在 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 无法完成的原因。