Потери на беспроводном участке Wi-Fi / cellular link loss
ID причины rt-wireless · Основной ответственный Внешние стороны · Внешние стороны · Совместно Команда инфраструктуры · Серверная инфраструктура, Команда разработки · Разработка сервера, Команда разработки · Разработка клиента
Wi-Fi и мобильная сеть несколько раз повторяют передачу на беспроводном участке, а если и это не помогает, выбрасывают пакет. Выброшенный пакет TCP отправит повторно только спустя заметное время.
Почему Слабый сигнал или сильные помехи, передача на беспроводном участке срывается раз за разом → Следствие Если превышен лимит повторов беспроводного оборудования (обычно от нескольких до десяти с лишним раз), пакет выбрасывается → На экране Фриз на всё время ожидания повторной передачи TCP, следующие пакеты ждут в буфере приёма, затем перемотка
Основной ответственный Внешние стороны · Внешние стороны · Совместно Команда инфраструктуры · Серверная инфраструктура, Команда разработки · Разработка сервера, Команда разработки · Разработка клиента
Команда разработки: задачи
Сервер: включить TCP_NODELAY (при включённом Nagle у RACK нет следующих пакетов, по которым он определяет потерю), пока соединение ждёт повторной передачи, отправлять только самое свежее обновление состояния, без накопления старых (объём, который копится в ядре, ограничить через TCP_NOTSENT_LOWAT). Клиент: включить TCP_NODELAY (потери на пути ввода игрока к серверу восстанавливает ОС клиента), при серии потерь или скачке пинга показывать на экране состояние сети.
Команда инфраструктуры: задачи
Ускорить восстановление потерь с помощью RACK-TLP (предотвратить потери на беспроводном участке сервер не может, он может только быстрее их восстанавливать), проверить, что не изменены значения по умолчанию современных Linux net.ipv4.tcp_recovery=1 (RACK) и net.ipv4.tcp_early_retrans=3 (TLP).
Внешние стороны: задачи
Посоветовать игроку кабельное подключение, диапазоны 5 GHz или 6 GHz, другое место для роутера или другой радиоканал.
Цифры для ориентира
При потерях 1% на беспроводном участке пропадает 1 игровой пакет из 100. Если за 1 с приходит 10 пакетов, короткий фриз случается примерно раз в 10 с. Без RACK-TLP каждый такой фриз длится RTO (пинг + 200 ms и больше).
На графике
Высоко только у некоторых · доля повторных передач по соединениям, RTT (пинг) по соединениям
Где смотреть
С ПК игрока по несколько сотен раз пинговать адрес роутера (шлюза) и игровой сервер и сравнить потери и разброс задержки, затем переключиться на кабель или мобильный интернет и измерить снова. На сервере посмотреть в ss -ti retrans и rtt (среднее/разброс) соединения этого игрока
Подтверждает
Уже в ping до роутера видны потери или скачущая задержка, а на кабеле они исчезают. На сервере большие retrans и разброс RTT только у соединения этого игрока
Опровергает
Если до роутера всё чисто, а потери начинаются дальше, причина у провайдера или на маршруте («Переполнение очереди в узком месте (потери от перегрузки)», «Смена маршрута и неисправный путь ECMP»). Если ухудшение одновременно у многих игроков одного провайдера, начинать с участка провайдера
Чем проверить
Проверка на стороне игрока
Подробнее
Повторы в беспроводном оборудовании создают джиттер (каждый повтор добавляет несколько ms), а потерей становится только пакет, превысивший лимит повторов. Поэтому по мере ухудшения радиосвязи симптомы нарастают в таком порядке: «джиттер → редкие фризы → частые фризы». В момент перехода между точками доступа (AP), то есть при роуминге, пакеты могут теряться подряд от десятков ms до нескольких секунд. В мобильной сети участок до базовой станции сам многократно повторяет передачу, поэтому проблема там чаще проявляется скачками задержки на сотни ms. Потерь при этом немного.
net/wireless/core.cLinux kernel Лимит повторов по умолчанию в беспроводном стеке Linux: 7 для коротких кадров, 4 для длинных (dot11ShortRetryLimit, dot11LongRetryLimit)
Wi-Fi roaming support in Apple devicesApple При переходе на другую AP данные нельзя отправлять, пока не завершится аутентификация на новой AP, а в среде 802.1X это может занять несколько секунд
IP SysctlLinux kernel tcp_recovery по умолчанию 0x1 (RACK), tcp_early_retrans по умолчанию 3 (TLP включён), TCP_NOTSENT_LOWAT и tcp_notsent_lowat ограничивают объём ещё не отправленных данных
tcp(7) — Linux manual pageLinux man-pages TCP_NODELAY отключает алгоритм Нейгла, и даже мелкие данные отправляются сразу