用MTR診斷網絡問題

時間  2019-11-12
標籤 mtr 診斷 網絡 問題 欄目 系統網絡 简体版
原文   原文鏈接

MTR是一個功能強大的工具，使管理員可以診斷和隔離網絡錯誤，並向上遊提供商提供網絡狀態報告。MTR表示的演進traceroute經過提供更大的數據樣本，好像加強命令traceroute與ping輸出。本文深刻介紹了MTR，它產生的數據，以及如何根據它提供的數據得出結論。html

有關網絡診斷技術的基本概述，請參閱咱們的網絡診斷簡介。若是您的系統存在其餘問題，請閱讀咱們的常規系統診斷概述。node

網絡診斷背景

網絡診斷工具包括ping，traceroute和mtr，它們使用Internet控制消息協議（ICMP）數據包來測試Internet上兩點之間的鏈接和傳輸。當用戶在Internet上ping主機時，會向主機發送一系列ICMP數據包，主機經過發送數據包做爲響應。而後，用戶的客戶端可以計算因特網上兩點之間的往返時間。linux

相反，諸如traceroute和MTR之類的工具發送ICMP數據包的TTL遞增，能夠查看數據包在源和目的地之間產生的一系列跳。TTL即生存時間，控制着數據包在「死亡」並返回主機以前將進行多少跳。經過發送一系列數據包並使它們在一跳、兩跳、三跳以後返回，MTR可以分析英特網上不一樣主機之間流量的通路。ios

MTR不是隻提供Internet的路由間的簡單概述，而是收集有關中間主機的狀態，鏈接和響應性的其餘信息。因爲這些附加信息，MTR能夠提供Internet上兩臺主機之間鏈接的完整描述。如下部分概述瞭如何安裝MTR軟件以及如何解釋此工具提供的結果。服務器

安裝MTR

Linux

Debian / Ubuntu網絡

apt update && apt upgrade
apt install mtr-tiny

CentOS/ RHEL / Fedoraide

yum update
yum install mtr

Windows

對於Windows，有一個名爲「WinMTR」的MTR端口。您能夠從WinMTR上游下載此應用程序。工具

蘋果系統

使用Homebrew或MacPorts在macOS上安裝MTR 。要使用Homebrew安裝MTR，請運行：性能

brew install mtr

要使用MacPorts安裝MTR，請運行：測試

port install mtr

生成MTR報告

由於MTR提供了從一個主機到另外一個主機的路由流量的圖像，因此它本質上是一個定向工具。互聯網上兩點之間的路由可能因位置和位於上游的路由器而有很大差別。所以，對於遇到鏈接問題的全部主機，最好雙向收集MTR報告。

Linode客戶支持每每會要求中期審查報告都要以你的Linode爲起點或終點若是你遇到網絡問題。這是由於，當來自相反方向的數據包丟失時，MTR報告有時從一個方向檢測不到錯誤。

在引用MTR報告時，此文檔指的是源主機運行mtr查詢隊列做爲目標主機。

在基於Unix的系統上使用MTR

使用如下語法生成MTR報告：

mtr -rw [destination_host]

例如，要測試到目標主機example.com的流量的路由和鏈接質量：

mtr -rw example.com

能夠從本地計算機運行到您的Linode的MTR報告。替換192.0.2.0爲您的Linode的IP地址：

mtr -rw 192.0.2.0

SSH進入您的Linode並從您的Linode收集MTR到您的家庭網絡的報告。替換198.51.100.0爲家庭網絡的IP地址。

mtr -rw 198.51.100.0

若是您不知道您的家庭IP地址，請使用WhatIsMyIP.com。

若是未檢測到數據包丟失，則技術支持人員可能會要求您以更短的時間間隔運行：

mtr -rwc 50 -i 0.2 -rw 198.51.100.0

在某些系統上，使用此標誌可能須要管理權限：

sudo mtr -rwc 50 -i 0.2 -rw 198.51.100.0

注意r選項標誌生成報告（簡稱--report）。 w選項標誌使用主機名，以便咱們的技術人員和你能夠看到每一跳（簡稱的全名--report-wide）。 c選項標誌設置多少數據包被髮送並記錄在報告中。不使用時，默認值一般爲10，可是對於更快的間隔，您可能須要將其設置爲50或100.執行此操做時，報告可能須要更長時間才能完成。 i選項標誌以更快的速度運行監測是否只在網絡擁塞發生丟包。該標誌指示MTR每n秒發送一個數據包。默認值爲1秒，所以將其設置爲十分之幾秒（0.1,0.2等）一般頗有幫助。

在Windows系統上使用MTR

在Windows上使用GUI運行MTR。打開WinMTR，根據提示在框中鍵入目標主機，而後選擇開始選項以開始生成報告數據。如上所示，您須要使用Linux版本的MTR從您的Linode生成MTR報告。

閱讀MTR報告

因爲MTR報告包含大量信息，所以最初可能難以解釋。如下示例是本地鏈接google.com的報告：

$ mtr --report google.com
HOST: example                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. inner-cake                    0.0%    10    2.8   2.1   1.9   2.8   0.3
  2. outer-cake                    0.0%    10    3.2   2.6   2.4   3.2   0.3
  3. 68.85.118.13                  0.0%    10    9.8  12.2   8.7  18.2   3.0
  4. po-20-ar01.absecon.nj.panjde  0.0%    10   10.2  10.4   8.9  14.2   1.6
  5. be-30-crs01.audubon.nj.panjd  0.0%    10   10.8  12.2  10.1  16.6   1.7
  6. pos-0-12-0-0-ar01.plainfield  0.0%    10   13.4  14.6  12.6  21.6   2.6
  7. pos-0-6-0-0-cr01.newyork.ny.  0.0%    10   15.2  15.3  13.9  18.2   1.3
  8. pos-0-4-0-0-pe01.111eighthav  0.0%    10   16.5  16.2  14.5  19.3   1.3
  9. as15169-3.111eighthave.ny.ib  0.0%    10   16.0  17.1  14.2  27.7   3.9
 10. 72.14.238.232                 0.0%    10   19.1  22.0  13.9  43.3  11.1
 11. 209.85.241.148                0.0%    10   15.1  16.2  14.8  20.2   1.6
 12. lga15s02-in-f104.1e100.net    0.0%    10   15.6  16.9  15.2  20.6   1.7

報告是用mtr --report google.com。生成的。這使用report選項，該選項將10個數據包發送到主機google.com並生成報告。若是沒有--report選項，mtr將在交互式環境中持續運行。交互模式反映了每一個主機的當前往返時間。在大多數狀況下，--report模式以有用的格式提供足夠的數據。

報告中的每一個編號行表明一個躍點。躍點是數據包經過併到達目的地的Internet節點。主機的名稱（例如，示例中的「inner-cake」和「outer-cake」）由反向DNS查找肯定。若是要省略rDNS查找，可使用--no-dns選項，該選項生成相似於如下內容的輸出：

% mtr --no-dns --report google.com
HOST: deleuze                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.1.1                   0.0%    10    2.2   2.2   2.0   2.7   0.2
  2. 68.85.118.13                  0.0%    10    8.6  11.0   8.4  17.8   3.0
  3. 68.86.210.126                 0.0%    10    9.1  12.1   8.5  24.3   5.2
  4. 68.86.208.22                  0.0%    10   12.2  15.1  11.7  23.4   4.4
  5. 68.85.192.86                  0.0%    10   17.2  14.8  13.2  17.2   1.3
  6. 68.86.90.25                   0.0%    10   14.2  16.4  14.2  20.3   1.9
  7. 68.86.86.194                  0.0%    10   17.6  16.8  15.5  18.1   0.9
  8. 75.149.230.194                0.0%    10   15.0  20.1  15.0  33.8   5.6
  9. 72.14.238.232                 0.0%    10   15.6  18.7  14.1  32.8   5.9
 10. 209.85.241.148                0.0%    10   16.3  16.9  14.7  21.2   2.2
 11. 66.249.91.104                 0.0%    10   22.2  18.6  14.2  36.0   6.5

除了簡單地查看數據包到達其主機所使用的服務器之間的路徑以外，MTR還在後面的七列中提供有關該鏈接的持久性的有價值的統計信息。Loss%列顯示每跳的丟包百分比。Snt列計算髮送的數據包數。--report除非指定--report-cycles=[number-of-packets]，不然該選項將發送10個數據包，其中[number-of-packets]表示要發送到遠程主機的數據包總數。

接下來的四列Last，Avg，Best和Wrst以毫秒爲單位測量全部延遲（ms）。Last是最後發送的數據包的延遲，Avg是全部數據包的平均延遲，而Best並Wrst顯示最佳（最短）和最差（最長）往返時間的到該主機的包的時間。在大多數狀況下，average（Avg）列應該是您關注的焦點。

最後一列StDev提供了每一個主機的延遲標準誤差。標準差越大，延遲測量之間的差別越大。標準誤差容許您評估所提供的平均值（平均值）是否表明數據集的真實中心，或者是否因某種現象或測量偏差而偏斜。若是標準誤差很高，則延遲測量值不一致。在對發送的10個數據包的延遲進行平均後，平均值看起來正常但實際上可能不能很好地表示數據。若是標準誤差很高，請查看最佳和最差延遲測量，以確保平均值是實際延遲的良好表示，而不是太大波動的結果。

在大多數狀況下，您可能會想到三個主要部分的MTR輸出。根據配置，前2或3跳一般表明源主機的ISP，而最後2或3跳錶明目標主機的ISP。中間的跳數是數據包遍歷到達目的地的路由器。

例如，若是MTR從您的家用PC運行到您的Linode，則前2或3個躍點屬於您的ISP。最後3個躍點屬於您的Linode所在的數據中心。中間的任何跳都是處於中間媒介的跳。在本地運行MTR時，若是您在源附近的前幾個躍點中看到異常，請聯繫您當地的ISP或調查您的本地網絡配置。相反，若是您在目的地附近看到異常，則可能須要聯繫目標服務器的操做員或該計算機的網絡支持。不幸的是，在中間躍點存在問題的狀況下，兩個服務提供商解決問題的能力都有限。

分析MTR報告

驗證數據包丟失

在分析MTR輸出時，您要尋找兩件事：丟包和延遲。若是您在任何特定跳中看到丟失百分比，則可能表示該特定路由器存在問題。可是，某些ISP一般會對MTR使用的ICMP流量進行速率限制。這可能給出丟包的錯覺然而實際上並無丟包。要肯定您所看到的丟包是真實的仍是因爲速率限制，請查看後續跳。若是後續跳顯示0.0％的丟包，那麼您多是看到ICMP速率限制而非實際丟包：

root@localhost:~# mtr --report www.google.com
HOST: example               Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
2. 63.247.64.157                50.0%    10    0.4   1.0   0.4   6.1   1.8
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9
6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

在這種狀況下，跳1和2之間報告的丟包多是因爲第二跳的速率限制。剩餘8個躍點的流量都到第二跳，但沒有數據包丟失。若是丟失持續超過一跳，則可能存在丟包或路由問題。請記住，速率限制和丟包能夠同時發生。在這種狀況下，將序列中最低的丟包百分比做爲實際丟包：

root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 63.247.74.43                   0.0%    10    0.3   0.6   0.3   1.2   0.3
2. 63.247.64.157                  0.0%    10    0.4   1.0   0.4   6.1   1.8
3. 209.51.130.213                60.0%    10    0.8   2.7   0.8  19.0   5.7
4. aix.pr1.atl.google.com        60.0%    10    6.7   6.8   6.7   6.9   0.1
5. 72.14.233.56                  50.0%   10    7.2   8.3   7.1  16.4   2.9
6. 209.85.254.247                40.0%   10   39.1  39.4  39.1  39.7   0.2
7. 64.233.174.46                 40.0%   10   39.6  40.4  39.4  46.9   2.3
8. gw-in-f147.1e100.net          40.0%   10   39.6  40.5  39.5  46.7   2.2

在這種狀況下，跳2和3之間以及跳3和4之間有60％的丟包。您能夠假設第三跳和第四跳可能會丟失一些流量，由於沒有後續主機報告零丟失。然而，一些丟包是因爲速率限制，由於幾個最終的跳僅經歷了40％的丟包。報告不一樣數量的丟包時，請始終信任後續躍點中的報告。

一些丟包也能夠經過返回路線中的問題來解釋。數據包將毫無錯誤地到達目的地，但很難進行返回。所以，當您遇到問題時，一般最好在兩個方向收集MTR報告。

不要調查或報告鏈接中全部的丟包事件。Internet協議對某些網絡性能降低具備彈性，而且在Internet上傳輸數據的路由可能會因負載、簡短維護事件和其餘路由問題而發生波動。若是您的MTR報告顯示10％左右的少許丟包，則沒有理由去關注，由於應用層將補償這些丟包。

網絡延遲

除了幫助您評估數據包丟失外，MTR還將幫助評估主機與目標主機之間鏈接的延遲。因爲物理約束，延遲老是隨着路由中的跳數而增長。可是，增長應該是線性的。不幸的是，延遲一般是相對的，而且很是依賴於主機鏈接的質量和它們的物理距離。在評估可能存在問題的鏈接的MTR報告時，除了已知給定區域中其餘主機之間的鏈接速度以外，還要關注早期的全部的功能報告。

鏈接質量還可能影響您到特定路由器遇到的延遲量。能夠知道，撥號鏈接比鏈接到同一目的地的電纜調制解調器鏈接具備更高的延遲。如下MTR報告顯示的高延遲：

root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10  388.0 360.4 342.1 396.7   0.2
  5. 72.14.233.56                  0.0%    10  390.6 360.4 342.1 396.7   0.2
  6. 209.85.254.247                0.0%    10  391.6 360.4 342.1 396.7   0.4
  7. 64.233.174.46                 0.0%    10  391.8 360.4 342.1 396.7   2.1
  8. gw-in-f147.1e100.net          0.0%    10  392.0 360.4 342.1 396.7   1.2

延遲量在跳3和4之間顯著增高。這多是網絡延遲問題，由於在第四跳以後往返時間仍然很高。從該報告中能夠知道，配置不良的路由器或擁塞的鏈路是可能緣由，但沒法肯定緣由。

不幸的是，高延遲並不老是意味着當前路線的問題。像上面那樣的報告意味着儘管第4跳出現了某種問題，但流量仍然到達目標主機並返回到源主機。延遲也多是由返回路線問題引發的。您的MTR報告中將不會顯示返回路由，而且數據包能夠採用與特定目的地徹底不一樣的路由。

在上面的示例中，雖然主機3和4之間的延遲有很大的跳躍，但延遲在任何後續跳躍中都不會異常增長。由此能夠合理地假設第4個路由器存在一些問題。

ICMP速率限制還能夠建立延遲的假象，相似於它能夠建立丟包假象的方式：

root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 72.14.233.56                  0.0%    10  254.2 250.3 230.1 263.4   2.9
  6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

乍一看，跳躍4和5之間的延遲引發了人們的注意。然而，在第五跳以後，延遲急劇降低。這裏測量的實際延遲大約是40ms。在這種狀況下，MTR的報告的延遲並無什麼影響。在評估MTR報告時，請考慮最後一跳的延遲。

通用MTR報告

一些網絡問題是新穎的而且須要升級到上游網絡的運營商。可是，有一些常見的MTR報告能夠描述常見的網絡問題。若是您遇到某種網絡問題並想要診斷問題，請考慮如下示例。

目標主機網絡配置不正確

在下一個示例中，因爲路由器配置不正確，彷佛100％丟失了目標主機。乍一看，彷佛數據包沒有到達主機，但事實並不是如此。

root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9
  6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net         100.0    10    0.0   0.0   0.0   0.0   0.0

流量確實到達目標主機。可是，MTR報告顯示丟失，由於目標主機未發送回覆。這多是因爲未正確配置的網絡或防火牆（iptables）規則致使主機丟棄ICMP數據包的結果。

您能夠判斷丟失是因爲配置錯誤的主機形成的，就是查看顯示100％丟失的跳數。從之前的報告中，您能夠看到這是最後一跳，而且MTR不會嘗試額外的躍點。雖然沒有基線測量很難找到這個問題，但這類錯誤很常見。

住宅或商業路由器

住宅網關有時會致使誤導性報告：

% mtr --no-dns --report google.com
HOST: deleuze                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.1.1                   0.0%    10    2.2   2.2   2.0   2.7   0.2
  2. ???                          100.0    10    8.6  11.0   8.4  17.8   3.0
  3. 68.86.210.126                 0.0%    10    9.1  12.1   8.5  24.3   5.2
  4. 68.86.208.22                  0.0%    10   12.2  15.1  11.7  23.4   4.4
  5. 68.85.192.86                  0.0%    10   17.2  14.8  13.2  17.2   1.3
  6. 68.86.90.25                   0.0%    10   14.2  16.4  14.2  20.3   1.9
  7. 68.86.86.194                  0.0%    10   17.6  16.8  15.5  18.1   0.9
  8. 75.149.230.194                0.0%    10   15.0  20.1  15.0  33.8   5.6
  9. 72.14.238.232                 0.0%    10   15.6  18.7  14.1  32.8   5.9
 10. 209.85.241.148                0.0%    10   16.3  16.9  14.7  21.2   2.2
 11. 66.249.91.104                 0.0%    10   22.2  18.6  14.2  36.0   6.5

第二跳報告的100％損失並不表示存在問題。您能夠看到後續躍點沒有丟失。

未正確配置ISP路由器

有時，您的數據包所使用的路由上的路由器配置錯誤，您的數據包可能永遠沒法到達目的地：

root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  6. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  7. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  8. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  9. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
 10. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0

當沒有其餘路線信息時，會出現問號。有時，配置不當的路由器會在循環中發送數據包。您能夠在如下示例中看到：

root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  6. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  7. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  8. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  9. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
 10. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
 11. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
 12. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
 13. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
 14. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0

這些報告顯示第4跳路由器未正確配置。發生這些狀況時，解決問題的惟一方法是聯繫源主機上的網絡管理員的操做員團隊。

ICMP速率限制

ICMP速率限制可能致使明顯的數據包丟失。若是丟包到一個跳不會持續到後續跳，則丟失是由ICMP限制引發的。請參閱如下示例：

root@localhost:~# mtr --report www.google.com
 HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
   1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
   2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
   3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
   4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
   5. 72.14.233.56                 60.0%    10   27.2  25.3  23.1  26.4   2.9
   6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
   7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
   8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

本報告不會引發關注。速率限制是一種常見作法，它能夠減小擁塞，優先處理更重要的流量。

超時

超時可能因爲各類緣由而發生。有些路由器將丟棄ICMP，缺乏的回覆將在輸出中顯示爲超時（???）。或者，返回路線可能存在問題：

root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. ???                           0.0%    10    7.2   8.3   7.1  16.4   2.9
  6. ???                           0.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

超時不必定表示數據包丟失。數據包仍然能夠到達目的地，而不會出現明顯的丟包或延遲 超時可能歸因於路由器爲了QoS（服務質量）目的而丟棄數據包，或者致使超時的返回路由可能存在一些問題。這是另外一個誤報。

先進的MTR技術

較新版本的MTR可以在指定的TCP端口上以TCP模式運行，而不是ICMP（ping）協議。在某些狀況下，網絡性能降低可能只限於特定端口，它們多是因爲配置不正當的防火牆規則或者特定路由器禁用特定端口所致使的。在某個端口上運行MTR可能會顯示丟包，而默認的ICMP報告可能沒有。

在TCP模式下運行MTR在大多數機器上須要具備sudo權限：

sudo mtr -P 80 -i 0.5 -rwc 50 example.com
sudo mtr -P 22 -i 0.5 -rwc 50 example.com

解決您的MTR報告中肯定的路由和網絡問題

MTR報告顯示的大多數路由問題都是暫時的。大多數問題將在24小時內自行解決。在大多數狀況下，當您可以發現路由問題時，Internet服務提供商的監控已經報告了問題，管理員正在努力解決問題。若是您在較長時間內遇到服務質量降低，您能夠選擇向提供商提醒您遇到的問題。聯繫服務提供商時，請發送MTR報告以及您可能擁有的任何其餘相關數據。沒有可用的數據，提供商沒法驗證或修復問題。

雖然路由錯誤和問題佔網絡速度問題的必定的百分比，但它們毫不是下降性能的惟一緣由。網絡擁塞，特別是在高峯時段的長距離傳輸，可能會變得嚴重。跨大西洋和跨太平洋的網絡波動可能變化很大，而且受到通常網絡擁塞的影響。在這些狀況下，建議您將主機和資源定位在儘量靠近目標受衆的地理位置。

若是您遇到鏈接問題且沒法解釋您的MTR報告，請打開支持服務單。在Linode Manager的「支持」選項卡中提交報告的輸出，咱們的技術人員能夠幫助您分析問題。

更多信息

有關此主題的其餘信息，您可能須要參考如下資源。雖然提供這些是但願它們有用，但請注意，咱們沒法保證外部託管材料的準確性或時效性。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程