Администратор Skula1975 906 Администратор Share Опубликовано: Май 17, 2017 Кто виноват и что делать при высоком пинге и потерях пакетов Краткая версия Кто виноват: Один из узлов на маршруте начиная от клиентского приложения и заканчивая его серверной частью. Что делать: Одно из: Решить или обойти проблему на узле, либо подождать когда само решиться Подробная версия Без лишних слов, рассмотрим общую "схему" маршрута между пользователем в поисках правды и сервером. На схеме: цифры - "номер" следующего хопа (ретранслятора\рутера) в цепочке маршрута. "ISP" - Internet Service Provider - интернет-провайдер пользователя "Домашний рутер" - Wi-Fi рутер пользователя: "|" - канал(линк) между узлами на маршруте. В первой колонке цифрами обозначены все узлы на маршруте пакетов клиент-серверного приложения (Старконфликт\ Кроссаут и т.п.). 0 [сетевое приложение-клиент на ПК пользователя] | 1 [домашний рутер] | 2 [рутер ISP] | 3 [аплинки ISP] | .. ...большой и непредсказуемый интернет | 7 [аплинки Датацентра] | 8 [Датацентр] | 9 [Сервер] Чем ближе проблема к той или иной стороне (Пользователь <--> Сервер) - тем выше ответственность(самостоятельность) этой стороны за решение. с Уважением., Кэп :) Кто виноват? Определить проблемный участок на маршруте можно с помощью диагностических утилит. В большинстве современных ОС таковые имеются "из коробки". Разумеется, на просторах всемирной свалки можно накопать неприличное множество аналогов Здесь будет пользоваться pathping - консольная утилита, входящая в состав Windows. pathping -n ip-адрес Рекомендуем пользовать ключ -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) со стороны датацентра до любого из узлов в интернет. Кстати, команда ping с ключом -r показывает и обратный маршрут (правда максимум до 9 хопов). Что делать? 1. Если потери пакетов и большие задержки на вашей стороне (до вашего провайдера ). Здесь вся ответственность за решение полностью Ваша. Вам придется двигать решение вопроса самостоятельно, или совместно через форум. 2. Если потери пакетов и большие задержки начинаются от канала провайдера и до его аплинков. Решайте вопрос с провайдером. 3. Если потери пакетов и большие задержки где-то в интернет (за третьим хопом от стороны), то у вас вариантов не особо много. Обычно "за третьим хопом" находятся крупные узлы, имеющие несколько резервных линков. И, часто бывает так, что перерывы связи обусловлены перестроением таблиц маршрутизации в результате прилетевшего сверху машрутного анонса, либо переключением на резервного линка. Что вы сами можете сделать? 3.1. тариф "Нормальный": Расслабьтесь - само пройдет в течение 24 часов. Потому как скорее всего это крупный хаб и страдаете не только вы, но и организации, несущие убытки горораздо бОльшие чем частное лицо, поверьте администрацию этого узла пинают весьма активно в направлении решения проблемы. Да и сам крупный узел несет огромные убытки с каждой минутой простоя - в его интересах решить проблему "вчера", тем самым сохранив взаимо-теплые и улыбчивые отношения с клиентами\партнерами не только за счет безупречного качества предоставляемого сервиса, но и молниеносной скоростью решения проблем. 3.2. тариф "Чем бы себя развлечь": Сходите по всем друзьям, знакомым и незнакомым (к ним домой и на работу), а так же по пути загляните во все кафешки, автосервисы, салоны красоты и прочие места где есть вай-фай - главное чтобы у них был альтернативный от вашего провайдер и проверьте качество маршрута от них. Выберите провайдера с наиболее выгодным маршрутом. Смените провайдера и наслаждайтесь до тех пор, пока не случиться вариант пп3. , повторите пп 3.2 =) 4. Если потери пакетов и большие задержки начинаются с аплинков Датацентра сервера. Скорее всего, мы уже в курсе. Так как проблема массовая. Но все-равно пинайте нас, но обязательно приложив результат работы pathping или хотябы tracert. Еще лучше воспользоваться волшебным скриптом. И еще лучше дополнить результатами трейса из lookingglass со стороны датацентра. -+- Секретное чтиво для тех, кто хочет постичь тайные знания об устройстве интернет и усовершенствовать свое Кунг-фу сетевой диагностики. Тайное знание только для избранных, поэтому до кучи еще и на английском: Richard A. Steenbergen. A Practical Guide to (Correctly) Troubleshooting with Traceroute 2 5 6 Ссылка на комментарий Поделиться на других сайтах More sharing options...
Разработчик Crossout Это популярное сообщение. sgdmitry 14 Разработчик Crossout Это популярное сообщение. Share Опубликовано: Май 17, 2017 Тестирование канала связи до текущего игрового сервера ВАЖНО ЗНАТЬ: - трассировку канала есть смысл выполнять только в момент возникновения проблем со связью! - в этой инструкции есть скрипт, позволяющий отлавливать момент ухудшения качества связи и автоматически запускать тесты - игровой сервер может меняться от карты к карте. Поэтому, перед выполнением тестов обязательно определите актуальный адрес вашего сервера, иначе тесты будут бесполезными. ВАРИАНТ A. Ручной метод. Этот вариант используется только в том случае, когда невозможно по какой-либо причине использовать автоматизирующий скрипт (см.ниже вариант Б) 1. Найти адрес текущего сервера из активного файла game.log, расположенного в подкаталоге с текущей датой здесь: Win XP: {диск}:\Documents and Settings\{имя пользователя}\Мои документы\My Games\Crossout\logs\ Win Vista/7: {диск}:\Users\{имя пользователя}\Documents\My Games\Crossout\logs\ Linux: ~/.local/share/Crossout/logs/ MAC OS: Users\<user>\Library\Application Support\Crossout\logs\ Перейдите в каталог logs (см.выше), отсортируйте содержимое каталога по времени создания и перейдите в самый свежий подкаталог начинающийся цифрами текущей даты. Например, ...My Games\Crossout\logs\2015.10.09 22.18.55 Подкаталогов с текущей датой может быть несколько, поэтому важно перейти в самый свежий. откройте файл game.log Искать в game.log подстроку: client: connected to Таких строк может быть несколько. Нужна последняя найденная . Если "сегодня" вылетов на карту не было, то строчки не будет. Пример найденной строки: 12:21:54.115 | client: connected to IP|35004, setting up session... Если поиск производился в момент нахождения в игре (на карте), то это и будет Ваш текущий сервер. Если поиск производился сразу после завершения игры (находясь в ангаре), то это будет сервер на котором игралась последняя карта. Серверы могут меняться от карте к карте. 2. Проверяем задержки и потерю пакетов до сервера Выполняем проверку до сервера с помощью WinMTR Подождите пока WinMtr проработает секунд 30 и запостьте скриншот окна 2.3. Выполняем проверку MTU (смотри пост рядом с описанием что это и зачем) ping -f -l 1472 <IP адрес Dedicated сервера> здесь l - это английская L (эль). Регистр важен. Адрес сервера добудьте одним из способов выше например: ping - f - l 1472 11.222 . 333.444 Если MTU "зажат", вы увидите сообщения: требуется фрагментация пакета, но установлен запрещающий флаг. требуется фрагментация пакета, но установлен запрещающий флаг. требуется фрагментация пакета, но установлен запрещающий флаг. 2.4. Делаем скриншот Кроме того, по найденному IP адресу можно запустить утилиты WinMTR и Ping Plotter из старой версии инструкции (см. предыдущий пост). ВАРИАНТ Б. Использовать скрипт. Скачайте con_tester.zip Внутри находится каталог con_tester с парой скриптов.: - XO_Active_Srv_nettest.cmd - основной скрипт - PacketLoss_Trapper.cmd - вспомогательный скрипт, запускающий основной с ключом monitor (режим мониторинга ухудшения связи(ждет пока будут логироваться потери пакетов в игровом логе game.log)) Положите в каталог con_tester утилиту WinMTR.exe (WinMTR) WinMtr позволит более качественно проверить связь до сервера. Без него будут использоваться менее эффективные штатные инструменты windows. После запуска любого из скриптов, скрипт будет ожидать наличие записи в game.log об игровом сервере. Такая запись появляется только при выезде на карту. Если "сегодня" выездов не было, т.е. в файле game.log отсутствуют такие записи, скрипт будет ждать пока не будет произведен выезд. Если игралась хотя бы одна карта - будет использована запись сервера игры этой карты. Если записей несколько - будет использоваться последняя. Waiting for DS server record in game . log play any map to continue or press CtrlC to exit ....... 1. Моментальная проверка связи до текущего(или последнего) сервера на котором игралась текущая (последняя) карта Моментальная - значит проверки будут выполнены сразу после запуска скрипта в отличие от другого скрипта в пункте 2. (ниже) Запустите XO_Active_Srv_nettest.cmd Если вы запустили скрипт, находясь на карте, будет тестироваться текущий сервер Если вы запустили скрипт, находясь в меню игры, будет тестироваться последний сервер на котором игралась карта. Откроется окно с информацией по используемым текущим серверам и процедурой тестирования канала до сервера. ********************************************************* 0:29:18 2014-12-10 (Wed Dec 2014) RTZ 2 (чшьр) UTC+03:00 GameServer [US]ip-адрес Далее будет либо запущен WinMtr.exe, либо будут использованы встроенные утилиты windows (ping, pathping, tracert) --------------------------------------------------------- [ INFO ] checking minimum MTU value with 1000byte , not - fragmented packets ... Обмен пакетами с 5.178 . 86.27 по с 1000 байтами данных: Ответ от 5.178 . 86.27 : число байт= 1000 время= 48 мс TTL = 58 Ответ от 5.178 . 86.27 : число байт= 1000 время= 47 мс TTL = 58 ... --------------------------------------------------------- [ INFO ] Testing route path ... Трассировка маршрута к 91.230 . 61.167 с максимальным числом прыжков 30 1 2 ms 1 ms 1 ms 192.168 . 1.1 2 11 ms 5 ms 7 ms 187.24 . 238.1 3 * 2 ms 2 ms 95.54 . 92.82 4 30 ms 30 ms 29 ms 95.167 . 92.31 5 43 ms 42 ms 58 ms 81.91 . 186.66 6 42 ms 42 ms 44 ms 91.230 . 61.167 Трассировка завершена. Выкладываем скриншот ВСЕХ окон с тестами (включая winmtr) и файлы логов игры (см выше в пп 1. где их взять). Если был запущен WinMtr, закройте его. 2. Запуск тестирующих процедур в режиме мониторинга по факту ухудшения качества связи. PacketLoss_Trapper.cmd Используйте данный скрипт когда требуется отследить момент ухудшения качества связи и сразу запустить трассировку и пинг. При запуске скрипта начинается мониторинг файла game.log на наличие записей об ухудшении качества связи с сервером. Waiting for DS server record in game . log play any map to continue or press CtrlC to exit ... DS record found Monitoring game . log for packet loss record > 10 % at 1 seconds intervals Как только случиться ухудшение связи(потеря пакетов >10%), будет либо запущен WinMtr либо, при его отсутствии в текущем каталоге, ДВА отдельных диагностических окна: трассировка и ping текущего сервера. Ping модифицирован - каждый цикл - это результат отправки нескольких icmp запросов с последующей обработкой вывода результатов. В каждой строке показано: среднее значение задержек, количество потерянных пакетов/количество отправленных пакетов (процент потерь): 0 : 48 : 39 2014 - 12 - 10 ( Wed Dec 2014 ) RTZ 2 (чшьр) UTC + 03 : 00 Pinging current server . Press Ctrl - C to exit or just close this window [ 0 : 48 : 47 ] 91.230 . 61.167 : avg : 42ms lost : 0 / 8 ( 0 %) [ 0 : 48 : 55 ] 91.230 . 61.167 : avg : 42ms lost : 0 / 8 ( 0 %) [ 0 : 49 : 03 ] 91.230 . 61.167 : avg : 42ms lost : 0 / 8 ( 0 %) Во втором окне обычный tracert в цикле. 0 : 48 : 38 2014 - 12 - 10 ( Wed Dec 2014 ) RTZ 2 (чшьр) UTC + 03 : 00 Tracing current server . Log file is : nettest - tracing . 15.12 . 2014.log [ 0 : 48 : 38 ] Run 1. Collecting tracing data . Press Ctrl - C to abort ... Трассировка маршрута к 91.230 . 61.167 с максимальным числом прыжков 30 1 2 ms 1 ms 1 ms 192.168 . 1.1 2 11 ms 5 ms 7 ms 187.24 . 238.1 3 * 2 ms 2 ms 95.54 . 92.82 4 30 ms 30 ms 29 ms 95.167 . 92.31 5 43 ms 42 ms 58 ms 81.91 . 186.66 6 42 ms 42 ms 44 ms 91.230 . 61.167 Трассировка завершена. [ 0 : 48 : 53 ] Run 2. Collecting tracing data . Press Ctrl - C to abort ... Трассировка маршрута к 91.230 . 61.167 с максимальным числом прыжков 30 Обе утилиты будут работать в цикле. Дайте им поработать хотя бы минуту чтобы собрать статистику Чтобы остановить цикл запуска утилит, нажмите Ctrl-C и подтвердите завершение командного файла. По окончании диагностики, сделайте скриншоты ВСЕХ диагностиеческих окон (включая WinMTR) Скрипты "понимают" смену игрового сервера и подставляют правильный адрес для тестирования. Поэтому, вы можете играть и держать запущенным в фоне скрипт. Не волнуйтесь, вы не упустите важный момент - скрипт ведет лог-файл всех трассировок (см.ниже). Это не касается варианта с запуском WinMtr. Однако, winMTR все же предпочтительнее. Кроме вывода на экран, результаты работы утилиты tracert сохраняются в лог-файл,расположенный в одном каталоге со скриптом. именуется он nettest-tracing.<текущая дата>.log Все результаты запусков PacketLoss_Trapper.cmd (сколько бы запусков ни было) будут сохранены в этом файле. Результаты работы утилиты ping в лог-файле не сохраняются Таким образом, вы можете играть множество карт подряд и только спустя время просмотреть содержимое лог файла в поисках проблем со связью. Если проблема выявлена, приложите к скриншотам (если на них видны потери) и этот лог-файл. Если на скриншотах проблема не видна (но есть в лог-файле) - приложите только его. Скриншоты нужны только для удобства при просмотре сообщения на форуме. winmtr_bin_0.8.zip 2 2 9 1 10 Ссылка на комментарий Поделиться на других сайтах More sharing options...
Recommended Posts