Периодическая проблема с высоким пингом / задержкой

WISP? Смысл Беспроводной Интернет-провайдер? Если да, то вот ваш вероятный ответ. Беспроводная связь ненадежна, и вы видите доказательство этого.

Вы не можете это исправить, потому что ваша среда (атмосфера) действительно ужасна для передачи данных. Во-первых, потому что воздух - это концентратор, а не коммутатор, поэтому вы делитесь им со всеми вокруг вас и сталкиваетесь между пакетами, во-вторых, потому что CSMA / CA работает медленнее, чем CSMA / CD, в-третьих, потому что беспроводная связь обычно полудуплексная, а не полнодуплексная, и в-четвертых, потому что помехи по воздуху на порядок выше, чем по меди. [Микроволны, например, работают на той же длине волны, что и 802.11b / g ... но микроволновая печь работает примерно на 500-1000 Вт против 100 милливатт вашей беспроводной антенны. Микроволны экранированы, но экранирование не является идеальным, и микроволны не регулируются Федеральной комиссией по связи, поэтому это не является незаконным, если они вызывают помехи.] Плюс тот факт, что вы проходите через 10+ переходов только для того, чтобы попасть в Интернет. Это не может помочь, особенно если используется NAT или брандмауэр.

Как сообщает @dbasnett, задержка пинга traceroute для данного хоста указывает только состояние всей сети между интерфейсами, взятыми в целом в этот момент времени. Вот почему время отклика идет вниз иногда. Они резкие, потому что сеть ненадежна. Ваш pathping выглядит хорошо, потому что он выполняет большое количество запросов вместо трех, tracert это работает. Так pathping показывает, что сеть делает в течение 325 секунд (по умолчанию), и tracert показывает, что делают 3 пакета на переход в сети.

9 случаев из 10 результатов трассировки маршрута не указывают на проблемы с сетью. Traceroute отправляет пакеты эхо-запроса ICMP на каждый последующий переход между источником и местом назначения, увеличивая TTL на единицу для каждого последующего перехода. Результат каждого прыжка является показателем того, как ЭТОТ прыжок отвечает на трафик ICMP, но не является показателем качества пути через этот прыжок и за ним. Работа маршрутизаторов заключается в пересылке трафика, и поэтому многие из них запрограммированы на игнорирование, отбрасывание или присвоение низкого приоритета трафику ICMP, направленному на себя. Тот факт, что переходы 14, 19 и 21 имеют очень хорошее время отклика, указывает на то, что с маршрутом все в порядке. Если возникла проблема на переходе 12 (как вы подчеркнули) или на любом другом переходе, влияющем на путь, вы бы увидели проблему на каждом последующем переходе, и каждый переход был бы хуже, чем предыдущий. Только когда вы видите результаты такого типа в traceroute, вы можете заподозрить проблему с путем. Переход 21 - это пункт назначения, и время отклика 59 мс сообщает вам, что путь между источником и пунктом назначения в порядке. Ключом к анализу проблемы пути является анализ ее производительности во время передачи реальных данных, что невозможно, если у вас нет анализатора пакетов / сетевого монитора на каждом переходе и доступа к памяти, ЦП и счетчикам пропускной способности на каждом узле. сетевой узел (маршрутизаторы и коммутаторы) на пути от источника к месту назначения.

Вместо того, чтобы пытаться выяснить, почему у вас возникают проблемы с производительностью на основе трассировки пути, вам следует сосредоточиться на фактическом сеансе TCP между источником и получателем и посмотреть на время ответа (задержку) и любые потери пакетов между этими двумя конечными точками.

Маршрут трассировки, как следует из его названия, представляет собой инструмент для обнаружения пути между двумя конечными точками, а не инструмент для анализа качества этого пути.

Я должен согласиться с joeqwerty, ICMP давно перестал быть надежным измерителем производительности, задержки или пропускной способности. Это особенно верно для маршрутов с большим количеством переходов по неизвестным сетям.

Более реалистичным будет тест с протоколом (ами), который вы используете. Например, если бы это был http, вы могли бы настроить захват сетевых пакетов Wireshark. Отфильтруйте диалог с указанным хостом и используйте Статистика Wireshark> График потока TCP> График времени приема-передачи. Этот тест будет более точным, если вы выполните захват хотя бы в течение нескольких минут.

Еще один интересный вариант - PingPlotter Standard (не бесплатно, но с полным набором функций в течение 30 дней). Это дает очень хорошую возможность для тестирования пропускной способности конкретного протокола путем указания номера порта, а также имеет графики времени приема-передачи, которые можно сохранять и загружать.

Пинги и маршрут трассировки (эхо-запросы с определенным TTL) являются временными. То, что вы видите в какой-то конкретный момент времени, - это всего лишь это и не имеет ничего общего с прошлыми или будущими событиями.

Часть пропускной способности интернета (2%) - это пинг-трафик, который, если вы не являетесь специалистом в магистральной сети Интернет, не имеет реальной цели. Если у вас возникла проблема, позвоните своему интернет-провайдеру.

После дополнительного тестирования это проблема с задержкой UDP.

Причина, по которой высокая задержка совпадает с низкой производительностью приложения, по-видимому, связана с хостом, привязанным к ЦП. ICMP-пакет с истекшим TTL требует процессорного времени для обработки ответа, и, таким образом, большинство маршрутизаторов настроены так, чтобы «отвечать, когда мне этого хочется». В этом случае задержка для ICMP-трафика с истекшим TTL является показателем занятости маршрутизатора. Кажется, что хост находится на краю их сети, поэтому через этот переход проходит большая часть всего трафика.

Я очень подозреваю, что интернет-провайдер проводит какую-то проверку трафика или формирует протокол UDP, что также требует времени процессора.

Убедись в уменьшите ваши буферы по насыщенной ссылке.