Неподходящая настройка RTO RTO min too low or too high
ID причины rt-rto-setting · Основной ответственный Команда инфраструктуры · Серверная инфраструктура · Совместно Команда разработки · Разработка сервера
Если слишком занизить минимальный RTO, от малейшей задержки возникают ложные повторные передачи, а значение по умолчанию (200 ms) для игры слишком велико, и каждая потеря даёт долгий фриз.
Почему Минимальный RTO сильно занижен под ЦОД, или на интернет-участке оставлено значение по умолчанию → Следствие Если мало, лавина повторных передач даже от мгновенной задержки, если много, долгое ожидание при каждой потере → На экране При значении по умолчанию каждая потеря даёт фриз на сотни ms, потом перемотку. Если слишком занизить, фризы короче, но резко растут ложные повторные передачи и линия связи загружается зря
Основной ответственный Команда инфраструктуры · Серверная инфраструктура · Совместно Команда разработки · Разработка сервера
Команда разработки: задачи
В Linux 6.15 и новее рассмотреть снижение потолка RTO для игровых соединений через TCP_RTO_MAX_MS (время до отказа от соединения тоже сокращается, поэтому вместе с этим задать время признания обрыва через TCP_USER_TIMEOUT), снижать минимальный RTO опцией сокета TCP_RTO_MIN_US (6.15 и новее) только для внутренних соединений между серверами, рассмотреть опцию сокета TCP_THIN_LINEAR_TIMEOUTS, чтобы только у игровых соединений RTO не удваивался при серии таймаутов.
Команда инфраструктуры: задачи
Снижать rto_min по маршрутам только для внутренних соединений между серверами, на интернет-участке оставить значение по умолчанию и компенсировать настройками RACK-TLP и thin stream (tcp_thin_linear_timeouts).
Цифры для ориентира
В Linux RTO = время пути туда и обратно + max(200 ms, разброс RTT×4). После каждой неудачи удваивается, максимум 120 с. В Linux 6.15 и новее этот потолок можно снизить до 1 с через TCP_RTO_MAX_MS.
На графике
Высоко с самого начала · RTO по соединениям, число ложных RTO
Где смотреть
Посмотреть настройку минимального RTO на сервере (rto_min в ip route show, в Linux 6.11 и новее sysctl net.ipv4.tcp_rto_min_us), rto и rtt в ss -ti и прирост TcpExtTCPSpuriousRTOs в nstat
Подтверждает
На сервере с заниженным минимумом rto интернет-соединений вплотную прижат к rtt, и TcpExtTCPSpuriousRTOs сильно растёт. При значении по умолчанию rto игровых соединений больше rtt на 200 ms и более, и каждая потеря даёт фриз на это время
Опровергает
Если rto соответствует расчёту по умолчанию (около rtt + 200 ms) и ложных RTO мало, но фризы необычно долгие, дело в сериях потерь или способе восстановления («Медленное восстановление потерь в thin stream», «Удаление опций TCP промежуточным оборудованием»)
IP SysctlLinux kernel tcp_rto_min_us по умолчанию 200000 (приоритет у опции маршрута rto_min и опции сокета TCP_RTO_MIN_US), tcp_rto_max_ms от 1 000 до 120 000 (по умолчанию 120 000), tcp_thin_linear_timeouts