诊断 8 分钟阅读

用 Traceroute 理解网络延迟

理解 TTL 跳数原理、为什么有些路由器超时、如何识别运营商边界，以及何时该用 MTR 替代 traceroute。

Traceroute 实际是怎么工作的

Traceroute 利用了 IP 包里的 TTL 字段。它先发一个 TTL=1 的包，第一个路由器把 TTL 减到 0、丢弃、返回 ICMP "Time Exceeded"，里面就有路由器的 IP。然后 TTL=2 到达第二个路由器，以此类推。

所以每一"跳"行只是 TTL 正好在那一段距离归零的那个路由器。路径是推断出来的——协议层没有"把路径给我"这种请求。

把每一跳当作路径看

前几跳几乎一定是本地路由器、运营商接入层、运营商核心层。后面会跨到骨干传输、IXP、CDN PoP，最后才是目标网络。

对路由器 IP 做 whois，或匹配主机名规律，能看出每一跳属于谁。`tier1.network`、`as-XXXX.peer` 这种命名很常见。

traceroute example.com
tracert example.com   # Windows

# 把跳的 IP 反查 ASN：
for IP in $(traceroute -n example.com | awk 'NR>1 {print $2}'); do
  echo -n "$IP -> "; whois $IP | grep -i origin | head -1
done

ICMP / UDP / TCP traceroute

Linux/macOS 的 traceroute 默认用 UDP 探测包；Windows `tracert` 用 ICMP。很多防火墙只放 ICMP 不放 UDP，反过来也有——满屏 `* * *` 不一定是网络死了，可能只是探测包类型被过滤了。

TCP traceroute 用 SYN 包发到真实端口（一般是 80 或 443）。它走的路径更接近真实应用流量，能穿过那些屏蔽 ICMP/UDP traceroute 的防火墙。其他方法都不通时用它。

# UDP（Linux/mac 默认）：
traceroute example.com

# ICMP：
traceroute -I example.com
sudo traceroute -I example.com   # 可能需要权限

# TCP 到 443 端口：
traceroute -T -p 443 example.com

为什么会超时——什么时候该担心

路由器经常限制 ICMP 响应速率，甚至完全不回。某一跳 `* * *` 而后续跳数都正常返回，几乎一定是那台路由器不回包，不是流量在那死了。

真正该担心的：超时持续到路径末尾、某一跳之后延迟一路高、目标完全不响应。

用 ASN 识别运营商边界

延迟突跳通常发生在运营商边界。把每跳映射到 ASN，能看出问题属于哪张网络。同一个 ASN 内突然涨 200ms 是这张网的事；跨 ASN 的跳变可能是传输拥塞或长距离物理链路。

bgp.he.net 或对跳 IP 做 `whois` 都能查到 AS 号。ipconf.me 的 JSON 接口也返回任意 IP 的 ASN。

# 查单个 IP 的 ASN：
curl -s https://ipconf.cn/json/4.2.2.2 | jq .asn

# bgp.he.net（手动查）：
# https://bgp.he.net/ip/4.2.2.2

从多个网络对比

一次 traceroute 只是一个数据点。从家宽、移动数据、不同区域的云 VM 各打一次同一目标。最后 3-5 跳的延迟一致变高，问题在目标侧；某一个接入网络才高的，问题在本地或那个运营商。

想长期对比，可以在每个关心的区域开个便宜 VPS，定时跑 traceroute、记录、把每跳延迟随时间画出来。

MTR 用于持续监控

MTR（My TraceRoute）就是 traceroute + ping 循环。它持续做 trace，按跳聚合丢包率和延迟，比单次快照实用得多。

排查"间歇性慢"时，MTR 能看清是某一跳的问题（那一跳持续丢包）还是端到端问题（只在目标处丢包，上游全部干净）。

# 交互模式：
mtr example.com

# 报告模式（跑 N 轮后退出）：
mtr -r -c 100 example.com

# 强制 TCP（防火墙更友好）：
mtr -T -P 443 example.com