摘要

  • RFC 3074 让协作中的 DHCP 服务器根据客户端标识和预先配置的 256 桶位图，各自在本地作出一致的应答判断。
  • 哈希划分的是“谁可以答”，不是观测到的工作量。未分配的桶可能让请求沉默；延时应答只是等待后的另一种尝试，不是租约交付证明。

分配应答权，不是安装实时负载计

DHCP 广播可能同时到达多台服务器。2001 年发布的 RFC 3074 试图减少重复应答，又不要求修改客户端：每台服务器对同一事务计算同一种哈希，结果落在自身 Hash Bucket Assignment（HBA，哈希桶分配）中的服务器才回应。

哈希输入优先取 DHCP 的 Client Identifier 选项；若没有该选项，就使用硬件地址长度字段和客户端硬件地址，最多取前 16 个字节。Pearson 哈希把输入映射到 256 个值。32 字节位图指出服务器能处理哪些桶；BOOTP 中继也可以把桶范围映射到服务器标识，再按映射转发请求。

它把每个请求都要协商的问题，改成启动时的一次配置。这个点子最初是 DHCP Failover 草案的一项负载优化，随后扩展到互相协作的服务器和 BOOTP 中继。承诺很克制：服务器无需逐请求交换信息，客户端也无需改变协议行为。

配置里写出的百分比不是 CPU 使用率、地址池压力、响应时间或成功分配量的实时读数。RFC 明说，短时间内实际比例可能偏离目标，随着请求数量增多才趋近配置比例。这描述的是一段时间内客户端事务的分布，并不说明每笔事务成本相同，更不意味着各服务器承担了等量工作。

没有归属者的桶，可能就是沉默

最重要的边界不在哈希公式，而在位图。RFC 3074 指出，映射到未分配数值的事务可能被完全忽略；在某些情形下，这还可能是有意为之。换言之，沉默既可能是配置策略，也可能是丢包。

可选的 Delayed Service 参数给了另一台服务器一个等待计时器：原本不应服务该请求的服务器，可以在客户端等待一段时间后再回应。这不是在线仲裁，也不能证明指定服务器已经故障。规范还允许实现考虑目标服务器不可用或没有合适地址的情况，但并未把恢复结果保证给所有实现。

中继模式让链条更清楚：中继可以把一个桶送往单台服务器，也可以送到使用另一套 failover 机制的主备组合。服务器选择、报文转发、租约状态、客户端最终使用地址，是不同步骤。RFC 3074规定了选择方法，却没有把位图变成共享租约数据库或端到端收据。

IETF Datatracker 目前仍将 RFC 3074 列作 Proposed Standard。这是标准流程中的文件状态，不是当代部署证据。2017 年的 RFC 8156 则定义了 DHCPv6 failover，让两台服务器能在故障或网络分区后接管客户端租约。它可用于对照，却不能据此说 RFC 3074 已被更新或广泛采用。

Heng Lu 后来的“现实层次”笔记在此只是编辑分析视角，并非 DHCP 证据：书面规则、运营者配置、服务器实际执行和客户端得到的结果应分别核验。RFC 3074 的历史贡献因此很明确：它让“谁有资格回应”可被计算，却没有让服务结果自动自证。

来源