当前位置: 首页 > news >正文

mtr命令,看完这篇就够用!

先上我最近跑的 MTR 结果截图——这是从我的电脑到微软官网的路由追踪:

说说 MTR 是什么

MTR(My Traceroute)是把pingtraceroute合二为一的工具。比单纯用 traceroute 强不少——traceroute 只给你看一跳的路径,而 MTR 会持续对每一跳发数据包,统计丢包率、延迟、抖动这些关键指标。

表头信息解读

先看最顶部那几行:

xuliat14p (172.30.67.50) -> www.microsoft.com (23.217.78.102)

这行很简单:左边是我的机器主机名和IP,右边是目标域名和解析后的IP。注意这里微软的网站走了 Akamai 的 CDN,所以最终地址是a23-217-78-102.deploy.static.akamaitechnologies.com,这很正常。

右上角是测试时间2026-07-10T14:01:24+0800

再下面一行是快捷键提示:HelpDisplay modeRestart statisticsOrder of fieldsquit。交互式运行时按对应的字母键就能用这些功能。

核心列解释(重点!)

这是核心部分。

列名全称含义
HostHost每一跳的IP地址或主机名
Loss%Packet Loss丢包率,核心指标
SntSent已发送的数据包数量
LastLast最后一个包的延迟
AvgAverage平均延迟
BestBest最好(最小)延迟
WrstWorst最差(最大)延迟
StDevStandard Deviation延迟标准差,反映抖动程度

第一列:Host(路由跳数)

左边的数字是跳数(TTL)。从第1跳开始:

  • 第1跳 172.30.64.1:这是我的网关,本地局域网出口。延迟只有 0.7ms,很健康。
  • 第2跳 10.0.1.1第3跳 10.0.0.1:这两个都是公司内网IP。
  • 第4跳 121.15.204.41:开始进入公网,看IP应该是电信的设备。
  • 第5跳 59.37.186.69:继续公网路由。
  • 第6跳 (waiting for reply):这个设备禁了ICMP,所以看不到IP。这种情况很常见,不用慌——只要后面的跳能通,说明这一跳其实是工作的,只是不回包而已。如果后面能显示,说明做了限速,毕竟公共路由器ICMP响应也是很耗CPU的。
  • 第7-9跳:开始进入国际链路了,IP变成 202.97 开头(电信骨干网),然后是 twelve99.net(Telia Carrier,国际带宽运营商)。这里要特别注意下,第9跳是电信节点,为什么它的延时突然变大了,因为该节点已经在美国了。有些查询工具显示IP是国内,这是不准确的,多对比几个工具。
  • 最后一跳:终于到了 Akamai 的 CDN 节点,就是微软网站实际托管的地方。

第二列:Loss%(丢包率)—— 判断问题的核心

这是最重要的一列。在深入分析之前,先搞懂一个最容易搞错的问题:

Loss% 到底是哪到哪的丢包?

答案:和延迟一样,这个丢包率是你的电脑到这一跳的总丢包率,不是上一跳到这一跳之间的丢包率。

MTR 对每一跳都独立发15个包,每个包设置对应的TTL值:

跳数发送方式丢包率含义
第1跳15个TTL=1的包这15个包里多少个没能到达第1跳
第2跳15个TTL=2的包这15个包里多少个没能到达第2跳
第7跳15个TTL=7的包这15个包里多少个没能到达第7跳

丢包率和延迟一样,都是从你的电脑到这一跳的"累计值"

怎么定位丢包在哪发生的?

方法就是对比前后跳的丢包率变化。看截图数据:

第14跳:0.0% 丢包 (15个包全到了) 第15跳:7.1% 丢包 (15个包里丢了约1个)

这就可以精确判断:这1个包就是在第14跳→第15跳这段路上丢的

因为前13跳0丢包,说明前面的路完全没问题。到第15跳突然少了1个,问题就出在这一跳之间。


划重点:怎么看丢包是不是真问题?

很多人看到第7跳 78.6% 的丢包就吓坏了,以为网炸了。但仔细看——第9跳又恢复了 0% 丢包!这说明什么?

这不是真的网络丢包,而是第7、8跳的设备做了ICMP速率限制。

路由器对 traceroute 用的 ICMP 包通常优先级很低,忙的时候就直接丢了,这叫"控制平面限速"。判断是不是真丢包的方法很简单:

如果后面的跳丢包率比前面低→ 前面的丢包是假的,是设备限速
如果丢包从某一跳开始一直持续到最后→ 这才是真的有问题

在这个例子里,第7跳虽然 78.6% 丢包,但第9跳就完全正常了,说明这就是设备限速导致的假象,不用管。

第三列:Snt(发送包数)

这里每一跳都发了15个包。MTR默认每秒发一个包,所以这大概跑了15秒。

跑的时间越长,数据越准。排查偶发问题时,我一般会跑5分钟以上(Snt到300+),这样统计才有意义。

延迟相关四列:Last、Avg、Best、Wrst

这四列都是毫秒(ms)为单位。

看第1跳的数据:Last=0.6,Avg=0.7,Best=0.6,Wrst=1.9。

这说明什么?局域网非常稳定,最好和最差延迟只差1.3ms。

再看第9跳:Last=153.8,Avg=191.2,Best=141.7,Wrst=389.0。

这里波动就大了——最好141ms,最差接近390ms,差了两倍多。这是国际链路的正常现象,跨海网络波动在所难免。

经验分享:

  • Avg(平均延迟)最有参考价值,反映链路整体质量
  • Wrst - Best的差值越大,说明链路越不稳定
  • Last只看最后一个包,参考价值有限,但可以看趋势

最后一列:StDev(标准差)—— 被忽略的宝藏指标

这一列很多人直接跳过,但其实非常重要。

标准差反映的是延迟的离散程度,也就是抖动(jitter)

  • StDev越小 → 延迟越稳定
  • StDev越大 → 抖动越厉害

看几个例子:

  • 第1跳 StDev=0.3 → 极其稳定
  • 第3跳 StDev=0.2 → 简直完美
  • 第9跳 StDev=79.9 → 抖动非常大,这就是国际链路的特性
  • 第15跳 StDev=3.1 → 虽然有7.1%的丢包,但延迟其实很稳定

为什么抖动比延迟本身更重要?

打游戏、开视频会议、用VoIP的时候,你最怕的不是延迟高,而是时快时慢。100ms固定延迟你可能感觉不到,但上百毫秒的抖动,你就能明显感觉到。

StDev就是量化这个"卡"的程度的指标。

重要补充:Avg 到底是谁到谁的延迟?

这是不少人都会搞错的核心问题,必须单独拎出来说。

答案:Avg显示的是你的电脑到这一跳的总往返延迟(累计RTT),不是上一跳到这一跳之间的单跳延迟。

MTR的TTL递增机制

MTR 是靠逐次增大TTL值来实现追踪的:

跳数TTL设置测量内容
第1跳TTL=1你的电脑 ↔ 网关 的RTT
第2跳TTL=2你的电脑 ↔ 第2跳 的RTT
第3跳TTL=3你的电脑 ↔ 第3跳 的RTT
第4跳TTL=4你的电脑 ↔ 第4跳 的RTT

所以每一行的延迟都是从你的机器开始累计的总时间,越往后越大是正常的。

怎么估算单跳延迟?

用截图数据做真实计算:

第3跳 Avg = 1.3ms (电脑到第3跳总延迟) 第4跳 Avg = 9.7ms (电脑到第4跳总延迟) 第3跳 → 第4跳 单跳延迟 ≈ 9.7 - 1.3 = 8.4ms

注意一个常见现象:后面的跳延迟反而更小

看截图里第5跳 Avg=5.4ms,比第4跳的9.7ms还小,算出负数了!这不是MTR坏了,而是:

  • 不同跳的数据包走的路径可能有细微差异
  • 路由器对ICMP超时包的回复优先级很低,忙的时候就慢
  • 网络状况本身就是波动的

所以单跳延迟只能估算,不能精确计算。MTR的真正价值是看整体趋势,而不是纠结某一跳的具体数值。

这个 MTR 结果告诉我们什么?

综合分析下来,这次到微软官网的网络情况:

  1. 本地网络没问题:前3跳0丢包,延迟个位数
  2. 国际链路正常:虽然中间几跳显示高丢包,但那是ICMP限速,不是真问题
  3. 跨国延迟正常:全程平均200ms左右,跨太平洋链路的正常水平
  4. 轻微抖动:中间几跳抖动较大,但最终节点StDev只有3.1,还算稳定
  5. 终点有7.1%丢包:这个要注意——如果是最后一跳持续丢包,可能是Akamai节点本身或者回程有问题

用 MTR 的几个实用技巧

最后分享几个我平时用 MTR 的心得:

  1. 双向都要测:网络是双向的,A到B好不等于B到A也好。排查问题最好两边都跑 MTR
  2. 跑足够长时间:至少30秒,最好5分钟,数据才靠谱
  3. 不要迷信中间跳的丢包:记住那个判断方法——后面恢复了就是假丢包
  4. --tcp模式更真实:很多运营商封ICMP,用mtr --tcp测TCP端口,结果更接近真实业务情况
  5. --report生成报告mtr --report www.example.com跑完直接输出统计结果,适合截图发运维

总结

MTR 看起来输出复杂,其实核心就是看几件事:

  • 丢包从哪一跳开始?是不是一直持续到最后?
  • 平均延迟是多少?有没有突然暴涨?
  • 抖动(StDev)大不大?

掌握了这三点,90%的网络问题你都能快速定位。下次再遇到网站卡、游戏掉帧、连接超时,先跑个 MTR 看看。

http://www.cnnetsun.cn/news/3278896.html

相关文章:

  • FPGA程序固化实战:Quartus 23.1 转换JIC文件5步避坑指南(含Flash选型)
  • Text2SQL+LangGraph智能体
  • PN结测温电路设计:2N3904/2N3906三极管选型与LTC2991配置实战
  • 零壹教育:打破正则依赖!非结构化文本高效预处理方法总结
  • RTSP 与 RTP/RTCP 实战联调:5步搭建简易流媒体服务器与客户端
  • 用 OAS 光学软件仿真剪切干涉仪
  • OpenCV 4.8 与 ROS Noetic 相机标定实战:3步完成USB摄像头内参获取与验证
  • MIPI DSI 时钟与带宽计算:从800x600@60Hz到4K面板的3个关键公式与实例
  • 为什么是8时18分?皓贝一口腔医院开业时刻的深意
  • 压电陶瓷点火器电气参数全测量:从6.3pF电容到20GΩ绝缘电阻的5项数据
  • JWT 与 Opaque Token 对比:5个维度解析API认证方案选型
  • Gemma 4移动端部署实战:Android原生跑大模型全链路指南
  • 什么是数据库事务?一文搞懂 ACID 四大特性(一)
  • C++实现一维数组主波峰检测算法:从信号处理到工程实践
  • 点对点接口开发6大核心痛点与集成平台式解决方案
  • 3种 PWM 生成方案对比:MCU 硬件定时器 vs 软件模拟 vs 专用 IC
  • LabVIEW 2023 卷积码性能对比:(2,1,5) vs (2,1,7) 在AWGN信道下的3组误码率实测
  • 全球首款80FPS大双屏墨水屏手机 于7月10日开启;Kickstarter 众筹:Big
  • 计算机大数据毕设实战-基于 Python 的抖音时尚女装用户评论舆情系统的设计与实现 基于 Python 的女装抖音评论热度态势分析系统【完整源码+LW+部署说明+演示视频,全bao一条龙等】
  • Java volatile 关键字深度解析:从存储金字塔到L3 Cache的3层缓存一致性
  • 93号文数据安全要求怎么落地?金融机构最难啃的骨头,有解了
  • 红外与热成像图像融合实战:基于 OpenCV 4.8 的 3 种配准算法对比
  • MBTiles vs 文件夹切片:QGIS 3.24.1 两种格式 5 项性能与部署对比
  • 昆仑万维AI大模型技术实践:从多模态生成到企业级部署优化
  • 中央SoC完整原理与车载落地详解
  • Cesium 雷达扫描 3 种方案对比:Entity Wall vs Primitive vs PostProcessStage 性能实测
  • Waterfox:比Firefox更快更隐私?这款开源浏览器,老电脑也能飞起来!
  • 干了多年物流,竟然不知道物流成本还能这么分析!
  • TPA3138D2音频放大器与STM32L041C6的音频系统设计
  • Ubuntu 22.04源码编译CARLA 0.10.0与UE5.0.3深度实践指南