Представим распределённую инфраструктуру в разных регионах. Между площадками есть 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. А эту статью добавь в сохраненки - если ты тут, то точно пригодится =)
