mtr vs traceroute

Traceroute і mtr - це інструменти командного рядка для діагностики проблем з мережевими шляхами. Traceroute робить одноразовий знімок маршруту проходження ваших пакетів. mtr робить те ж саме, але продовжує дослідження, збираючи статистику про втрату пакетів, затримки і джиттер з плином часу. У цій статті ви дізнаєтеся, як працює кожен інструмент, як читати результати і коли їх використовувати.

Як працює traceroute

Traceroute використовує поле Time-to-Live (TTL) в заголовках IP-пакетів. Він надсилає пакет із значенням TTL, рівним 1. Перший маршрутизатор зменшує TTL до нуля, відкидає пакет і надсилає назад ICMP-повідомлення "Час вичерпано". Traceroute записує IP-адресу маршрутизатора і час в обидва кінці, потім надсилає ще один пакет з TTL, встановленим на 2, і так до тих пір, поки пакет не досягне місця призначення або не досягне максимального ліміту пересилання (30 за замовчуванням, регулюється за допомогою -m).

За замовчуванням traceroute надсилає три зонди за одне пересилання, що дає вам три значення затримки. Протоколи відрізняються залежно від ОС:

• Windows: Команда tracert надсилає ехо-запити ICMP.
• Linux/macOS: команда traceroute надсилає дейтаграми UDP (порти 33434-33534). Використовуйте -I для ICMP або -T для TCP, якщо UDP заблоковано.

Додавання прапорця -n пропускає зворотний пошук DNS, що помітно прискорює роботу на шляхах з великою кількістю переходів.

Як працює mtr

mtr (My Traceroute) використовує той самий метод виявлення шляху на основі TTL, що і traceroute, але він продовжує надсилати зонди, як правило, по одному в секунду. Замість трьох точок даних за крок, ви отримуєте поточну статистику: відсоток втрат пакетів, середню затримку, найкращий і найгірший час відгуку, а також стандартне відхилення (джиттер).

mtr підтримує ICMP (за замовчуванням), UDP і TCP SYN-зонди. Режим TCP корисний, коли брандмауери блокують ICMP, або коли ви хочете протестувати певний порт програми:

mtr --tcp --port 443 example.com

Для отримання неінтерактивного звіту, яким ви можете поділитися з командою підтримки, використовуйте режим звіту:

mtr --report --report-cycles 100 example.com

У цьому режимі виконується 100 тестів і друкується звіт. Ви також можете встановити власні розміри пакунків за допомогою --psize для тестування на наявність проблем з MTU або фрагментацією.

mtr виконується нативно на Linux і macOS. Користувачі Windows можуть скористатися WinMTR для отримання еквівалента з графічним інтерфейсом.

Основні відмінності

Практична різниця зводиться до переривчастих проблем. Один трасування може легко пропустити маршрутизатор, який втрачає 2% пакетів, або стрибок з джиттером 15 мс. mtr ловить їх, тому що він продовжує вимірювати.

Читання вихідних даних

Найпоширенішою помилкою при читанні результатів traceroute або mtr є припущення, що проміжний перехід, який виглядає проблематично, означає наявність реальної проблеми. Зазвичай це не так.

Зірочки(*) у traceroute означають, що маршрутизатор не відповів на запит. Багато маршрутизаторів налаштовано на ігнорування або обмеження швидкості ICMP. Якщо наступні хопи після нього реагують нормально, шлях є нормальним.

Втрата пакетів на одному переході в mtr відбувається за тією ж логікою. Якщо на етапі 5 спостерігається втрата 20%, а в кінцевому пункті призначення - 0%, маршрутизатор просто знижує пріоритетність відповідей на запити. Реальна втрата пакетів проявляється у вигляді шаблону: втрата з'являється на одному стрибку і зберігається на кожному наступному стрибку до місця призначення.

Стрибки затримки між стрибками є нормальним і очікуваним явищем. Стрибок з 10 мс до 80 мс зазвичай означає, що пакет перетнув океан або довгий наземний маршрут. Турбуйтеся про затримку, тільки якщо вона незвично висока для даної відстані (менше 5 мс в межах міста, десятки мілісекунд по країні, 80-150 мс трансокеанська) або якщо затримка в кінцевому пункті призначення неприйнятна.

Варто звернути увагу наStDev (джиттер) в mtr. Значення вище 10 мс на будь-якому переході можуть спричинити проблеми для VoIP, відеодзвінків та ігор. Якщо ви бачите високий джиттер, виконайте принаймні 100 циклів, щоб переконатися, що це стійка тенденція, а не короткий сплеск.

Коли використовувати кожен інструмент

Використовуйте трасування, коли вам потрібна швидка відповідь: чи досяжний пункт призначення, а якщо ні, то де обривається шлях? Це правильна відправна точка для виявлення збоїв і перевірки базової маршрутизації.

Використовуйте mtr, коли проблема є переривчастою або пов'язана з продуктивністю. Користувачі, які повідомляють про періодичні відключення, проблеми з якістю VoIP або сплески затримок, потребують безперервних даних mtr. Запустіть принаймні 50-100 циклів для отримання надійної статистики.

Для ретельної діагностики запустіть mtr в обох напрямках: від вашого комп'ютера до сервера і від сервера назад до вашої IP-адреси. Маршрутизація в Інтернеті асиметрична, тому зворотний шлях може мати абсолютно різні характеристики. Якщо ви протестуєте тільки один напрямок, ви можете пропустити, де насправді знаходиться проблема.

Якщо у вас виникли проблеми з вашим виділеним сервером або VPS, команди підтримки FDC Servers приймають звіти mtr як стандартні діагностичні дані для ескалації мережевих проблем.