关于APIPA实现机制、候选地址选择逻辑及算法确定性的技术问询

嘿，这个问题问到点子上了，我来给你拆解清楚：

一、APIPA的核心实现流程 #

APIPA（自动专用IP寻址）是设备无法通过DHCP获取有效IP时的 fallback 方案，主流系统（比如Windows、部分Linux发行版）都支持，核心步骤是这样的：

• 触发时机：当设备连续几次DHCP请求都没收到服务器回应时，就会自动切换到APIPA模式。
• 地址探测：先从169.254.1.0到169.254.254.255这个可用区间里挑一个候选地址（排除网段首尾的保留地址，比如169.254.0.0和169.254.255.255），然后发送ARP请求到局域网，确认这个地址有没有被其他设备占用。
• 冲突重试：如果收到ARP回应，说明地址被占，立刻换一个新候选地址重新探测；要是连续碰到10次冲突，设备会暂停尝试，每隔5分钟再重新发起探测。
• 地址维护：成功拿到地址后，设备会每隔10分钟发一次ARP请求，确保自己的地址没被其他后来的设备抢占。

二、候选地址的选择逻辑 #

早期的APIPA实现是基于伪随机算法选地址的：它会把设备的MAC地址、系统启动时间这类唯一且可变的参数作为随机种子，再通过算法映射到169.254网段的可用区间里。
举个实际例子：Windows系统里，会用MAC地址的后32位，加上系统启动后的毫秒数，经过哈希运算后得到一个数值，再转化为符合网段要求的IP地址。

三、关于算法的确定性：不是真·非确定性 #

日本维基提到的“非決定論的”，其实是站在外部观察者的角度——你没法直接预判它会选哪个地址，但从技术底层来说，它不是真正的非确定性算法，而是伪随机：

• 只要输入的种子参数（MAC地址、启动时间等）完全一致，生成的候选地址就是固定的；
• 只有当这些参数变化（比如设备重启、更换网卡），或者网络里有其他设备占用了候选地址时，才会出现不同的结果。

简单说，它看起来“随机”，但背后是有确定逻辑的，不是完全无迹可寻的真随机。

备注：内容来源于stack exchange，提问作者Taro