Истечение отслеживания соединений в облачной группе безопасности Cloud security group connection tracking timeout
ID причины dc-cloud-conntrack · Основной ответственный Команда инфраструктуры · Серверная инфраструктура · Совместно Команда разработки · Разработка клиента, Команда разработки · Разработка сервера
Файрвол облачного сервера (группа безопасности) тоже отслеживает соединения, и запись о неактивном соединении истекает через заданное время. Поэтому даже на сервере, к которому подключаются напрямую без балансировщика, игрок после бездействия может получить дисконнект.
Почему Группа безопасности настроена так, что отслеживает игровые соединения (разрешены только определённые адреса, ограничены исходящие правила, трафик идёт через NLB и т. п.) → Следствие Запись о соединении, которое какое-то время неактивно, истекает, и последующие пакеты группа безопасности молча отбрасывает → На экране После отлучки игрок двигается, но ответа нет, затем дисконнект. Серверная программа долго ничего не замечает
Основной ответственный Команда инфраструктуры · Серверная инфраструктура · Совместно Команда разработки · Разработка клиента, Команда разработки · Разработка сервера
Команда разработки: задачи
Клиент: слать хартбиты с интервалом не больше половины самого короткого таймаута простоя (при 350 с для TCP не реже раза в 175 с, при 180 с для UDP-потока не реже раза в 90 с), при обрыве автоматически переподключаться. Сервер: отвечать на хартбиты и первым закрывать соединение, если их нет определённое время, подхватывать игрока по токену сессии.
Команда инфраструктуры: задачи
Проверить время отслеживания соединений на инстансе (TcpEstablishedTimeout) и при необходимости увеличить (для UDP максимум 180 с, больше нельзя), рассмотреть конфигурацию группы безопасности без отслеживания (игровой порт открыт для всех адресов, исходящие правила разрешают всё. Соединения через NLB всё равно отслеживаются), при переходе на новое поколение инстансов проводить тест с бездействием.
Цифры для ориентира
В AWS типы инстансов Nitro v6 по умолчанию удаляют запись о неактивном TCP-соединении через 350 с (остальные типы через 5 дней). Для UDP по умолчанию 180 с для потоков с многократным обменом запросами и ответами (stream) и 30 с для потоков в одну сторону или с единственной парой запрос–ответ.
На графике
Массовый обрыв соединений · число обрывов, время бездействия перед обрывом
Где смотреть
Проверить настройку времени отслеживания соединений на инстансе и правила группы безопасности (создают ли они отслеживание), собрать время бездействия у оборвавшихся соединений. Сразу после обрыва посмотреть на сервере через ss -tnoi, остаётся ли соединение в ESTABLISHED с работающим таймером повторной передачи (timer:(on,…)) и растущим backoff
Подтверждает
Время бездействия у оборвавшихся соединений скапливается сразу после 350 с для TCP, 180 с для UDP-потока, 30 с для UDP в одну сторону, а сокет на стороне сервера, не заметив обрыва, остаётся в ESTABLISHED (если серверу есть что отправить, он только повторяет передачу)
Опровергает
Если группа безопасности настроена без отслеживания (игровой порт открыт для всех адресов, исходящие правила разрешают всё, NLB на пути нет), причина в другом. Если трафик идёт через NLB, сравнить значения с таймаутом из причины «Таймаут простоя балансировщика»
Чем проверить
Инструменты инфраструктуры (игровой код не нужен)
Источники
Amazon EC2 security group connection trackingAWS Отслеживание неактивных TCP-соединений по умолчанию 350 с (Nitro v6, у остальных 432 000 с = 5 дней), UDP в одну сторону 30 с, stream 180 с (максимум 180), при правилах «разрешить все адреса» отслеживания нет, соединения через NLB отслеживаются всегда
ss(8) — Linux manual pageiproute2 timer:(on,…) в выводе -o означает таймер повторной передачи, backoff в выводе -i показывает, сколько раз ожидание перед повтором удваивалось