Ping 与 traceroute:路由跟踪原理详解

用 ping 判断通断与延迟,用 traceroute 逐跳看清数据包走过的每一站,读懂延迟从哪里来。

排查服务器网络问题,ping 和 traceroute 是最常用的两把工具。理解它们的工作原理,才能正确判断“慢”和“不通”到底出在哪里。

ping:测通断与 RTT

ping 向目标发送 ICMP Echo Request(回显请求)报文,目标收到后回一个 Echo Reply。工具记录发出到收到的时间差,即 RTT(往返时延),并统计丢包率。

# Linux:默认持续发送,Ctrl+C 停止
ping your-server.example.com
ping -c 4 203.0.113.10        # 只发 4 个包

# Windows:默认发 4 个包
ping your-server.example.com
ping -t 203.0.113.10          # 持续发送,Ctrl+C 停止

重点看三项:是否有 Reply(通不通)、time= 的毫秒数(延迟)、以及末尾的丢包统计。RTT 稳定、丢包为 0,通常说明链路健康。

traceroute:逐跳探路

ping 只告诉你两端之间的整体情况,traceroute 则能揭示数据包途中经过的每一跳(路由器)。

它的核心是 TTL(Time To Live)。IP 报文每经过一台路由器,TTL 减 1;减到 0 时该路由器丢弃报文,并回一个 ICMP Time Exceeded(超时)消息。traceroute 正是利用这一点:

先发 TTL=1 的探测包 → 第一跳路由器回超时,暴露第一跳地址;
再发 TTL=2 → 第二跳暴露;
依次递增,直到到达目标或触及最大跳数。

Linux 与 Windows 的差异

# Linux:默认发 UDP 探测包(部分实现或加 -I 用 ICMP)
traceroute your-server.example.com

# Windows:命令名不同,且默认就用 ICMP Echo 探测
tracert your-server.example.com

差异在于探测包类型:Linux 的 traceroute 默认用 UDP,Windows 的 tracert 用 ICMP。因为中间设备对不同协议的处理策略不同,两者跑出来的路径和延迟可能略有出入。

读懂逐跳输出

每一跳通常显示三个延迟值(默认探测 3 次)和该跳的 IP。看输出时注意几点:

号:表示这次探测没收到回复。可能是该跳配置了不响应、防火墙拦截,或探测包/回包丢失。个别不代表链路断,只要后续跳仍有回应即可。
中间某跳延迟突然很高、后面又降回来:通常不是问题。中间路由器对“回超时消息”这类控制报文常做 ICMP 限速,优先转发正常流量,导致回给 traceroute 的应答被延后。真正要关注的是最后一跳(目标)的延迟,以及从某跳起延迟持续升高且不再回落。
判断丢包:看某跳是否 ,更要看它之后的跳是否也丢——中间跳丢而末跳正常,多半是限速;从某跳起一路都丢,才可能是真故障。

mtr:ping 与 traceroute 的结合

mtr 把两者合二为一:它持续对路径上每一跳发包,实时刷新每跳的丢包率和延迟统计。

mtr your-server.example.com
mtr -r -c 100 your-server.example.com   # 跑 100 轮后输出报告

相比一次性的 traceroute,mtr 靠长时间采样能更可靠地暴露偶发丢包和抖动,是定位线路质量问题的首选。

小结

ping 用 ICMP 测通断与 RTT,快速回答“通不通、快不快”;traceroute/tracert 靠 TTL 递增逐跳揭示路径,Windows 用 ICMP、Linux 默认用 UDP。读输出时, 和中间跳高延迟常源于 ICMP 限速,不必惊慌,重点看末跳延迟和持续性丢包。需要长期观测线路质量时,用 mtr 结合两者的优势。