ping 与 traceroute 大多数人只看了「通不通」，其实 TTL 能反推跳数。 中间跳显示超时不代表断，中间跳延迟高不代表那里慢——两个最常见的误读。
上一节讲时间，这一节讲具体的排查命令。 这一节的价值不在「会用」，在「会读」。
一、ping 的四个字段
字段 说明什么 异常意味着
是否回包 通不通 路由、ACL、或被禁 ping RTT 往返延迟 路径远、拥塞、或排队 TTL 对端初始值减跳数 可反推经过几跳 丢包率 稳定性 链路质量或限速
「被禁 ping」这一项要记住：很多服务器与防火墙默认不回 ICMP， 所以「ping 不通」不等于「服务不可用」。 要判断端口通不通，得用 telnet 或 nc 测端口。
二、用 TTL 反推跳数
不同系统的初始 TTL 不同：Linux 与 macOS 是 64，Windows 是 128，部分网络设备是 255。
所以收到 TTL 等于 57，就能推出「经过 7 跳」（假设对端是 64）。 这是一个不用 traceroute 就能估跳数的办法。
它的用处在于「快速判断远近」：同一个服务从两个地方 ping，TTL 差很多， 说明路径长度差很多——而路径长度往往能解释延迟差异。
三、traceroute 的原理与耗时
它发 TTL 递增的包：第一组 TTL=1，到第一跳就减到 0，那一跳回一个 ICMP 超时； 第二组 TTL=2，到第二跳才超时……于是逐跳把路径画出来。
所以 traceroute 的耗时是「逐跳累加」的， 总时间大致等于「平均 RTT 乘跳数」——这就是它越往后越慢的原因。
顺带一个推论：traceroute 每一跳都要发多个包（通常三个）， 所以它对目标产生的流量是「跳数乘三」——在很长的路径上，这本身就是一个不小的负担。
四、两个最常见的误读
误读一：中间几跳显示星号代表断。 很多设备不回 ICMP 超时（限速或禁用），但只要最后一跳能到，路径就是通的。
误读二：中间某跳 RTT 特别高代表那里慢。 它可能是「回 ICMP 这件事被限速了」，而转发本身是好的。 要看「到最后一跳的累计 RTT」，不是「单跳的差」。
这两个误读的共同根源是「把控制面当成数据面」：回 ICMP 是控制面的事，它的优先级很低； 而转发是数据面的事，优先级很高。 两者被区别对待，读数就不能直接当性能。
五、动手 Demo：ping 与 traceroute，读出来的信息比想象中多
这段列出 ping 四个字段的含义与异常判读，再用三组 TTL 反推跳数， 并按「RTT 乘跳数」算 traceroute 的累计耗时。
for ttl in (57, 50, 43):
P(u" 收到 TTL=%d：约经过 %d 跳。" % (ttl, 64 - ttl))
P(u" 三跳累计约 %d 毫秒。" % (3 * 4))
实跑输出：
--------------------------------------------------------------------
ping 与 traceroute，读出来的信息比想象中多
--------------------------------------------------------------------
**这两个命令人人会用，但大多数人只看了「通不通」。**这一节看它们还能读出什么。
**ping 的四个输出字段各说明什么**：
字段 说明什么 异常意味着
-----------------------------------------------------------------------
是否回包 通不通 不通：路由、ACL、或者被禁 ping
RTT 往返延迟 大：路径远、拥塞、或者排队
TTL 对端初始 TTL 减跳数 可以反推经过几跳
丢包率 稳定性的直观指标 有丢：链路质量或限速
**TTL 那一行值得展开**：不同系统的初始 TTL 不同——
Linux／macOS：初始 64。
Windows：初始 128。
部分网络设备：初始 255。
**所以收到 TTL=57，就能推出「经过 7 跳」**（假设对端是 64）。
**这是一个不用 traceroute 就能估跳数的办法。**
**traceroute 的原理要讲清**：它发 TTL 递增的包，**每一跳把 TTL 减到 0 就回一个 ICMP 超时**，
于是知道了那一跳的地址。
**算一下三跳的时间**：
· 第 1 组 TTL=1 → 第 1 跳回 ICMP
· 第 2 组 TTL=2 → 第 2 跳回 ICMP
· 第 3 组 TTL=3 → 第 3 跳回 ICMP
**所以 traceroute 的耗时是「逐跳累加」的**，
**总时间约等于「RTT 乘跳数」**——这也是为什么它越往后越慢。
**两个常见误读**：
1. **中间几跳显示 `* * *` 不代表断**：**很多设备不回 ICMP 超时**（限速或禁用），
但只要最后一跳能到，路径就是通的。
2. **中间某跳 RTT 特别高不代表那里慢**：**它可能是「回 ICMP 这件事被限速了」**，而转发本身是好的。
**要看「到最后一跳的累计 RTT」，不是「单跳的差」。**
「TTL=57 推出 7 跳」这个技巧要会用但要小心：它假设对端初始值是 64， 如果对端是 Windows（128），57 就要按「128 减 57 等于 71 跳」——明显不合理，这时候说明假设错了，要换一个初始值试。
「中间跳 RTT 高是限速」这一条是最有价值的： 很多人看到某跳 200 毫秒就去找那一跳的设备，结果白找半天。 正确的读法是「看最后一跳的累计值」。
最后「控制面与数据面被区别对待」是这一节的总结： 它解释了 ping 与 traceroute 的所有反常读数， 也解释了为什么「设备 ping 不通但它转发正常」是可能的。
30 秒实验
- 用 ping 一个外网地址，用 TTL 反推跳数。
- 用 traceroute 对比，看反推得对不对。
- 找一台 ping 不通但端口能通的服务器，验证「禁 ping」。
常见误区
- 以为 ping 不通就是服务没起。很多设备禁 ICMP。
- 以为 traceroute 的星号代表断。多数是那一跳不回 ICMP。
- 以为某跳 RTT 高就是那里慢。可能只是回 ICMP 被限速。
自测三问（点开对答案）
1. 收到 TTL 为 57，能推出什么？ —— 若对端初始 TTL 为 64，则经过约 7 跳。 2. traceroute 为什么越往后越慢？ —— 它逐跳累加，总耗时约等于平均 RTT 乘跳数。 3. 中间某跳 RTT 偏高该怀疑什么？ —— 该跳对 ICMP 超时报文做了限速，转发本身可能正常。下一节：排查之后要改配置，改之前先备份。
- ☐ （本节完，下一节 03.07.07 文件传输控制）