dark

Информация: При потерях соединения, высоком пинге и подобных проблемах

Recommended Posts

Кто виноват и что делать при высоком пинге и потерях пакетов

 

Краткая версия

 

Кто виноват: Один из узлов на маршруте начиная от клиентского приложения и заканчивая его серверной частью.

Что делать:  Одно из: Решить или обойти проблему на узле, либо подождать когда само решится

 

 

Подробная версия

 

Без лишних слов, рассмотрим общую "схему" маршрута между пользователем в поисках правды и сервером. 

  На схеме:

                  цифры - "номер" следующего хопа (ретранслятора\рутера) в цепочке маршрута.
                  "ISP"  - Internet Service Provider  - интернет-провайдер пользователя 
                  "Домашний рутер" -  Wi-Fi рутер пользователя:
                  "|" - канал(линк) между узлами на маршруте. 
 
В первой колонке цифрами обозначены все узлы на маршруте пакетов  клиент-серверного приложения (Старконфликт\Кроссаут и т.п.). 
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" на нашего честного, но несправедливо осужденного героя под гомерический хохот злодея.
welcome-to-real-world.jpg
      Этот весьма распространенный случай называется Асимметрией маршрутов.  В нормальной ситуации асимметрия жить не мешает, возможно даже гдето помогает, если альтернативный маршрут "обратно"  оказался короче.
      Маршрут "вперед" так же может отличаться для очередного пакета. Что, кстати, может показывать юникосовый traceroute, в отличии от windows версии.:
unix_tracert_multiple_to.jpg
        Стоит вспомнить про асимметрию когда вы видите резко возросшие задержки между хостами раположенными в одной геозоне, например, внутри города. Определить (с определенной вероятностью) географическое расположение серверов можно по 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]      //Москва

       Для демонстрации буйства асимметрии взгляните на эту картинку:

 netscheme.png

       Чтобы получить обратный маршрут, на сегодня самый "дешевый" вариант - это протрейсить с другой стороны, т.е. запустить tracert или pathping со стороны сервера до вас. Конечно никто вас на сервер не пустит, но выход есть - воспользоваться сервисом "looking glass  (lg) иногда любезно предоставляемым датацентром где находится сервер. Этот сервис позволяет выполнить ряд сетевых проверок (обычно ping/tracert) со стороны датацентра до любого из узлов в интернет.  Чтобы узнать маршрут до вас от серверов старконфликта, воспользуйтесь сообразным lg

     Кстати, команда 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

post-1098527-0-51883700-1433256460_thumb

post-1098527-0-55479900-1433620071_thumb

post-1098527-0-23579700-1434216322_thumb

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 
Тестирование канала связи до текущего игрового сервера 
 
ВАЖНО ЗНАТЬ:
- трассировку канала есть смысл выполнять  только в момент возникновения проблем со связью!
- в этой инструкции есть скрипт, позволяющий отлавливать момент ухудшения качества связи и автоматически запускать тесты
- игровой сервер может меняться от карты к карте. Поэтому, перед выполнением тестов обязательно определите актуальный адрес вашего сервера, иначе тесты будут бесполезными.
 
 
ВАРИАНТ A. Ручной метод.
 
Этот вариант используется только в том случае, когда невозможно по какой-либо причине использовать автоматизирующий скрипт (см.ниже вариант Б)
 
1.  Найти адрес текущего  сервера из активного файла game.log, расположенного в подкаталоге с текущей датой здесь:

Win XP:      {диск}:\Documents and Settings\{имя пользователя}ои документы\My Games\StarConflict\logs\ 
Win Vista/7: {диск}:\Users\{имя пользователя}\Documents\My Games\StarConflict\logs\ 
Linux:       ~/.local/share/starconflict/logs/ 
MAC OS:      Users\<user>\Library\Application Support\Star Conflict\logs\ 

Перейдите в каталог logs (см.выше), отсортируйте содержимое каталога по времени создания и перейдите в самый свежий подкаталог начинающийся цифрами текущей даты.
Например, ...My Games\StarConflict\logs\2015.10.09 22.18.55
Подкаталогов с текущей датой может быть несколько, поэтому важно перейти в самый свежий.
 
откройте файл game.log
 
Искать в game.log подстроку: client: connected to
Таких строк может быть несколько. Нужна последняя найденная. Если "сегодня" вылетов на карту не было, то строчки не будет.
 
Пример найденной строки:
12:21:54.115 | client: connected to 219.18.15.139|35004, setting up session...
 
Искомый IP адрес сервера:   219.18.15.139
 
Если поиск производился в момент нахождения в игре (на карте), то это и будет Ваш текущий сервер.
Если поиск производился сразу после завершения игры (находясь в ангаре), то это будет сервер на котором игралась последняя карта.
 
Серверы могут меняться от карте к карте.
 
 
2. Проверяем задержки и потерю пакетов до сервера
2.1. Вводим команду:
           PathPing -n -4 -w 500 <Искомый IP адрес сервера>
                                    ,где <Искомый IP адрес сервера> - найденный выше IP адрес
 
       Например,
            PathPing -n -4 -w 500 219.18.15.139
 
2.2. В результате на экран будет выведена информация примерно такого вида:  
 

C:\>PathPing -n -4 -w 500 219.18.15.139
Трассировка маршрута к 219.18.15.139
с максимальным числом прыжков 30:
  0  192.168.20.62
  1  192.168.20.5
  2  92.242.1.153
  3  92.242.31.37
  4  219.18.15.1
  5  219.18.15.139

Подсчет статистики за: 125 сек. ...
           Исходный узел     Маршрутный узел
Прыжок  RTT   Утер./Отпр.   %   Утер./Отпр.  %   Адрес
  0                                           192.168.20.62
                                0/ 100 =  0%   |
  1    0мс     0/ 100 =  0%     0/ 100 =  0%  192.168.20.5
                                0/ 100 =  0%   |
  2    1мс     0/ 100 =  0%     0/ 100 =  0%  92.242.1.153
                                0/ 100 =  0%   |
  3   15мс     2/ 100 =  2%     2/ 100 =  2%  92.242.31.37
                                0/ 100 =  0%   |
  4    1мс     0/ 100 =  0%     0/ 100 =  0%  219.18.15.1
                                0/ 100 =  0%   |
  5    2мс     0/ 100 =  0%     0/ 100 =  0%  219.18.15.139

Трассировка завершена. 

 

Выполняем проверку до сервера с помощью WinMTR

winmtr.png

Подождите пока WinMtr проработает секунд 30 и запостьте скриншот окна

 

2.3. Выполняем проверку MTU (смотри пост рядом с описанием что это и зачем)
 
 ping -f -l 1472 <IP адрес Dedicated сервера>
здесь l - это английская L (эль). Регистр важен. Адрес сервера добудьте одним из способов выше
например:

 ping --1472 11.222.333.444

Если MTU "зажат", вы увидите сообщения:

требуется фрагментация пакета, но установлен запрещающий флаг.
требуется фрагментация пакета, но установлен запрещающий флаг.
требуется фрагментация пакета, но установлен запрещающий флаг.

2.4. Делаем скриншот 
 
 
 Кроме того, по найденному IP адресу можно запустить утилиты WinMTR и Ping Plotter из старой версии инструкции (см. предыдущий пост).
 
 
ВАРИАНТ Б. Использовать скрипт (для  windows 7)
 

Перейдите в каталог с установленной игрой. (По умолчанию, C:\Program Files (x86)\Star Conflict)  Затем, в подкаталог  con_tester

 

Если в этом каталоге нет WinMTR.exe, скачайте его отсюда. WinMtr позволит более качественно проверить связь до сервера.

 

Среди прочего, там должны быть два cmd-файла:

- SC_Active_Srv_nettest.cmd  - основной скрипт
- PacketLoss_Trapper.cmd     - вспомогательный скрипт, запускающий основной с ключом monitor


После запуска любого из скриптов, скрипт будет ожидать наличие записи в game.log об игровом сервере.

Такая запись появляется только при вылете на карту.  Если "сегодня" вылетов не было, т.е. в файле game.log отсутствуют такие записи, скрипт будет ждать пока не будет произведен вылет. Если игралась хотя бы одна карта - будет использована запись сервера игры этой карты. Если записей несколько - будет использоваться последняя.

Waiting for DS server record in game.log
play any map to continue or press CtrlC to exit.......

 
1. Моментальная проверка связи до текущего(или последнего) сервера на котором игралась текущая (последняя) карта
 
Моментальная - значит проверки будут выполнены сразу после запуска скрипта в отличие от другого скрипта в пункте 2. (ниже)
Запустите SC_Active_Srv_nettest.cmd 
Если вы запустили скрипт, находясь на карте, будет тестироваться текущий сервер
Если вы запустили скрипт, находясь в меню игры, будет тестироваться последний сервер на котором игралась карта.
 
Откроется окно с информацией по используемым текущим серверам и процедурой тестирования канала до сервера. 

*********************************************************
 0:29:18 2014-12-10 (Wed Dec 2014) RTZ 2 (чшьр) UTC+03:00
LoadBalancer      [RU] 91.230.61.25
Shard             [RU] 5.153.37.199
Chat              [RU] 91.230.61.97
Dedicated         [US]219.18.15.139

Далее будет либо запущен 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) и файлы логов игры. Если был запущен 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 в лог-файле не сохраняются
 
Таким образом, вы можете играть множество карт подряд и только спустя время просмотреть содержимое лог файла в поисках проблем со связью.
 
Если проблема выявлена, приложите к скриншотам (если на них видны потери) и этот лог-файл. Если на скриншотах проблема не видна (но есть в лог-файле) - приложите только его. Скриншоты нужны только для удобства при просмотре соощения на форуме.

SC_Active_Srv_nettest-0.4.3.0.zip

  • Вверх 7

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проверка максимального значения MTU до сервера (для windows)

 

Официальная инструкция  по изменению MTU для владельцев продукции Apple

 

 

post-1098527-0-53469400-1428487735_thumb

 

Обычно такая ошибка вызвана "зажатым" значением MTU, как правило, коммутационным оборудованием провайдера или домашним маршрутизатором.

Реже - клиентской операционной системой.

 

В game.log при этом может наблюдается такая запись после дисконнекта:

client: connection closed. DR_CLIENT_COULD_NOT_CONNECT

Чтобы исключить этот вариант в решении проблем со связью, используйте проверку реального максимального нефрагментированного размера пакета до текущего игрового сервера.

 

Его значение должно быть не ниже 604. 

 

Его нормальное значение на большинстве OS:  1500

 

 

Проверить максимально-возможный размер нефрагментированных пакетов, долетающих до игрового сервера можно штатным ping'ом или сторонними утилитами

 

1. Ручной метод штатной командой ping:

 

  Заголовок пакета займет 28 байт, поэтому для проверки ping'ом прохождения пакета размером в 1500 байт нужно вычесть 28 из 1500, т.е. пинговать размером 1472:

 

  Используя команду ping с ключами -f -l 1472   (здесь l - это английская L (эль). Регистр важен!

 

 Нажмите "Пуск", выполните cmd.exe

 

Введите:

ping -f -l 1472 <IP адрес Dedicated сервера>

здесь l - это английская L (эль). Регистр важен. Адрес сервера добудьте одним из способов выше

 

Например:

ping -f -l 1472 11.222.333.444

Если MTU "зажат", вы увидите сообщения:

требуется фрагментация пакета, но установлен запрещающий флаг.
требуется фрагментация пакета, но установлен запрещающий флаг.
требуется фрагментация пакета, но установлен запрещающий флаг.
...
 
Чтобы определить максимально-допустимый размер MTU, попробуйте попинговать со значения  -l 1432 и ниже, определив таким образом максимально возможную цифру. Прибавьте к ней 28 и получите максимальное MTU.
Пролистайте в конец поста чтобы узнать что делать дальше.
 
 

2. Автоматизированное определение MSS

 

Воспользоваться утилитой mtupath.exe

mtupath.exe <IP адрес Dedicated сервера>

В результате получите картинку в виде:

MTU path scan to 11.222.333.444, ttl=64, limit=48
# 16 processing - best MSS 1472 (estimated MTU 1500) [pPPPPpPppPpppppp]
# 01 nearest minimum MTU on local interface


        #1 MSS IN RANGE     1 <==  1471 ==>  1472
        #2 MSS EXCEEDED  1473 <== 14911 ==> 16384

Ваш диапазон фактического значения которое может принимать MTU отражается в строчке #1 MSS IN RANGE . Прибавьте к крайней цифре 28 и получите максимальный MTU.  1472+28=1500

 

 

3. Что делать если зажат MTU?

 

Изменить значение MTU можно средствами ОС windows, командой netsh.

Например, установить mtu=1460 (для MSS=1432) для сетевого интерфейса с именем Local Area Connection:

netsh interface ipv4 set subinterface "Local Area Connection" mtu=1460 store=active

чтобы изменение стало постоянным, используйте ключ store=persistent

 

 текущее значение MTU с названиями интерфейсов можно посмотреть командой

netsh interface ipv4 show subinterface

Более правильное решение - изменить конфигурацию пограничного оборудования. домашнего маршрутизатора, или пообщать провайдера на эту тему.если машрутизатор не при чем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проверка обратного маршрута от сервера до клиента
 
Применять в случае подозрения на асимметрию маршрутов
Для этой цели используйте looking glass (lg) датацентров:

 

рекомендуется запустить последовательно tracert, mtr (там будет выбор из меню)
и каждый результат заскриншотить

 
 

lg датацентра  IP серверов

----------------------------------
Россия    5.178.*.*

Россия     95.213.*.*
Россия     188.93.*.*

Европа    159.8.*.*
Европа    5.153.*.*

Европа    81.171.*.*

США       198.11.*.*
Азия      119.81.*.*

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сброс стека TCP/IP в Windows

Иногда загадочные проблемы с подключением решаются обнулением конфигурации стека tcp/ip

для этого выполните последовательно действия:
1. Нажмите "Пуск", введите cmd.exe 
2. В найденном приложении правым кликом кликните "запуск от имени Администратора"
3. Внутри окна cmd.exe введите

netsh winsock reset 

после чего перезагрузите компьютер

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проверка доступности tcp/udp портов

 

Для работы игры требуется разрешить на вашем оборудовании (роутере и вашем ПК )  трафик с указанных ниже портов в вашу сеть :

TCP:  80, 443, 3800-3815
UDP:  35000-36000

 Для работы launcher.exe нужно открыть эти порты (если вы запускаете игру через launcher.exe, а не из Steam): 

TCP 27022-27042, 6881, 8090

Проверить доступность портов снаружи можно так

Используя утилиту ConnectionTester.exe  для проверки доступности UDP портов с игрового сервера до вашего ПК
  Найти её можно в подкаталоге игры \con_tester
 Утилита сходит на один из серверов и попробует подключиться с сервера на Ваш ПК по UDP протоколу .

 Запустите, дождитесь окончания работы и приложите в свою тему созданный утилитой conntest.log 

Если файрвол настроен правильно, то результат работы ConnectionTester должен содержать подобные записи:

INFO   : ConnectionTester: new state 'CTS_UDP_TESTING'
INFO   : UdpTester(95.213.156.195|35900): Connected. MTU size = 1492
INFO   : UdpTester(95.213.156.195|35900): Sending request 1
INFO   : UdpTester(95.213.156.195|35900): Received packet (len=1025)

Если файрвол не настроен, то результат работы ConnectionTester будет содержать подобные записи:
08:34:54.786         | ConnectionTester: new state 'CTS_UDP_TESTING'
08:35:01.384         | UdpTester(95.213.156.195|35900): Failed to connect


Для чистоты эксперимента рекомендуется временно выполнить действия:

1. Отключите на вашем ПК все программы, которые так или иначе могут влиять на соединение. uTorrent, FlashGet, Skype, ICQ и т.д. Пока проблема не будет решена, они должны быть отключены;

2. Отключите на вашем ПК файрвол и брандмауэр, проверьте наличие проблемы. Пока проблема не будет решена - не включайте их;


 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Гость
Эта тема закрыта для публикации сообщений.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу