ID причины rt-sack-stripped · Основной ответственный Команда инфраструктуры · Сетевая инфраструктура · Совместно Команда инфраструктуры · Серверная инфраструктура
Если некоторые файрволы или ускорители удаляют или меняют опции TCP, то при потере нескольких пакетов они восстанавливаются по одному за RTT или окно (сколько можно отправить за раз) становится маленьким, и передача замедляется.
Почему «Нормализация TCP» на файрволе или старый ускоритель удаляют опции SACK, временных меток и масштабирования окна → Следствие Если потеряно несколько пакетов, они восстанавливаются по одному за RTT, окно ограничено 64 KB → На экране Каждая потеря даёт намного более долгий фриз (без SACK нельзя использовать и RACK-TLP), после которого перемотка. Большие передачи вроде патчей тоже идут медленно
Основной ответственный Команда инфраструктуры · Сетевая инфраструктура · Совместно Команда инфраструктуры · Серверная инфраструктура
Команда инфраструктуры: задачи
Сеть: отключить нормализацию TCP на этом оборудовании, проверить и рандомизацию номеров последовательности на файрволе, сравнить опции SYN по захватам пакетов на обоих концах. Серверы и ОС: проверить в ss -ti, не сосредоточены ли соединения без sack и wscale на определённом маршруте (ПК с Windows в зависимости от настроек не используют ts, поэтому отсутствие только ts может быть нормой), проверить, что net.ipv4.tcp_sack на сервере равен 1.
На графике
Высоко с самого начала · число восстановлений, начатых без SACK (TcpExtTCPRenoRecovery)
Где смотреть
Проверить в ss -ti, есть ли у каждого соединения отметки sack и wscale, и посмотреть в nstat соотношение TcpExtTCPRenoRecovery (восстановления без SACK) и TcpExtTCPSackRecovery, а также TcpExtTCPSACKDiscard (число SACK-блоков, выброшенных как несогласованные). На подозрительном маршруте захватить SYN на обоих концах и сравнить опции (tcp.options.sack_perm в Wireshark и др.)
Подтверждает
sack и wscale отсутствуют только у соединений через определённый маршрут или оборудование, и доля TcpExtTCPRenoRecovery высокая. Опция разрешения SACK, которая была в SYN на стороне отправителя, отсутствует в SYN на стороне получателя. Если причина в рандомизации номеров последовательности, опции на месте, но растёт TcpExtTCPSACKDiscard
Опровергает
Если sack нет у всех соединений, сначала проверить значение net.ipv4.tcp_sack на сервере. Если опции целы и TcpExtTCPSACKDiscard не меняется, медленное восстановление объясняется чем-то другим («Медленное восстановление потерь в thin stream»)
Чем проверить
Инструменты инфраструктуры (игровой код не нужен)
Подробнее
SACK может сломаться, даже если опции сохранились. Если рандомизация номеров последовательности на файрволе (sequence randomization) меняет номера только в заголовке и оставляет прежними номера внутри SACK, отправитель выбрасывает несогласованные SACK. Тот же результат, если в 2019 году из-за уязвимости SACK на сервере его отключили через tcp_sack=0 и забыли.