我最近一直在尝试mtr来解决networking拥塞问题。 以下是示例mtr请求
例1
$ mtr --report -c 10 my.example.com HOST: ansh0l-Lenovo Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0% 10 1.3 5.2 1.3 22.4 8.0 2.|-- 10.10.20.1 0.0% 10 3.9 2.5 1.6 4.6 1.2 3.|-- NSG-Static-*.*.*.* 10.0% 10 7.7 6.7 5.1 10.1 1.5 4.|-- AES-Static-*.*.*.* 10.0% 10 46.3 48.5 46.2 53.8 2.6 5.|-- s38895.sgw.equinix.com 0.0% 10 50.3 47.9 46.1 50.3 1.5 6.|-- 203.83.223.2 0.0% 10 49.0 48.7 47.0 51.1 1.2 7.|-- 203.83.223.23 0.0% 10 47.8 48.1 46.9 50.0 1.0 8.|-- ec2-175-*-*-*.ap-sou 0.0% 10 47.7 49.0 47.6 55.8 2.5 9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
例2
$ mtr --report -c 100 my.example.com HOST: ansh0l-Lenovo Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 2.0% 100 5.5 3.2 1.2 94.6 9.8 2.|-- 10.10.20.1 3.0% 100 4.3 3.9 1.5 160.5 16.3 3.|-- NSG-Static-*.*.*.* 3.0% 100 9.9 8.1 4.3 99.0 9.8 4.|-- AES-Static-*.*.*.* 3.0% 100 48.6 48.9 45.9 137.0 9.4 5.|-- s38895.sgw.equinix.com 5.0% 100 46.7 49.6 45.5 155.6 11.5 6.|-- 203.83.223.2 2.0% 100 52.4 53.0 46.5 213.3 20.8 7.|-- 203.83.223.23 4.0% 100 49.1 50.0 46.2 145.6 11.5 8.|-- ec2-175-*-*-*.ap-sou 5.0% 100 49.3 50.8 46.4 169.6 12.8 9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
问题：
数据包在HOST处丢弃n =专用于HOST n的数据包丢包和？ 假设发送给主机7的数据包将具有与之前相同的跳数，这有多安全？
在示例1中，在主机3和4，数据包丢失相同（10％）。 假设在节点3发生了所有的丢包是否安全？
在例子1中。当主机4有10％的数据包丢失时，下一跳是否也会影响性能？ 如果我在一个中间节点中有10％的数据包丢失，那么它之后的节点也应该经历一些数据包丢失，对吧？
在示例2中，一些节点具有更高的StDev 。 这些应该被解释为不可靠的点吗？
1）数据包在HOST处丢弃n =专用于HOST n的数据包丢包和？
是的，他们是专门为那个主机。 MTR依靠发送一个固定TTL的数据包，并且期望接收到它原来发送的ICMP回声的“超时”ICMP响应，该响应将来自TTL超出的路由器。
假设发送给主机7的数据包将具有与之前相同的跳数，这有多安全？
它是非常安全的，我不能说所有的networking，但它在跳转路线上的exception罕见，期望stream量被路由到多个path – 它可能发生，但它比例外更多的例外。
2）在示例1中，在主机3和4处，丢包率相同（10％）。 假设在节点3处发生了所有的数据包丢失是安全的吗？
不，可能不是。 如果节点3实际上正在丢弃转发数据包，则期望在其后的所有其他跳跃中看到衍生损失（所以在跳5,6,7,8和9上损失大约10％）。
3）在例1中。 当HOST 4出现10％的数据包丢失时，下一跳是否也会影响性能？ 如果我在一个中间节点中有10％的数据包丢失，那么它之后的节点也应该经历一些数据包丢失，对吧？
是的，如果你正在收到真正的数据包丢失。 不幸的是事情要复杂得多。
4）在例2中，有些节点的StDev较高。 这应该被解释为不可靠的点吗？
地铁真的只能给你一个球场的数字。 许多路由器将丢弃ICMP数据包作为服务质量的一部分（icmp对于tcp / udpstream量来说不那么重要）。 其他人可能会延迟交通，或者两者兼而有之。
所有你可以真正说的是，发送路由器应该响应的ICMPstream量可能会导致不可靠的性能，但是对于TCP等其他types的stream量，你不能说同样的情况。
总而言之，如果由于路由器中跳而导致数据包真正丢失到某个特定目的地，那么在未来的跳跃中，您将看到<= loss％。
如果您的目的地跳响应0％损失，您不丢包。
一些路由器故意丢弃它们负责响应的ICMPstream量，因此你可能会得到“额外的损失”。 如果那一跳是进行某种forms的stream量调整，并真正失去交通的事情变得可怕的混乱，因为你不能告诉你有多less损失，你真的有。 相反，你所能做的最好的是从未来的一跳中获得最低的损失百分比，并说明它可能在你看到的损失百分比左右。
简而言之，路由器在处理stream量方面的优先级高于响应0ttl的数据包的优先级。 像mtr和traceroute这样的工具对确定你正在使用的path很有用。 它们对确定该path的性能没有用处。 在我对“美国东西海岸”的networking延迟是多less“典型”的答案中，我更详细地讨论了这个问题。