网络丢包，网络延迟？这款神器帮你搞定所有( 二 ) _网络丢包

在大多数情况下，您可以把 MTR 的输出分成三大块。根据配置，第二或第三跳一般都是您的本地 ISP，倒数第二或第三跳一般为您目的主机的ISP 。中间的节点是数据包经过的路由器。
当分析 MTR 的输出时，您需要注意两点：loss 和 latency 。

网络丢包如果在任何一跳上看到 loss 的百分比，这就说明这一跳上可能有问题了。当然，很多服务提供商人为限制 ICMP 发送的速率，这也会导致此问题。那么如何才能指定是人为的限制 ICMP 传输还是确定有丢包的现象？此时需要查看下一跳。如果下一跳没有丢包现象，说明上一条是人为限制的。如下示例：

文章插图
人为限制MTR丢包
在此例中，第4跳发生了丢包现象，但是接下来几条都没任何丢包现象，说明第二跳的丢包是人为限制的。如果在接下来的几条中都有丢包，那就可能是第二跳有问题了。请记住，ICMP 包的速率限制和丢失可能会同时发生。

文章插图
MTR丢包截图
从上面的图中，您可以看从第13跳和第17跳都有 10% 的丢包率，从接下来的几跳都有丢包现象，但是最后15、16跳都是 100% 的丢包率，我们可以猜测到100%的丢包率除了网络糟糕的原因之外还有人为限制 ICMP 。所以，当我们看到不同的丢包率时，通常要以最后几跳为准。
还有很多时候问题是在数据包返回途中发生的。数据包可以成功的到达目的主机，但是返回过程中遇到“困难”了。所以，当问题发生后，我们通常需要收集反方向的 MTR 报告。
此外，互联网设施的维护或短暂的网络拥挤可能会带来短暂的丢包率，当出现短暂的10%丢包率时候，不必担心，应用层的程序会弥补这点损失。

网络延迟除了可以通过MTR报告查看丢包率，我们也还可以看到本地到目的地之间的时延。因为是不通的位置，延迟通常会随着条数的增加而增加。所以，延迟通常取决于节点之间的物理距离和线路质量。

文章插图
MTR查看网络延迟
从上面的MTR报告截图中，我们可以看到从第11跳到12跳的延迟猛增，直接导致了后面的延迟也很大，一般有可能是11跳到12跳属于不同地域，物理距离导致时延猛增，也有可能是第12条的路由器配置不当，或者是线路拥塞。需要具体问题进行具体的分析。
然而，高延迟并不一定意味着当前路由器有问题。延迟很大的原因也有可能是在返回过程中引发的。从这份报告的截图看不到返回的路径，返回的路径可能是完全不同的线路，所以一般需要进行双向MTR测试。
注：ICMP 速率限制也可能会增加延迟，但是一般可以查看最后一条的时间延迟来判断是否是上述情况。

根据MTR结果解决网络问题MTR 报告显示的路由问题大都是暂时性的。很多问题在24小时内都被解决了。大多数情况下，如果您发现了路由问题，ISP 提供商已经监视到并且正在解决中了。当您经历网络问题后，可以选择提醒您的 ISP 提供商。当联系您的提供商时，需要发送一下 MTR 报告和相关的数据。没有有用的数据，提供商是没有办法去解决问题的。
然而大多数情况下，路由问题是比较少见的。比较常见的是因为物理距离太长，或者上网高峰，导致网络变的很慢。尤其是跨越大西洋和太平洋的时候，网络有时候会变的很慢。这种情况下，建议就近接入客户的节点。
来源：
https://cloud.tencent.com/developer/article/1491610