Представим распределённую инфраструктуру в разных регионах. Между площадками есть 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=fqnet.ipv4.tcp_congestion_control=bbrEOFsudo 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.
ссылка на оригинал статьи https://habr.com/ru/articles/1087874/