Інкапсуляція одного надійного транспортного протоколу всередину іншого на перший погляд здається цілком зрозумілим рішенням. Системні адміністратори та користувачі нерідко спрямовують трафік VPN через порт TCP 443, щоб подолати обмеження корпоративних проксі-серверів або мережевих екранів, які блокують звичайні дейтаграми UDP. Проте побудова тунелю TCP всередині іншого TCP призводить до критичного збою розподілених систем, відомого як TCP-over-TCP Meltdown (колапс вкладеного протоколу TCP).

У реальних умовах із природними коливаннями затримки (джитером) і втратою пакетів два незалежні контури керування TCP починають деструктивно взаємодіяти. Замість стабілізації каналу неузгоджені таймери повторного передавання викликають лавиноподібне переповнення черг, експоненційне уповільнення та критичне падіння пропускної здатності практично до нуля. Розуміння цього явища пояснює, чому сучасні архітектури VPN — зокрема WireGuard та протокол RiceGuard від VPNRice — функціонують виключно поверх дейтаграм UDP на третьому мережевому рівні (Layer 3).

Проблема двох контурів: конфлікт вкладених протоколів

Протокол TCP створено на основі принципу наскрізного зв'язку (end-to-end principle). Транспортний рівень виходить із того, що фізична мережа під ним є ненадійною (пакети IP можуть губитися чи приходити в іншому порядку), і гарантує цілісність через послідовні номери (sequence numbers), підтвердження (ACK), ковзні вікна та алгоритми контролю перевантаження (CUBIC або BBR).

Коли VPN-тунель загортає дані в TCP, на єдиному фізичному маршруті виникають два незалежні контури керування, які не узгоджують дії між собою:

+-------------------------------------------------------------------------+
|                  Конфлікт двох контурів вкладеного TCP                  |
+-------------------------------------------------------------------------+
| Прикладний рівень: HTTPS, SSH, виклики API                              |
|   |                                                                     |
|   v                                                                     |
| [ Внутрішній контур TCP (Inner Loop) ]                                  |
|   - Номери послідовностей, оцінка RTT програми, таймер RTO              |
|   - Вікно перевантаження (cwnd) масштабується за прикладним потоком     |
|   |                                                                     |
|   v (Упаковується як корисне навантаження в інтерфейс тунелю)           |
| [ Зовнішній контур TCP (Outer Loop) ]                                   |
|   - Працює на фізичному каналі (Wi-Fi, 4G/5G, оптоволокно)             |
|   - Власні номери послідовностей, зовнішній RTT і таймер RTO            |
|   - Автономно буферизує, перевпорядковує та повторно надсилає пакети    |
+-------------------------------------------------------------------------+

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

  1. Зовнішній TCP починає відновлення: Виявивши втрату пакета (через повторні ACK або тайм-аут власного RTO), тунель зупиняє передачу наступних байтів прикладному інтерфейсу та надсилає повторний запит фізичною мережею.
  2. Штучний сплеск затримки: Доки зовнішній TCP чекає на прибуття пакета, віртуальний інтерфейс не може віддати дані програмі через вимогу суворої послідовності. Значення RTT, яке фіксує внутрішній стек TCP, миттєво підскакує з десятків мілісекунд до сотень і тисяч.
  3. Спрацьовування внутрішнього таймера: Таймер очікування повторного передавання (RTO) внутрішнього TCP, розрахований за стабільних умов, вичерпується раніше, ніж зовнішній канал усуває втрату.
  4. Викид дублікатів: Вважаючи, що дані повністю втрачено, програма самостійно генерує копію того самого пакета.
  5. Лавиноподібне переповнення черги: Зовнішній TCP приймає цей повторний пакет як нові корисні дані та ставить його в чергу позаду вже затриманих пакетів.

Анатомія колапсу: лавина повторних передач

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

+-------------------------------------------------------------------------+
|                     Послідовність розвитку колапсу                      |
+-------------------------------------------------------------------------+
| Фізичний канал: втрачено пакет #10                                      |
|                                                                         |
| Зовнішній TCP:                                                          |
|   - Фіксує втрату -> Зупиняє потік -> Переходить у Fast Retransmit      |
|   - Утримує пакети #11, #12, #13 в очікуванні пакета #10                |
|                                                                         |
| Внутрішній TCP (сесія програми):                                        |
|   - Очікує підтвердження (ACK) на внутрішній пакет #4                   |
|   - Таймер внутрішнього RTO вичерпується (наприклад, минуло 200 мс)     |
|   - Вікно cwnd стискається до мінімуму: cwnd = 1 MSS                    |
|   - Повторно надсилає пакет #4 -> потрапляє в чергу зовнішнього TCP     |
|                                                                         |
| Зовнішній TCP відновлює пакет #10:                                      |
|   - Передає початковий пакет #4 програмі                                |
|   - Змушений додатково передавати дублікат #4 через фізичну мережу      |
|                                                                         |
| Результат: Bufferbloat, зростання RTO, швидкість падає до нуля          |
+-------------------------------------------------------------------------+

Математика прогресуючого таймера RTO

Згідно зі стандартом RFC 6298, обчислення значення RTO базується на згладженій затримці (SRTT) та її дисперсії (RTTVAR):

$$\text{RTO} \leftarrow \text{SRTT} + \max(G, 4 \cdot \text{RTTVAR})$$

Під час втрат на зовнішньому рівні загальна затримка для внутрішнього стека збільшується:

$$\text{RTT}{\text{внутр., факт}} = \text{RTT}{\text{зовнішн.}} + \text{Затримка повторного надсилання}$$

Оскільки час зовнішнього повторного надсилання майже завжди перевищує згладжений $\text{SRTT}$ програми, внутрішній RTO неминуче спрацьовує завчасно. При кожному невиконаному тайм-ауті протокол подвоює інтервал очікування (Exponential Backoff):

$$\text{RTO}{\text{наст.}} = 2 \cdot \text{RTO}{\text{пот.}}$$

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

Блокування початку черги (Head-of-Line Blocking)

У типовому сценарії тунель користувача обслуговує одночасно багато різних потоків:

  • Системні запити DNS
  • Голосові дзвінки та відеоконференції WebRTC
  • Сесії термінала SSH і завантаження сайтів

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

Порівняння: тунелі TCP проти дейтаграмного UDP

Сучасні протоколи тунелювання використовують виключно дейтаграми UDP на мережевому рівні, повністю відокремлюючи транспортування від логіки надійності.

+-------------------------------------------------------------------------+
|                  Порівняння тунелів TCP і дейтаграмних UDP              |
+-------------------------------------------------------------------------+
| Параметр               | Тунель TCP            | Тунель UDP (WireGuard) |
|------------------------|-----------------------|------------------------|
| Модель транспорту      | Надійний байтовий потік| Автономні дейтаграми   |
| Контроль перевантаження| Два конкуруючі рівні  | Єдиний наскрізний      |
| Реакція на втрати      | Повтор зовнішнього шару| Відкидання та передача |
| Блокування черги (HoL) | Блокує весь тунель    | Ізольовано за потоком  |
| Чутливість до джитеру  | Критична (колапс)     | Повна стійкість        |
| Мобільний роумінг      | Перезапуск сокетів    | Без стану (0 мс)       |
| Трафік реального часу  | Погіршення звуку/відео| Збереження мін. затримки|
+-------------------------------------------------------------------------+

Перевага UDP: автономність пакетів

При використанні інкапсуляції в дейтаграми UDP (як у WireGuard, IPsec ESP і RiceGuard):

  • Жодних повторних передач у тунелі: Мережевий інтерфейс не перевіряє послідовність і ніколи повторно не надсилає втрачені дейтаграми.
  • Наскрізна відповідальність програм: Якщо програмі потрібна надійність (HTTPS через TCP), її власний стек TCP контролює втрати та надсилає повторні запити. У системі діє рівно один контур керування.
  • Захист чутливого до затримок трафіку: Запити DNS, голосовий зв'язок і пакети протоколу QUIC передаються вільно і не залежать від збоїв у сусідніх з'єднаннях.

Діагностика колапсу за допомогою tcpdump

Аналіз TCP-в-TCP з'єднання за штучної втрати 2% пакетів через утиліту tcpdump наочно демонструє симптоми колапсу:

# Трасування пакетів: каскадний конфлікт повторного надсилання
14:10:01.102341 IP client.45210 > vpn.443: Flags [P.], seq 1024:2472, ack 1
14:10:01.102410 IP client.45210 > vpn.443: Flags [P.], seq 2472:3920, ack 1
14:10:01.182105 IP vpn.443 > client.45210: Flags [.], ack 1024, win 65535, options [sack 1 {2472:3920}]
14:10:01.182190 IP client.45210 > vpn.443: Flags [P.], seq 1024:2472, ack 1  <-- Зовнішній повтор
14:10:01.382410 IP client.45210 > vpn.443: Flags [P.], seq 3920:5368, ack 1  <-- Внутрішній RTO (Дублікат)
14:10:01.782890 IP client.45210 > vpn.443: Flags [P.], seq 5368:6816, ack 1  <-- Зростання таймера до 400мс

Трасування підтверджує:

  1. Сигнал SACK вказує на втрату сегмента 1024:2472 у фізичному середовищі.
  2. Зовнішнє з'єднання повторно передає втрачені дані о 14:10:01.182.
  3. Водночас таймер внутрішньої програми (200 мс) спливає о 14:10:01.382, додаючи в чергу зайвий дублікат.
  4. Подальше подвоєння таймерів до 400 мс і 800 мс призводить до цілковитого простою мережевого каналу.

Робота в мережах з обмеженням UDP без колапсу

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

  • Вимкнення алгоритму Нейгла (TCP_NODELAY): Забороняє сокету затримувати пакети для накопичення повної рамки, усуваючи штучні паузи.
  • Обмеження розміру буферів сокета: Менший розмір буфера запису не дає змоги тунелю поглинати забагато дублікатів, вчасно передаючи сигнал зворотного тиску програмі.
  • Автоматичне відновлення UDP: Клієнтська програма постійно зондує наявність відкритого шляху UDP у фоновому режимі, повертаючи активне з'єднання на безкласовий дейтаграмний протокол за першої можливості.

Мережева архітектура Layer 3 у VPNRice

Ядро RiceGuard від VPNRice побудоване на суворому розподілі потоків даних на третьому мережевому рівні (Layer 3), що виключає ризик виникнення вкладеного колапсу:

  1. Дейтаграмне пересилання за замовчуванням: Весь трафік інкапсулюється в незалежні дейтаграми UDP, надаючи прикладним сесіям повний контроль над власними вікнами передачі.
  2. Виключення блокування початку черги: Запити DNS, онлайн-відео та перегляд сайтів рухаються в ізольованих кадрах і не сповільнюються через проблеми у фонових завантаженнях.
  3. Надійний мобільний роумінг: Безкласова криптографічна маршрутизація забезпечує миттєве перемикання між Wi-Fi та мережами 5G без перезапуску сокетів і зайвих затримок.

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