Диагностика потери пакетов (packet loss) на игровом сервере

MAATRIX GAMES

Игроки жалуются, что персонажа «телепортирует», пули не долетают, а в чате постоянно рябит — но ping в консоли показывает вменяемые 40 мс. Это классическая картина packet loss: часть UDP-пакетов между клиентом и сервером просто не долетает, и обычный пинг эту потерю почти не показывает. Разберём, какими инструментами реально ловить потерю пакетов, как понять, на чьей она стороне, и когда тащить проблему в поддержку хостинга, а когда чинить самому.

Чем packet loss отличается от обычного лага

Высокий пинг — это задержка: пакет долетает, но медленно, игра ощущается «вязкой», но предсказуемой. Потеря пакетов — это когда пакет не долетает вообще, и клиенту или серверу приходится либо ждать повтора (в TCP), либо просто терять кусок состояния (в UDP, а почти все игровые протоколы работают именно на UDP).

Симптомы, которые указывают именно на потери, а не на лаг:

• персонажи и снаряды «телепортируются» рывками, а не плавно тормозят;
• удары/выстрелы засчитываются с задержкой или не засчитываются вовсе, хотя пинг у игрока нормальный;
• проблема нестабильна — то всё летает, то раз в несколько секунд «заикание»;
• ping показывает низкое среднее значение, но с редкими таймаутами (Request timed out) или резкими скачками.

Если пинг стабильно высокий у всех — это, скорее, вопрос маршрутизации или перегруженного канала, там другая диагностика (подробнее — в статье про высокий пинг у всех игроков одновременно). А вот рваная, непредсказуемая потеря пакетов почти всегда требует именно mtr.

Почему обычного ping недостаточно

ping отправляет ICMP-запросы напрямую до конечного узла и показывает только итоговую статистику по всему маршруту: сколько пакетов ушло, сколько пришло, средний RTT. Это полезно для первой проверки («сервер вообще жив?»), но у метода два серьёзных ограничения:

1. Нет разбивки по хопам. Если из 30 отправленных пакетов потерялось 5, вы не знаете, на каком именно узле маршрута это произошло — у вашего провайдера, на магистрали или уже на входе в дата-центр хостинга.
2. ICMP часто приоритизируется иначе, чем игровой трафик. Многие маршрутизаторы и файрволы обрабатывают ICMP по остаточному принципу (rate-limiting), поэтому ping может показывать потери там, где реальный UDP-трафик игры проходит нормально, — и наоборот, молчать там, где реальные пакеты теряются.

Отсюда правило: ping — только для быстрой проверки «жив/не жив», для реальной диагностики потерь нужен инструмент, который видит весь маршрут и достаточную выборку пакетов.

mtr — основной инструмент диагностики маршрута

mtr (My TraceRoute) объединяет traceroute и ping: он строит маршрут до сервера и на каждом хопе непрерывно шлёт пакеты, показывая процент потерь и задержку именно на этом узле, а не только в конце пути.

Установка:

# Debian/Ubuntu
sudo apt install mtr-tiny

# CentOS/AlmaLinux
sudo dnf install mtr

# macOS
brew install mtr

# Windows — аналог WinMTR (GUI) или tracert как fallback

Базовый запуск с игрового сервера в сторону игрока (или наоборот, с ПК игрока в сторону сервера):

mtr -rwzbc 100 IP_ИЛИ_ДОМЕН

Разбор флагов: -r — вывод отчётом (не в реальном времени, удобно копировать в тикет), -w — широкий формат с полными доменными именами, -z — показывать AS-номер каждого хопа (полезно понять, где чей узел), -b — показывать и IP, и hostname, -c 100 — отправить 100 пакетов на хоп вместо стандартных 10 (чем больше выборка, тем достовернее процент потерь).

Пример того, что смотреть в выводе:

                                  Packets               Pings
 Host                           Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.1.1                  0.0%   100    0.4   0.5   0.3   1.2   0.2
 2. 10.20.0.1                    0.0%   100    2.1   2.3   1.9   4.0   0.3
 3. core1.upstream.net           0.0%   100    5.2   5.5   4.8   9.1   0.6
 4. transit-node.example.com    12.0%   100   28.4  30.1  27.9  45.2   3.1
 5. edge.hoster.net              0.0%   100   14.2  14.8  13.9  20.0   1.0
 6. game-server.hoster.net       0.0%   100   14.5  15.0  14.1  21.3   1.1

Здесь потери на 4-м хопе (12%) не «утекают» на 5-й и 6-й — это признак того, что реальных потерь дальше по маршруту нет, промежуточный узел просто ограничивает или депрриоритизирует ICMP/traceroute-пакеты (частая ситуация на транзитных узлах, которые сознательно troттлят ICMP). А вот если процент потерь появляется на каком-то хопе и сохраняется на всех последующих, включая последний — это уже реальная потеря, которая долетает до сервера или до игрока.

Если провайдер троттлит именно ICMP, а не UDP-трафик игры, для чистоты эксперимента можно погнать TCP-пробы вместо ICMP:

mtr -rwzbc 100 -T -P 443 IP_ИЛИ_ДОМЕН

-T переключает на TCP SYN-пакеты, -P задаёт порт (443 обычно открыт почти везде и реже фильтруется, чем произвольные UDP-порты).

Три точки диагностики: сервер, ваш ПК, игрок

Одного замера мало — потеря пакетов часто асимметрична (маршрут туда и обратно может идти по разным путям через разных провайдеров). Чтобы локализовать проблему, нужно минимум три точки:

1. С сервера в сторону игрока (если у вас есть SSH-доступ к серверу — актуально для VPS/dedicated, для панельного хостинга этот пункт обычно недоступен):

mtr -rwzbc 100 IP_ИГРОКА

1. С вашего личного ПК/ноутбука в сторону сервера (не с того же провайдера, что у сервера, — так вы увидите магистральный маршрут «снаружи»):

mtr -rwzbc 100 адрес-сервера.example.com

1. С ПК игрока, который жалуется на проблему — попросите его тоже прогнать mtr (или WinMTR под Windows) и прислать скриншот или текстовый отчёт.

Если потери видны на всех трёх замерах примерно на одних и тех же узлах ближе к серверу — проблема на стороне дата-центра или его аплинков. Если потери у каждого замера свои, разные хопы и разные узлы — скорее всего, это индивидуальные проблемы у конкретных игроков (домашний Wi-Fi, перегруженный роутер, VPN) или у отдельного транзитного провайдера, через которого идёт трафик именно этого игрока. Подробный разбор того, что стоит проверять в сетевом трафике сервера в целом, — в статье про мониторинг сетевого трафика игрового сервера.

Как отличить потери на своей стороне от потерь у игрока

Практический чек-лист, прежде чем писать тикет в поддержку:

• Жалуется один игрок или несколько сразу? Один — почти всегда проблема на его стороне (Wi-Fi, домашний роутер, VPN, торрент-клиент, который ест канал). Несколько игроков из разных регионов одновременно — уже похоже на проблему сервера или его аплинка.
• Проверьте потери на самом сервере локально. Загрузка CPU под 100% или своп на диск тоже создают ощущение «потери пакетов» — на деле сервер просто не успевает обрабатывать тики и роняет данные уже внутри игровой логики, а не в сети. Гляньте top/htop и free -h параллельно с mtr.
• Проверьте статистику UDP-сокетов на сервере:

netstat -su | grep -i -A5 Udp:
# или через ss
ss -su

В выводе netstat -su смотрите на packet receive errors и RcvbufErrors — рост этих счётчиков во время жалоб игроков означает, что ядро ОС не успевает вычитывать входящие UDP-пакеты из буфера сокета быстрее, чем они приходят, то есть потери происходят уже на самом сервере, а не в сети. Это лечится тюнингом сетевого стека (см. статью про тюнинг сетевого стека Linux через sysctl), а не поддержкой хостинга.

• Прогоните flood-тест на короткое время, чтобы убедиться, что канал вообще не насыщен:

ping -f -c 500 IP_СЕРВЕРА

Флаг -f шлёт пакеты максимально часто (нужны root-права); если при такой нагрузке потери резко растут — это может быть просто ограничение по полосе или rate-limit на маршруте, а не «сломанная сеть».

• Проверьте, не идёт ли в этот момент DDoS-атака — многие хостинги включают scrubbing (фильтрацию трафика через промежуточные узлы), которая сама по себе добавляет пару лишних хопов и иногда небольшую потерю на них. Если у хостинга есть панель с графиком входящего трафика — сверьтесь с ней. Общий принцип работы такой защиты описан в статье что такое DDoS-защита и как она работает.

Что подготовить перед обращением в поддержку хостинга

Тикет вида «у меня лагает» поддержка обработает в последнюю очередь — нет данных, чтобы за что-то зацепиться. Тикет с приложенным mtr-отчётом обрабатывается быстрее и часто эскалируется сразу на сетевых инженеров. В заявку стоит включить:

• отчёт mtr -rwzbc 100 и с сервера в сторону проблемного адреса, и с внешней точки в сторону сервера — так поддержка видит оба направления;
• точное время, когда наблюдались потери (с часовым поясом) — это позволяет сверить с логами их сетевого оборудования;
• IP или имя ноды сервера, номер тикета/аккаунта;
• если есть — скриншот mtr от самого игрока, особенно если жалобы идут от игроков из одного региона/провайдера.

Отдельно стоит зафиксировать: если потери видны только на 1–2 промежуточных хопах, а на входе в сеть хостинга (последний хоп до сервера) — 0%, поддержка с высокой вероятностью ответит, что проблема на транзитном провайдере, который им не подконтролен, и это часто правда. Хостинг отвечает за свою сеть и последнюю милю до сервера, а не за весь путь пакета по интернету. Если же потери именно на входе в их дата-центр или на самом сервере — это уже их зона ответственности, и отчёт mtr с чёткой картиной ускорит решение в разы.

Частые вопросы