Кто виноват и что делать при высоком пинге и потерях пакетов
Краткая версия
Кто виноват: Один из узлов на маршруте начиная от клиентского приложения и заканчивая его серверной частью.
Что делать: Одно из: Решить или обойти проблему на узле, либо подождать когда само решится
Подробная версия
Без лишних слов, рассмотрим общую “схему” маршрута между пользователем в поисках правды и сервером.
На схеме:
цифры - “номер” следующего хопа (ретранслятора\рутера) в цепочке маршрута.
“ISP” - Internet Service Provider - интернет-провайдер пользователя
“Домашний рутер” - Wi-Fi рутер пользователя:
“|” - канал(линк) между узлами на маршруте.
В первой колонке цифрами обозначены все узлы на маршруте пакетов клиент-серверного приложения ([Старконфликт](http://star-conflict.com/ru/)Кроссаут и т.п.).
0 [сетевое приложение-клиент на ПК пользователя]
|
1 [домашний рутер]
|
2 [рутер ISP]
|
3 [аплинки ISP]
|
.. ...большой и непредсказуемый интернет
|
7 [аплинки Датацентра]
|
8 [Датацентр]
|
9 [Сервер]
Чем ближе проблема к той или иной стороне (Пользователь <--> Сервер) - тем выше ответственность(самостоятельность) этой стороны за решение. с Уважением., Кэп :)
Кто виноват?
Определить проблемный участок на маршруте можно с помощью диагностических утилит. В большинстве современных ОС таковые имеются “из коробки”. Разумеется, на просторах всемирной свалки можно накопать неприличное множество аналогов
Здесь будет пользоваться pathping - консольная утилита, входящая в состав Windows.
pathping -n 219.18.15.139
Рекомендуем пользовать ключ -n. Иногда в потугах безуспешного резолвинга, pathping прекращает работу. Если есть желание отрезолвить хосты на маршруте, а это делать рекомендуется, пользуйте совместно с утилитой tracert например, запущенной параллельно в другом окне.
Результат работы pathping состоит из трех частей:
В начале выводится маршрут, как при использовании traceroute. Здесь ничего ценного нет. Затем, каждый узлел на маршруте “пингуется” 100 пакетами, собирается статистика и производятся вычисления. Результат этих вычислений и есть ценность данной утилиты.
Нужно набраться терпения и дождаться окончания работы утилиты. В зависимости от числа промежуточных хостов, сбор статистики может занять внушительное время.
В итоге ваши ожидания будут вознаграждены расширенным вариантом traceroute:
------------------±-------------------------------------------------------------------------------------------------------------------------------------
Колонка | Пояснение
------------------±-------------------------------------------------------------------------------------------------------------------------------------
Прыжок Номер узла(хоста) на маршруте, как и в traceroute
Исходный Задержки (RTT) и потери (Утер./Отпр.%) до узла - это просто результаты обычного ping до этого узла
узел RTT : Round Trip Time (в расчет берется время прохождения пакета туда И обратно )
Маршрутный Вот где начинается самое интересное и волшебное:
узел Все показанные цифры потерь в этой колонке - рассчитанные (вычисленные) значения на основе статистических данных.
Ценность их в том, что в отличие от цифр потерь в результатах ping, эти цифры говорят где именно и в каком масштабе происходит геноцид пакетов - какой узел или линк за это отвечает. Узел может быть перегружен(ЦПУ китайского рутера не справляется), канал между двумя линками может быть перегружен (слишком длинные очереди на отправку или прием) пакетов или просто физические повреждения линии или влияния внешней среды - например высоковольтный кабель упал рядом и создает помехи…
К сожалению, 100% выявить виновника невозможно. И чем дальше от вас проблема - тем меньше шансов. Интернет сложнее чем кажется. Казалось бы, два хоста в одной подсети, отличаются лишь одной цифрой в адресе(1.1.1.1 vs 1.1.1.2) - в современном интернет наивно утверждать, что эти два хоста расположены в одном и том же датацентре. Это могут быть как виртуальные машины запущенные в VitrualBox на домашнем ПК школьника-любителя, но так же могут оказаться серверами, расположенными в разных странах, связанных на низком сетевом уровне через ряд резервных\дублируемых магистральных каналов, принадлежащих нескольким партнерским сетям, окутывающих весь мир и, возможно часть некольких галактик, образуя единый бекбон крупных провайдеров, позволяющий выдавать ИП из одной подсети в разных частях планеты. Кстати, именно поэтому иногда пустыми оказываются попытки достоверно определить географическое расположение сервера только по его IP (geoiplookup, geoiptool, и т.п.). Для более точной геолокации требуется применение нескольких инструментов (whois+инфобазы по пирам; fqdn сервера и т.д.)
Чтобы овладеть кунг-фу диагностики, нужны годы накопления и применения знаний о бесчисленных вариантах конфигураций инфраструктурных элементов Интернет а также не лишним будет развитие навыков телепатии. Новичкам легко обмануться и сделать ложные выводы. Именно поэтому traceroute и pathping службы тех.поддержки называют инструментами генерации тикетов
Приведем несколько примеров чтобы показать насколько интересна и загадочна жизнь сетевого пакета на его пути “туда-обратно”.
Дроп пакетов ретранслятором “или Алярм! - я вижу цифру 100% потери на хосте”.
Самый распространенный случай паники, вызванной “потерями” пакетов на ретрансляторах.
Многие маршрутизаторы дропают пакеты, адресованные непосредственно им как конечной точке маршрута, как если бы вы пинговали этот промежуточный рутер. Иногда дропаются 100%, иногда только часть. Это нормальное явление, т.к. назначение маршрутизатора - пересылать пакеты дальше по таблице рутинга и нет необходимости тратить ресурсы на обработку пакетов предназначенных себе. Такое нормальное поведение определяется как отсутствие потерь пакетов в статистике пинга за этим узлом и это самое распространенное явление в результатах Traceroute\Pathping.
Неисповедимы пути рутинга “или у нас на ретрансляторе все хорошо, аццтаньте уже со своим pathping >:-F~”
Особенность traceroute\pathping в том, что они показывают только узлы, через которые пакет прошел вперед. Таким образом, непринужденно вводя нас в легкое заблуждение, что в обратную сторону пакеты ходят точно таким же маршрутом. В реальности пакет может возвращаться совершенно другим маршрутом. Цифры потерь и задержек считаются с учетом прохождения пакета по всему кругу туда и обратно, (помните- выше по тексту колонка RTT ) и pathping/tracert взваливает 100% отвественность за эти цифры на один хост, даже не подозревая что этот хост может быть только на половину отвественен за маршрут. Хост может выполнять честно и добросовестно свою часть работы, ретранслируя пакет до аплинка с 0% потерями и 0мс задержками, но некто в тени обратного маршрута добавляет 66% потерь и 666мс задержек, однако, его вина безкомпромисно возлагается недалеким судьей “tracert/pathping” на нашего честного, но несправедливо осужденного героя под гомерический хохот злодея.
Этот весьма распространенный случай называется Асимметрией маршрутов. В нормальной ситуации асимметрия жить не мешает, возможно даже гдето помогает, если альтернативный маршрут “обратно” оказался короче.
Маршрут “вперед” так же может отличаться для очередного пакета. Что, кстати, может показывать юникосовый traceroute, в отличии от windows версии.:
Стоит вспомнить про асимметрию когда вы видите резко возросшие задержки между хостами раположенными в одной геозоне, например, внутри города. Определить (с определенной вероятностью) географическое расположение серверов можно по dns имени хоста. В примере ниже резко вырос пинг внутри одного города, к тому же еще и внутри одного провайдера. Возможно действительно проблемы на этом узле(или канале), а возможно это как раз наш случай.
... 5 7 ms 3 ms 1 ms vl2444.ar26-14.ekb.ru.mirasystem.net [96.242.41.187] //Екатеринбург (...ekb.ru...) 6 632 ms 1 ms 1 ms vl4002.sr06-02.ekb.ru.mirasystem.net [96.242.32.37] //Екатеринбург 7 641 ms 39 ms 38 ms mx240-msk-m9-12f-1.ix.dataix.ru [178.18.233.1] //Москва
Для демонстрации буйства асимметрии взгляните на эту картинку:
Чтобы получить обратный маршрут, на сегодня самый “дешевый” вариант - это протрейсить с другой стороны, т.е. запустить tracert или pathping со стороны сервера до вас. Конечно никто вас на сервер не пустит, но выход есть - воспользоваться сервисом **"looking glass (lg) **иногда любезно предоставляемым датацентром где находится сервер. Этот сервис позволяет выполнить ряд сетевых проверок (обычно ping/tracert) со стороны датацентра до любого из узлов в интернет. Чтобы узнать маршрут до вас от серверов старконфликта, воспользуйтесьсообразным lg.
Кстати, команда ping с ключом -r показывает и обратный маршрут (правда максимум до 9 хопов).
Что делать?
-
Если потери пакетов и большие задержки на вашей стороне (до вашего провайдера ). Здесь вся ответственность за решение полностью Ваша. Вам придется двигать решение вопроса самостоятельно, или совместно через форум.
-
Если потери пакетов и большие задержки начинаются от канала провайдера и до его аплинков. Решайте вопрос с провайдером.
-
Если потери пакетов и большие задержки где-то в интернет (за третьим хопом от стороны), то у вас вариантов не особо много. Обычно “за третьим хопом” находятся крупные узлы, имеющие несколько резервных линков. И, часто бывает так, что перерывы связи обусловлены перестроением таблиц маршрутизации в результате прилетевшего сверху машрутного анонса, либо переключением на резервного линка. Что вы сами можете сделать?
3.1. тариф “Нормальный”: Расслабьтесь - само пройдет в течение 24 часов. Потому как скорее всего это крупный хаб и страдаете не только вы, но и организации, несущие убытки горораздо бОльшие чем частное лицо, поверьте администрацию этого узла пинают весьма активно в направлении решения проблемы. Да и сам крупный узел несет огромные убытки с каждой минутой простоя - в его интересах решить проблему “вчера”, тем самым сохранив взаимо-теплые и улыбчивые отношения с клиентами\партнерами не только за счет безупречного качества предоставляемого сервиса, но и молниеносной скоростью решения проблем.
3.2. тариф “Чем бы себя развлечь”: Сходите по всем друзьям, знакомым и незнакомым (к ним домой и на работу), а так же по пути загляните во все кафешки, автосервисы, салоны красоты и прочие места где есть вай-фай - главное чтобы у них был альтернативный от вашего провайдер и проверьте качество маршрута от них. Выберите провайдера с наиболее выгодным маршрутом. Смените провайдера и наслаждайтесь до тех пор, пока не случиться вариант пп3. , повторите пп 3.2 =)
- Если потери пакетов и большие задержки начинаются с аплинков Датацентра сервера. Скорее всего, мы уже в курсе. Так как проблема массовая. Но все-равно пинайте нас, но обязательно приложив результат работы pathping или хотябы tracert. Еще лучше воспользоваться волшебным скриптом. И еще лучше дополнить результатами трейса из lookingglass со стороны датацентра.
-±
Секретное чтиво для тех, кто хочет постичь тайные знания об устройстве интернет и усовершенствовать свое Кунг-фу сетевой диагностики. Тайное знание только для избранных, поэтому до кучи еще и на английском: Richard A. Steenbergen. A Practical Guide to (Correctly) Troubleshooting with Traceroute
