我目前正试图让我的头更多的高级networking概念。 我这样做的方法是通过将我所关注的服务器之一作为系统pipe理员，并运行networking捕获来查看和理解数据。 （我运行此捕获的机器是serveriamon.networkname.local，IP为172.16.2.7）
这导致我在networking上进行这种交stream：
1127 11:46:55 12/10/2012 30.2960887 172.16.3.30 serveriamon.networkname.local ARP ARP:Request, 172.16.3.30 asks for 172.16.2.7 1128 11:46:55 12/10/2012 30.2961939 serveriamon.networkname.local 172.16.3.30 ARP ARP:Response, 172.16.2.7 at 78-2B-CB-23-8D-07 我可以理解这个交stream。 机器在172.16.3.30想要找出MAC为172.16.2.7的地方和什么。 该地址处的服务器（此服务器）以包含Mac地址的ARP响应进行回复。
之后立即发生这个框架：
1129 11:46:55 12/10/2012 30.2964210 172.16.3.30 serveriamon.networkname.local SNTP SNTP:NTPv3 Request, Leap = 0, Mode = 3, RID = 5154 {SNTP:377, UDP:376, IPv4:375}
这我理解是在服务器上的时间的请求。 没关系。 下一个框架是让我感到困惑的是：
1130 11:46:55 12/10/2012 30.2972641 serveriamon.networkname.local 172.16.3.30 ARP ARP:Request, 172.16.2.7 asks for 172.16.3.30
在SNTP请求中的帧1129中embedded的是源地址。 为什么服务器立即进行广播以找出IP地址在哪里？
我怀疑我只是误解这是如何运作，但我真的很感兴趣。 当它已经有了这些信息的时候，发出一个ARP似乎是“浪费”和“嘈杂”的？
这是一个有趣的观察，我从来没有注意过。 这种行为表明，当服务器获取arp请求时，不会将硬件地址放入其arp表中。 这是什么types的操作系统？
最初的ARP RFC 826对于“合并标志”提到了一点点：
“注意，在操作码被查看之前，三元组被合并到表中，这是假定通信是双向的;如果A有理由与B对话，那么B可能有一些理由与A对话。
我很难find有关合并标志的更多信息。
猜测这种行为的原因：
我猜你可能会这样做的一个原因是为了防止有人溢出你的ARPcaching。 换句话说，“为了安全起见，如果我要求 ，我只会caching这个”。
否则，人们可能会用很多不同的IP来制作一堆ARP请求并填满表格（可能有许多其他的方法可以防止这种情况发生，但这似乎是一种简单的方法）。