RFC 没有解决您的第二种情况。这样做的原因是主机 C 发送到主机 A 可能与主机 A 不在同一网络上。在这种情况下，主机 A 具有 ARP 缓存条目是没有意义的，因为主机 A 永远不会在其 ARP 中查找主机 C缓存。主机 A 将始终知道主机 C 不在其网络上，因此当它想要发送到主机 C 时，它总是会在其 ARP 缓存中查找自己的网关条目。

可能有一些实现可以按照您的描述进行操作，但是标准没有解决它，并且似乎会浪费 ARP 缓存内存。

我会尝试一个接一个地回答你的每一个问题。但前提是，只有当它看到 ARP 响应时，才会在主机上生成 arp 条目。主机通常不会从所有帧中进行 mac 学习。开关执行该功能。

A 发送 arp 请求给 BB 发送 arp 回复给 AA 更新的 arp 表。

• 说正确的做法是一个不不发送ARP请求到B明确。它发出一个 arp 请求（句点）。这是寻址到广播 MAC。所以子网（广播域）上的每个人，包括 B 都得到了它。现在 B 发送一个 arp 回复。这是一种非常特殊的数据包格式（参见 RFC）。一旦 A 得到这个，它就会更新它的 ARP 表。

C 向 A 发送一个数据包（假设 C 的 arp 表中已经有 A 的 IP/MAC） 由于某种原因 A 的 arp 表没有 C 的条目 A 立即更新了 C 的 IP/MAC 的 arp 表

• 不是。在这种情况下，如果A没有C的MAC，需要向C发送响应，它会首先发出一个IP-MAC映射的ARP请求。（又名 WHOIS）。这将发送到 bcast MAC。C，看到这个会响应，这会导致 A 更新它的映射

所有这些都假设它们在同一个子网上。否则，网关就会出现。请参阅 Ron 的回答。

一张图解释了 arp 请求：

首先，在这个例子中，Poste1 想向 poste4 发送一个数据包，但它没有 poste 4 的@MAC，所以它发送了一个广播ARP。在这个请求中，poste 1 会问“IP 地址为 192.168.0.44 的 MAC 地址是什么？”

帖子 B 将只回答帖子1，“我是 192.168.0.44，我的@MAC 是 9c-d2-1e-31-19-44”

最后，Poste1 用 poste 4 的新值更新他的 MAC 表。该条目将在操作系统确定的一段时间内保留在该表中。

我认为你有一些问题：

A 发送一个目的地址为 FF:FF:FF:FF:FF:FF 的 Arp 广播请求，询问谁有一些“IP 地址”。这个请求到达“IP地址”，这台电脑更新它的arp表并用它自己的MAC发送一个回复。