顺藤摸瓜：Traceroute 到底是怎么工作的？
你在排查网络故障时，大概率用过这个命令：在终端敲下 traceroute baidu.com（Windows 上是 tracert），然后屏幕上便开始一行行地跳出 IP 地址和延迟。
看着这一行行数字，就像是一场网络世界的“沿途打卡”，清晰地记录了你的数据包从电脑出发，跨越千山万水到达目的地的全过程。
但你有没有想过一个问题： IP 协议本来是一个“只管发、不管中间过程”的无连接协议，沿途的路由器也只会默默帮你转发数据包，从来不会主动告诉别人自己是谁。Traceroute 凭什么能把沿途所有的路由器一个不漏地“揪”出来？
今天，我们就来揭开这个网络世界“借力打力”的神奇探秘工具。
一、 核心秘密武器：TTL（生存时间）
Traceroute 的整个工作原理，核心就围绕着 IPv4 报文头部的一个关键字段——TTL（Time to Live，生存时间）。
很多人一看到“Time to Live”，以为它代表的是时间（比如几秒钟）。其实不然，在网络包里，TTL 是一个整数（最大 255），代表这个数据包还能被转发多少次（也就是最多能跳过多少个路由器）。
当你的电脑发送一个数据包时：
- 你可以给这个包设定一个初始 TTL（比如设为 1）。
- 数据包每经过一个路由器（行业里叫一“跳” / Hop），负责转发的路由器就会把 TTL 的值减 1。
- 关键点来了：如果某个路由器把 TTL 减到了 0，它就会认为这个包已经迷路、在网络里死循环了。于是，这个路由器会无情地把这个包丢弃，并顺便给源头（你的电脑）回一封信。
- 这封“回信”是一个 ICMP 差错报文，专业术语叫 “超时（Time Exceeded，类型 11）”。在这封回信里，会大方地写上：“我是哪个路由器，我在这里把包销毁的”（带上该路由器的 IP 地址）。
Traceroute 就是利用这个机制，像“打桩”一样把沿途的路由器一个个逼问出来的。
二、 Traceroute 的具体工作流程
Traceroute 并不是一下子就能查出所有路径的，它是一个步步为营、逐个探测的过程：
- 第一步：探测第 1 跳（离你最近的网关，如家里的路由器或光猫）
- Traceroute 发送一个探测包，把 TTL 设为 1。
- 包刚到达你家里的路由器，路由器一看：“哎，TTL 是 1，减 1 之后变成 0 了！”
- 路由器丢弃该包，并给你的电脑回了一封 ICMP 超时信。
- 你的电脑收到回信，一看发信人的 IP，记录下来：“哦，第一跳是 192.168.1.1，耗时 2ms。”
- 第二步：探测第 2 跳（运营商的汇聚路由器）
- Traceroute 把 TTL 设为 2，再次发送探测包。
- 第一个路由器收到后，TTL 减 1 变成 1，没到期，它把包转发给第二个路由器。
- 第二个路由器收到后，TTL 减 1 变成 0，超期！
- 第二个路由器丢弃包，并回信：“我是 10.0.0.1。”
- 你的电脑记录下第二跳。
- 第 3、4、5 步……（以此类推）
- Traceroute 每次把 TTL 加 1（TTL = 3, 4, 5……），直到这个数据包成功抵达真正的目的地。
- 当数据包到达终点（例如百度服务器）时，终点服务器发现：“诶？这是发给我的包呀！”由于没有超时，它不会回超时信，而是会根据你发的协议类型回应一个“端口不可达”或者“Ping 响应”。
- Traceroute 收到终点的回信，就知道：“全剧终，目的地到了。”
三、 细节：UDP 还是 ICMP？
早期的 Traceroute（在 Unix/Linux 系统中默认）使用的是 UDP 协议：
- 它向目标主机的一个极不可能开放的高位端口（例如 33434 开始的端口）发送 UDP 数据包。
- 这样当包最终到达目的地时，目的主机由于找不到对应服务的端口，会回一个“ICMP 端口不可达”的包，Traceroute 看到这个回信就知道“到终点了”。
而在 Windows 的 tracert 中，默认使用的是 ICMP 协议（发送 ICMP Echo Request，也就是 Ping 请求）。
在现代网络中，为了穿透防火墙，很多高级的网络诊断工具甚至支持发送 TCP SYN 包来追踪，因为很多防火墙会过滤 UDP/ICMP，但对网页常用的 TCP 80/443 端口通常会网开一面。
四、 为什么有些路由会显示 * * *（超时无响应）？
你在跑 Traceroute 时，经常会看到某一行全是星号 * * *。这并不意味着这段网络断了，通常是由以下原因造成的：
- 安全策略（ICMP 限速或禁 Ping）： 大量的路由器（特别是运营商骨干网的路由器、防火墙）为了防止被 DDoS 攻击或出于隐私考虑，故意设置了不回复 ICMP 超时报文。包其实顺利通过了，但路由器选择“默默无闻，不回信”，所以 Traceroute 拿不到它的 IP。
- 中间设备性能或丢包： 确实发生了偶发性丢包，或者该路由器太忙来不及回信。
- 去程和回程路径不对称： 互联网极其庞大，去的时候走 A 路线，回的时候走 B 路线，导致统计数据出现偏差。
总结
Traceroute 的工作原理堪称计算机网络里“借力打力”的经典范本：
- 它不强求沿途的路由器主动配合。
- 它故意制造“TTL 超时”的错误，利用路由器“大公无私”回传的 ICMP 超时错误包，顺藤摸瓜地把每一跳的 IP 地址和延迟记录下来。
就像是在黑暗的迷宫里，你不断扔出倒计时不同的探测器，根据爆炸时传回的回音（ICMP 超时信），精准定位出沿途到底站了多少个岗哨。掌握了它的原理，下次网络卡顿时，你就能一眼看出究竟是卡在家里的路由器，还是卡在运营商的骨干网了。
评论
发表评论