TCP BBR v1/v2 в Linux на VDS: ускоряем throughput и снижаем latency без магии

На практике «скорость сайта» или API часто упирается не в CPU и не в диск, а в то, как TCP разгоняет и удерживает окно передачи в условиях реальной сети: с очередями, переменным rtt, случайным packet loss и конкурентным трафиком. Алгоритм congestion control определяет, как быстро соединение увеличивает скорость (cwnd) и как реагирует на признаки перегрузки.

Исторически на Linux долгое время дефолтом был CUBIC: он хорошо «пробивает» пропускную способность на широких каналах, но в некоторых сценариях провоцирует очереди (bufferbloat), рост задержек (latency) и сильную вариативность времени ответа. На VDS это особенно заметно, когда в одном интерфейсе смешиваются HTTPS-трафик, бэкапы, синхронизации, репликации и проксирование.

TCP BBR (Bottleneck Bandwidth and RTT) меняет философию: он пытается держать скорость примерно на уровне «узкого места» (bottleneck bandwidth) и одновременно не раздувать очереди, ориентируясь на оценку минимального RTT. В результате часто получается более ровный throughput при меньшей задержке, особенно под смешанной нагрузкой.

Зачем трогать congestion control на сервере

Переключение congestion control — один из редких тюнингов, который иногда даёт измеримый эффект «почти бесплатно»: без правок приложения и без дорогостоящего апгрейда железа. Особенно когда у вас много параллельных TCP-сессий (браузеры, мобилки, API-клиенты) и есть фоновый трафик, который способен раздувать очередь.

Типовые симптомы, когда стоит проверить BBR:

• p95/p99 времени ответа растут во время загрузок/бэкапов, хотя CPU свободен;
• скорость отдачи больших файлов «пилит» и плохо держит плато;
• SSH/админка заметно «тупит» в моменты активного трафика;
• пользователи из мобильных сетей жалуются сильнее остальных.

BBR v1 vs bbrv2: что реально важно администратору

BBR v1 — первая массовая версия, доступная во многих ядрах Linux. Для веб-нагрузок и смешанного трафика это часто хороший старт: более ровная скорость и меньше роста задержки из-за локальных очередей.

BBRv2 (в Linux часто отображается как bbr2) — развитие идеи. Упрощённо: v2 старается аккуратнее учитывать потери и лучше сосуществовать с другими потоками, делая поведение более предсказуемым на «неровных» сетях и при конкуренции за канал.

Практическая оговорка: bbrv2 зависит от версии ядра и того, включён ли он в сборке. Поэтому правильный порядок действий такой: сначала проверяем, что доступно на конкретной машине, затем тестируем в одинаковых условиях.

Если вы подбираете сервер под сетевую нагрузку (трафик, география, число соединений), ориентируйтесь на характеристики канала и стабильность сети так же внимательно, как на CPU и RAM. При необходимости можно перейти на более подходящий тариф VDS под ваш профиль трафика.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

qdisc: почему без fq/fq_codel эффект может быть хуже

Congestion control управляет тем, сколько данных TCP держит «в полёте». Но есть ещё локальная очередь на исходящем интерфейсе (qdisc). Если она устроена неудачно, пакеты начинают копиться перед отправкой, растёт latency и появляется bufferbloat даже при правильном congestion control.

Поэтому рядом с BBR почти всегда всплывают две дисциплины очередей:

• fq — частый выбор для BBR: fair queueing и хороший pacing (BBR активно «дозирует» отправку).
• fq_codel — вариант, когда приоритетом является задержка под нагрузкой: CoDel пытается подрезать очередь. Иногда цена — чуть меньший пиковый throughput на некоторых каналах.

Два ключевых sysctl, которые обычно меняют:

• net.ipv4.tcp_congestion_control — выбранный алгоритм (например, bbr или bbr2);
• net.core.default_qdisc — qdisc по умолчанию (например, fq или fq_codel).

Важно понимать границу ответственности: на VDS вы управляете qdisc внутри гостевой ОС. Если основная очередь образуется на хосте виртуализации или у провайдера, эффект будет менее предсказуем. Но даже в этом случае fq/fq_codel часто улучшают локальную очередь и сглаживают отправку.

Проверяем, доступен ли BBR / bbrv2 в системе

Сначала смотрим текущее состояние:

sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc

Проверяем, какие алгоритмы вообще доступны:

sysctl net.ipv4.tcp_available_congestion_control

Если bbrv2 доступен, он часто будет в списке как bbr2. Далее имеет смысл зафиксировать версию ядра:

uname -r

Если дистрибутив грузит BBR модулем, проверяем модуль:

lsmod | grep bbr
modprobe tcp_bbr

Если modprobe сообщает, что модуль не найден, это не всегда проблема: алгоритм может быть встроен в ядро. В таком случае ориентируйтесь на net.ipv4.tcp_available_congestion_control.

Включаем BBR v1: безопасный базовый рецепт

Если в списке доступных есть bbr, начните с него и fq. Это «нейтральная» связка для старта: обычно улучшает ровность отдачи и снижает рост задержек под смешанной нагрузкой.

Временно (до перезагрузки)

sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

Постоянно (через /etc/sysctl.d/)

cat > /etc/sysctl.d/99-bbr.conf << 'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
sysctl --system

Проверка, что значения применились:

sysctl net.core.default_qdisc
sysctl net.ipv4.tcp_congestion_control

Почему не начинать сразу с fq_codel? Потому что fq проще интерпретировать при первичном тесте. Если ваша цель — именно минимальная задержка под аплоадом и очередями, тогда уже сравнивайте с fq_codel по метрикам.

Если хотите системно подойти к подбору ресурсов под ваши сервисы, смотрите материал как подобрать VDS по CPU и RAM под реальные задачи.

Включаем bbrv2 (bbr2): когда пробовать и как не запутаться

Если в net.ipv4.tcp_available_congestion_control есть bbr2, можно тестировать так же, как v1:

Временно

sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr2

Постоянно

cat > /etc/sysctl.d/99-bbr2.conf << 'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr2
EOF
sysctl --system

Сценарии, где bbrv2 чаще оправдан:

• много «длинных» соединений (скачивания, репликации) параллельно с интерактивными запросами;
• значимая доля пользователей в мобильных/Wi‑Fi сетях;
• на BBR v1 наблюдается нестабильный throughput или «качели» под конкуренцией потоков.

Если у вас типичный сайт/API без тяжёлых передач, а ограничения упираются в приложение/БД, разница между v1 и v2 может быть минимальной. Тогда лучше потратить время на профилирование и оптимизацию узких мест.

Как измерять эффект правильно: RTT, loss, throughput и latency под нагрузкой

Ошибка №1 — включить BBR и сделать один прогон «спидтеста». BBR меняет динамику именно под нагрузкой и при конкуренции потоков, поэтому измеряйте минимум в двух режимах: «пусто» и «под нагрузкой».

1) Базовая задержка и джиттер

Быстрая оценка до какого-нибудь стабильного узла:

ping -c 20 1.1.1.1

Для понимания, где проявляются потери и задержки по маршруту:

mtr -rw -c 200 1.1.1.1

Отличайте реальную потерю от rate-limit ICMP на промежуточных узлах: чаще всего важнее поведение на последнем хопе и итоговый RTT.

2) RTT и состояние TCP на сервере

Состояние активных TCP-соединений и оценку RTT удобно смотреть через ss:

ss -ti '( sport = :https or dport = :https )'

В выводе ищите rtt, cwnd и признаки ретрансляций. Это не бенчмарк, но хорошая «живущая» диагностика, когда пользователи жалуются прямо сейчас.

3) Throughput и «latency под нагрузкой»

Самый честный тест — замерить реальную отдачу ваших файлов/ответов и параллельно держать серию запросов к приложению (или простую проверку доступности) и смотреть p95/p99. Именно «хвосты» часто улучшаются от BBR + fq, даже если среднее меняется слабо.

Типовые сценарии на VDS, где BBR даёт плюс

Раздача больших файлов и обновлений

Если вы раздаёте архивы, бэкапы, образы или проксируете ответы большого размера, BBR часто повышает стабильный throughput и уменьшает «пилу» скорости, особенно при неидеальной сети у клиента и большом числе потоков.

HTTPS плюс фоновые задачи (бэкапы, rsync, репликации)

Классика: стартует бэкап, канал забивается, и даже SSH начинает лагать. Переход с CUBIC на BBR нередко делает деградацию менее болезненной, но если задача регулярная и тяжёлая, следующий уровень — shaping и приоритизация через tc.

API и веб-приложения, чувствительные к latency

BBR не «сократит расстояние» до пользователя, но может уменьшить рост задержки из-за очередей на сервере при пиковых всплесках, особенно когда параллельно идут тяжёлые передачи.

Когда BBR может не помочь (или даже ухудшить)

Ожидайте нулевой эффект или спорный результат, если:

• узкое место не сеть, а CPU/диск/БД;
• канал жёстко полисится или шейпинг нестандартный, и доступная полоса сильно «дергается»;
• важна специфическая «справедливость» между потоками, и после переключения вы видите конфликты с соседним трафиком.

BBR — не «ускоритель интернета», а инструмент управления очередями и скоростью в TCP. Включайте его как изменение на проде: с измерениями и откатом, если p95/p99 и стабильность не улучшаются.

Если параллельно вы закрываете вопросы безопасности (HTTPS, HSTS, корректные цепочки), удобно держать сертификаты в порядке и обновлять их заранее: SSL-сертификаты для публичных сервисов.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Чек-лист внедрения на проде

1. Зафиксируйте исходные значения net.ipv4.tcp_congestion_control и net.core.default_qdisc, а также p95/p99 времени ответа и базовый RTT.

2. Включите fq + BBR v1, соберите метрики минимум за сутки (лучше за 2–3), учитывая пик и фоновые задачи.

3. Если доступен bbr2, повторите тест в отдельное окно времени с теми же сценариями нагрузки.

4. Сравнивайте не только среднее: смотрите ретрансляции, стабильность throughput и «хвосты» latency (p95/p99).

5. При сильном аплоаде/бэкапах планируйте следующий шаг: shaping и приоритизация трафика, иначе congestion control будет лечить симптом.

Мини-FAQ

Можно ли включить BBR «для всех» и забыть?

Технически да: это пара sysctl. Практически лучше сделать короткий A/B-тест по времени и оставить тот вариант, который улучшает ваши метрики (особенно p95/p99), а не разовый пик в тесте.

Что выбрать: fq или fq_codel?

Для старта с BBR берите fq. Если боретесь именно с bufferbloat и ростом задержки под нагрузкой, пробуйте fq_codel и обязательно перепроверяйте throughput на ваших типовых передачах.

Нужно ли менять что-то ещё, кроме двух sysctl?

Обычно нет. Если же аплоад забивает интерактивный трафик, то дальше уже tc, классы и приоритизация. И отдельно следите за прикладной частью: например, для PostgreSQL часто полезнее оптимизировать пул соединений и запросы, чем бесконечно тюнить сеть.

Вывод

TCP BBR (и bbrv2, когда он доступен) — один из самых «дешёвых» по усилиям способов улучшить сетевое качество на Linux: повысить стабильный throughput и снизить рост latency из-за очередей. Начните с BBR v1 и fq, измерьте реальные метрики (rtt, packet loss, p95/p99 времени ответа под нагрузкой), а затем решайте, нужен ли bbr2 и стоит ли пробовать fq_codel.