首先介绍一下背景知识：在所讨论的（隔离的）/16 LAN 上，我们有几个设备，它们之间保持多个持久 TCP 连接打开。这些 TCP 连接两端的程序每两秒钟向其伙伴发送一次“心跳”数据包；而且每个程序都会跟踪上次收到心跳的时间：如果四秒钟内没有收到心跳数据包，它会认为出了问题，关闭 TCP 连接，向用户报告问题，然后尝试重新建立连接。
该局域网上还有一个 Linux 机器，它会定期运行以下命令：
/usr/bin/arp-scan --interface=bond0:2 --localnet --bandwidth=2560
它这样做是为了查明 LAN 上是否存在任何重复的 IPv4 地址；如果有，它会向用户报告该问题。
这一切都很好，只是偶尔（例如每隔几天一次）我们会毫无原因地收到心跳超时，有人猜测 arp-scan 可能会干扰 TCP 流量，导致心跳被延迟足够长的时间，从而触发 4 秒超时。这些事件通常发生在晚上，此时 LAN 或多或少处于空闲状态（当然，心跳数据包和 arp-scan 除外）。当这些事件发生时，TCP 连接总是会立即成功重新建立，但由此产生的错误消息让用户感到紧张，所以我想弄清楚这里发生了什么。
我的问题是：arp-scan 的扫描机制是否具有足够的侵入性，以至于它可能是罪魁祸首？请注意，我们提供了一个 --bandwidth=2560 参数，以便它在扫描期间不会占用大量带宽；但也许 arp 数据包会导致 arp<->IP 地址缓存被刷新，或者类似的事情？
答案1
arp-scan 只是将 arp-who-has 请求发送到广播地址 - 无论如何，这都是网络上一直在发生的事情，因此没有理由让它干扰任何连接。
即使主机的 ARP 缓存溢出，它也只会在发送 IP 数据包之前自行发出 arp-who-has 请求 - 它会将数据包延迟至少 RTT，这比 LAN 环境中的超时值低三个数量级，因此可以忽略不计。
TCP 不是用于非常频繁的心跳的最佳协议 - 链接上丢失的每个段（即确认）都会延迟其接收至少一秒（最小重传超时值）。如果在某个链接上不幸连续发生 2-3 次丢失，您的应用程序将超时。
另一个可能的解释是发送心跳的主机的负载 - 如果它正在以高饱和度执行一些高优先级的工作，则您的心跳生成线程可能会受到短期饥饿并且不能及时发出心跳。
因此，为了查明问题所在，我会在晚上检查数据链路层计数器是否存在错误或可能的流量控制影响，并检查心跳生成服务器的性能计数器是否存在可能的 CPU 或内存瓶颈。如果您没有发现任何可疑情况，只需增加超时时间 :)
答案2
就我个人而言，我会停止自动运行 arp-scan，并在一天中手动运行几次。等待几周，看看是否真的是 arp-scan 导致了您的问题，因为我敢打赌它完全不相关。
我还将开始对双方进行 tcpdump，以便您可以看到实际发送/接收了哪些数据包。
但实际上，TCP 连接永远不会无限期地持续下去。只要您的应用“始终”能够重新创建连接，为什么要提醒用户？为什么不默默地重新创建连接，而只在重新创建失败或检测到每小时/每天创建的连接数超过 X 个时才抛出错误？