mtr 如何工作/使用 mtr 解釋痛點
我最近一直在嘗試解決
mtr網路擁塞的痛點。以下是範例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問題：
- 主機 n 處的數據包丟棄 = 專門為主機 n 發送的數據包丟棄的總和？假設發送到 HOST 7 的數據包具有相同的先前躍點有多安全？
- 在範例 1 中，在 HOST 3 和 4 處，丟包率相同 (10%)。假設所有封包遺失都發生在節點 3 上是否安全？
- 在範例 1 中。當 HOST 4 的封包遺失 10% 時，下一個躍點是否也應該在性能方面受到影響？如果我在其中一個中間節點有 10% 的封包遺失，那麼它之後的節點也應該會出現一些封包遺失，對吧？
- 在範例 2 中，一些節點具有更高的StDev。這些是否應該被解釋為不可靠點？
- 主機 n 處的數據包丟棄 = 專門為主機 n 發送的數據包丟棄的總和？
是的，它們專門針對該主機。MTR 依賴於發送一個固定 TTL 的數據包，並期望收到一個“時間超過”的 ICMP 響應，它最初發送的 ICMP 回顯將來自 TTL 超過的路由器。
假設發送到 HOST 7 的數據包具有相同的先前躍點有多安全？
它非常安全，我不能代表所有網路，但它在跨跳路由上非常不尋常，期望流量被路由到多個路徑 - 它可能會發生，但它更多的是例外而不是常態。
- 在 Example1 中，在 HOST 3 和 4 處，丟包率相同 (10%)。假設所有封包遺失都發生在節點 3 上是否安全？
不，可能不是。如果節點 3 確實在丟棄轉發的數據包，那麼人們會期望看到此後所有其他躍點的衍生損失（因此在躍點 5、6、7、8 和 9 上大約有 10% 的損失）。
- 在範例 1 中。當 HOST 4 有 10% 的丟包率時，下一個躍點不應該在性能方面也受到影響嗎？如果我在其中一個中間節點有 10% 的封包遺失，那麼它之後的節點也應該會出現一些封包遺失，對吧？
是的，如果您收到真正的丟包。不幸的是，事情比這複雜得多。
4）在Example2中，一些節點有更高的StDev。這些是否應該被解釋為不可靠的點？
mtr 真的只能給你一個大概的數字。許多路由器將丟棄 ICMP 數據包作為服務質量機制的一部分（對它而言，icmp 不如 tcp/udp 流量重要）。其他人可能會延遲交通，或兩者兼而有之。
您真正可以說的是，發送該路由器應響應的 ICMP 流量可能會導致性能不可靠，但您不能說對於 TCP 等其他類型的流量也是如此。
總而言之，如果由於路由器中間躍點導致到特定目的地的數據包真正失去，您將在未來的躍點中看到 <= loss %。
如果您的目標躍點響應為 0% 失去，則說明您沒有丟棄數據包。
一些路由器故意丟棄它們負責響應的 ICMP 流量，因此您可能會在該躍點內獲得“額外損失”。如果該躍點既在執行某種形式的流量整形，又在真正失去流量時，事情就會變得非常混亂，因為您無法判斷自己到底有多少損失。相反，您可以做的最好的事情是從未來的躍點中獲取最低的損失百分比，並聲明它可能在您所看到的損失百分比附近。