mtr这是向 google.com 发送的关于 ipv4 和 ipv6 的两份报告的结果
当启用 ipv6 时，我有非常一致的延迟峰值。我禁用了 ipv6，所有的延迟峰值都消失了。我得出的结论是，问题在于 ipv6 报告中丢失 80% 的节点。
我向一位非常有经验的网络工程师展示了这张图，他告诉我这并不表明存在问题。他表示，很可能但不确定，80% 丢失的节点是由于 TTL 为 0 时路由器丢弃 ping 的结果，因为数据包从优化的网络 ASIC 卸载到 CPU 已满。
难道这份报告没有指出问题吗？
（抱歉，屏幕截图，我不再有文本形式）
与 ping 和 Traceroute 类似，mtr 依赖于返回探测数据包超出的 ICMP 时间的中间跃点。
ICMP 处理的优先级非常低，并且通常频率有限。这意味着当您看到 ICMP 消息丢失指示时，您无法可靠地推断出某个跃点上存在一般数据包丢失。相反，如果后续跃点根本没有显示数据包丢失，则您看到的是 ICMP 处理或速率限制，而不是实际的数据包丢失。
这是对这些节点的速率限制。
如果数据包丢失是由拥塞引起的，则直到目的地之前的所有下一跳都会观察到一些数据包丢失。
只需尝试使用：
mtr -i 20 www.google.com