7. 为何如此设计 (Why)

周期性广播显然是不可取的. 设想一条以太网上有 100 台工作站, 每台每 10 分钟广播一次地址解析信息 (作为一组可能的参数). 这相当于每 6 秒一个数据包. 这几乎是合理的, 但有什么用呢? 工作站通常不会相互通信 (因此表中会有 100 个无用条目); 它们主要与主机, 文件服务器或网桥通信, 只与少数其他工作站通信 (例如用于交互式会话). 本文描述的协议按需分发信息, 且每次机器启动可能只需一次.

此格式不允许在同一数据包中完成多个解析. 这是为了简单起见. 如果进行多路复用, 数据包格式将难以解析, 且大量信息可能是多余的. 试想一个使用四种协议的网桥向工作站告知所有四个协议地址, 而工作站可能永远不会使用其中三个.

此格式允许在生成回复时重用数据包缓冲区; 回复与请求长度相同, 且多个字段相同.

硬件字段 (ar$hrd) 的值取自专用列表. 目前唯一定义的值是 10Mbit 以太网 (ares_hrd$Ethernet = 1). 已有讨论将此协议用于分组无线网络 (Packet Radio Network), 这将需要另一个值, 未来希望使用此协议的其他硬件介质也同样如此.

对于 10Mbit 以太网, 协议字段 (ar$pro) 的值取自 ether_type$ 集合. 这是对已分配协议类型的自然复用. 将其与操作码 (ar$op) 合并将有效地将此协议下可解析的协议数量减半, 并使监控/调试器更加复杂 (见下文网络监控与调试). 希望我们永远不会看到 32768 种协议, 但墨菲定律告诉我们不能做此假设.

理论上, 长度字段 (ar$hln 和 ar$pln) 是冗余的, 因为协议地址的长度应由硬件类型 (ar$hrd) 和协议类型 (ar$pro) 确定. 包含它们是为了可选的一致性检查以及网络监控和调试 (见下文).

操作码用于确定这是一个请求 (可能引发回复) 还是对先前请求的回复. 16 位对此来说过于充裕, 但确实需要一个标志 (字段).

发送方硬件地址和发送方协议地址是绝对必要的. 正是这些字段被放入转换表.

目标协议地址在请求形式的数据包中是必要的, 以便机器确定是否将发送方信息录入表中或发送回复. 如果假设回复仅由请求触发, 则在回复形式中不一定需要. 包含它是为了完整性, 网络监控, 以及简化上述建议的处理算法 (该算法在将发送方信息放入表之后才查看操作码).

目标硬件地址包含在内是为了完整性和网络监控. 它在请求形式中没有意义, 因为这正是机器正在请求的数字. 它在回复形式中的含义是发出请求的机器的地址. 在某些实现中 (例如无法访问 14 字节以太网头的实现), 通过将此字段作为数据包的硬件目标地址发送给硬件驱动程序, 可以节省一些寄存器操作或栈空间.

地址之间没有填充字节. 数据包数据应视为字节流, 其中只有 3 个字节对被定义为字 (ar$hrd, ar$pro 和 ar$op), 以最高有效字节优先 (Ethernet/PDP-10 字节风格) 发送.