Представим распределённую инфраструктуру в разных регионах. Между площадками есть VPN: он даёт связность и защищает трафик. Каждый час нужно передать бэкап объёмом 50 GB и развернуть его в другом регионе.

Чтобы уложиться в час, нужна стабильная полезная скорость. Но после запуска cronjob оказывается, что передача идёт заметно медленнее: RTT около 30 ms, иногда теряются пакеты, а бэкап не успевает скачаться даже за пару часов.

30 ms между регионами - само по себе нормально. Проблема обычно в сочетании задержки, потерь, очередей на пути и одного TCP-потока.

Частая причина - не сам VPN, а алгоритм управления перегрузкой TCP, который работает на сервере-отправителе.

По умолчанию на Linux используется CUBIC. Он постепенно увеличивает окно TCP и воспринимает потери пакетов как сигнал перегрузки. На длинном или неидеальном канале это может привести к тому, что доступная полоса используется не полностью.

Google в 2016 году представил BBR - Bottleneck Bandwidth and Round-trip time. И вместо того чтобы ориентироваться в первую очередь на потери, новый лагоритм пытается оценить:

максимальную пропускную способность узкого места;
минимальный RTT;
сколько данных нужно держать "в полёте", чтобы загрузить канал, но не раздувать очереди.

Периодически BBR осторожно проверяет, не выросла ли доступная полоса, а затем возвращается к рассчитанному рабочему режиму.

Важно понимать, что BBR - не магическая кнопка "ускорить сетку" и не замена диагностике. Он не исправит узкий канал, неверный MTU, перегруженный VPN-шлюз, медленный диск или реальную потерю пакетов из-за проблем в сети. Но на межрегиональных TCP-передачах может дать очень заметный эффект.

И ещё важный нюанс: BBR влияет на TCP-соединения, которые создаёт сам хост. Если VPN-шлюз просто маршрутизирует или NAT’ит трафик, включение BBR только на нём не ускорит проходящие через него TCP-сессии. Включать его нужно прежде всего на сервере, который реально отправляет большой объём данных.

Например, если rsync передаёт файлы из региона A в регион B, BBR нужен на сервере в регионе A, который отправляет содержимое файлов.

Где это имеет смысл пробовать включить BBR:

передача бэкапов между регионами;
rsync и репликация больших объёмов данных;
выгрузки из хранилищ;
сервисы с длинными TCP-соединениями между облаками или ЦОДами;
серверы, которые реально являются отправителями трафика.

Включается очень просто - на Linux сначала проверяем, доступен ли алгоритм:

sysctl net.ipv4.tcp_available_congestion_control

Если в выводе есть bbr, можно включить его для новых TCP-соединений:

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

Для постоянной настройки после теста можно добавить параметры в отдельный файл:

sudo tee /etc/sysctl.d/90-bbr.conf <<'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF

sudo sysctl --system

На моей практике включение BBR на серверах, которые непосредственно передавали данные, дало прирост до x6. Но это результат конкретного канала, а не гарантированный эффект для любой сети.

Сравнивать лучше до и после, причём и одним потоком, и несколькими:

# Один TCP-поток — ближе к одному backup/rsync-потоку
iperf3 -c YOUR_IP -t 60 -P 1

# Суммарная доступная полоса при нескольких потоках
iperf3 -c YOUR_IP -t 60 -P 16

# Проверка обратного направления
iperf3 -c YOUR_IP -t 60 -P 1 -R

Тестируйте на отдельном окне или в согласованное время: iperf3 -P 16 вполне способен нагрузить канал так, что коллеги быстро заметят эксперимент 🙂

Ну а если вам инетерсно почитать как это работает под капотом, то начинайте сразу с BBRv3. А эту статью добавь в сохраненки - если ты тут, то точно пригодится =)

Пробуем прокачать сеть между цодами