Вступление
Pingplotter— это программа Windows, похожая на команду traceroute, которая показывает путь между клиентом и сервером, но делает это гораздо более четко. В этой статье содержится информация об использовании этого инструмента, а также о некоторых типичных ошибках.
Скачать
Бесплатную версию можно скачать с официального сайта .
Диагностика сети с помощью пингплоттера
На этом рисунке показан почти идеальный путь от клиента к серверу. Во втором столбце перечислены потери пакетов, то есть тестовые пакеты, которые были потеряны. Поскольку в этом примере не было потери пакетов, этот столбец пуст.
В столбцах IP и DNSName можно проследить путь, по которому проходят тестовые пакеты. Путь начинается с мюнхенского провайдера M-Net, на шагах 6 и 7 (на пиринговом узле INXS), переданных Noris, а затем, наконец, на шаге 9 (на пиринговом узле NIX), переданном сети Hetzner.
Столбцы Avg и Cur показывают время, необходимое пакету (в мс), чтобы добраться до перехода: Avg — среднее время, Cur — значение последнего тестового пакета.
В конце время передачи пакетов отображается графически. «Выбросы» можно быстро определить по ходу красной линии. Однако вы можете сделать лишь ограниченные выводы из положения линии: черные линии показывают разницу между самым быстрым и самым медленным ответом для конкретного перехода. Однако, если прыжок реагирует особенно медленно, красная линия перемещается влево (так как справа требуется больше места).
mtr
Если у вас нет Pingplotter, вы можете получить те же базовые функции с программой mtr( WinMTRдля Windows). Здесь описано, как работает mtr .
Типичные ошибки
Это «отстает»!
Время отклика увеличивается, терминальные сеансы прерывистые, а игры становятся неиграбельными. Сервер не всегда является виновником, хотя использование пингов в качестве диагностического инструмента не очень помогает:
Pingplotter предлагает гораздо лучшую информацию:
Сразу видно, что ошибка (в данной симуляции) находится в сети M-Netz. Начиная с шага 4, наблюдаются значительные задержки, пакеты с шага 5 частично отбрасываются (что, в свою очередь, может быть причиной ошибки на шаге 4), а шаг 6 вызывает чрезмерные задержки. Подобные шаблоны отказов могут быть вызваны серьезной нехваткой, например, вызванной DDoS-атаками.
Потеря пакетов
В этом примере дело обстоит иначе: несмотря на то, что имеется много отброшенных пакетов, начинающихся с 10-го скачка, время проверки связи 37 мс находится в нормальном диапазоне. Это могло быть вызвано неисправным маршрутизатором или неисправным кабелем.
Все идет медленно
При подключении по DSL часто появляется следующий экран с ошибкой:
Эта трассировка на самом деле не показывает проблему. Пингплоттер снова более полезен:
Высокая нагрузка уже на втором переходе указывает на перегрузку частного интернет-соединения, которая может быть вызвана, например, отправкой больших объемов данных по электронной почте, засорением восходящего ADSL-соединения. Инструменты для обмена файлами, которые в фоновом режиме поглощают трафик и о которых давно забыли, также могут быть проблемой. Четкую картину проблемы можно найти, выполнив трассировку в обратном направлении:
Все выглядит как находка (зеленый) до тех пор, пока маршрутизатор клиента не отвечает слишком поздно. Возможными проблемами могут быть нарушение подключения к Интернету или перегрузка маршрутизатора.
Потери пакетов, которые нереальны
На самом деле это не проблема / ошибка, так как отсутствие ответа на тестовые пакеты — это нормально для маршрутизаторов. В зависимости от конфигурации маршрутизатора он будет маршрутизировать пакеты, но отвечать на тестовые пакеты только при наличии достаточной свободной вычислительной мощности. Пока следующие переходы не показывают потерю пакетов, нет причин для беспокойства.
Асимметричная маршрутизация
Диагностика сбоев относительно проста, если круговой обход между клиентом и сервером следует по одному и тому же пути. Однако часто пакеты будут иметь другой обратный маршрут (это вызвано разными требованиями провайдера клиента и местоположения сервера).
Следующая анимация (требуется плагин Flash) иллюстрирует проблему:
Пример ошибки
В следующем примере сеть Hetzner кажется причиной задержек. Начиная с первого маршрутизатора Hetzner, время пинга значительно увеличивается, и пакеты отбрасываются:
Client ---> Server
1 67 ms 65 ms 66 ms 62.26.xx.xx
2 63 ms 63 ms 65 ms 62.26.251.97
3 80 ms 74 ms 76 ms so-6-0-0.core3.f.tiscali.de (62.27.95.2)
4 74 ms 75 ms 73 ms so-3-0-0.fra30.ip.tiscali.net (213.200.64.25)
5 73 ms 74 ms 75 ms ffm-s2-rou-1071.DE.eurorings.net (80.81.192.22)
6 75 ms 74 ms 75 ms ffm-s1-rou-1001.DE.eurorings.net (134.222.227.65)
7 78 ms 79 ms 78 ms nbg-s1-rou-1071.DE.eurorings.net (134.222.227.30)
8 84 ms 78 ms 79 ms gi-0-1-286-nbg5.noris.net (134.222.107.26)
9 392 ms 393 ms * ne.gi-2-1.RS8000.RZ2.hetzner.de (213.133.96.65)
10 393 ms * 392 ms et-2-16.RS3000.RZ2.hetzner.de (213.133.96.38)
11 393 ms 392 ms * (...)Erst bei Traceroute в umgekehrter Richtung erkannte man die eigentliche Fehlerquelle:
Server ---> Client
1 213.133.xx.xx (213.133.xx.xx) 0.233 ms 0.205 ms 0.281 ms
2 et-1-11.RS8000.RZ2.hetzner.de (213.133.96.37) 0.653 ms 0.660 ms 0.650 ms
3 nefkom-gw.hetzner.de (213.133.96.66) 1.119 ms 0.423 ms 0.415 ms
4 GW-SF-BBR-06-S2-3.nefkom.de (212.114.147.23) 0.635 ms 0.807 ms 0.457 ms
5 hsa2.mun1.pos6-0.eu.level3.net (212.162.44.25) 6.811 ms 6.347 ms 6.143 ms
6 ae0-19.mp1.Munich1.Level3.net (195.122.176.193) 315.587 ms 314.949 ms 315.164 ms
7 so-0-0-0.mp1.Frankfurt1.Level3.net (212.187.128.90) 301.324 ms 300.789 ms 300.742 ms
8 gige1-2.core1.Frankfurt1.Level3.net (195.122.136.101) 301.673 ms 300.853 ms 301.087 ms
9 de-cix.fra30.ip.tiscali.net (80.81.192.30) - 317.844 ms 317.634 ms
10 so-4-0-0.core3f.tiscali.de (213.200.64.26) 318.453 ms - 318.021 ms
11 so-1-0-0.core1.hh.tiscali.de (62.27.95.38) 307.780 ms 307.230 ms 307.252 ms
12 ge-2-0-0.7.core0.hh.tiscali.de (62.27.93.83) 307.431 ms 307.298 ms 307.084 ms
13 62.26.251.101 (62.26.251.101) - 307.753 ms 308.933 ms
14 (...) 390.856 ms 399.355 ms -В этом случае произошла ошибка между двумя маршрутизаторами Level3 в Мюнхене. Проблема, похоже, заключалась в Hetzner, поскольку пакеты до Надежды 8 (Noris) были успешно возвращены. Однако тестовые пакеты в сеть Hetzner и обратно пошли другим маршрутом, что привело к задержке в Мюнхене.