Сучасні мобільні пристрої одночасно мають кілька фізичних радіоінтерфейсів, зокрема Wi-Fi 6/7, стільниковий зв'язок 5G та супутникові канали на низькій навколоземній орбіті. Попри апаратне різноманіття, традиційні корпоративні VPN-тунелі залишаються прив'язаними до одного транспортного маршруту. Коли інженер виходить з офісної будівлі або переміщується між базовими станціями, активний IP-маршрут деградує, що призводить до затримки пакетів, розриву з'єднань і зависання інтерактивних застосунків.

Стандартний протокол QUIC (RFC 9000) запропонував механізм міграції з'єднання (Connection Migration) для забезпечення роумінгу при зміні IP-адреси клієнта. Проте міграція з'єднання залишається суто послідовною: вона перемикає трафік зі старого шляху на новий лише після погіршення сигналу, не дозволяючи агрегувати пропускну здатність або дублювати передачу через кілька каналів одночасно.

Чернетка стандарту Multipath Extension for QUIC від IETF (draft-ietf-quic-multipath) докорінно змінює цю парадигму. Завдяки створенню окремих просторів номерів пакетів для кожного фізичного маршруту, впровадженню кадрів багатопутевого підтвердження (ACK_MP) та координації алгоритмів адаптивного планування, Multipath QUIC (MPQUIC) забезпечує активне об'єднання каналів (active-active multi-link bonding). В надійних VPN-архітектурах MPQUIC гарантує роумінг без втрати пакетів і високу стійкість сесій.

Вузьке місце двох інтерфейсів: чому однопутеві тунелі підводять мобільних користувачів

У класичних віртуальних приватних мережах кожен активний туннель жорстко прив'язаний до одного сокета з фіксованим кортежем ((src_ip, src_port, dst_ip, dst_port, protocol)). Хоча мобільні операційні системи підтримують інтерфейси Wi-Fi та стільникового зв'язку в режимі готовності, лише один фізичний канал слугує шлюзом за замовчуванням у конкретний момент часу.

Коли пристрій виходить із зони покриття Wi-Fi, сигнал зазнає стрімкого згасання ще до того, як операційна система ініціює вимкнення інтерфейсу. Протягом цього перехідного періоду (тривалістю від 2 до 8 секунд) пакети, надіслані у згасаючий канал Wi-Fi, безповоротно втрачаються.

Традиційна міграція VPN (Послідовне вузьке місце):
Час -------------------------------------------------------------------->
[Канал Wi-Fi активний] ===> [Згасання сигналу (Втрата пакетів)] -> [Розрив зв'язку]
                                                                          |
                                                       [Повторне рукостискання 5G]
                                                                          |
                                                       [Канал 5G активний (Пауза 2-8с)]

Активне об'єднання Multipath QUIC (Роумінг без втрат):
Час -------------------------------------------------------------------->
Шлях 0 (Wi-Fi):  [Передача даних] ===> [Деградація / Дренаж]   -> [Резерв / Закрито]
Шлях 1 (5G):     [Прогрітий зонд] ===> [Миттєве підхоплення]   -> [Стабільна швидкість]
Результат: 0 втрачених пакетів, 0 стрибків RTT, безперервна корпоративна сесія!

Міграція з'єднання проти справжнього Multipath: Перемикання каналів чи Одночасне об'єднання

Стандартний QUIC (RFC 9000) мінімізує затримку зміни адреси завдяки криптографічним ідентифікаторам з'єднання (CID), дозволяючи мігрувати між мережами без повторення повного рукостискання TLS 1.3.

Однак стандартна міграція має суттєві обмеження:

  1. Послідовне виконання: Стандартний QUIC дозволяє використовувати лише один активний шлях у будь-який момент часу. Перевірка нового каналу вимагає зупинки або виведення з експлуатації попереднього.
  2. Блокування початку черги (Head-of-Line Blocking): Якщо застосунок намагається розподіляти пакети між двома незалежними з'єднаннями QUIC, різниця в затримках поширення сигналів спричиняє порушення порядку доставки та переповнення буферів збирання.
  3. Відсутність агрегації пропускної здатності: Пристрій не здатний об'єднати 300 Мбіт/с офісного Wi-Fi та 200 Мбіт/с мережі 5G у сукупний канал зі швидкістю 500 Мбіт/с.

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

Архітектура Multipath QUIC: Окремі простори номерів пакетів та кадри ACK_MP

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

Для запобігання помилковому колапсу вікна перевантаження MPQUIC впроваджує незалежні простори номерів пакетів (Packet Number - PN) для кожного валідованого мережевого шляху.

Транспортний механізм відправника:
========================================================================
Шлях ID 0 (Wi-Fi, 10 мс RTT):   [PN 0] [PN 1] [PN 2] [PN 3] ---> ACK_MP (Шлях 0)
Шлях ID 1 (5G, 45 мс RTT):      [PN 0] [PN 1] [PN 2] [PN 3] ---> ACK_MP (Шлях 1)
========================================================================
Спільний рівень потоків сесії:
[Кадр потоку Stream 0 (Offset 0..1399)]    -> Направлено в Шлях 0
[Кадр потоку Stream 1 (Offset 1400..2799)]  -> Направлено в Шлях 1
[Кадр потоку Stream 2 (Offset 2800..4199)]  -> Направлено в Шлях 0

Кожен простір номерів пакетів діє виключно в межах свого Path ID. Оскільки алгоритми виявлення втрат (такі як RACK-TLP, RFC 8985) працюють автономно для кожного маршруту, зміна черговості пакетів між різними середовищами не спричиняє хибних повторних надсилань.

Для передавання підтверджень відправнику MPQUIC визначає кадр ACK_MP (0x15228c00–0x15228c01). На відміну від стандартного кадру ACK, ACK_MP явно містить Path ID, до якого належать діапазони підтверджених номерів:

Формат кадру даних ACK_MP:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Тип кадру = ACK_MP (0x15228c00..)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Ідентифікатор Path ID (i)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Найбільший підтверджений пакет (i)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Затримка підтвердження ACK Delay (i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Кількість діапазонів ACK Range (i)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Перший діапазон підтвердження (i)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Наступні діапазони (*)             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Алгоритми диспетчеризації шляхів: MinRTT, Надлишкове передавання та BLEST

Формат кадрів визначає передачу даних фізичним каналом, тоді як планувальник шляхів (path scheduler) вирішує, через який інтерфейс надсилати кожен вихідний кадр. Залежно від вимог корпоративні VPN-шлюзи застосовують різні дисципліни планування:

Стратегія диспетчеризації Мета оптимізації Ефективність смуги Профіль затримки Головний сценарій використання
Мінімальний RTT (MinRTT) Максимізація швидкості Висока (Агрегація) Низька / Середня Передавання великих файлів, бекапи
Надлишкова (Redundant) Усунення втрат і джитера Низька (Дублювання) Мінімально можлива Фінансові транзакції, онлайн-ігри, сесії SSH
Оцінка блокування (BLEST) Захист від блокування черги Оптимальна Плавна та стабільна Відеоконференції, інтерактивні RPC

Валідація шляху та вимірювання RTT у неоднорідних бездротових мережах

Перед надсиланням корисного навантаження додатковим каналом кінцева точка MPQUIC виконує перевірку шляху за допомогою кадрів PATH_CHALLENGE та PATH_RESPONSE. Це підтверджує автентичність IP-адреси та захищає систему від атак відмови в обслуговуванні.

Після успішної валідації для кожного шляху безперервно розраховуються згладжений час кругового обігу (SRTT), мінімальний RTT (min_rtt) та дисперсія затримок (RTTVAR):

$$ ext{SRTT}{ ext{new}} = rac{7}{8} imes ext{SRTT}{ ext{prior}} + rac{1}{8} imes ext{RTT}_{ ext{sample}}$$

/* Приклад планувальника MinRTT мовою C */
struct quic_path *select_min_rtt_path(struct quic_conn *qc)
{
    struct quic_path *best_path = NULL;
    uint32_t lowest_rtt = UINT32_MAX;

    for (int i = 0; i < qc->num_paths; i++) {
        struct quic_path *p = &qc->paths[i];
        
        /* Пропуск шляхів без валідації або із заповненим вікном перевантаження */
        if (!p->is_validated || p->bytes_in_flight >= p->cwnd)
            continue;

        if (p->srtt < lowest_rtt) {
            lowest_rtt = p->srtt;
            best_path = p;
        }
    }
    return best_path;
}

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

Пов'язаний контроль перевантаження: Балансування BBR та CUBIC на кількох шляхах

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

Для забезпечення справедливості архітектури MPQUIC застосовують моделі пов'язаного контролю перевантаження (LIA, RFC 6356; OLIA) або автономні алгоритми на основі затримки, такі як BBRv2/v3 для кожного шляху. Під керуванням BBR кожен шлях незалежно визначає доступну швидкість і мінімальний час затримки без роздування буферів:

Шлях 0 (Оптика Wi-Fi): Стан регулювання BBR -> BtlBw = 400 Мбіт/с, RTprop = 12 мс
Шлях 1 (Мобільний 5G): Стан регулювання BBR -> BtlBw = 120 Мбіт/с, RTprop = 38 мс
Загальна швидкість доставки: 520 Мбіт/с без переповнення проміжних буферів!

Архітектурна інтеграція в RiceGuard та оверлеях Core L3 VPN

Повна реалізація переваг Multipath QUIC потребує узгодженості між клієнтським застосунком та високоефективним рівнем обробки тунельних даних.

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

  1. Багатопутевий транспорт у RiceGuard: Двигун RiceGuard встановлює одночасні тунелі через усі доступні фізичні інтерфейси. Підтримуючи захищені стани на модемі 5G та локальному Wi-Fi, пристрій може миттєво перемикати, розподіляти або дублювати IP-датаграми.
  2. Динамічна маршрутизація в Core L3 VPN: Корпоративні шлюзи Core L3 VPN аналізують ідентифікатори транспорту, динамічно спрямовуючи UDP-пакети магістральними оптоволоконними лініями з мінімальними втратами.
  3. Плавне перемикання між мережами: Коли користувач залишає зону покриття Wi-Fi, RiceGuard фіксує деградацію першого шляху за таймаутами валідації та непомітно перемикає трафік на другий канал, захищаючи від обриву активні сесії SSH, баз даних або виклики VoIP.

Підсумок: Детермінована стійкість на кількох каналах для VPN нового покоління

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

Поєднуйте офісний Wi-Fi зі швидкісними каналами 5G та створюйте надійні резервні лінії для критичної інфраструктури підприємств. Захистіть корпоративні сесії від розривів під час руху разом із Завантажити VPNRice.