traceroute 发送 IPv4 TTL 或 IPv6 Hop Limit 逐步递增的探测包。数值耗尽处的路由器可以返回超时消息，从而显示去程路径上部分会响应的节点。
故障排除 · 第 3 课
traceroute
了解 traceroute 如何发现作出响应的跳点，以及如何解读缺口、时延和路径变化。
跳点发现的工作方式
探测从跳数限制 1 开始逐步增加。第一台路由器将数值从 1 减到 0，并可以返回 ICMP 错误。限制为 2 时，探测会到达第二台路由器后才过期。此过程持续到目的地响应或达到最大值。
哪个字段使连续探测包在越来越远的路由器处过期？
探测方法
传统 Linux traceroute 通常向较高的目的端口发送 UDP 探测包。目的地可以用 ICMP 端口不可达消息表示探测完成。选项也可改用 ICMP 回显或 TCP SYN 探测，它们穿过过滤规则的效果可能不同：
$ traceroute -n example.com
$ traceroute -I -n example.com
$ traceroute -T -p 443 -n example.com
所需权限和支持的选项因实现而异。只对获准目标采用相应方法，并在比较结果时记录使用的探测方法。
传统 Linux UDP traceroute 通常由什么响应结束？
解读星号
星号表示在超时前没有观察到该探测包的响应。路由器可能继续转发过境流量，却过滤诊断响应或限制其速率。如果后续跳点作出响应，那么沉默的跳点显然至少转发了部分探测包。
某一跳的 * 能证明什么？
时延与路径变化
每跳时间测量的是到控制响应的往返时间，并不是相邻两行之间链路增加的时延。路由器可能降低控制平面响应的优先级；负载均衡可能让各探测包走不同路径；名称解析还可能增加显示延迟，而 -n 可以避免反向查询。
每个 ICMP 响应的返回路径也可能与去程路径不同。在认定瓶颈之前，应重复测试，并与端点应用程序的计时互相印证。
为什么不能把相邻跳点的 RTT 相减，当作准确的链路延迟？
与应用程序比较
traceroute 可以到达目的地而服务仍被阻止；服务也可能正常工作，而中间路由器隐藏自己的响应。请测试与应用程序相同的地址族、目的地、传输协议和端口，再把 traceroute 作为辅助路径证据。
一次完成的 traceroute 能证明 HTTPS 服务健康吗？
课程已完成
你已完成 traceroute
现在，你可以把 traceroute 解读为一系列跳数有界的探测，而不是无所不知的完整路径工具。
解释如何通过 TTL 或 Hop Limit 过期发现跳点。
记录使用的是 UDP、ICMP 还是 TCP 探测。
把星号视为响应缺失，而不是已经证实的中断。
不要从相邻跳点的 RTT 推导准确链路延迟。
将路径证据与实际应用程序相互印证。