У меня большая потеря пакетов, согласно mtr, при отправке пакетов через Интернет. Стоит ли мне жаловаться своему провайдеру?
Я читаю OReilly Linux Networking Cookbook и глава Using traceroute, tcptraceroute, and mtr to
Pinpoint Network Problems обратил мое внимание. Проверка связи с хостом, например Google, через Интернет от моего интернет-провайдера дает мне рекордные задержки 1200 мс и выше (не только с сегодняшнего дня, а с давних времен), поэтому я подумал, что не буду хуже анализировать путь пакетов с mtr.
Mtr is a network diagnostic tool that combines ping and traceroute into one program.
Отрывок и, в то же время, причина этой ветки вопросов:
Если какой-либо из них постоянно зависает на одном и том же маршрутизаторе, или если mtr постоянно показывает потери пакетов более 5% и длительное время передачи на одном и том же маршрутизаторе, то можно с уверенностью сказать, что проблема в этом конкретном маршрутизаторе. Если это роутер, которым вы управляете, то, черт возьми, почините его. Если это не так, используйте dig или whois, чтобы узнать, кому он принадлежит, и вежливо сообщите им о проблеме.
Увидеть mtr --report www.google.com выведите себя: (Всего 12 тестов, 1 тест каждые 5 минут; это отчет, который представляет собой надежное «среднее»)
HOST: km Loss% Snt Last Avg Best Wrst StDev
1. 192.168.0.1 0.0% 10 1.2 3.7 1.2 6.3 1.8
2. 10.150.144.145 10.0% 10 89.1 77.3 58.7 90.4 11.1
3. 172.16.251.1 50.0% 10 52.2 62.1 52.2 70.3 8.8
4. 172.16.250.54 60.0% 10 74.9 87.5 74.9 100.4 12.1
5. 172.16.250.251 40.0% 10 68.6 75.4 52.4 113.8 24.2
6. 200.85.47.2 10.0% 10 109.6 110.6 80.6 146.2 21.1
7. 201.217.4.113 0.0% 10 103.6 87.3 64.4 103.7 12.2
8. 201.217.0.9 0.0% 10 229.0 102.6 46.7 229.0 48.1
9. 201.217.0.3 0.0% 10 78.8 88.1 53.9 128.8 23.8
10. So2-3-2-0-grtbueba2.red.tele 0.0% 10 134.1 129.2 71.3 176.6 29.2
11. Xe4-1-3-0-grtmiabr7.red.tele 0.0% 10 257.3 255.1 221.0 291.6 21.1
12. Xe2-0-2-0-grtmiana3.red.tele 0.0% 10 290.4 267.0 213.2 319.1 31.0
13. Xe2-0-2-0-grtmiana3.red.tele 0.0% 10 300.0 250.8 217.3 312.7 34.6
14. GOOGLE-xe-5-0-0-0-grtmiana3. 10.0% 10 249.8 256.9 206.7 324.0 34.6
15. 209.85.254.252 0.0% 10 254.3 253.8 217.1 283.1 23.4
16. 209.85.254.252 10.0% 10 301.2 280.6 252.1 319.7 21.6
17. 72.14.236.200 10.0% 10 273.4 278.4 238.4 311.0 25.0
18. 216.239.49.145 20.0% 10 291.0 276.3 240.4 293.5 19.1
19. 72.14.232.25 10.0% 10 297.9 286.3 242.4 337.1 30.0
20. yo-in-f105.1e100.net 70.0% 10 300.7 304.7 280.3 333.0 26.6
Вы сразу видите, что хосты 3-5 испытывают очень высокую потерю пакетов, намного превышающую 5%. Выполнение запроса к базе данных whois показывает мне, что это серверы имен (пожалуйста, поправьте меня, если я ошибаюсь).
* 1 Ребята из службы технической поддержки не всегда понимают, или я не могу достаточно четко выразить свою проблему (иногда они, без сомнения, просто идиоты)
Многие маршрутизаторы обычно программируются так, чтобы давать более низкий приоритет пакетам ICMP, поэтому они не «тратят впустую» вычислительную мощность по сравнению с «реальным» трафиком. То, что вы видите прыжок с высокими потерями, не означает, что он замедляет «настоящий» трафик; это может быть только отбрасывание ICMP. Это не обязательно хорошо, потому что это может означать, что маршрутизатор слишком занят, но это не гарантируется.
Маршрутизатор также может быть запрограммирован на ограничение количества ответов, которые он отправляет на пакеты ICMP, с целью смягчения DoS-атак.
Возможно, ошибка внутри вашей сети.
Какой у вас интернет-маршрутизатор / шлюз?
Скорее всего,
3. 172.16.251.1 50.0% 10 52.2 62.1 52.2 70.3 8.8
4. 172.16.250.54 60.0% 10 74.9 87.5 74.9 100.4 12.1
5. 172.16.250.251 40.0% 10 68.6 75.4 52.4 113.8 24.2
находятся внутри вашей собственной сети.
Учитывая, что у вас нулевые потери на переходе 15, вы знаете, что можете получить трафик на всем пути без потерь. Все номера потерь на переходах 1-15 являются "локальными", то есть маршрутизаторы не ответили на ICMP, но они перенаправили ваш трафик.
Наибольшая потеря происходит на последнем переходе, номер 20, поэтому лучше всего предположить, что проблема заключается в перегрузке на другом конце. Сообщение о проблеме вашему интернет-провайдеру не принесет никакой пользы, но, возможно, жалоба на любую службу, которая находится на другом конце, может помочь.
Изменить: я знаю, что это старый вопрос, но я думаю, что он заслуживает разъяснения о том, как интерпретировать числа потерь> 0, за которыми следуют переходы без потерь.
Какое соединение и абонентская пропускная способность? DSL, выделенная линия, Frame Relay, кабель? 768 вниз / 128 вверх ... и т. Д.
Вы можете получить более реалистичную информацию с помощью WireShark и захвата / фильтрации пакетов между двумя хостами в течение определенного периода времени (30 минут). Затем используйте Статистика> TCP Stream Graph> Round Trip Time Graph. Время приема-передачи (RTT) - это фактическая задержка на уровне tcp.