BBR или CUBIC на VDS: как выбрать TCP congestion control и не потерять ни в throughput, ни в latency

Если вы держите сайты и API на VDS, сетевой стек Linux — ваш скрытый тюнинговый рычаг. Решение, какой TCP congestion control использовать — cubic по умолчанию или более современный bbr — напрямую влияет на throughput и latency ваших пользователей. В этой статье системно разберем, где BBR обгоняет CUBIC, где наоборот, и как аккуратно включить, протестировать и при необходимости откатить изменения без риска для продакшена.

Коротко о TCP congestion control

TCP живет в мире, где канал и буферы конечны. Congestion control — это набор правил роста и снижения окна отправки (cwnd), чтобы занять полосу, но не утонуть в потерях и очередях. Классические алгоритмы (Reno, CUBIC) полагаются на потери пакетов или ECN как сигнал перегрузки, а их стратегия определяет профиль поведения: быстрее ли мы выжмем пропускную, как быстро восстановимся после потерь и какой хвост задержек получим на пиках.

Практический компромисс для веба: нам нужен высокий throughput под крупные отдачи и как можно ниже latency под мелкие ответы (HTML, JSON, gRPC). Очереди на маршрутизаторах и серверных NIC, вместе с буферизацией в ядре, склонны к bufferbloat — той самой липкой задержке, когда задержка резко растет под нагрузкой.

Что делает CUBIC

CUBIC — сегодня дефолт почти во всех дистрибутивах Linux. Это эволюция Reno с кубической функцией роста cwnd, устойчивый и предсказуемый для высоких скоростей и больших RTT. Он хорошо использует доступную полосу, но сигналом для снижения служат потери/ECN, что часто означает: очередь уже выросла, latency поползла вверх, и только потом последует откат.

Сильные стороны CUBIC:

• Зрелость и предсказуемость на стабильных каналах с низким RTT.
• Хорошая совместимость и дружественность к экосистеме (включая ECN).
• Отличная производительность на больших потоках данных внутри одного дата‑центра.

Слабые стороны:

• Хуже контролирует задержку под очередями (bufferbloat) на перегруженных/мобильных/межконтинентальных трассах.
• Восстановление после потерь — «реактивное», тянущее хвосты latency.

Что меняет BBR

BBR (Bottleneck Bandwidth and RTT) пытается измерять узкое место: максимальную пропускную способность и минимальный RTT пути, затем поддерживает такой темп отправки, чтобы не раздувать очередь. Итог — заметно ниже задержка под нагрузкой при сопоставимой или лучшей пропускной способности для типичных веб‑нагрузок.

В реальности это означает: под пиками трафика страницы и API отвечают равномернее, меньше скачков P95/P99, меньше таймаутов у клиентов. В сегментах с переменным качеством канала (WAN, межрегион, 4G/5G) BBR часто выглядит как «бесплатный апгрейд отзывчивости» без кода и CDN.

BBR особенно ценен там, где важно удерживать низкий tail latency при высокой конкуренции за канал. CUBIC выигрывает на простых, стабильных и очень быстрых линках, где очередь почти не растет.

Где на VDS выбор критичен

Для типичного web‑server c HTTP/1.1 или HTTP/2, а также REST/gRPC API:

• Если клиентская аудитория распределена географически и/или сидит на мобильных сетях — BBR почти всегда улучшает отклик.
• Если львиная доля трафика — большие скачивания внутри того же региона/ДЦ, с низким RTT и качественной сетью — CUBIC может быть столь же хорош и предсказуем.
• Смешанной аудитории часто подходит BBR благодаря лучшему контролю задержки.

Важно: для QUIC/HTTP/3 TCP congestion control не применяется — там свои алгоритмы на UDP. Но пока что у многих критичный трафик остается на TCP: TLS‑терминация прокси, бекенды, базы, очереди, микросервисы — тут BBR/CUBIC по‑прежнему решают.

Совместимость ядра и подготовка

Поддержка bbr присутствует в Linux начиная с 4.9. На большинстве LTS‑ядер 5.4/5.10/5.15/6.x алгоритм доступен «из коробки». Тонкости:

• Для качественной работы BBR важен пакетный пайсинг. Рекомендуется дисциплина очереди fq на egress интерфейсе (как минимум по умолчанию в системе).
• Некоторые старые ядра могли собирать BBR как модуль. Убедитесь, что он подгружен.
• Реализации bbr2 встречаются как экспериментальные; в проде начинайте с классического bbr, если нет уверенности и тестов.

Проверка текущих настроек

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

sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control

Проверить дисциплину очереди по умолчанию:

sysctl net.core.default_qdisc

И на конкретном интерфейсе (замените eth0 на ваш):

tc qdisc show dev eth0

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

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

Подробнее

Включаем BBR шаг за шагом

1) Временно (для проверки):

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

2) Проверьте, применилось ли:

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

3) Убедитесь, что новая дисциплина реально на интерфейсе:

tc qdisc show dev eth0

4) Для постоянного применения добавьте в /etc/sysctl.d/99-bbr.conf (или в /etc/sysctl.conf):

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

5) Примените:

sysctl --system

Если BBR в ядре — всё готово. Если видите ошибку о неизвестном алгоритме, проверьте версию ядра или наличие модуля. Также проверьте, что провайдер VDS не использует слишком агрессивные ограничители трафика с высоким jitter — это может смазать эффект.

Проверка на реальном трафике

Минимальный контрольный список, чтобы оценить эффект от BBR на вашем web‑server:

• Соберите базовую метрику до переключения: P50/P95/P99 по $request_time Nginx, ошибки 499/504, средняя скорость отдачи статических файлов, время ответа API под нагрузкой.
• Сделайте переключение на отдельной машине или порту, чтобы провести A/B (например, через TCP‑балансировщик; см. руководство по stream‑балансировке в Nginx).
• Прогоните нагрузочный тест из того же региона и межрегиона, отдельно по мелким ответам (1–50 КБ) и крупным (10–200 МБ).
• Параллельно снимайте ss -s, netstat -s, tc -s qdisc, наблюдайте retransmits и backlog.

Пример быстрой sanity‑проверки того, какой алгоритм применён к текущему TCP‑соединению (подключитесь к вашему порту и смотрите):

ss -ti sport = :443 | grep -i cong

Если хотите оценить throughput, используйте двусторонний iperf3 между двумя вашими VDS (один сервер, другой клиент), в двух режимах — с cubic и bbr. Старайтесь повторить тест в одинаковых условиях времени суток.

Тонкая настройка sysctl под VDS

Базовые системные лимиты чаще не мешают BBR, но есть смысл проверить сетевые буферы и параметры, влияющие на TCP‑поведение. Пример набора, с которого удобно стартовать и проверить влияние:

# Автотюнинг буферов (ориентируйтесь на реальный RTT и BDP)
net.core.rmem_max=33554432
net.core.wmem_max=33554432
net.ipv4.tcp_rmem=4096 87380 33554432
net.ipv4.tcp_wmem=4096 65536 33554432

# Опционально ускоряет разгон после простоя
net.ipv4.tcp_slow_start_after_idle=0

# Пробинг MTU, если часто встречается PMTUD blackhole
net.ipv4.tcp_mtu_probing=1

# timestamps полезны для оценки RTT в BBR
net.ipv4.tcp_timestamps=1

# ECN включайте только при уверенности в трактах
net.ipv4.tcp_ecn=0

• BBR полагается на точный RTT, не отключайте tcp_timestamps.
• tcp_slow_start_after_idle=0 делает поведение дружелюбнее к коротким всплескам (частый паттерн у веба), но оцените влияние на конкурирующие потоки.
• Не раздувайте буферы бездумно — большие rmem/wmem при CUBIC могут усиливать bufferbloat. Тестируйте на ваших профилях трафика.

Взаимодействие с Nginx/Apache и приложениями

BBR снижает вероятность «прилипших» очередей, что уменьшает хвосты latency при высокой конкуренции keep‑alive соединений (особенно HTTP/2). На стороне Nginx стоит убедиться, что лимиты и таймауты не мешают честно измерить эффект:

• Проверьте keepalive_timeout и лимиты подключения к upstream, чтобы не создавать искусственные узкие места.
• Оптимизируйте sendfile и размеры буферов, чтобы не перегружать CPU прерываниями; BBR с pacing может чуть увеличить нагрузку на обработку пакетов, но обычно это компенсируется меньшими очередями.
• Для стриминга больших файлов параллельно с мелкими ответами эффект BBR наиболее заметен — мелким ответам достается меньше «очередного» штрафа.

Типичные грабли

— Включили bbr, но забыли про fq. Проверьте tc qdisc show dev …. Без качественного pacing профиль может быть хуже ожидаемого.

— Тестировали в «час пик» один режим, а другой — ночью. Сетевой фон сильно меняет картину, планируйте A/B синхронно.

— Занижены лимиты файловых дескрипторов и соединений, результат — не сетевой, а ресурсный. Проверьте nofile, бэкенды, очереди.

— Высокий CPU steal на перегруженном узле виртуализации. Проверьте top/vmstat и перенесите тесты на более «чистое» окно.

Когда лучше оставить CUBIC

— Внутридатacenter трафик с очень низким RTT и минимумом очередей, большие сквозные потоки. CUBIC занимает канал стабильно и предсказуемо.

— Вы сильно полагаетесь на ECN в своей сети. BBR не использует ECN как ключевой сигнал.

— У вас старое ядро без BBR и нет возможности обновиться — вкладывайтесь в борьбу с bufferbloat на уровне очередей (например, fq_codel) и таймаутов.

Методика измерений: простой план

1) Снимите базовую метрику с CUBIC: P50/P95/P99 времени ответа, ошибки, средний размер ответа и скорость отдачи. Отдельно сравните внутрисетевой и межрегиональный трафик.

2) Переключите один стенд/порт на BBR. Пустите часть трафика туда (например, через балансировщик по весам или географии). При выборе ресурсов под тест см. как подобрать конфигурацию VDS.

3) Проведите нагрузочное тестирование двумя профилями: «мелкие ответы» и «крупные файлы», фиксируйте стабильность скорости и хвосты задержек.

4) Снимите телеметрию: ss -s, netstat -s, метрики retry/retransmit, количество активных сокетов, заполненность accept‑очереди.

5) Примите решение не по одному числу «средняя скорость», а по набору метрик: P95/P99 latency, таймауты клиентов, успешность загрузок, ровность трафика в часы пиков.

Мониторинг и диагностика

— ss -s, netstat -s: обзор сокетов и статистики TCP.

— tc -s qdisc: очереди и дропы/ECN (если используется).

— sar -n DEV, ethtool -S: загрузка интерфейса и ошибки на NIC.

— Экспортеры для метрик ядра и Nginx: наблюдайте latency‑перцентили, retransmits и 5xx.

Откат на CUBIC

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

sysctl -w net.ipv4.tcp_congestion_control=cubic
sysctl -w net.core.default_qdisc=fq_codel

И верните постоянные значения в вашем sysctl.d, затем sysctl --system. Убедитесь, что новые соединения используют CUBIC (повторная проверка ss -ti).

FAQ по нюансам

— Нужно ли fq_codel вместо fq? Для BBR обычно рекомендуют fq из‑за более точного pacing. fq_codel хорош против bufferbloat под классическими алгоритмами; для BBR тоже может дать приемлемый результат, но fq предсказуемее в тестах с высокими скоростями.

— Поможет ли BBR на медленном диске/CPU? Нет, он не лечит I/O/CPU узкие места, но иногда снижает их видимость за счет сглаживания сетевой очереди.

— Как понять, что BBR работает? Проверьте активный алгоритм, измерьте падение P95/P99 latency под нагрузкой, посмотрите ровность скорости и снижение retransmissions без роста 5xx.

Выводы

BBR — мощный инструмент для снижения задержек без потери пропускной на типичных VDS‑нагрузках: веб‑серверы, API, микросервисы. Он особенно полезен там, где сеть меняется и склонна к очередям. CUBIC остаётся отличным, зрелым дефолтом для стабильных, быстрых линков, крупных потоков внутри одного региона/ДЦ. Универсального «лучшего» нет — есть грамотное A/B‑тестирование под ваш профиль трафика. Начните с аккуратного включения bbr и fq, замерьте метрики и принимайте решение по фактам.