Поле битвы: Проверьте потерю пакетов и время возврата пакетов в многопользовательской игре

805
halirutan

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

Вопрос: Какой хороший способ проанализировать время выполнения пакета и потерю, который дает мне более подробную информацию о том, где находится узкое место в соединении? Есть ли простой способ воспроизвести трафик в некоторой степени искусственно, не играя в игру?

Вот моя ситуация:

  • Мой провайдер обеспечивает соединение через большую беспроводную сеть с несколькими точками доступа на расстоянии около 10 км, прежде чем подключиться к основному кабелю. Так было всегда, и в прошлом оно оказалось чрезвычайно надежным. Из-за изменений в оборудовании или других изменений настроек моего интернет-провайдера качество игрового процесса несколько месяцев назад упало. Мой провайдер очень полезен и пытается найти и исправить источник проблем.
  • В целом, у меня очень хороший пинг, и когда я играю, информация в игре всегда показывает хороший пинг в 20-30 мс.
  • Особенностью Battlefield является то, что он показывает предупреждающие символы, когда частота кадров падает, время обработки соединения плохое или потеря пакетов. Ситуация, которая повторяется, состоит в том, что я могу играть около 10-60 секунд без какого-либо предупреждающего символа, а затем я испытываю серьезную потерю пакетов, где у меня возникают задержки, и BF показывает мне все виды предупреждений о соединении. После этого я могу снова играть несколько секунд, прежде чем снова увижу это поведение.

Я исключительно работает на Linux, и я несколько комфортно ping, traceroute, nmapи других сетевых инструментов. Я знаю высокие порты, которые использует BF, я могу узнать используемые размеры пакетов и, конечно, я могу извлечь IP-адреса с игровых серверов. Какой хороший способ начать отслеживать эту проблему, чтобы я мог, я надеюсь, искусственно спровоцировать потерю пакетов, пока мой провайдер отлаживает то, что происходит в его сети?

Анализ

Я установил WireShark, как любезно предложено Moonpoint, и запечатлел несколько минут затянувшегося игрового процесса. В первом анализе я сосредоточился на пакетах, поступающих с игрового сервера. Я отфильтровал все UDP-пакеты, поступающие с сервера, на мой IP-адрес и скорректировал время, чтобы увидеть относительное время между этими пакетами. После сортировки было около 20 пакетов, которые занимали от 650 мс до 1300 мсек, и я подозреваю, что это те, где я прыгаю наполовину по карте. Между большинством других пакетов почти точно время выполнения, которое я вижу как «Ping» в игре, составляет около 30 мс.

После маркировки всех критических пакетов, я очистил фильтр и посмотрел весь трафик, чтобы увидеть, могу ли я найти какую-то модель того, что происходит со всеми пакетами вокруг критических. Я обнаружил, что есть две ситуации. Обратите внимание, что 94.250.208.153 является игровым сервером, а синяя подсветка является критическим пакетом игр UDP:

Во-первых, примерно за 10-15 пакетов до критического существует мистический пакет SSDP M-Search, приходящий с MAC-адреса:

IMG

Вторая ситуация заключается в том, что критическому пакету предшествует (или иногда окружается) ретрансляция TCP, в основном на сервер Google:

Поле битвы: Проверьте потерю пакетов и время возврата пакетов в многопользовательской игре

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

1
Первое, что я хотел бы проверить, это убедиться, что ваш восходящий и нисходящий потоки не перегружены. Загрузка остановится, если загрузка произойдет, и наоборот. Загрузка обычно достаточно быстрая, но загрузка может быть проблемой. Ping не обнаружит проблем с загрузкой, кроме того, что обнаружит сбой, но не причину. Такие сайты, как speedtest.net, дают график, пока они делают тест. Является ли загрузка стабильной? У вас есть другие программы, которые могут использовать загрузку? LPChip 6 лет назад 0
@LPChip Спасибо за предложение, но это одна вещь, которую я уже проверял. У меня довольно стабильный восходящий и нисходящий поток. halirutan 6 лет назад 0
На момент написания этого комментария, который был до того, как вы отредактировали ваше сообщение, он не был написан в вашем вопросе, иначе я бы не предложил его. Полезное правило. Во избежание того, чтобы люди просили вас сделать то, что вы уже сделали, упомяните их в своем вопросе. :) LPChip 6 лет назад 0
@LPChip Не беспокойся. Мое редактирование было возможно только из-за ответа Moonpoint :) halirutan 6 лет назад 0

1 ответ на вопрос

1
moonpoint

MTR, который сочетает в себе функциональность, обнаруженную в ping и traceroute, также может быть полезным инструментом для определения точки или точек на сетевом пути, где происходит потеря пакетов или где большое дрожание ( пример ).

Вы также можете использовать бесплатный анализатор пакетов Wireshark с открытым исходным кодом для устранения проблемы, но для понимания информации, которую он предоставляет, необходимо знать, как работают базовые интернет-протоколы, такие как TCP / IP. Есть курсы и руководства по его использованию онлайн. Хотя на изучение того, как эффективно его использовать, может уйти довольно много времени, но как только вы научитесь использовать такой инструмент, как Wireshark, вы сможете легче решать любые проблемы, связанные с сетевым подключением.

Если вы не знакомы с Wireshark, на YouTube есть Руководство по WireShark для начинающих и Wireshark 101: How to Wireshark, Haktip 115 ; многие другие можно найти, выполнив поиск по термину «Учебник по Wireshark». Веб-сайты с учебными пособиями включают в себя краткое и грязное учебное пособие по Wireshark, как использовать Wireshark для захвата, фильтрации и проверки пакетов и учебное пособие по Wireshark, которое представляет собой файл PDF, созданный профессором Анджелосом Ставру на факультете компьютерных наук Университета Джорджа Мейсона. Есть также онлайн-курсы о том, как использовать Wireshark

С помощью Wireshark или tcpdump, инструмента захвата пакетов из командной строки, доступного для систем Linux, OS X и Microsoft Windows ( WinDump ), вы можете перехватывать пакеты, поступающие из вашей системы и в нее, когда возникает проблема, чтобы вы могли самостоятельно проанализировать данные позже или в режиме реального времени, или, поскольку оба инструмента могут сохранять данные, которые вы захватили, в виде файла pcap, вы можете предоставить данные персоналу службы поддержки вашего интернет-провайдера, поскольку их персонал может быть знаком с интерпретацией таких данных, так как файлы pcap распространенный метод обмена данными по сетевой проблеме между сетевыми инженерами при отладке проблемы.

Wireshark будет собирать все данные в сетевом интерфейсе, но, поскольку вы знаете номера сетевых портов и IP-адреса, связанные с игровыми серверами Battlefield, вы можете использовать фильтр Wireshark для фильтрации по номерам портов и / или IP-адресам .

Обновить:

В шестнадцатеричные цифры вы видели, связанные с «SSDP M-Search пакет» не является управление доступом к среде (MAC) адрес. MAC-адреса аналогичны 50-c5-8d-26-c2-06, т. Е. MAC-адреса Ethernet и Wi-Fi обычно отображаются с тире или двоеточиями между каждыми двумя шестнадцатеричными цифрами, всего 12 цифр, т. Е. 48 Адреса Вместо этого вы видите адрес IPv6 - сегодня в Интернете используются две версии интернет-протокола: давно используемая версия 4 интернет-протокола (IPv4) и более поздняя версия 6 интернет-протокола (IPv6).

SSDP расшифровывается как Simple Service Discovery Protocol, протокол, используемый для универсального Plug and Play (UPnP) . Некоторая система в вашей локальной сети с IPv6-адресом fe80 :: 50e7: d4f0: db: c4dc отправляет пакет на IP- адрес многоадресной рассылки, ff02 :: c. Для IPv4 адрес многоадресной рассылки - 239.255.255.250, в то время как SSDP через IPv6 использует набор адресов ff0X :: c для всех диапазонов области действия, обозначенных X («X» в пакете, который вы видели, равно «2»).

Я не знаю, почему ваша система связывается с IP-адресом Amazon Web Services (AWS) или с адресом Google.

C:\>nslookup 52.203.205.255 8.8.8.8 Server: google-public-dns-a.google.com Address: 8.8.8.8  Name: ec2-52-203-205-255.compute-1.amazonaws.com Address: 52.203.205.255   C:\>nslookup 216.58.212.78 8.8.8.8 Server: google-public-dns-a.google.com Address: 8.8.8.8  Name: lhr35s05-in-f78.1e100.net Address: 216.58.212.78  

Я вижу, что соединение с портом 443, известным портом для трафика HTTPS, но когда я выполнил Обратный IP- поиск 52.203.205.255 с использованием возможности Обратного IP-поиска DomainTools, он сообщил: «Мы не нашли никаких результатов для вашего поиска». Зачастую, добавление IP-адреса в это средство поиска покажет вам полные доменные имена (FQDN) для веб-сайтов, размещенных по IP-адресу (несколько веб-сайтов могут быть размещены на одном IP-адресе), но не в этом случае.

216.58.212.78 Reverse IP Lookup возвращается то же самое сообщение. Если вы видите 1e100.net, это система Google. Google использует «1e100» в своем имени, потому что это способ представить «1» с сотней нулей после него, что является гуголом .

Оба этих пакета могут не иметь отношения к связи с сервером Battlefield. Тот факт, что они являются повторными передачами, которые отправляются, когда система отправила пакет, но не получил пакет подтверждения от другой стороны, указывающий, что он был получен, может указывать на то, что трафик на другие сайты также испытывает потерю пакетов на одновременно с проблемами на сервере Battlefield. Вы можете отфильтровать эти два IP-адреса, чтобы просмотреть другие пакеты к ним или из них, чтобы получить лучшее представление о том, почему они могут появляться в перехвате пакетов, если вас интересовало, почему ваша система взаимодействует с этими двумя IP-адресами.

+1 Отличный ответ. Я сделал небольшой анализ и добавил детали к своему вопросу. Возможно, у вас есть идея, могу ли я сделать что-то еще со своей стороны, кроме как передать файл pcap моему провайдеру. Может быть, есть способ сделать это еще хуже, чтобы мы знали, на что обращать внимание. halirutan 6 лет назад 0
@halirutan, я добавил дополнительную информацию в свой ответ относительно пакета SSDP. moonpoint 6 лет назад 0
Спасибо за обновление. Пакеты для Google и Amazon, скорее всего, от демона фонового обновления. Прошлой ночью я выключил все и убил все службы обновлений, которые смог найти. Действительно были редко другие пакеты. Кажется, в сети есть огромная проблема с дрожанием. IMO трафик должен, в лучшем случае, чередоваться между пакетами от и к игровому серверу. Это часто бывает так, как можно увидеть [здесь] (http://imgur.com/LWPfw6H). Однако в случае критических задержек это выглядит следующим образом (http://imgur.com/VMeRKWp), когда пакеты с сервера поступают слишком поздно. halirutan 6 лет назад 0

Похожие вопросы