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