한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Анатомия игровых лагов › Первопричины повторных передач TCP

Перегрузка промежуточного оборудования (файрвол, IPS, защита от DDoS) Inline appliance PPS / CPU overload

ID причины rt-appliance-pps · Основной ответственный Команда инфраструктуры · Сетевая инфраструктура · Совместно Команда разработки · Разработка сервера

Открыть карточку в основной версии с иллюстрациями и экспериментами →

Файрволы, системы предотвращения вторжений (IPS) и оборудование защиты от DDoS проверяют каждый проходящий пакет. Как только поток превышает их возможности, необработанные пакеты выбрасываются.

Почему В часы пик и на событиях идёт больше сотен тысяч мелких игровых пакетов в секунду, или правила проверки слишком тяжёлые → Следствие Упор в лимит CPU или пакетов в секунду, оборудование отбрасывает пакеты. При ложном срабатывании блокируются и нормальные пакеты → На экране Фризы и телепортация одновременно на всех серверах за этим оборудованием, хуже всего при наплыве игроков

Симптомы
Фриз, Перемотка, Телепортация, Дисконнект
Факторы
Потери, Задержка
У кого
Весь сервер, Один регион или провайдер
Когда
Вечерний пик, При наплыве игроков
Ответственные
Основной ответственный Команда инфраструктуры · Сетевая инфраструктура · Совместно Команда разработки · Разработка сервера
Команда разработки: задачи
Передать команде инфраструктуры профиль игрового трафика (порты, размер пакетов, пакеты в секунду), собирать мелкие сообщения одного тика и отправлять разом, чтобы уменьшить число пакетов.
Команда инфраструктуры: задачи
Смотреть CPU, пакеты в секунду и счётчики дропов оборудования вместе с игровыми метриками, закладывать производительность оборудования из расчёта на мелкие пакеты, исключить игровые порты из тяжёлых проверок, подогнать правила защиты от DDoS под профиль игрового трафика.
Цифры для ориентира
Цифра «10 Gbps» в характеристиках оборудования часто указана для больших пакетов по 1 500 байт. Игровых пакетов размером около 100 байт при той же пропускной способности в 10 с лишним раз больше, поэтому лимит пакетов в секунду исчерпывается раньше, даже если линия связи выглядит свободной.
На графике
Упор в лимит (плато) · пакеты в секунду и загрузка CPU оборудования, число дропов на оборудовании
Где смотреть
Посмотреть счётчики CPU, пакетов в секунду и дропов на оборудовании и с одинаковым интервалом сравнить число пакетов на портах коммутаторов до и после оборудования. Наложить на тот же экран онлайн и долю повторных передач на серверах
Подтверждает
В часы пик и на событиях пакеты в секунду или CPU оборудования упираются в одно значение и выше не растут, из оборудования выходит меньше пакетов, чем входит, и одновременно растёт доля повторных передач на всех серверах за ним
Опровергает
Если число пакетов до и после оборудования совпадает и дропов на нём нет, причина другая. Если на сервере растут счётчики отбрасываний NIC или softnet dropped, это «Отбрасывание пакетов на принимающем сервере»
Чем проверить
Инструменты инфраструктуры (игровой код не нужен)

Источники

  1. RFC 2544: Benchmarking Methodology for Network Interconnect Devices IETF
    Производительность оборудования нужно проверять на разных размерах кадров, включая минимальный и максимальный (скорость обработки зависит от размера пакета)

Смотрите также

Тот же слой: Первопричины повторных передач TCP

Причины с тем же симптомом (Фриз) на других слоях

Карточка в основной версии с иллюстрациями и экспериментами