Високошвидкісні шифровані тунелі VPN поєднують розподілені центри обробки даних та корпоративні філії через публічні магістральні мережі. Попри те що фізичні інтерфейси регулярно забезпечують пропускну здатність від 10 до 100 Гбіт/с, реальна швидкість передачі даних на транспортному рівні нерідко падає до кількох мегабітів, якщо час кругового обігу (RTT) перевищує 50 мілісекунд. За умов класичних алгоритмів адитивного збільшення та мультиплікативного зменшення (AIMD), таких як TCP Reno (RFC 5681), темп зростання вікна перевантаження є обернено пропорційним до величини RTT. На протяжних трансконтинентальних маршрутах стандартний TCP неспроможний заповнити канали з високим добутком смуги на затримку (Bandwidth-Delay Product, BDP).

Щоб усунути ці обмеження, інженерна група IETF стандартизувала алгоритм CUBIC у RFC 8312 та ґрунтовно модернізувала його в офіційному стандарті RFC 9438. Будучи типовим алгоритмом керування перевантаженням у ядрах Linux, Android, macOS та Windows, CUBIC замінює лінійне зростання математичною функцією третього степеня. Прив'язуючи збільшення вікна до реального фізичного часу замість мережевого RTT, RFC 9438 гарантує високу масштабованість, швидке відновлення швидкості та справедливий розподіл ресурсів у магістральних тунелях VPN.

Траєкторії зростання вікна TCP у мережах із високим BDP:

Вікно перевантаження (W)
    ▲
    │                                  ...--- Опукла фаза зондування (Convex)
    │                               .-'
Wmax├ - - - - - - - - - - - - - -.-' (Точка перегину / Плато: t = K)
    │                         .-'
    │                     _.-'  <-- Увігнута фаза стабілізації (Concave)
    │                _.-''
Wmin├───────────────' (Мультиплікативне зниження: W = beta * Wmax)
    │
    │   Класичний TCP Reno (Лінійний нахил: 1 MSS / RTT)
    │   ...........................................> [Деградація при високому RTT]
    └─────────────────────────────────────────────────────────────► Пройдений час (t)

Проблема добутку смуги на затримку (BDP) в зашифрованих тунелях

Добуток смуги пропускання на затримку (BDP) визначає обсяг даних, який має одночасно перебувати в каналі (in-flight), щоб повноцінно використати його ємність:

$$\text{BDP} = \text{Смуга пропускання (біт/с)} \times \text{Час RTT (секунди)}$$

У локальній мережі 1 Гбіт/с із затримкою 1 мс значення BDP становить приблизно 125 кілобайтів. Проте коли трафік спрямовується через трансокеанський шифрований тунель 10 Гбіт/с із затримкою 120 мс, BDP збільшується до 150 мегабайтів:

$$\text{BDP} = \frac{10 \times 10^9 \text{ біт/с} \times 0.120 \text{ с}}{8 \text{ біт/байт}} = 150,000,000 \text{ байтів} \approx 143 \text{ МБ}$$

Стагнація класичного алгоритму AIMD у швидкісних мережах із високою затримкою

Класичний алгоритм TCP Reno збільшує вікно суворо лінійно: після отримання кожного підтвердження (ACK) відправник збільшує вікно перевантаження (cwnd) на $1/\text{cwnd}$, тобто лише на один максимальний розмір сегмента (MSS) за інтервал RTT. У разі втрати пакета Reno зменшує вікно рівно наполовину ($\beta = 0.5$).

У тунелі з BDP 150 МБ і стандартним MSS 1420 байтів (після врахування накладних витрат заголовків IPsec або WireGuard) падіння вікна на 50% викидає з каналу майже 52 800 пакетів. Для повного відновлення вікна алгоритму Reno знадобиться 52 800 послідовних циклів RTT. За умови RTT 120 мс:

$$\text{Час відновлення} = 52,800 \times 0.120 \text{ с} \approx 6,336 \text{ с} \approx 105.6 \text{ хвилин}$$

Поодинока втрата пакета раз на годину прирікає TCP Reno на постійне недовантаження каналу, за якого використовується менше ніж 5% доступної ємності тунелю.

Несправедливість RTT: дискримінація транскордонного трафіку VPN

У неоднорідних мережах локальні сесії з малим RTT та віддалені потоки VPN проходять крізь спільні маршрутизатори. Оскільки темп зростання вікна Reno пропорційний $1/\text{RTT}$, локальне з'єднання з RTT 6 мс розширює вікно у 20 разів швидше, ніж міжнародний тунель із RTT 120 мс. Короткі з'єднання переповнюють буфери обладнання, спричиняють втрату пакетів і витісняють магістральний трафік VPN.

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

Математичні засади алгоритму RFC 9438 CUBIC

CUBIC замінює прямолінійне зростання поліномом третього степеня, орієнтованим на розмір вікна, досягнутий перед останнім інцидентом перевантаження ($W_{max}$).

Кубічна функція реального часу та фаза увігнутого плато

У разі фіксації втрати CUBIC фіксує поточний розмір вікна у змінній $W_{max}$ і зменшує cwnd з коефіцієнтом $\beta_{cubic} = 0.7$ (зберігаючи 70% пропускної здатності проти 50% у Reno):

$$W_{min} = \beta_{cubic} \times W_{max} = 0.7 \times W_{max}$$

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

$$W_{cubic}(t) = C \cdot (t - K)^3 + W_{max}$$

Де:

  • $t$: Фізичний час, що минув після зниження вікна.
  • $C$: Масштабна константа, зафіксована в RFC 9438 на рівні $0.4$.
  • $K$: Проміжок часу, необхідний функції для підйому від мінімуму $W_{min}$ назад до $W_{max}$:

$$K = \sqrt[3]{\frac{W_{max} \cdot (1 - \beta_{cubic})}{C}} = \sqrt[3]{\frac{0.3 \cdot W_{max}}{0.4}}$$

На відрізку $t < K$ крива має увігнуту форму (concave). Спочатку вікно зростає швидко, повертаючи тунелю високу швидкість. Із наближенням $t$ до значення $K$ зростання сповільнюється, формуючи плато поблизу $W_{max}$. Це плато стабілізує з'єднання біля межі пропускної здатності каналу, гасить коливання та запобігає втратам у чергах комутаторів.

Опукле зондування: агресивне освоєння вільної смуги пропускання

Коли час $t$ перевищує величину $K$ ($t > K$), алгоритм переходить в опуклу фазу (convex). Переконавшись, що з'єднання стабільно утримує рівень $W_{max}$ без втрат, CUBIC прискорює розширення вікна задля виявлення нової вільної смуги пропускання.

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

Сумісність протоколів: емуляція Reno та інтеграція HyStart++

Хоча кубічна траєкторія чудово працює на довгих лініях, у мережах із малим BDP вона може поступатися швидкості звичайного TCP Reno. Специфікація RFC 9438 поєднує кубічну математику з режимом емуляції Reno та сучасними фільтрами повільного старту.

Режим сумісності з Reno для вузьких місць із малими буферами

У мережах із невисоким BDP лінійний темп Reno може тимчасово випереджати початковий кубічний підйом. Щоб CUBIC не втрачав швидкість перед застарілими пристроями, RFC 9438 постійно обчислює розрахункове вікно Reno:

$$W_{est}(t) = W_{max} \cdot \beta_{cubic} + \left[ 3 \cdot \frac{1 - \beta_{cubic}}{1 + \beta_{cubic}} \right] \cdot \frac{t}{\text{RTT}}$$

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

$$\text{cwnd} = \max(W_{cubic}(t), W_{est}(t))$$

Це гарантує, що CUBIC функціонує не гірше за Reno на коротких маршрутах, багаторазово перевершуючи його на далеких магістралях.

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

Традиційний Slow-Start подвоює cwnd за кожен RTT, доки переповнення буфера не спричинить втрату пакетів. У мережах 10 Гбіт/с стрибок через край пропускної здатності скидає в черги мегабайти даних, викликаючи роздування буферів (Bufferbloat) і шторм втрат.

RFC 9438 використовує алгоритм HyStart++, який аналізує мікродинаміку затримок на ранньому етапі з'єднання:

  1. Базовий моніторинг затримки: HyStart++ реєструє мінімальний час обігу $\text{RTT}_{min}$.
  2. Спрацювання порогу затримки: Якщо поточний RTT зростає на динамічну величину ($\Delta \text{RTT} = \text{clamp}(8, \text{RTT}_{min} / 8, 16) \text{ мс}$) через накопичення черги, алгоритм виявляє наближення перевантаження.
  3. Безпечний перехід: Відправник зупиняє експоненційне зростання і м'яко переходить у режим обережного старту (Conservative Slow Start) до фактичної втрати пакетів.

Ключові архітектурні оновлення RFC 9438 порівняно з RFC 8312

Статус офіційного стандарту RFC 9438 увібрав у себе результати десятирічної експлуатації протоколу у світовому масштабі:

  • Точне узгодження коефіцієнтів: Взаємозв'язок між множником зменшення $\beta_{cubic}$ та масштабом $C$ строго вивірено, що усуває помилкове роздування вікна під час мікроперестановок пакетів.
  • Покращена швидка збіжність (Fast Convergence): У разі зростання фонового трафіку CUBIC делікатніше знижує поріг $W_{max}$, запобігаючи затяжним падінням швидкості.
  • Інтеграція із сучасними схемами відновлення: Повна сумісність із механізмом пропорційного зниження швидкості (PRR, RFC 6937) гарантує стабільність обсягу даних у дорозі під час обробки вибіркових підтверджень SACK.

Налаштування буферів ядра та дисциплін черг для високошвидкісних тунелів

Належна робота RFC 9438 через шифровані інтерфейси VPN потребує достатніх розмірів сокетних буферів у ядрі Linux. Якщо пам'ять ядра штучно обмежена, CUBIC фізично не зможе розширити cwnd до рівня місткості лінії.

Рекомендовані налаштування у файлі /etc/sysctl.conf:

# Налаштування автомасштабування буферів для BDP 10 Гбіт/с / 120 мс (150 МБ)
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.tcp_rmem = 4096 87380 268435456
net.ipv4.tcp_wmem = 4096 65536 268435456

# Активація RFC 9438 CUBIC та дисципліни fq_codel
net.ipv4.tcp_congestion_control = cubic
net.core.default_qdisc = fq_codel

Використання CUBIC у поєднанні з дисциплінами черг fq_codel або CAKE запобігає затримкам інтерактивного трафіку SSH, VoIP та DNS під час передачі великих файлів.

Захист корпоративних мереж: адаптивна транспортна архітектура RiceGuard

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

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

  • Адаптивне коригування MSS: RiceGuard обчислює накладні витрати інкапсуляції (WireGuard, IPsec ESP, DTLS) і точно налаштовує TCP MSS, уникаючи фрагментації зовнішніх пакетів і зберігаючи геометрію вікна CUBIC.
  • Ізоляція потоків: Вбудовані планувальники черг відокремлюють масивні передачі файлів від чутливих пакетів керування, запобігаючи перевантаженню буферів на шлюзах.
  • Динамічне зондування BDP: RiceGuard вимірює мікросекундні коливання затримок, надаючи ядру дані для усунення роздування буферів без втрати мультигігабітних швидкостей.
  • Стійкість до випадкових втрат: На нестабільних лініях RiceGuard нівелює вплив штучних втрат, утримуючи CUBIC у продуктивній фазі опуклого зондування.

Діагностика та профілювання: аудит TCP CUBIC у робочих системах Linux

Фахівці можуть перевірити параметри роботи алгоритму CUBIC на серверах Linux за допомогою інструмента ss з детальними метриками:

# Перегляд стану активних сокетів TCP
ss -tin '( dport = :443 or sport = :443 )'

Приклад діагностичного виводу:

ESTAB      0      1420000     198.51.100.2:443      203.0.113.8:54210
     cubic wscale:11,11 rto:320 rtt:118.24/0.82 ato:40 mss:1420 rcvspace:268435456
     cwnd:1052 ssthresh:980 bytes_acked:894210842 segs_out:642109 segs_in:321054
     data_segs_out:642100 minrtt:117.802

Пояснення параметрів:

  • cubic: Підтверджує керування сокетом за стандартом RFC 9438.
  • cwnd:1052: Поточний розмір вікна дорівнює 1052 сегментам ($\approx 1.49$ МБ даних у польоті).
  • ssthresh:980: Поріг повільного старту після мультиплікативного зменшення.
  • rtt:118.24/0.82: Стабільна лінія з базовою затримкою 118 мс і джитером менше ніж 1 мс.

Поєднання переваг RFC 9438, вивіреного налаштування буферів ядра та технологій RiceGuard гарантує передачу зашифрованих даних із максимальною швидкістю фізичного каналу.

Щоб розгорнути швидкісне, бездоганно стабільне шифроване з'єднання на міжнародних магістралях, Завантажити VPNRice.