Понад три десятиліття протокол Transmission Control Protocol (TCP) спирався на евристичний підрахунок пакетів для діагностики втрат: при отриманні трьох дубльованих підтверджень (Duplicate ACK, DupACK) відправник робив висновок, що проміжний сегмент був відкинутий маршрутизатором, а не просто змінив черговість прибуття. Зафіксоване у специфікації RFC 5681 правило ґрунтувалося на припущенні, що мережеві маршрути симетричні, швидкості з'єднань однорідні, а перевпорядкування даних трапляється рідко.

У сучасній мережевій інфраструктурі ця класична парадигма часто виявляється неефективною. Зашифровані тунелі, багаточергові мережеві адаптери (multi-queue NIC), повторні передачі на канальному рівні Wi-Fi, агрегація несучих у мобільних мережах та програмно-конфігуровані канали (SD-WAN) регулярно спричиняють безпечні інверсії пакетів. Випадкове перевпорядкування лише двох пакетів здатне хибно викликати алгоритм Fast Retransmit, що скорочує вікно перевантаження вдвічі та погіршує швидкість передачі. І навпаки: коли втрата виникає наприкінці транзакції (хвостові втрати, tail drop), у каналі немає наступних пакетів для формування трьох підтверджень DupACK. З'єднання вимушено зависає в очікуванні спрацьовування таймера Retransmission Timeout (RTO), що створює паузу тривалістю від двохсот мілісекунд до цілої секунди.

Щоб модернізувати механізми транспортного рівня, Інженерна рада інтернету (IETF) затвердила стандарт RFC 8985 — Алгоритм виявлення втрат RACK-TLP для TCP. Замінюючи підрахунок номерів послідовності аналізом фізичного часу доставки (Recent ACKnowledgment, RACK) та використовуючи випереджальне зондування хвоста (Tail Loss Probe, TLP), стандарт RFC 8985 гарантує надійне функціонування зв'язку в чутливих до затримок тунелях VPN.

[Традиційна схема: Жорсткий поріг із 3 дубльованих ACK]
Відправник ──[P1]──[P2]──[P3]──[P4]──> Одержувач (P2 випередив P1 через перевпорядкування)
Відправник <──[Ack 0]──[DupAck 0]──[DupAck 0]──[DupAck 0] (Хибний запуск Fast Retransmit!)
Відправник даремно зменшує CWND удвічі -> Швидкість потоку раптово обвалюється.

[RFC 8985 RACK: Аналіз часу з динамічним вікном затримки]
Відправник ──[P1]──[P2]──────────────> Одержувач (P2 доставлено в T1, P1 прибув на 2 мс пізніше)
Відправник отримує ACK для P2 -> Оцінює: Час, що минув < Вікна затримки RACK.
Відправник стримує надсилання -> Приходить підтвердження для P1 -> Вікно CWND збережено.

[RFC 8985 TLP: Випереджальне зондування при втраті у хвості]
Відправник ──[P1]──[P2]──────────────> Одержувач (P2 втрачено; наступних пакетів немає)
Звичайний TCP: Завмирає на 200–1000 мс у вимушеному очікуванні таймера RTO.
RFC 8985 TLP:   Активує таймер PTO (~ 2*SRTT) -> Надсилає перевірочний зонд.
Одержувач відповідає DupACK -> RACK запускає Fast Recovery -> Затримка знижується на 85%+.

Обмеження підрахунку пакетів: чому традиційні дубльовані ACK дають збій

Класичний механізм виявлення втрат TCP формувався за часів одночергових маршрутизаторів і виділених ліній. За таких умов послідовність пакетів суворо зберігалася, якщо тільки буфер черги не переповнювався.

Сьогодні глобальна мережа спирається на багатоядерні диспетчери пакетів, балансування трафіку ECMP та динамічну інкапсуляцію тунелів, що неминуче вносить мікроскопічні розбіжності в часі обробки сегментів сусідніми процесорними ядрами.

Вразливість евристичного порогу в три DupACK перед мікроперевпорядкуванням

Правило трьох дубльованих підтверджень є компромісним інженерним рішенням із низкою недоліків:

  • Занижений поріг (1 або 2 DupACK): Незначні затримки пакетів у радіомережах Wi-Fi або LTE провокують зайві повторні відправлення. Відправник передчасно переходить у фазу Fast Recovery, знижує поріг повільного старту (ssthresh) і марнує ресурси каналу.
  • Завищений поріг (3 DupACK): Інтерактивні з'єднання з малим обсягом даних у польоті — такі як віддалений термінал SSH, сесії TLS або запити API RPC — фізично не здатні згенерувати три дублікати в разі втрати пакета, завмираючи в очікуванні RTO.

Під час руху пакетів крізь криптографічні тунелі WireGuard, IPsec ESP або OpenVPN багатопотокова обробка шифротексту на процесорі нерідко призводить до зміни послідовності пакетів. Звичайний фіксований лічильник не в змозі відрізнити безпечну зміну черговості від реального скидання пакета.

Обмеження SACK у разі втрат у хвості потоку та на асиметричних маршрутах

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

Якщо втрата стається у хвості сесії — наприклад, в останньому кадрі HTTP/2 або під час введення окремого символу в терміналі — слідом не надсилається нових даних, здатних ініціювати блок SACK. У такій ситуації опція SACK стає повністю безпорадною, залишаючи з'єднання під контролем грубого таймера RFC 6298:

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

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

Архітектурні засади RFC 8985: механізм Recent ACKnowledgment (RACK)

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

Логіка виявлення втрат за часовими мітками замість лічильника зсуву номерів

Головний принцип Recent ACKnowledgment (RACK) дуже прозорий: якщо сегмент, переданий у момент часу $T_1$, успішно підтверджено, то будь-який раніше надісланий непідтверджений сегмент вважається втраченим за умови, що з моменту його передачі минуло достатньо часу.

Замість підрахунку кількості сегментів, які прибули після пропуску, RACK відстежує історію подій доставки:

  1. RACK.xmit_ts: Кожен надісланий або повторно переданий сегмент маркується монотонною часовою міткою з високою точністю.
  2. RACK.end_seq: Фіксує максимальний номер послідовності, надісланий до поточного моменту.
  3. RACK.rtt: Зберігає останнє виміряне значення кругової затримки RTT із вхідного підтвердження (накопичувального ACK чи блоку SACK).
  4. Умова втрати: Непідтверджений сегмент $S$ вважається втраченим, якщо виконується співвідношення: $$S.\text{xmit_ts} + \text{RACK.rtt} + \text{RACK.rwin} \le \text{Current_Time}$$ де $\text{RACK.rwin}$ позначає динамічне вікно допустимого перевпорядкування.

Завдяки орієнтації на фізичний час RACK однаково надійно ідентифікує втрати як за наявності десятків сегментів у дорозі, так і за єдиного залишкового пакета.

Адаптивне вікно перевпорядкування та моніторинг варіацій затримки RTT

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

Базова формула вікна має такий вигляд:

$$\text{RACK.rwin} = \max\left(\frac{\text{SRTT}}{4}, \text{Min_RTT_Window}\right)$$

Коли завдяки розширенню DSACK (RFC 2883) з'ясовується, що раніше повторно переданий сегмент насправді дійшов до адресата вчасно, RACK фіксує випадок помилкового відправлення. У відповідь алгоритм збільшує значення $\text{RACK.rwin}$, запобігаючи новим хибним спрацьовуванням. Коли стан мережі стабілізується, вікно поступово повертається до початкового розміру.

[Схема ухвалення рішень в алгоритмі RACK]
     ┌────────────────────────────────────────────────────────┐
     │          Отримання нового пакета ACK або SACK          │
     └───────────────────────────┬────────────────────────────┘
                                 │
                                 ▼
     ┌────────────────────────────────────────────────────────┐
     │       Оновлення RACK.rtt та мітки часу доставки        │
     └───────────────────────────┬────────────────────────────┘
                                 │
                                 ▼
             Чи виконується S.xmit_ts + RACK.rtt + RACK.rwin
                         <= Current_Time ?
                                ╱ ╲
                              ╱     ╲
                             ТАК     НІ
                            ╱         ╲
                           ▼           ▼
             ┌───────────────────┐   ┌───────────────────────┐
             │ Визнати втрату    │   │ Увімкнути таймер RACK │
             │ Надіслати сегмент │   │ Очікувати доставку    │
             └───────────────────┘   └───────────────────────┘

Усунення затримок повторної передачі за допомогою зондування хвоста (TLP)

Хоча RACK ефективно долає втрати за наявності подальших підтверджень, він потребує спеціального підходу, якщо втрачається останній сегмент порції даних. Для розв'язання проблеми хвостових втрат без очікування таймера RTO стандарт RFC 8985 реалізує алгоритм Tail Loss Probe (TLP).

Випереджальне зондування: перетворення пауз RTO на швидке відновлення

Механізм Tail Loss Probe встановлює швидкий таймер — Probe Timeout (PTO). Якщо відправлення нових даних призупиняється, але в мережі залишаються непідтверджені байти, таймер PTO спрацьовує значно раніше за таймер RTO.

Після завершення відліку PTO система не скидає вікно перевантаження і не вважає маршрут пошкодженим. Натомість вона передає один тестовий зонд — або нові дані з черги, або копію пакета з найвищим номером послідовності.

Отримавши зонд, вузол призначення надсилає у відповідь дубльований ACK або блок SACK. Цей зустрічний відгук надає механізму RACK свіжу мітку часу, дозволяючи негайно локалізувати втрачений раніше пакет і перейти до процедури Fast Recovery без просідання швидкості.

Розрахунок тайм-ауту зондування PTO та правила вибору перевірочних сегментів

Період спрацьовування таймера Probe Timeout обчислюється так, щоб активуватися одразу після очікуваного часу прибуття стандартної відповіді з урахуванням мережевого джитера:

$$\text{PTO} = \begin{cases} \max(2 \times \text{SRTT}, 10\text{ ms}) & \text{якщо кількість пакетів у дорозі } = 1 \ \max(2 \times \text{SRTT}, 1.5 \times \text{SRTT} + \text{Wdelay}) & \text{якщо кількість пакетів у дорозі } > 1 \end{cases}$$

Величина $\text{Wdelay}$ враховує затримку генерації підтверджень на боці отримувача (зазвичай обмежена $200\text{ ms}$ або дорівнює нулю у разі негайного надсилання SACK).

Критерій порівняння Звичайний TCP (RFC 5681) Специфікація RFC 8985 RACK-TLP Отриманий ефект
Втрата хвостового пакета Зупинка на 200–1000 мс (RTO) Зонд PTO через ~2x SRTT (~40 мс) Скорочення затримки на 80–95%
Зміна черговості у Wi-Fi Помилкова реакція зі спадом CWND Вікно RACK.rwin нівелює зсув Збереження пропускної здатності
Короткі інтерактивні потоки Зависання через брак 3 DupACK Точне відновлення за часом Миттєвий відгук термінала
Вплив на вікно CWND Скидання CWND до 1 сегмента Плавне зменшення вікна вдвічі Швидке повернення швидкості
Захист від зайвого трафіку Негнучкі ліміти підрахунку Адаптивне налаштування через DSACK Зниження навантаження на канал

Завдяки активній ініціації зворотного зв'язку TLP перетворює тривалі простої RTO на швидкі й контрольовані процедури відновлення.

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

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

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

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

У класичному стеку TCP:

  1. Через перемикання мережі два пакети міняються місцями.
  2. Приймач надсилає два підтвердження DupACK.
  3. Якщо проміжний сегмент був втрачений, сесія зависає, адже тонкий потік не має третього пакета для генерації фінального DupACK.
  4. Додаток зупиняється на 300 мс в очікуванні спрацьовування RTO.

За використання стандарту RFC 8985:

  1. RACK зіставляє часові показники з адаптивним вікном $\text{RACK.rwin}$, запобігаючи передчасній тривозі під час роумінгу.
  2. Якщо кінцевий пакет було відкинуто, TLP генерує зонд за $2 \times \text{SRTT}$, даючи змогу системі RACK відновити цілісність передачі за мілісекунди.

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

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

Інфраструктурний комплекс VPNRice використовує технологічний рушій RiceGuard, здійснюючи оптимізацію транспортного рівня на серверах-шлюзах і кінцевих вузлах:

[Інтерактивний трафік додатків]
   (SSH / HTTP/2 / WebRTC / Мережеві ігри)
                     │
                     ▼  (Тонкі імпульсні потоки)
[Рівень прискорення передачі RiceGuard]
   ├── Ядро RFC 8985 RACK-TLP (Виявлення втрат за мітками часу)
   ├── Калібрування вікна перевпорядкування (Захист від хибних відправлень)
   ├── Адаптивний запуск PTO (Ліквідація хвостових затримок)
   └── Узгодження темпу передачі з BBRv3 та CUBIC Pacing
                     │
                     ▼  (Виключення затримок таймера RTO)
[Шифрований тунель зв'язку]
   (WireGuard / IPsec ESP / ChaCha20-Poly1305)
  1. Впровадження стандарту RACK-TLP: Платформа RiceGuard гарантує роботу мережевих сокетів у режимі часового аналізу втрат, позбавляючи з'єднання прив'язки до правила трьох DupACK.
  2. Стійкість тунелю до зміни порядку пакетів: Взаємодія показників RACK внутрішнього TCP із зовнішнім каналом UDP усуває небажані скидання швидкості під час багаторівневої маршрутизації провайдерів.
  3. Регулювання темпу та черг: Зондувальні пакети TLP передаються під контролем алгоритмів диспетчеризації FQ/CoDel, що виключає їхнє відкидання через локальне переповнення буферів.

Практична діагностика та аудит: моніторинг сокетів із підтримкою RACK і TLP

Мережеві фахівці та адміністратори можуть легко перевірити стан роботи алгоритмів RFC 8985 RACK-TLP на серверах Linux за допомогою стандартних інтерфейсів.

Перевірка поточного системного параметра відновлення TCP:

# Перевірка поточної конфігурації відновлення втрат TCP
sysctl net.ipv4.tcp_recovery

# Значення бітової маски в ядрі Linux:
# 0x1: Активація алгоритму RACK
# 0x2: Активація механізму Tail Loss Probe (TLP)
# 0x4: Активація адаптивного вікна перевпорядкування
# Рекомендоване значення: 0x7 (Усі компоненти активні, за замовчуванням у Linux 4.15+)

Щоб гарантовано задіяти повний стек RACK-TLP за стандартом RFC 8985, виконайте команду:

# Активація повного стека RFC 8985 RACK-TLP
sudo sysctl -w net.ipv4.tcp_recovery=7

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

# Отримання детальних показників TCP для активного з'єднання
ss -ti dst 198.51.100.1

Зверніть увагу на прапорець rack серед параметрів сокета, а також на індикатор reord, лічильники tlp та rto. З'єднання, що працюють за стандартом RFC 8985, зберігають стабільну пропускну здатність і майже не фіксують таймаутів RTO під час передачі через мобільні та бездротові мережі.

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