TCP F-RTO RFC 5682: Устранение ложных таймаутов RTO в мобильных VPN

Современные каналы сотовой связи характеризуются высокой нестабильностью задержек. Когда мобильное устройство передает данные через защищенный VPN-туннель, физические явления на радиоинтерфейсе — переключение между базовыми станциями, замирания радиосигнала и очереди планировщика на уровне L2 — нередко вызывают внезапное увеличение времени кругового обращения (RTT) на сотни миллисекунд. В соответствии с классической спецификацией TCP (RFC 5681), таймер Retransmission Timeout (RTO) отвечает за надежность и живучесть сессии. Однако при возникновении кратковременного скачка задержки таймер RTO срабатывает раньше, чем задержанные пакеты успевают дойти до адресата, хотя никакой реальной потери пакетов в сети не произошло. Классический стек TCP воспринимает это событие как критическую перегрузку, сбрасывает окно перегрузки (cwnd) до 1 MSS и начинает полную повторную отправку всех переданных ранее сегментов. Подобная ситуация называется ложным таймаутом (Spurious RTO).

Для устранения деградации пропускной способности Инженерный совет интернета (IETF) утвердил спецификацию RFC 5682: Forward RTO-Recovery (F-RTO): алгоритм обнаружения ложных таймаутов повторной передачи для TCP. Изменяя последовательность отправки пакетов после срабатывания таймера RTO, F-RTO проверяет, продвигают ли поступающие подтверждения окно передачи благодаря ранее отправленным пакетам. Это позволяет стеку безопасно отменить штрафное уменьшение окна и сохранить максимальную скорость передачи.

[Стандартный TCP RFC 5681: Коллапс конвейера при ложном RTO]
Отправитель: Передает сегменты 1, 2, 3, 4, 5, 6
Сотовая сеть: Хендовер задерживает пакеты на 300 мс (таймер RTO истекает на 200 мс!)
Отправитель: Фиксирует потерю! Сбрасывает cwnd до 1 MSS, уменьшает ssthresh вдвое
Отправитель: Повторно передает сегмент 1, затем сегмент 2, сегмент 3... (Избыточный трафик)
Сегменты 1-6 благополучно доходят, но сессия надолго застревает в фазе Slow Start

[RFC 5682 F-RTO: Зондирование новыми данными и мгновенное восстановление]
Отправитель: Таймер RTO истек; отправляется ТОЛЬКО сегмент 1
Отправитель: Получает ACK, продвигающий окно; включается алгоритм F-RTO
Отправитель: Отправляет ДВА НОВЫХ сегмента (7 и 8) вместо повторов старых данных
Получатель: Присылает подтверждение на исходные переданные пакеты (сегменты 2-6)
Отправитель: Ложный RTO подтвержден! Отменяет штраф cwnd и возобновляет полную скорость

Кризис ложных таймаутов: как джиттер задержки парализует мобильные VPN

Концепция управления перегрузкой TCP изначально строилась на постулате, что потеря пакета является прямым следствием переполнения буферов на промежуточных сетевых узлах. В проводных инфраструктурах сброс пакетов действительно служит главным признаком перегрузки. В беспроводных мобильных средах физические свойства радиоканала нарушают эту аксиому.

Хендоверы сотовых вышек, раздувание буферов и динамика таймера RTO

В сетях LTE и 5G мобильные терминалы регулярно переключаются между базовыми станциями (gNodeB / eNodeB). Процедуры переконфигурации Radio Resource Control (RRC) и перенаправление очередей на канальном уровне создают технологические паузы передачи длительностью от 80 до 400 мс.

                    ┌─────────────────────────┐
                    │     Стек TCP ядра       │
                    └────────────┬────────────┘
                                 │
           ┌─────────────────────┴─────────────────────┐
           ▼                                           ▼
[Стандартный цикл RFC 5681]                 [Алгоритм F-RTO RFC 5682]
  1. Срабатывание таймера RTO                 1. Срабатывание таймера RTO
  2. cwnd = 1 MSS                             2. Повтор только первого сегмента
  3. ssthresh = FlightSize / 2                3. Ожидание первого подтверждения
  4. Повтор всех неподтвержденных данных      4. Передача двух новых сегментов
  5. Затяжной выход из Slow Start             5. Проверка продвижения окна ACK
  6. Рост задержки на секунды                 6. Подтверждение ложного RTO и откат cwnd

При инкапсуляции трафика в VPN-туннель подобные флуктуации задержки становятся еще более выраженными. Таймер RTO рассчитывается динамически на основе сглаженного времени кругового обращения (SRTT) и вариации задержки (RTTVAR):

$$\text{RTO} = \text{SRTT} + \max(G, 4 \times \text{RTTVAR})$$

где $G$ — гранулярность системного таймера. При стабильной передаче расчетный RTO может составлять всего десятки миллисекунд. В момент хендовера резкий рост задержки до нескольких сотен миллисекунд приводит к преждевременному срабатыванию таймера при отсутствии реальных потерь в радиоканале.

Штраф медленного старта: как ложный RTO обрушивает пропускную способность TCP

Срабатывание ложного RTO наносит серьезный ущерб производительности транспортного соединения:

1. Обнуление окна перегрузки: значение cwnd падает до 1 MSS, что фактически замораживает передачу.
2. Снижение порога ssthresh: порог перегрузки уменьшается вдвое от объема данных в полете, переводя соединение в фазу Congestion Avoidance задолго до достижения емкости канала.
3. Шквал дублирующих пакетов: передающая сторона начинает повторно отправлять данные, которые уже находятся в пути, засоряя радиоэфир ненужным трафиком.
4. Зависание чувствительного трафика: соединению требуются десятки интервалов RTT для возврата к прежней скорости, вызывая буферизацию потокового видео и задержки в приложениях.

Архитектурное устройство RFC 5682: как F-RTO распознает ложные таймауты

Алгоритм Forward RTO-Recovery, стандартизированный в RFC 5682, использует логику тестового зондирования канала после срабатывания таймера, не требуя модификаций на принимающей стороне.

              ┌────────────────────────────────┐
              │      Истечение таймера RTO     │
              └───────────────┬────────────────┘
                              │
                              ▼
              ┌────────────────────────────────┐
              │  Повтор сегмента (SN=SND.UNA)  │
              └───────────────┬────────────────┘
                              │
                              ▼
                    Ожидание первого ACK
                              │
              ┌───────────────┴───────────────┐
              ▼                               ▼
     [Повторный DupACK]              [Продвигающий ACK]
              │                               │
              ▼                               ▼
    Реальная потеря пакета            Фаза проверки F-RTO
    Обычное восстановление            Отправка 2 НОВЫХ сегментов
                                              │
                                              ▼
                                    Ожидание второго ACK
                                              │
                              ┌───────────────┴───────────────┐
                              ▼                               ▼
                     [ACK на новые сегменты]        [ACK на старые данные]
                              │                               │
                              ▼                               ▼
                     Частичная потеря/сдвиг         ЛОЖНЫЙ ТАЙМАУТ ПОДТВЕРЖДЕН!
                     Стандартное восстановление     Откат cwnd по алгоритму Eifel

Зондирование сетевого канала двумя новыми сегментами данных

Последовательность операций алгоритма F-RTO регламентирована следующим образом:

1. Фаза инициализации: при истечении таймера RTO стек отправляет повторно только один сегмент с номером SND.UNA. Переменная Recovery активируется, однако решение о перманентном сбросе cwnd и ssthresh временно откладывается.
2. Оценка первого входящего ACK:
   • Если получен дублирующий ACK или подтверждение, не сдвигающее границу SND.UNA, алгоритм прекращает процедуру F-RTO и переходит к стандартному режиму восстановления с повторной передачей всех данных.
   • Если первый ACK продвигает SND.UNA, это подтверждает прием данных получателем. В этот момент стек не передает старые сегменты, а незамедлительно отправляет до двух ранее не передававшихся сегментов (SND.NXT и SND.NXT + 1).
3. Решение по второму входящему ACK:
   • Если второй ACK продвигает границу окна за счет подтверждения данных, отправленных еще до наступления RTO, это математически доказывает, что пакеты не были потеряны, а исходный таймаут являлся ложным.

F-RTO с поддержкой SACK: устранение неопределенности ACK в каналах с потерями

При включенной опции Selective Acknowledgement (SACK, RFC 2018 / RFC 2883) точность работы F-RTO многократно возрастает.

Анализируя блоки SACK в первом же поступившем ответе, алгоритм может определить, были ли получены сегменты, отправленные до наступления таймаута после SND.UNA. Если блоки SACK подтверждают прием исходных данных, F-RTO констатирует ложный таймаут без необходимости ожидания второго ACK, экономя полный цикл RTT.

Устранение последствий RTO: восстановление окна перегрузки и избегание коллапса

Точное обнаружение ложного таймаута позволяет восстановить исходные параметры сессии и избежать длительной фазы медленного старта.

Механика отката CWND и мгновенного восстановления FlightSize

При фиксации ложного срабатывания F-RTO использует алгоритм отклика Eifel (RFC 4015) для восстановления параметров окна:

$$\text{cwnd} = \max(\text{FlightSize} + \text{MSS}, \text{saved_cwnd})$$

$$\text{ssthresh} = \text{saved_ssthresh}$$

Благодаря восстановлению сохраненных значений соединение полностью избегает медленного старта и продолжает обмен данными на полной канальной скорости.

Перекалибровка оценщика RTT и защита SRTT от искажения

Одной из угроз при ложных таймаутах является искажение метрик SRTT. Если задержка, вызванная технологической паузой хендовера, попадет в расчет по алгоритму Карна, последующие значения RTO окажутся завышенными.

RFC 5682 предписывает исключать неоднозначные замеры времени повторно переданных сегментов при успешном завершении процедуры F-RTO, используя только чистые замеры от новых зондирующих пакетов.

Инженерия уровня ядра: архитектура мобильной устойчивости RiceGuard

В сервисе VPNRice оптимизация транспортного уровня осуществляется на уровне ядра операционной системы с использованием технологий RiceGuard:

                    ┌─────────────────────────┐
                    │    Прикладной трафик    │
                    └────────────┬────────────┘
                                 │
                    ┌────────────▼────────────┐
                    │     Ядро RiceGuard      │
                    └──────┬───────────┬──────┘
                           │           │
          ┌────────────────▼───┐   ┌───▼────────────────┐
          │   Модуль TCP F-RTO │   │ Бесшовный роуминг  │
          └────────────────┬───┘   └───┬────────────────┘
                           │           │
                    ┌──────▼───────────▼──────┐
                    │ Защищенный туннель L3   │
                    └─────────────────────────┘

1. Адаптивная настройка F-RTO: RiceGuard непрерывно отслеживает профиль стабильности радиоканала. В условиях частой смены базовых станций ядро динамически корректирует поведение F-RTO, предотвращая ложные срабатывания.
2. Защита контекста сессий: при кратковременных разрывах соединения транспортные сокеты удерживаются от сброса, а поддержка расширений SACK гарантирует быстрое возобновление передачи без повторной пересылки данных.
3. Синхронизация с алгоритмами BBR: совместное использование с современными механизмами BBR исключает переход алгоритма в режим удержания при всплесках задержек на мобильных устройствах.

Диагностика и аудит: проверка работы F-RTO в среде Linux

Системные администраторы и сетевые инженеры могут легко проконтролировать работу механизма F-RTO на серверах Linux.

Анализ телеметрии SACK и F-RTO в реальном времени с помощью утилиты ss

Утилита ss позволяет просматривать внутренние параметры TCP-сокетов:

# Просмотр внутренних параметров активных сокетов TCP
ss -tin "sport = :443 or dport = :443"

В выводе команды следует обратить внимание на следующие параметры:

• sack: флаг согласования и активности опции SACK.
• app_limited: признак ограничения скорости со стороны приложения или сетевого окна.
• rto: текущее расчетное значение таймера повторной передачи в миллисекундах.
• rtt: текущее сглаженное значение RTT и вариация задержки.

Настройка параметров ядра и конфигурации sysctl для tcp_frto

В ядре Linux поведение алгоритма управляется параметром net.ipv4.tcp_frto:

# Проверка текущего значения параметра tcp_frto
sysctl net.ipv4.tcp_frto

# Значения параметра:
# 0 = F-RTO отключен
# 1 = базовый алгоритм F-RTO (без учета SACK)
# 2 = усовершенствованный алгоритм F-RTO с поддержкой SACK (рекомендуется)

# Включение оптимизированного режима F-RTO
sudo sysctl -w net.ipv4.tcp_frto=2

# Проверка общесистемной статистики ложных таймаутов
cat /proc/net/netstat | grep -E "TCPSPuriousRTOs|TCPSackRecovery"

Значения метрик в /proc/net/netstat:

• TCPSPuriousRTOs: общее количество успешно выявленных и нейтрализованных ложных RTO.
• TCPSackRecovery: количество циклов успешного восстановления на основе SACK.
• TCPSackReneging: случаи отзыва ранее подтвержденных данных из-за нехватки памяти у получателя.

Практическая проверка и тесты производительности мобильного транспорта

В тестах с эмуляцией частых хендоверов и всплесков задержек включение механизма RFC 5682 F-RTO демонстрирует стабильное преимущество:

Трансформируя ложные таймауты из деструктивных сетевых сбоев в штатные процедуры зондирования канала, RFC 5682 F-RTO гарантирует надежную работу современных VPN-туннелей в изменчивых беспроводных средах. В сочетании с оптимизацией стека это обеспечивает непрерывность мультимедийных трансляций, отзывчивость онлайн-сервисов и максимальное использование пропускной способности мобильных сетей.

Скачать VPNRice.