udp - ARP 超时。为什么要固定周期？

Question

这个问题多年来一直困扰着我。

基本问题:是否有某种原因必须在 ARP 缓存条目上使用固定超时来实现 ARP？

我在实时圈子中做了很多工作。如今，我们的大部分系统间通信都是通过专用 UDP/IP 链路进行的。这在很大程度上可以实时可靠地工作，但有一点是:ARP 条目超时。

典型的 ARP 实现方式如下:

• 当客户端请求将 IP 数据包发送到具有未知 MAC 地址的 IP 地址时，堆栈不会发送该 IP 数据包，而是发出 ARP 请求。如果上层 (TCP) 确实重新发送，那没问题。但由于我们使用UDP，原始消息丢失了。在启动时这是可以的，但在操作过程中这是一个Bad Thing™。
• (动态)ARP 表条目会定期从 ARP 表中删除，即使我们在一毫秒前刚刚从该系统收到一个数据包。这意味着我们的系统会定期发生Bad Thing™。

显而易见的解决方案(我们经常使用的)是使所有 ARP 条目静态化。然而，这是一个皇家 PITA(特别是在 RTOS 上，查找接口(interface)的 MAC 地址并不总是只需单击几次 GUI 即可)。

当我们编写自己的 IP 堆栈时，我通过从不使 ARP 表条目超时来解决这个问题。这有明显的缺点。更稳健且完全合理的解决方案可能是每当看到来自同一 MAC/IP 组合的数据包时刷新条目超时。这样，只有在一段时间内没有与堆栈通信的条目才会超时。

但是现在我们正在使用供应商的 IP 堆栈，并且我们又回到了愚蠢的 ARP 超时。我们对这个供应商有足够的影响力，我也许可以让他们使用一个不那么不方便的方案。然而，这种脑死亡超时算法的普遍性让我相信它可能是实现的必需部分。

这就是问题所在。这种行为是否有某种必要？

Answer 1

RFC1122 Requirements for Internet Hosts 讨论这个。

     2.3.2.1  ARP Cache Validation

        An implementation of the Address Resolution Protocol (ARP)
        [LINK:2] MUST provide a mechanism to flush out-of-date cache
        entries.  If this mechanism involves a timeout, it SHOULD be
        possible to configure the timeout value.

      ...

       DISCUSSION:
             The ARP specification [LINK:2] suggests but does not
             require a timeout mechanism to invalidate cache entries
             when hosts change their Ethernet addresses.  The
             prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
             has significantly increased the likelihood that cache
             entries in hosts will become invalid, and therefore
             some ARP-cache invalidation mechanism is now required
             for hosts.  Even in the absence of proxy ARP, a long-
             period cache timeout is useful in order to
             automatically correct any bad ARP data that might have
             been cached.

网络可以非常动态；当旧的租用时间到期时(使当前的 ARP 数据无效)，DHCP 服务器可以将相同的 IP 地址分配给不同的计算机，可能会出现 IP 冲突，除非定期发出 ARP 请求，否则永远不会注意到，等等。

它还提供了一种检查主机是否仍在网络上的机制。想象一下，您正在通过 UDP 将视频流式传输到某个 IP 地址 192.168.0.5。如果您永远缓存该机器的 MAC 地址，即使主机出现故障，您也只会继续发送 UDP 数据包。时不时地发出 ARP 请求会因目标无法到达错误而停止流，因为没有人响应该 IP 的 MAC。