TCP Early Retransmit RFC 5827: Усунення Затримок RTO у Тонких Потоках VPN

Надійність транспортного протоколу Transmission Control Protocol (TCP) базується на механізмах виявлення втрат, здатних розрізняти короткочасну зміну порядку слідування сегментів і реальну втрату пакетів на проміжних маршрутизаторах. Базовий алгоритм швидкої повторної передачі Fast Retransmit (RFC 5681) виходить із припущення, що мережевий конвеєр транспортує безперервний потік даних, достатній для генерації постійного потоку підтверджень (ACK) від сторони, що приймає.

Під час масового пересилання файлів із десятками активних сегментів у польоті Fast Retransmit працює ефективно: три послідовні дубльовані підтвердження (Duplicate ACK) свідчать про ізольовану втрату, викликаючи миттєву повторну передачу сегмента без простою з'єднання. Однак це класичне припущення руйнується в сучасних сценаріях інтерактивної взаємодії, де застосунки генерують тонкі потоки (thin streams), короткі спалахи активності або оперують вузькими вікнами перевантаження.

Коли в з'єднанні TCP передається менше чотирьох пакетів одночасно, зустрічні дубльовані підтвердження фізично не здатні досягти нормативного порогу в три одиниці. Канал зависає до моменту спрацьовування грубого таймера повторної передачі Retransmission Timeout (RTO), що створює штраф до затримки тривалістю від двохсот мілісекунд до цілої секунди.

Інженерна рада інтернету (IETF) стандартизувала специфікацію RFC 5827 — Early Retransmit для TCP і SCTP. Завдяки динамічному зниженню порогу дубльованих підтверджень за малого обсягу даних у дорозі, Early Retransmit забезпечує миттєве відновлення втрачених пакетів у чутливих до затримок VPN і проксі-каналах.

[Стандартний Fast Retransmit: Потребує від 4 пакетів у польоті]
Відправник ──[P1]──[P2]──[P3]──[P4]──> Одержувач (P1 втрачено на маршруті)
Відправник <──[Ack 1]──[DupAck 1]──[DupAck 2]──[DupAck 3]── (3 DupACK запускають повтор)

[Зависання малого вікна без RFC 5827: У польоті лише 2 пакети]
Відправник ──[P1]──[P2]──────────────> Одержувач (P1 втрачено на маршруті)
Відправник <──[Ack 1]──[DupAck 1]──── (Отримано лише 1 DupACK! Fast Retransmit блоковано)
           └─── ПРОСТІЙ З'ЄДНАННЯ ─────> [Очікування вичерпання таймера RTO 200–1000 мс!]

[RFC 5827 Early Retransmit: Адаптивне зниження порогу]
Відправник ──[P1]──[P2]──────────────> Одержувач (P1 втрачено на маршруті)
Відправник <──[Ack 1]──[DupAck 1]──── (FlightSize < 4*SMSS -> Поріг зменшено до 1)
Відправник ──[Повтор P1]─────────────> (Миттєве відновлення без простою RTO)

Проблема малого вікна: чому Fast Retransmit дає збій в інтерактивних потоках

Алгоритм Fast Retransmit створювався з урахуванням того, що порушення порядку пакетів в інтернеті зазвичай є локальним явищем і рідко перевищує зміщення на три сегменти. Вимога отримати три дубльовані ACK запобігає передчасному повторному відправленню сегмента, який лише трохи запізнився через паралельну маршрутизацію.

Ця евристика чудово зберігає ресурси каналу під час об'ємних завантажень, проте створює серйозну ваду в інтерактивних низькоінтенсивних комунікаціях.

Чому стандартний TCP Fast Retransmit вимагає три дубльовані ACK

Згідно з регламентом керування перевантаженням RFC 5681, сторона, що приймає, повинна негайно повернути дубльований ACK у відповідь на кожен отриманий сегмент, порядковий номер якого порушує очікувану послідовність. Ця відповідь дублює найбільший номер байта, прийнятого послідовно без прогалин.

Щоб відправник зміг накопичити три дубльовані підтвердження, слідом за втраченим пакетом до пункту призначення мають благополучно дійти щонайменше три наступні сегменти:

$$\text{Мінімум пакетів у польоті} = 1\ (\text{Втрачений сегмент}) + 3\ (\text{Наступні сегменти}) = 4\ \text{Сегменти}$$

Якщо вікно перевантаження ($\text{CWND}$) або загальна кількість непідтверджених байтів у польоті ($\text{FlightSize}$) є меншою за $4 \times \text{SMSS}$ (розмір максимального сегмента відправника), формування трьох дублікатів DupACK є математично неможливим. Одержувач повертає один або два дублікати і припиняє передачу відповідей.

Затримки тайм-ауту повторної передачі RTO під час імпульсного трафіку

Якщо кількість дубльованих підтверджень зупиняється на позначці одного чи двох, стандартний стек TCP занурюється у вимушене очікування. Передавання призупиняється на час очікування завершення таймера $RTO$, що вираховується за алгоритмом RFC 6298:

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

У реальних конфігураціях нижній ліміт $RTO$ обмежений значенням $200\text{ мс}$ у ядрі Linux та може сягати $1000\text{ мс}$ на інших мережевих платформах.

Для інтерактивного трафіку реального часу — символів терміналів SSH, звернень до API RPC, сигнальних повідомлень WebRTC, запитів DNS поверх HTTPS або змагальних онлайн-ігор — затримка від $200\text{ мс}$ до $1000\text{ мс}$ руйнує плавність взаємодії. Користувач фіксує мимовільне завмирання передачі та сплески мережевого джитера всередині тунелю.

Архітектура та протокольні алгоритми RFC 5827 Early Retransmit

Специфікація RFC 5827 розв'язує цю проблему, надаючи відправникові можливість гнучко зменшувати поріг спрацьовування дубльованих ACK, якщо поточна ємність конвеєра замала для генерації трьох відповідей.

Динамічна адаптація порогу на основі обсягу даних у польоті

Коли надходить нове підтвердження, стек TCP оцінює обсяг активних даних, які перебувають у мережевому транзиті. Якщо непідтверджений залишок перебуває в зоні ризику, алгоритм Early Retransmit перераховує поріг активації:

1. Оцінка обсягу в польоті: Якщо $\text{FlightSize} < 4 \times \text{SMSS}$, відправник констатує неможливість отримання трьох DupACK.
2. Адаптивне коригування: Поріг дублікатів ($ER\text{_threshold}$) встановлюється рівним кількості підтверджень, яку фізично здатні згенерувати наявні в польоті сегменти: $$ER\text{_threshold} = \left\lfloor \frac{\text{FlightSize} - 1}{\text{SMSS}} \right\rfloor$$
   • За умови $\text{FlightSize} = 3 \times \text{SMSS}$ поріг $ER\text{_threshold} = 2$.
   • За умови $\text{FlightSize} = 2 \times \text{SMSS}$ поріг $ER\text{_threshold} = 1$.
3. Відсутність нових даних у черзі: Early Retransmit активується виключно тоді, коли в буфері сокета немає нових даних, готових до відправлення. Якщо застосунок надав нові байти, система надає пріоритет механізму Limited Transmit (RFC 3042), передаючи нові сегменти для збору трьох DupACK у звичайному режимі.

Порівняння реалізацій Early Retransmit на рівні сегментів і байтів

Стандарт RFC 5827 описує два методи реалізації механізму:

• Early Retransmit на рівні сегментів: Створений для з'єднань без підтримки вибіркових підтверджень Selective Acknowledgment (SACK). Відправник веде підрахунок кількості переданих сегментів і виконує повторну відправку, коли число дублікатів збігається з кількістю пакетів у польоті.
• Early Retransmit на рівні байтів: Оптимізований для стеків із підтримкою SACK (RFC 2018). Відправник аналізує точні діапазони байтів у блоках SACK. Якщо блоки свідчать про те, що всі байти після пропущеного інтервалу успішно досягли адресата, відправник безпомилково ініціює повторне відправлення.

Сучасні дистрибутиви Linux послуговуються побайтовою моделлю, оскільки використання SACK узгоджується практично для всіх інтернет-сесій.

Взаємодія із SACK і захист від помилкових повторних відправлень

Зменшення порогу дубльованих підтверджень несе ризик хибного сприйняття зміни порядку пакетів як їхньої втрати. Якщо сегмент затримався на кілька мілісекунд у паралельних чергах комутатора, поріг в один DupACK міг би спричинити зайве надсилання копії.

Специфікація RFC 5827 містить чіткі інженерні запобіжники для захисту від перевитрати пропускної здатності.

Використання вибіркових підтверджень для точної локалізації втрат

За активного розширення SACK сторона, що приймає, повертає точні межі успішно отриманих фрагментів. Розглянемо приклад передавання трьох сегментів:

Відправник передає: Seq 1000-2000, Seq 2000-3000, Seq 3000-4000
Сегмент 1000-2000 втрачено.
Одержувач приймає 2000-3000 -> DupACK: Ack 1000, SACK [2000-3000]
Одержувач приймає 3000-4000 -> DupACK: Ack 1000, SACK [2000-4000]

Отримавши другий DupACK, відправник за блоками SACK фіксує, що наступні 2000 байтів успішно досягли одержувача. Оскільки загальний обсяг даних у польоті складав лише 3000 байтів, у мережі не залишилося інших сегментів. Очікувати на третій дублікат немає потреби — Early Retransmit негайно передає втрачений сегмент.

Згладжування перевпорядкування пакетів за допомогою таймера затримки

Щоб запобігти передчасним спрацьовуванням у мережах із незначними затримками сегментів, реалізація протоколу активує таймер невеликої затримки перед виконанням раннього відправлення.

Коли кількість дублікатів досягає зниженого порогу, ядро не надсилає пакет негайно, а запускає таймер, прив'язаний до згладженого часу кругового обігу:

$$\text{ER_Delay} = \frac{\text{SRTT}}{4}$$

Якщо затриманий сегмент доходить до місця призначення, і підтвердження, що закриває прогалину, повертається до завершення $\text{ER_Delay}$, повторна відправка скасовується. Якщо таймер вичерпано, втрату вважають підтвердженою і пакет надсилається повторно. Це дає змогу позбутися простоїв RTO зі збереженням стійкості до перевпорядкування.

Динаміка затримки та пропускної здатності в зашифрованих тунелях

Інкапсуляція мережевого трафіку у криптографічні тунелі — WireGuard, IPsec ESP чи OpenVPN — вносить зміни в динаміку транспортного рівня. Додавання зовнішніх заголовків IP, UDP та ESP зменшує корисний розмір MSS і збільшує ймовірність фрагментації.

Усунення хвостових затримок RTO в з'єднаннях під захистом VPN

У мобільних мережах або під час зміни точок доступу Wi-Fi втрата пакетів має спорадичний характер і викликається радіозавадами або чергами на базових станціях.

У стандартних з'єднаннях без підтримки раннього повторного надсилання втрата пакета в малому вікні спричиняє раптове завмирання. Тайм-аут RTO обнуляє вікно перевантаження до одного сегмента ($\text{CWND} = 1$), через що з'єднання вимушене повільно розганятися знову за протоколом повільного старту (Slow Start).

Специфікація RFC 5827 утримує з'єднання в стані швидкого відновлення (Fast Recovery), зберігаючи половину вікна замість його повного скидання.

Архітектура ядра: оптимізація мережевого стека в рушії RiceGuard

Більшість користувацьких програмних рішень сприймають системний мережевий стек як незмінний чорний ящик, спрямовуючи пакети крізь стандартні системні конфігурації ядра, розраховані на кабельні мережі дата-центрів.

Архітектура VPNRice впроваджує модуль оптимізації RiceGuard для тонкого налаштування параметрів транспортного рівня на шлюзах і клієнтських платформах:

[Інтерактивний потік застосунку]
   (SSH / HTTPS / API / Мережеві ігри)
                 │
                 ▼  (Малі вікна та імпульсна передача)
[Рівень оптимізації TCP RiceGuard]
   ├── Побайтовий Early Retransmit за стандартом RFC 5827
   ├── Узгодження блоків SACK та виявлення дублікатів DSACK
   ├── Адаптивний таймер затримки ER Delay (SRTT/4)
   └── Узгодження пейсингу алгоритмів BBRv3 та CUBIC
                 │
                 ▼  (Усунення затримок RTO за малих вікон)
[Шифрований тунель передавання]
   (WireGuard / IPsec ESP / ChaCha20-Poly1305)

1. Застосування стандарту RFC 5827: Шлюзи RiceGuard використовують побайтовий Early Retransmit з адаптивним таймером, запобігаючи виникненню 200-мілісекундних пауз очікування RTO.
2. Комплексна синхронізація SACK: RiceGuard забезпечує підтримку протоколів SACK (RFC 2018) і Duplicate SACK (RFC 2883) для зовнішнього тунелю та вкладеного трафіку, допомагаючи ядру точно ідентифікувати втрати.
3. Пейсинг і вирівнювання черг: Поєднання раннього повторного відправлення з механізмом активного керування чергами FQ/CoDel усуває групування пакетів перед бездротовими інтерфейсами, знижуючи частоту втрат під час роумінгу.

Діагностика та перевірка: аудит Early Retransmit через метрики сокетів

Системні інженери та мережеві адміністратори можуть перевірити активність алгоритмів RFC 5827 на шлюзах під керуванням Linux за допомогою системних інтерфейсів.

Перевірка поточного значення параметра sysctl для Early Retransmit:

# Перевірка поточної конфігурації TCP Early Retransmit
sysctl net.ipv4.tcp_early_retrans

# Можливі параметри:
# 0: Вимкнено
# 1: Early Retransmit на рівні сегментів
# 2: Early Retransmit на рівні байтів
# 3: Побайтовий режим з адаптивним таймером затримки (Рекомендовано для Linux)

Щоб активувати рекомендований режим побайтового повторного відправлення з таймером захисту від перевпорядкування, виконайте команду:

# Увімкнення RFC 5827 із захистом від перевпорядкування
sudo sysctl -w net.ipv4.tcp_early_retrans=3

Для аналізу активних з'єднань і підтвердження роботи ранньої повторної передачі скористайтеся утилітою ss:

# Перегляд внутрішніх параметрів TCP та метрик передавання
ss -ti dst 198.51.100.1

Зверніть увагу на показник early_retrans та співвідношення retrans. Збільшення лічильника early_retrans за мінімальних значень таймаутів RTO підтверджує, що ядро оперативно компенсує втрачені пакети без пауз у роботі інтерактивних сервісів.

Завантажити VPNRice.