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

Ложные быстрые повторные передачи из-за нарушения порядка Reordering triggers spurious fast retransmit

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

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

Если на нескольких путях или агрегированных линках порядок пакетов меняется, получатель дублирующими ACK сообщает «пакета не хватает», и отправитель повторно отправляет пакеты, которые не терялись.

Почему Порядок перемешивают оборудование с балансировкой по отдельным пакетам, LAG (агрегирование линков) с распределением по пакетам и моменты смены маршрута → Следствие Следующие пакеты приходят раньше, накапливаются 3 дублирующих ACK → быстрая повторная передача → На экране На редкие игровые пакеты почти не влияет. Медленнее идут крупные обновления в местах скопления игроков и загрузка патчей, иногда микрофризы

Симптомы

Микрофризы, Задержка ввода

Факторы

Джиттер

У кого

Один регион или провайдер, Весь сервер

Когда

Всегда, При наплыве игроков

Ответственные

Основной ответственный Команда инфраструктуры · Сетевая инфраструктура · Совместно Команда инфраструктуры · Серверная инфраструктура

Команда инфраструктуры: задачи

Сеть: балансировка по соединениям вместо балансировки по пакетам (ECMP и LAG по хешу адресов и портов). Серверы и ОС: использовать RACK (обнаружение потерь по времени, устойчиво к нарушению порядка. Обнаружив ложную повторную передачу по DSACK, автоматически расширяет допуск на нарушение порядка), проверить степень нарушения порядка, которую Linux автоматически оценивает для каждого соединения (значение reordering в ss -ti, начальное значение tcp_reordering=3).

На графике

Высоко с самого начала · число обнаруженных нарушений порядка, число полученных DSACK

Где смотреть

Посмотреть в nstat TcpExtTCPSACKReorder и TcpExtTCPTSReorder (сколько раз обнаружено нарушение порядка) и TcpExtTCPDSACKRecv, по соединениям смотреть reordering (выводится, если не равно 3) и reord_seen в ss -ti. В захвате пакетов использовать фильтр Wireshark tcp.analysis.out_of_order

Подтверждает

Счётчики нарушения порядка и DSACK стабильно растут независимо от времени суток, а у соединений через определённый путь или оборудование значение reordering больше 3. В захвате на стороне получателя следующий пакет приходит первым, а предыдущий тоже вскоре доходит

Опровергает

Если счётчики нарушения порядка не меняются, а растёт TcpExtTCPLostRetransmit, это реальные потери. Если DSACK растёт только в моменты скачков RTT, это «Ложные повторные передачи из-за скачков задержки»

Чем проверить

Инструменты инфраструктуры (игровой код не нужен)

Источники

1. RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
   При балансировке по отдельным пакетам порядок меняется, и если 3 и больше следующих пакетов приходят раньше, TCP делает ложную быструю повторную передачу
2. RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm IETF
   ECMP, выбирающий путь по хешу полей заголовка, определяющих поток (балансировка по потокам)
3. RFC 5681: TCP Congestion Control IETF
   Быстрая повторная передача по третьему дублирующему ACK
4. RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
   RACK определяет потери по времени и устойчив к нарушению порядка, а получив DSACK, увеличивает допустимое время нарушения порядка (reo_wnd)
5. IP Sysctl Linux kernel
   Начальное значение tcp_reordering 3 (для каждого соединения автоматически подстраивается вплоть до tcp_max_reordering), настройка RACK в tcp_recovery
6. misc/ss.c iproute2
   ss -ti выводит reordering:значение, если reordering соединения отличается от значения по умолчанию 3, и reord_seen:число, если соединение сталкивалось с нарушением порядка
7. SNMP counter Linux kernel
   TcpExtTCPSACKReorder и TcpExtTCPTSReorder (обнаружение нарушения порядка), TcpExtTCPDSACKRecv (число полученных DSACK), TcpExtTCPLostRetransmit (повторно отправленный пакет снова потерян)
8. include/uapi/linux/tcp.h Linux kernel
   tcpi_reord_seen в tcp_info: сколько раз соединение сталкивалось с нарушением порядка
9. Display Filter Reference: Transmission Control Protocol Wireshark
   Фильтр отображения tcp.analysis.out_of_order

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

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

• Потери на беспроводном участке
• Переполнение очереди в узком месте (потери от перегрузки)
• Переполнение неглубоких буферов всплесками отправки
• Отбрасывание избытка полисером
• Физические ошибки (неисправные кабели, оптические модули и разъёмы)
• Несовпадение дуплекса
• Отбрасывание пакетов на принимающем сервере
• Отбрасывание пакетов файрволом или conntrack
• Перегрузка промежуточного оборудования (файрвол, IPS, защита от DDoS)
• Чёрная дыра MTU (большие пакеты теряются раз за разом)
• Истечение записи NAT или балансировщика посреди соединения
• Смена маршрута и неисправный путь ECMP
• Ложные повторные передачи из-за скачков задержки
• Задержка и потеря ACK (забитая отдача)
• Неподходящая настройка RTO
• Медленное восстановление потерь в thin stream
• Удаление опций TCP промежуточным оборудованием
• Нулевое окно (остановка, похожая на повторную передачу)
• Повторная передача запроса на подключение (SYN)

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

• Всплески времени кадра L1 Процесс игрового клиента
• Сборка мусора на клиенте L1 Процесс игрового клиента
• Синхронная загрузка и компиляция шейдеров в главном потоке L1 Процесс игрового клиента
• Стриминг ассетов отстаёт из-за медленного накопителя L1 Процесс игрового клиента
• Нагрузка на рендеринг при большом скоплении игроков L1 Процесс игрового клиента
• Буфер интерполяции отсутствует или слишком короткий L1 Процесс игрового клиента
• Чрезмерная экстраполяция (dead reckoning) L1 Процесс игрового клиента
• Лавина догоняющих шагов при фиксированном таймстепе L1 Процесс игрового клиента

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