这个问题多年来一直困扰着我。
基本问题：ARP有什么原因吗has要在 ARP 缓存条目上实现固定超时吗？
我在实时圈子里做了很多工作。如今，我们的大部分系统间通信都是通过专用 UDP/IP 链路进行的。这在很大程度上可以实时可靠地工作，但有一点是：ARP 条目超时。
典型的 ARP 实现方式如下：
- 当客户端请求将 IP 数据包发送到 MAC 地址未知的 IP 地址时，堆栈不会发送该 IP 数据包，而是发出 ARP 请求。如果上层 (TCP) 确实重新发送，那没问题。但由于我们使用UDP，原始消息丢失了。在启动时这是可以的，但在操作过程中这是一个坏事™.
- （动态）ARP 表条目会定期从 ARP 表中删除，即使我们在一毫秒前刚刚从该系统收到一个数据包。这意味着坏事™我们的系统经常发生这种情况。
显而易见的解决方案（我们虔诚地使用它）是使所有 ARP 条目静态。然而，这是一个皇家 PITA（特别是在 RTOS 上，查找接口的 MAC 地址并不总是只需单击几次 GUI 即可）。
当我们编写自己的 IP 堆栈时，我通过从不使 ARP 表条目超时来解决这个问题。这有明显的缺点。更稳健且完全合理的解决方案可能是每当看到来自同一 MAC/IP 组合的数据包时刷新条目超时。这样，只有在一段时间内没有与堆栈通信的条目才会超时。
但现在我们使用供应商的 IP 堆栈，并且又回到了愚蠢的 ARP 超时。我们对这个供应商有足够的影响力，我也许可以让他们使用一个不那么不方便的方案。然而，这种脑死亡超时算法的普遍性让我相信它可能是实现的必需部分。
这就是问题所在。这种行为在某种程度上是必需的吗？
RFC1122 对互联网主机的要求 http://www.ietf.org/rfc/rfc1122.txt讨论这个。
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。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
