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

Question

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

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

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

• Мой провайдер обеспечивает соединение через большую беспроводную сеть с несколькими точками доступа на расстоянии около 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-адреса:

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

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

Answer 1

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 Обратный IP-поиск возвратил то же самое сообщение. Если вы видите 1e100.net, это система Google. Google использует "1e100" в своем имени, потому что это способ представить "1" с сотней нулей после него, что является гуголом.

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