STCP 虽然很早就具备了重复 IP 地址检测功能，但微软 Windows 2008 和 7 系统行为方式的改变却带来了一个有趣的变数。
首先，让我们回顾一下它是如何运作的。
重复IP地址的检测依赖于地址解析协议（ARP）。
packet_monitor 工具将一个 ARP 数据包显示为两行，如下所示：
11:13:43.123 接收以太网数据 目标 ff:ff:ff:ff:ff:ff 源 00:13:d4:59:7a:da 类型 0806 (ARP)
ARP 请求 目标 164.152.77.217 源地址 164.152.77.34 [00:13:d4:59:7a:da]
在哪里
|
STCP 关注 Src 字段，如果该字段与接收该数据包的接口的 IP 地址匹配，则 STCP 会在 syserr_log 中报告一个重复的 IP 地址，消息格式如下：
<time> WARNING (<index>): MAC address <MAC address> is using our IP address <IP address>
例如：
11:13:43 警告(5)：MAC地址 00:13:d4:59:7a:da 正在使用我们的IP地址 164.152.77.34
“MAC”是“媒体访问控制”（Media Access Control）的缩写，了解MAC地址能为你提供有关违规主机身份的一些线索。该地址的前3个字节被称为“组织唯一标识符”（OUI），可用于判断以太网卡或其所在主机的相关信息。 例如，Stratus 两个已注册的 OUI：00-00-A8 和 00-04-FC。您可以在http://standards.ieee.org/develop/regauth/oui/public.html上查询任何 OUI。
许多主机（包括 STCP）在启动时或配置 IP 接口时，会发送所谓的“无因 ARP”。该帧基本上是在查询自身的 IP 地址，如果收到回复，则说明该 IP 地址已被占用。以下是一个 packet_monitor 跟踪记录的示例，显示了另一个 VOS 模块在启动其接口时发送的无因 ARP。请注意， 目标 和 Src 字段都包含相同的 IP 地址。
10:19:53.045 接收以太网数据 目标 ff:ff:ff:ff:ff:ff 源 00:00:a8:41:3b:6e 类型 0806 (ARP)
ARP 请求 目标 164.152.77.34 源 164.152.77.34 [00:00:a8:41:3b:6e]
好的，那么我在本文开头提到的这个“纰漏”究竟是什么呢？
从 Windows 2008 和 Windows 7 开始，Microsoft TCP 协议栈发送的无因 ARP 请求中，Src 字段被设置为 0.0.0.0。
10:45:10.530 接收以太网数据 目标 ff:ff:ff:ff:ff:ff 源 1c:c1:de:b4:76:60 类型 0806 (ARP)
ARP 请求 目标 164.152.77.34 源地址 0.0.0.0 [1c:c1:de:b4:76:60]
结果是，STCP认为这是一个针对其以太网地址的“正常”查询，并返回了正常的响应
10:45:10.530 发送以太网 目标 1c:c1:de:b4:76:60 源 00:00:a8:41:3b:6e 类型 0806 (ARP)
ARP 响应 目标 0.0.0.0 [1c:c1:de:b4:76:60] 源 164.152.77.34 [00:00:a8:41:3b:6e]
它并未记录任何IP地址重复的迹象。好消息是，Windows协议栈能够识别这种重复情况，并将切换到格式为169.254.X.Y的链路本地地址。
微软为何要做出这一改动？似乎许多 TCP 协议栈（包括 STCP）会根据 ARP 帧中包含的以太网地址，更新其源 IP 地址的 ARP 缓存条目。如果该 IP 地址存在重复，由于数据包会被重定向到重复的主机，最终会导致与该重复 IP 地址的现有连接中断。 通过将 Src 字段更改为 0.0.0.0，微软阻止了 TCP 协议栈（包括 STCP）更新其 ARP 缓存条目。