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

В таких ситуациях подозрение часто ошибочно падает на вычислительные затраты криптографических алгоритмов или принудительное ограничение скорости со стороны интернет-провайдера (ISP). В действительности истинная причина почти всегда кроется в классическом алгоритме управления перегрузками транспортного уровня: TCP CUBIC.

На протяжении десятилетий стек сетевых протоколов полагался на механизмы управления перегрузками, ориентированные на потерю пакетов (Loss-based Congestion Control). Однако внутри инкапсулированных туннелей VPN с высоким произведением пропускной способности на задержку (Bandwidth-Delay Product, BDP) эти алгоритмы демонстрируют структурную неэффективность. Создание алгоритма 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) или механизму 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}$ — максимальный размер сегмента, $\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 Гбит/с всего 1% случайных потерь заставляет CUBIC снизить скорость передачи ниже 7 Мбит/с. Так как алгоритму требуются десятки циклов RTT для восстановления кубической кривой, высокая задержка усугубляет ситуацию, и соединение не успевает восстановить скорость до следующего случайного сброса пакета.

Проблема Bufferbloat в туннелях с шифрованием

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

Поскольку CUBIC распознает перегрузку только после переполнения буфера, он непрерывно закачивает избыточные пакеты в промежуточное оборудование. Сетевые коммутаторы и абонентские маршрутизаторы с объемными FIFO-буферами задерживают эти пакеты в системной памяти.

Это порождает колоссальную искусственную задержку:

  1. Во время фоновой передачи объемных данных CUBIC заполняет буфер узкого места на 100%.
  2. Чувствительные к задержке пакеты—такие как служебные сигналы WireGuard Keepalive, интерактивные сессии SSH, запросы 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 на протяжении 6 RTT).
  • PROBE_RTT: снижение объема данных в полете до 4 сегментов каждые 10 секунд на 200 мс для точного замера чистой физической задержки $\text{RTprop}$.

Использование пейсинга пакетов (Kernel Pacing) на уровне планировщика Fair Queueing вместо пакетных залпов (Bursts) обеспечивает равномерное поступление данных в канал без перегрузки очередей.

Эволюция алгоритма: от BBRv1 к BBRv3

Практическая эксплуатация BBRv1 выявила отдельные аспекты, требовавшие доработки:

  1. Взаимодействие с CUBIC: В глубоких буферах потоки CUBIC непрерывно переполняют память, из-за чего BBRv1 иногда уступал часть справедливой полосы пропускания.
  2. Неглубокие буферы: При очень высоких случайных потерях (свыше 20%) BBRv1 мог удерживать чрезмерный объем данных в полете.

Консорциум IETF и инженеры Google решили эти задачи в версиях BBRv2 и BBRv3:

  • Поддержка ECN (Explicit Congestion Notification): BBRv3 считывает флаги CE (Congestion Experienced) по RFC 3168 для упреждающего замедления до сброса пакетов.
  • Адаптивные лимиты данных в полете: ограничение объема передаваемых данных с учетом реального уровня потерь для гармоничного сосуществования с трафиком 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), минимальный RTT (mrtt:158.21) и аппаратную скорость пейсинга.

Интеграция BBR в инфраструктуру VPNRice и протокол RiceGuard

Современная сетевая безопасность требует продуманной маршрутизации и контроля задержек. Платформа VPNRice внедряет пейсинг BBR непосредственно в архитектуру RiceGuard:

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