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