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 доходять неушкодженими, але з'єднання застряє у повільному старті

[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 та відкат

Під час передавання даних у зашифрованому тунелі 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 виявляє хибні таймаути

Специфікація RFC 5682 визначає механізм Forward RTO-Recovery, який за допомогою вивіреної послідовності відправлення даних після таймауту надійно ідентифікує помилкові спрацьовування без жодних модифікацій на стороні отримувача.

              ┌────────────────────────────────┐
              │      Спливання таймера 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: згладжене значення затримки та її варіація.

Оптимізація параметрів 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.