Udp ARP超时。为什么固定周期？

这个问题困扰了我好几年了

基本问题：是否有某些原因导致ARP必须在ARP缓存项上执行固定超时？

我在实时循环中做了很多工作。现在，我们在专用UDP/IP链路上进行大多数系统间通信。这在很大程度上可以实时可靠地工作，但对于一个nit:ARP输入超时

典型的ARP实现方式如下：

• 当客户机请求向具有未知MAC地址的IP地址发送IP数据包时，堆栈将发送ARP请求，而不是发送该IP数据包。如果上层（TCP）确实重新发送，那没有问题。但是由于我们使用UDP，原始消息丢失了。在启动时，这是可以的，但在操作过程中，这是一个<强>坏的事物< /强>™.
• （动态）ARP表条目会周期性地从ARP表中删除，即使我们在一毫秒前刚刚从该系统收到一个数据包。这意味着坏事™ 我们的系统经常发生这种情况

显而易见的解决方案（我们反复使用）是使所有ARP条目都是静态的。然而，这是一个皇家PITA（特别是在RTO上，在RTO上，查找接口的MAC地址并不总是一个简单的GUI点击问题）

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

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

---

这就是问题所在。不知何故，这种行为是必需的吗？

它起源于对路由协议的不信任，特别是在非以太网世界（尤其是麻省理工学院的混沌网络）。Chris Moon，早期的“ARPAnauts”之一，在最初的ARP RFC中被特别引用

当然，你可以通过主动广播你自己的ARP公告来防止其他人的ARP缓存超时。大多数以太网层将接受免费的ARP响应到缓存中，而不尝试将它们与以前发送的ARP请求关联。

讨论了这一点

     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.

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

---

它还提供了一种检查主机是否仍在网络上的机制。假设您正在通过UDP将视频流传输到某个IP地址192.168.0.5。如果你永远缓存那台机器的MAC地址，即使主机宕机，你也会继续发送UDP数据包。时不时地执行ARP请求会导致流停止，并出现无法到达目的地的错误，因为没有人使用该IP的MAC进行响应。

我认为丢弃数据包而改为执行ARP过程的行为非常糟糕。e、 g.Windows在arp期间仅缓冲1个数据包，而许多其他操作系统在arp期间做更明智的事情，并在正常套接字缓冲区中缓冲数据包。@nos-传出还是传入？据我所知，传出的TCP数据包是缓冲的（因为TCP就是这样工作的，以确保可靠性）。传出的UDP数据包被丢弃。任何传出的IP数据包（用于目标），无论是TCP还是UDP。当然，TCP将检测并重新传输丢弃的数据包。在这种情况下，请衷心同意。对于典型的PC应用程序来说，这可能不是什么大问题，但在我的实时世界中，这是致命的。这已经是我生存的祸根7年左右了。今天早上我又遇到了一个奇怪的ARP问题-（有意思。我没有想到这个解决方案。当然，一些操作系统有一个恼人的倾向，即很难通过编程方式获取MAC地址。我必须看看我们的操作系统是如何处理的。OOC，你能自己做这件事吗？我的意思是广播ARP响应（可能是环回）与其他人的MAC/IP组合，以防止该项计时超出您自己的表。我这样问是因为保持我们的UDP链接确定性依赖于一台机器是链接上已确认的主机。除非主机请求，否则另一台机器不能说话，因此其他系统实际上不允许按照自己的时间表发送自己的ARP。如果操作系统和网络驱动程序不会阻止您，是的，您可以：呵呵。已经在另一个浏览器选项卡中加载了确切的链接，但谢谢。：-）根据您的回答，我找到了一个关于我正在谈论的确切算法的建议（据我所知，没有堆栈实现）。因此，我想这就是我的答案。从“或者可能从主机接收数据包时，应该重置用于向该主机发送数据包的地址解析条目中的超时；如果在适当的时间长度内没有从主机接收数据包，则地址解析条目会被遗忘。”@T.E.D.是的，您可以这样做。许多操作系统都会这样做，并且从传入的数据包到ARP缓存中有一个积极的反馈。OK。这就是我需要的。我希望我能接受这两个答案。这一个更好地回答了我的问题，但Ross’更有可能对我有所帮助（我可能有足够的动力让供应商改变他们的算法，但这需要很长时间，而且只能从一方面解决问题）。