Медленное восстановление потерь в thin stream Thin streams fall back to RTO
ID причины rt-thin · Основной ответственный Команда разработки · Разработка сервера · Совместно Команда инфраструктуры · Серверная инфраструктура, Команда разработки · Разработка клиента
Когда мелкие пакеты отправляются редко, как в играх, RTO наступает раньше, чем соберутся «3 следующих пакета». От тех же потерь поток стоит намного дольше, чем при больших передачах.
Почему Интервал между пакетами около 100 ms, поэтому неподтверждённых пакетов (in-flight) всего несколько → Следствие Чтобы собрались 3 дублирующих ACK, нужно больше 300 ms, поэтому раньше срабатывает RTO (пинг + 200 ms), при серии потерь он удваивается → На экране От одной потери фриз около 0,3 с, если потеряна и повторная передача, фриз почти на 1 с, потом перемотка
Основной ответственный Команда разработки · Разработка сервера · Совместно Команда инфраструктуры · Серверная инфраструктура, Команда разработки · Разработка клиента
Команда разработки: задачи
Сервер: включить TCP_NODELAY (при включённом Nagle у RACK нет следующих пакетов, по которым он принимает решение), пакеты реального времени отправлять по UDP со своей схемой повторных передач. Клиент: включить TCP_NODELAY, пакеты реального времени отправлять так же, как сервер (UDP).
Команда инфраструктуры: задачи
Использовать RACK-TLP (по умолчанию в современных Linux), через tcp_thin_linear_timeouts не давать RTO удваиваться при серии таймаутов.
Цифры для ориентира
При интервале пакетов 100 ms и пинге 60 ms до быстрой повторной передачи около 360 ms (пока не придут 3 следующих пакета и не вернётся их подтверждение), а RTO около 260 ms. С RACK пакет отправляется повторно, как только возвращается подтверждение следующего пакета, примерно через 160 ms. Если интервал пакетов больше 200 ms, RACK тоже не быстрее RTO.
На графике
Провал, затем пачка · объём приёма по соединениям, число истечений RTO
Где смотреть
Сравнить прирост TcpExtTCPTimeouts (истечения RTO), TcpExtTCPFastRetrans (быстрые повторные передачи), TcpExtTCPLossProbes и TcpExtTCPLossProbeRecovery (TLP) в nstat и посмотреть rto и backoff игровых соединений в ss -ti. Также проверить значения net.ipv4.tcp_recovery, tcp_early_retrans и tcp_sack на сервере
Подтверждает
Среди повторных передач истечений RTO больше, чем быстрых повторных передач, и у игровых соединений часто backoff больше 0 (соединение переживает RTO). Во время фриза принятый объём равен 0, а после восстановления всё приходит разом
Опровергает
Если большие передачи на том же сервере стоят так же долго, проблема в самих потерях и от формы соединения не зависит. Если проблема сосредоточена на соединениях без SACK и временных меток, это «Удаление опций TCP промежуточным оборудованием»
Чем проверить
Инструменты инфраструктуры (игровой код не нужен)
Подробнее
Раньше в Linux была и опция повторной передачи по одному дублирующему ACK для thin stream (tcp_thin_dupack), но в 2017 году её удалили, и теперь эту роль выполняет RACK. Если Nagle включён (TCP_NODELAY выключен), то, пока отправитель ждёт подтверждения потерянного пакета, новые пакеты тоже не уходят. У RACK не остаётся следующих пакетов для решения, и соединение ждёт RTO.
Источники
Thin-streams and TCPLinux kernel У thin stream (редкие потоки вроде игровых) быстрая повторная передача работает плохо, и восстановление зависит от длинного таймаута; критерий: меньше 4 неподтверждённых пакетов (in-flight)
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCPIETF RACK определяет потерю по тому, что дошёл пакет, отправленный позже; ожидание TLP равно 2·SRTT (если неподтверждённый пакет один, добавляется запас на отложенный ACK)
net/ipv4/proc.cLinux kernel Названия счётчиков в выводе nstat: TCPTimeouts, TCPFastRetrans, TCPLossProbes, TCPLossProbeRecovery
net/ipv4/tcp_timer.cLinux kernel TCPTimeouts растёт при истечении таймера повторной передачи (RTO)
SNMP counterLinux kernel TcpExtTCPFastRetrans (повторные передачи вне состояния Loss), TcpExtTCPLossProbes (отправлен TLP), TcpExtTCPLossProbeRecovery (потеря восстановлена через TLP)