Складним викликом для мережевих інженерів та віддалених фахівців залишається різке падіння швидкості на транзитних магістральних маршрутах великої протяжності. Користувач із симетричним гігабітним оптоволоконним каналом підключається до захищеного тунелю, наприклад, між Токіо та Франкфуртом із круговою затримкою Round-Trip Time (RTT) на рівні 220 мс. Попри мінімальне навантаження на процесор CPU та надлишок фізичної смуги пропускання, швидкість завантаження в один потік Single-Stream стрімко падає з сотень мегабітів до скромних 12–18 Мбіт/с.

У таких випадках підозра часто помилково падає на обчислювальні витрати криптографії або штучні обмеження провайдера інтернету (ISP). Насправді корінь проблеми майже завжди криється в класичному алгоритмі керування перевантаженнями транспортного рівня: TCP CUBIC.

Протягом десятиліть глобальна мережа спиралася на моделі контролю перевантажень, орієнтовані на втрату пакетів (Loss-based Congestion Control). Проте всередині інкапсульованих тунелів VPN із високим добутком пропускної здатності на затримку Bandwidth-Delay Product (BDP) цей підхід зазнає відчутного краху. Поява алгоритму TCP BBR (Bottleneck Bandwidth and Round-trip propagation time), створеного Ваном Якобсоном, Нілом Кардвеллом та дослідницькою групою Google, змінила правила проєктування мереж, замінивши виявлення втрат фізичним моделюванням каналу.

[Традиційна модель CUBIC на основі втрати пакетів]
Зростання cwnd ──> Заповнення буфера маршрутизатора ──> Переповнення (Tail Drop) ──> Втрата пакета ──> Зріз вікна (-30%)
                         ▲                                                                                     │
                         └──────────────── Повільне відновлення за кубічною кривою ───────────────────────────┘
                                 Наслідок: Значний Bufferbloat, стрибки затримки, провал швидкості

─────────────────────────────────────────────────────────────────────────────────────────────────────────────

[Модель TCP BBR на основі фізичного стану каналу]
Постійне вимірювання: Пропускна здатність вузького місця (BtlBw) та мінімальний RTT (RTprop)
Регулювання темпу Kernel Pacing за реальною швидкістю ──> Черги маршрутизатора порожні ──> Немає надлишкових даних
                                 Результат: Повна пропускна здатність, відсутність Bufferbloat, стабільний пінг

Математичні обмеження керування на основі втрат: CUBIC (RFC 9438)

Щоб з'ясувати причину падіння швидкості, варто проаналізувати логіку роботи алгоритму TCP CUBIC (стандартизованого в RFC 9438).

У межах схеми AIMD (Additive-Increase/Multiplicative-Decrease) CUBIC вважає, що втрата пакета є єдиним підтвердженням перевантаження мережі. Алгоритм безперервно розширює вікно перевантаження ($cwnd$), доки буферна пам'ять проміжного комутатора не переповниться і не почне відкидати пакети (Tail Drop).

Після фіксації втрати через потрійні дубльовані підтвердження Triple-Duplicate ACK або через Selective Acknowledgment (SACK), CUBIC застосовує жорстке мультиплікативне покарання:

$$W_{\max} = \text{Поточний обсяг даних у польоті}$$ $$cwnd_{\text{новий}} = W_{\max} \times \beta \quad (\text{де } \beta = 0.7)$$

Вікно передачі миттєво скорочується на 30%, незалежно від того, чи була втрата спричинена справжнім затором у черзі, чи звичайними радіозавадами в каналі Wi-Fi/LTE.

У 1997 році Метью Матіс сформулював фундаментальну математичну межу швидкості для протоколів TCP на основі втрат, відому як Формула Матіса (Mathis Formula):

$$\text{Пропускна здатність} \le \frac{\text{MSS}}{\text{RTT}} \times \frac{C}{\sqrt{p}}$$

Де $\text{MSS}$ — максимальний розмір сегмента Maximum Segment Size, $\text{RTT}$ — кругова затримка, $p$ — ймовірність втрати пакета, а константа $C \approx 1.22$.

Розглянемо параметри реального міжнародного тунелю VPN:

  • $\text{RTT} = 160\text{ мс } (0.160\text{ с})$
  • $\text{MSS} = 1380\text{ байтів } (11,040\text{ бітів})$
  • Фонова випадкова втрата пакетів у магістралі $p = 1% \ (0.01)$:

$$\text{Пропускна здатність} \le \frac{11,040}{0.160} \times \frac{1.22}{\sqrt{0.01}} = 69,000 \times 12.2 \approx 841,800\text{ біт/с} \approx 6.7\text{ Мбіт/с}$$

Навіть на гігабітному оптоволоконному каналі лише 1% випадкових втрат змушує CUBIC знизити швидкість до рівня нижче 7 Мбіт/с. Оскільки алгоритму потрібні десятки циклів RTT для відновлення кубічної траєкторії, висока затримка консервує низьку швидкість, і сесія не встигає відновитися до наступного скидання пакета.

Проблема Bufferbloat у зашифрованих каналах

Алгоритми на основі втрат не лише знижують швидкість завантаження, але й відчутно шкодять інтерактивному трафіку через феномен Bufferbloat (роздування буферів).

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

Це створює значну штучну затримку:

  1. Під час передачі великих файлів у фоновому режимі CUBIC заповнює буфер вузького місця на 100%.
  2. Пакети, чутливі до затримки—як-от службові сигнали WireGuard Keepalive, натискання клавіш у терміналі SSH, запити Domain Name System (DNS) або голосовий трафік VoIP—змушені чекати позаду тисяч великих пакетів.
  3. Кругова затримка RTT зростає з початкових 25 мс до понад 400 мс.
  4. Виникає високий джитер (Packet Jitter), переривання зв'язку та затримка відгуку програм, хоча фізичний канал не вичерпано.

Архітектура BBR: робота в оптимумі Клейнрока

У 2016 році Ван Якобсон та Ніл Кардвелл представили алгоритм BBR, щоб вирішити цю багаторічну проблему.

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

  1. Пропускна здатність вузького місця ($\text{BtlBw}$): максимальна фізична швидкість передачі на найповільнішому відрізку маршруту.
  2. Мінімальний час поширення сигналу ($\text{RTprop}$): чиста фізична затримка проходження світла в оптоволокні без урахування перебування в буферах.

Леонард Клейнрок ще у 1979 році довів, що ідеальна точка роботи будь-якої мережі досягається тоді, коли обсяг даних у польоті (Inflight Data) точно дорівнює добутку смуги на затримку (Bandwidth-Delay Product, BDP):

$$\text{BDP} = \text{BtlBw} \times \text{RTprop}$$

Затримка / Пропускна здатність
       │                       Оптимум Клейнрока (Kleinrock Point)
       │                                     ▼
Швидкість ──────────────────────────┐────────────────────────── (Канал насичено на рівні BtlBw)
       │                           ╱│
       │                          ╱ │
       │                         ╱  │
RTT    │                        ╱   │  Початок накопичення черги ─> (Поява Bufferbloat!)
       │                       ╱    │  ┌───────────────────────
Базовий RTprop ───────────────┴─────┴──┴───────────────────────
       └───────────────────────────────────────────────────────
                                 Обсяг даних у польоті (Inflight)

В оптимальній точці Клейнрока:

  • Швидкість доставки сягає фізичного максимуму ($\text{Throughput} = \text{BtlBw}$).
  • Затримка залишається мінімальною ($\text{RTT} = \text{RTprop}$).
  • Черга пакетів у буфері маршрутизатора дорівнює нулю, що виключає Bufferbloat.

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

  • STARTUP: експоненційне прискорення для швидкого визначення пікової смуги каналу.
  • DRAIN: короткочасне зниження темпу для спустошення черг, створених на старті.
  • PROBE_BW: циклічне зондування пропускної здатності (коефіцієнт 1.25x протягом одного RTT для пошуку нової смуги, 0.75x для очищення буфера, і 1.0x протягом наступних шести RTT).
  • PROBE_RTT: зменшення обсягу даних у польоті до 4 сегментів кожні 10 секунд на 200 мс для точного вимірювання чистої фізичної затримки $\text{RTprop}$.

Завдяки плавному регулюванню темпу Kernel Pacing на рівні планувальника Fair Queueing замість залпових сплесків, BBR забезпечує рівномірне надходження пакетів у канал.

Еволюція алгоритму: від BBRv1 до BBRv3

Практика використання BBRv1 окреслила два напрями для вдосконалення:

  1. Співіснування з CUBIC: У глибоких буферах потоки CUBIC заповнюють пам'ять до відмови, через що BBRv1 інколи отримував дещо меншу частку смуги.
  2. Неглибокі буфери: За значних випадкових втрат (понад 15–20%) BBRv1 міг утримувати зависокий обсяг даних у польоті.

Спільнота IETF та фахівці Google вирішили ці виклики у версіях BBRv2 та BBRv3:

  • Інтеграція Explicit Congestion Notification (ECN): BBRv3 зчитує прапорці CE за стандартом RFC 3168 для раннього зниження темпу до скидання пакетів.
  • Гнучкі обмеження обсягу в польоті: коригування темпу з урахуванням спостережуваних втрат для справедливого розподілу смуги (Fair-Share) з потоками CUBIC.
  • Прискорені фази вимірювання RTT: оптимізація інтервалів PROBE_RTT для усунення просідань швидкості.
Показник TCP Reno (RFC 5681) TCP CUBIC (RFC 9438) TCP BBRv1 TCP BBRv3
Керуючий сигнал Втрата пакета Втрата пакета Модель швидкості та RTT Швидкість, RTT, втрати та ECN
Механізм надсилання Залповий (Bursts) Залповий (Bursts) Темпування ядра (fq) Темпування ядра (fq)
Вплив на Bufferbloat Значний Значний Мінімальний Повністю усунуто
Стійкість до 1% втрат Критична (< 5% швидкості) Слабка (< 10% швидкості) Висока (95%+ швидкості) Максимальна (98%+ швидкості)
Заповнення BDP Дуже повільне Середнє Миттєве Миттєве та адаптивне
Баланс з іншими потоками Базовий Базовий Агресивний до CUBIC Справедливий (Fair-Share)

Налаштування BBR у системі Linux

Керування перевантаженнями TCP є рішенням кінцевого вузла (Endpoint Decision). У тунелях Layer-3 (WireGuard, RiceGuard) внутрішні потоки TCP пакуються в пакети UDP. Активація BBR на серверах або шлюзах VPN регулює інтенсивність введення даних у тунель.

Конфігурація ядра Linux

Для увімкнення BBR модуль поєднують із дисципліною черг Fair Queueing (fq):

# Перевірка доступних модулів керування перевантаженнями
sysctl net.ipv4.tcp_available_congestion_control

# Активація черги Fair Queueing та перехід на BBR
sudo sysctl -w "net.core.default_qdisc = fq"
sudo sysctl -w "net.ipv4.tcp_congestion_control = bbr"

# Налаштування ліміту невідісланих даних сокета
sudo sysctl -w "net.ipv4.tcp_notsent_lowat = 16384"

Для збереження параметрів створіть файл /etc/sysctl.d/99-bbr-optimization.conf:

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_notsent_lowat = 16384
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432

Параметр tcp_notsent_lowat = 16384 (16 КБ) обмежує накопичення даних у внутрішніх буферах сокетів, запобігаючи виникненню локального Bufferbloat.

Моніторинг активних сесій

Мережеві фахівці можуть відстежувати роботу BBR у реальному часі за допомогою утиліти ss:

# Перевірка телеметрії активних сесій TCP
ss -tin '( dport = :443 or sport = :443 )'

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

ESTAB 0 0 10.0.0.2:48392 198.51.100.1:443
  bbr:(bw:182.4Mbps,mrtt:158.21,pacing_rate:228.0Mbps,cwnd:240)
  cubic:(...)

Звіт відображає розрахункову смугу вузького місця bw:182.4Mbps, мінімальний пінг mrtt:158.21 мс та апаратну швидкість надсилання даних.

Впровадження BBR в інфраструктурі VPNRice та протоколі RiceGuard

Якісна безпечна мережа потребує раціонального керування потоками. VPNRice інтегрує алгоритми BBR безпосередньо в протокол RiceGuard:

  • Регулювання на вузлах Anycast: Сервери Anycast платформи VPNRice використовують алгоритми BBR та планувальник FQ на інтерфейсах маршрутизації, згладжуючи піки трафіку перед магістральними лініями.
  • Збереження швидкості під час випадкових втрат: Під час підключення через мобільні мережі 4G/5G або завантажений Wi-Fi протокол RiceGuard запобігає падінню швидкості на 70%, характерному для застарілих налаштувань CUBIC.
  • Стабільна затримка для інтерактивних сервісів: Збереження порожніх черг буферів за моделлю Клейнрока забезпечує стабільний відгук і відсутність коливань пінгу в онлайн-іграх та конференціях.