TCP BBR и тюнинг сети Linux: что реально ускоряет соединение

TCP BBR часто продают как «ускорение интернета одной командой». На практике алгоритм меняет то, как ядро выбирает скорость отправки, и помогает только там, где потери пакетов и задержка мешают классическому CUBIC. В локальной сети, при ограничении провайдера или плохом Wi-Fi выигрыша не будет. Разберём, что именно делает BBR, как проверить текущее состояние и какие параметры действительно влияют на соединение.

Как работает управление перегрузкой

Отправитель не знает пропускную способность пути заранее и подбирает её по обратной связи. CUBIC увеличивает окно, пока не появится потеря, а затем резко снижает скорость. На чистом канале это работает хорошо, но в мобильной сети или на дальнем маршруте потери бывают случайными, и алгоритм принимает их за перегрузку. BBR вместо реакции на потери строит модель: измеряет минимальную задержку и максимальную доставленную скорость, после чего подбирает темп отправки.

BBR требует планировщика с пейсингом, обычно fq. Без него алгоритм работает хуже, а иногда и вовсе не даёт эффекта. Важно понимать границы: BBR не увеличивает тариф провайдера, не ускоряет DNS, не лечит перегруженный процессор и не компенсирует потери в эфире. Он меняет только поведение отправителя в рамках доступного канала.

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

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

sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control
tc qdisc show dev eth0
ss -ti dst 203.0.113.10

В выводе ss -ti смотрите строку с bbr или cubic, значения cwnd, rtt, retrans и delivery_rate. Высокий RTT при низком delivery_rate говорит о задержке, а рост retrans — о потерях. Если модуль не загружен, modprobe tcp_bbr покажет ошибку; в контейнерах и облачных ядрах алгоритм иногда выключен на этапе сборки. Проверить конфигурацию ядра можно через /boot/config-$(uname -r) или /proc/config.gz.

Включение и сохранение настроек

Проверьте доступность алгоритма, загрузите модуль и переключите планировщик. Настройки нужно записать в файл, иначе после перезагрузки вернутся значения по умолчанию. Не редактируйте /etc/sysctl.conf без необходимости: отдельный файл в /etc/sysctl.d проще откатить.

sudo modprobe tcp_bbr
sudo sysctl -w net.core.default_qdisc=fq
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl --system

Файл /etc/sysctl.d/99-bbr.conf содержит две строки: net.core.default_qdisc = fq и net.ipv4.tcp_congestion_control = bbr. После sysctl --system повторите проверку из предыдущего раздела. Изменение затрагивает новые соединения; уже установленные сессии продолжат работать со старым алгоритмом.

cat /etc/sysctl.d/99-bbr.conf
sudo sysctl -p /etc/sysctl.d/99-bbr.conf
sysctl net.ipv4.tcp_congestion_control net.core.default_qdisc

Откат должен быть так же прост, как включение. Если после переключения выросли задержки или упала скорость на конкретном маршруте, верните CUBIC и fq_codel, не пытаясь «донастроить» всё сразу. Так вы сохраните контроль над изменениями и сможете сравнить поведение честно.

sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo sysctl -w net.core.default_qdisc=fq_codel
sudo rm /etc/sysctl.d/99-bbr.conf

В контейнерах параметр net.ipv4.tcp_congestion_control относится к сетевому пространству имён. Если приложение запущено в Docker с собственным namespace, настройка хоста может не примениться. Проверяйте изнутри контейнера, а не только на хосте.

Буферы, MTU и честный тест

BBR не требует гигантских буферов, но совсем маленькие ограничивают окно. Ориентир — произведение полосы на задержку: для 100 Мбит/с и 40 мс это около 500 КБ на поток. Значения net.ipv4.tcp_rmem и tcp_wmem задаются тройкой «минимум, по умолчанию, максимум»; увеличивать максимум имеет смысл на серверах с большим числом дальних клиентов, а не на домашнем ноутбуке.

Отдельная история — MTU. Если большие пакеты теряются, соединение «зависает» на передаче файлов, хотя мелкие запросы работают. Проверка с запретом фрагментации показывает рабочий размер: ping -M do -s 1472 для MTU 1500. Ноль потерь на 1472 и потери на 1473 указывают на проблему Path MTU; параметр net.ipv4.tcp_mtu_probing=1 помогает, но маскирует причину.

iperf3 -c 198.51.100.20 -t 30 -P 4
iperf3 -c 198.51.100.20 -t 30 -P 4 -R
ping -M do -s 1472 -c 4 198.51.100.20
nstat -az | grep -E "TcpRetrans|TcpExtTCPLostRetransmit"

Тестируйте на своём сервере, а не на публичных узлах: чужой канал и чужой процессор исказят картину. Сравнивайте CUBIC и BBR в одинаковых условиях, в обе стороны, с несколькими потоками и в разное время суток. Один прогон на 10 секунд ничего не доказывает.

Где BBR вредит

На домашнем роутере с медленным аплинком BBR может заполнить очередь и увеличить задержку для всех устройств. Если видеозвонки начинают «квакать» при скачивании, смотрите не на congestion control, а на очередь: tc -s qdisc show покажет backlog и drops. На маршрутизаторах помогает fq_codel или CAKE, а не BBR на каждом устройстве.

• Локальная сеть и дата-центр: выигрыша нет, иногда есть просадка из-за пейсинга.
• Слабый процессор роутера: дополнительная нагрузка на таймеры и обработку пакетов.
• Wi-Fi: потери из-за ретраев и помех, а не перегрузки; проверяйте iw dev wlan0 link.
• Смешанный трафик: BBR может быть агрессивнее CUBIC и отнимать полосу у соседей.
• Уже установленные соединения: параметр применяется только к новым.

Проверять эффект стоит по задержке и стабильности, а не только по максимальной скорости. Если скорость выросла, а ping под нагрузкой вырос с 20 до 200 мс, пользоваться сетью станет хуже. Смотрите на delivery_rate, ретрансмиссии и субъективную отзывчивость.

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

• Убедитесь, что канал действительно проблемный: высокий RTT, потери, дальний маршрут.
• Проверьте наличие модуля и планировщика fq.
• Включите BBR, повторите замеры в обе стороны.
• Сравните задержку под нагрузкой, а не только пиковую скорость.
• Зафиксируйте настройки в /etc/sysctl.d и задокументируйте откат.

Итог

BBR — точный инструмент для конкретной проблемы: потери и задержка мешают TCP использовать доступную полосу. Он не заменяет нормальный канал, драйверы и разумную настройку очередей. Проверяйте состояние через ss и tc, тестируйте на своём сервере и всегда оставляйте путь к откату.