当 Ping 命令后,背后发生了什么?( 二 )


上面的请求过程我画成流程图比较直观一点:

当 Ping 命令后,背后发生了什么?

文章插图
观察仔细的朋友可能已经发现 , Ping 4次请求和响应结束后 , 还有一次 B电脑对 A电脑的 ARP请求 , 这是为什么呢?这里我猜测应该是有 2个原因:
  • 由于 ARP有缓存机制 , 为了防止ARP过期 , 结束后重新更新下ARP缓存 , 保证下次请求能去往正确的路径 , 如果ARP过期就会导致出现一次错误 , 从而影响测试准确性 。
  • 由于 ping命令的响应时间是根据请求包和响应包的时间戳计算出来的 , 所以一次 ARP过程也是会消耗时间 。这里提前缓存最新的ARP结果就是节省了下次pingARP时间 。
为了验证我们的猜测 , 我再进行一次 ping操作 , 抓包看看是不是和我们猜测的一样 。此时 , 计算机里面已经有了ARP的缓存 , 我们执行ARP-a看看缓存的arp列表:
当 Ping 命令后,背后发生了什么?

文章插图
我们看看第二次 ping的抓包
当 Ping 命令后,背后发生了什么?

文章插图
我们看到上图中在真正 ping之前并没有进行一次ARP请求 , 这也就是说 , 直接拿了缓存中的ARP来执行了 , 另外当 B计算机进行响应之前还是进行了一次ARP请求 , 它还是要确认下之前的ARP缓存是否为正确的 。然后结束ping操作之后 , 同样再发一次ARP请求 , 更新下自己的ARP缓存 。这里和我们的猜想基本一致 。
弄懂了 ping的流程之后我们来解析下之前解释的ICMP数据结果是否和抓包的一致 。我们来点击一个ping request看看ICMP协议详情
当 Ping 命令后,背后发生了什么?

文章插图
图中红框内就行 ICMP协议的详情了 , 这里的Type=8,code=0, 校验是正确 , 且这是一个请求报文 。我们再点击Responseframe:57 , 这里说明响应报文在序号57 。详情如下:
当 Ping 命令后,背后发生了什么?

文章插图
上图的响应报文 ,  Type=0,code=0 , 这里知道就是响应报文了 , 然后最后就是根据请求和响应的时间戳计算出来的响应延迟 。3379.764ms-3376.890ms=2.874ms
04 总结
我们分析了一次完整的 ping请求过程 , ping命令是依托于ICMP协议的 , ICMP协议的存在就是为了更高效的转发 IP数据报和提高交付成功的机会 。ping命令除了依托于ICMP , 在局域网下还要借助于ARP协议 , ARP协议能根据 IP地址反查出计算机的 MAC地址 。另外ARP是有缓存的 , 为了保证ARP的准确性 , 计算机会更新ARP缓存 。




推荐阅读