Battlefield: проверка потери пакетов и времени возврата пакетов в многопользовательской игре

Question

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

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

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

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

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

Анализ

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

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

Сначала, примерно за 10-15 пакетов до критического, приходит мистический пакет SSDP M-Search с MAC-адреса:

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

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

Answer 1

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

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

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

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

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

Обновлять:

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

SSDP означаетПростой протокол обнаружения служб, который является протоколом, используемым дляУниверсальная технология 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»).

Я не знаю, почему ваша система связывается сВеб-сервисы Amazon (AWS)IP-адрес или адрес 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-трафика, но когда я выполнил52.203.205.255 Обратный поиск IPс использованием DomainToolsОбратный поиск IPвозможности, он сообщил: «Мы не нашли никаких результатов по вашему запросу». Часто, ввод IP-адреса в этот инструмент поиска покажет вамполностью квалифицированные доменные имена (FQDN)для веб-сайтов, размещенных на одном IP-адресе (на одном IP-адресе может быть размещено несколько веб-сайтов), но не в этом случае.

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

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