BBR принято считать современным стандартом TCP congestion control. Google разработал его в 2016 году, он работает в production крупнейших CDN, его хвалят в каждой второй статье о сетевой оптимизации. И всё это заслуженно — но с существенной оговоркой, о которой обычно не пишут.
Почему BBR хорош — и где именно
BBR (Bottleneck Bandwidth and Round-trip propagation time) отказывается от базового принципа большинства предшественников — считать потерю пакета признаком перегрузки. Вместо этого он строит модель пути — измеряет максимальную достигнутую полосу и минимальный RTT, и держит окно отправки соответствующим этой модели.
На WAN-линках с высоким BDP (bandwidth-delay product) это работает блестяще — по двум причинам. Во-первых, CUBIC (по-умолчанию в Linux с 2006 года) после потери пакета снижает окно на 30 % и восстанавливает его по кубической функции от времени: на линке 10 Gbps с RTT 100 мс возврат к полной полосе занимает секунды. BBR не снижает pacing rate из-за единичного дропа — он продолжает слать на измеренной скорости. Во-вторых, CUBIC для полной утилизации полосы на высоком BDP требует больших буферов на транзитных узлах — и, не найдя их, быстро ловит tail-drop и проваливается. BBR опирается на RTprop, не пытается заполнить транзитные буферы и держит их почти пустыми.
Но дома у вас, скорее всего, не WAN-линк до ноута и смартфона.
Wi-Fi — другая среда
802.11 устроен иначе, чем проводной Ethernet. У него есть собственный механизм ретрансмиссии на канальном уровне: когда фрейм не доходит, точка доступа повторяет его до 4–7 раз, прежде чем сообщить об ошибке выше.
Но большинство TCP-потерь при работе BBRv1 на Wi-Fi происходят не от того, что кадр «не пробился через помехи после 7 попыток». Чаще причина другая: BBRv1 рассчитывает pacing rate по пиковой полосе, и когда Wi-Fi линк кратковременно деградирует (скажем, из-за интерференции MCS падает с 12 до 8), BBRv1 продолжает заливать буфер точки доступа на прежней скорости. Буфер AP переполняется, и роутер дропает IP-пакеты ещё до того, как они попадут в эфир.
Проблема BBRv1 в том, что он игнорирует эти потери как сигнал. Его модель говорит: «полоса есть, RTT_min не вырос — продолжаем». И он продолжает, генерируя TCP-ретрансмиты поверх уже случившихся потерь. На shared medium это двойная нагрузка на эфир.
Вот как это выглядит на реальном железе — передача по iperf3 через Wi-Fi (TX 2.4 Gbps) с BBRv1 на ядре 6.17:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 1.56 GBytes 1.34 Gbits/sec 15410 sender
[ 5] 0.00-10.00 sec 1.51 GBytes 1.29 Gbits/sec receiver15 410 ретрансмитов за 10 секунд. Throughput высокий, но какой ценой для эфира.
Алгоритмы, которые знали про беспроводные сети ещё в нулевых
Пока BBR не существовал, исследователи уже понимали проблему: классические loss-based алгоритмы (Reno, CUBIC) ведут себя на Wi-Fi плохо именно потому, что не умеют отличать случайные потери от потерь из-за перегрузки. И написали алгоритмы, которые умеют.
TCP Westwood+ (2004) оценивает доступную полосу по скорости приходящих ACK. При потере он не режет окно пополам вслепую, а выставляет его пропорционально измеренному BW × RTT_min. Случайный дроп на беспроводном канале — не повод выбрасывать за борт всё накопленное знание о полосе. (Модуль в ядре называется tcp_westwood — внутри реализован именно Westwood+, исправляющий баг оригинала с переоценкой полосы при частых ACK.)
TCP Veno (2004) берёт идею из TCP Vegas: смотрит на разницу между текущим RTT и RTT_min как на косвенную оценку заполненности очереди. Если при потере очередь пустая — скорее всего, дроп случайный; окно режется мягче.
TCP Illinois (2006) — гибрид: потеря по-прежнему основной сигнал, но параметры AIMD (насколько агрессивно растём и насколько сильно откатываемся) модулируются по задержке. Маленькая задержка — растём быстро, откатываемся мало. Задержка выросла — тормозим заранее.
Те же условия, тот же роутер, те же 10 секунд:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 1.33 GBytes 1.14 Gbits/sec 1307 sender
[ 5] 0.00-10.00 sec 1.27 GBytes 1.09 Gbits/sec receiverThroughput ниже примерно на 15%, ретрансмитов — в 12 раз меньше. На shared Wi-Fi это не просто эстетика: меньше ретрансмитов означает меньше давления на эфир для всех остальных устройств в сети.
BBRv3: Google это тоже понял
BBRv3, анонсированный в 2023 году, исправляет главную агрессию первой версии: добавлен учёт потерь (inflight_hicap), реакция на ECN, ограничение inflight при детектировании перегрузки. В mainline ядро он пока не попал — там по-прежнему v1. Лишь дистрибутивы вроде CachyOS и кастомные ядра (zen, pf-kernel) его уже сравнительно давно используют.
Прямого сравнения с теми же условиями у нас нет: доступная машина с BBRv3 имеет проводной uplink до роутера 1 Gbit, а не 2.5 Gbit. При таком раскладе Wi-Fi PHY (2.4 Gbps) шире проводного канала, bottleneck — в проводе, и Wi-Fi-очередь в AP физически не насытится. Нулевые ретрансмиты в такой конфигурации покажет любой алгоритм — это не заслуга BBRv3. Корректное сравнение требует одинакового uplink или намеренно деградированного Wi-Fi-линка.
Одно понятно точно: архитектурно v3 правильнее v1 для беспроводных сетей — но «правильнее» нужно измерять, а не принимать на веру:
Поздравляем с оптимизацией
Интернет полон инструкций вида «включите BBR и ваша сеть взлетит». Выглядят они примерно так:
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -pДве строчки — и вы в авангарде сетевой оптимизации. Google же использует, верно?
Верно. Только есть нюанс, который в этих инструкциях обычно опускают.
Если у вас Ubuntu — или любой из примерно двадцати дистрибутивов, которые тащат её ядро: Mint, Pop!_OS, elementary, Kubuntu, Xubuntu, Lubuntu и прочие члены семьи — то вы включили BBRv1. Тот самый, образца 2016 года, про который сами разработчики Google пишут, что он «нечестно конкурирует с CUBIC и HTCP».
Можно попробовать проверить так:
modinfo tcp_bbr | grep '^version'— на ядре с BBRv3 это скорее всего вернёт version: 3. На стандартном Ubuntu-ядре поле вероятнее всего будет просто отсутствовать. Через sysctl не отличить: tcp_congestion_control в обоих случаях возвращает просто bbr.
Так что если вы скопировали те две строчки в sysctl.conf, работаете на Ubuntu и сидите на Wi-Fi — смотрите на цифры выше. Поздравляем с оптимизацией.
Отдельный нюанс в настройке default_qdisc=fq. Начиная с ядра 4.20, BBR не требует fq для pacing: TCP-стек использует внутренний механизм на базе EDT (Earliest Departure Time) — каждый пакет получает временну́ю метку отправки, без внешнего планировщика. На высоконагруженных серверах (10G+) fq всё ещё рекомендован — он снижает CPU-нагрузку за счёт TSO-агрегации пакетов. Но на Wi-Fi-клиенте fq — плохой выбор из-за следующих проблем: (1-я) нет AQM (Active Queue Management). Wi-Fi — среда с плавающей скоростью, и если физический линк внезапно просядет, fq будет тупо копить пакеты в буфере, создавая bufferbloat. Вторая: жёсткий per-flow pacing мешает Wi-Fi-чипу собирать большие агрегированные кадры (A-MPDU) — а агрегация для 802.11n/ac/ax критична для пропускной способности. Так что для Wi-Fi правильный стек: BBR (v3) с внутренним pacing + fq_codel или cake — они держат очереди пустыми по sojourn time и не мешают агрегации.
Что с этим делать
Посмотреть, что доступно на вашей машине:
sysctl net.ipv4.tcp_available_congestion_controlПодгрузить модуль и переключиться:
modprobe tcp_westwood # или tcp_veno, tcp_illinois
sysctl -w net.ipv4.tcp_congestion_control=westwoodЕсли хочется BBRv3 — потребуется либо кастомное ядро (zen, pf-kernel, CachyOS), либо сборка с патчами от google/bbr.
Итог
BBR — правильный выбор для WAN и высокого BDP. На локальном Wi-Fi, где потери случайны и канальный уровень уже занимается их исправлением, алгоритмы, спроектированные с учётом беспроводной среды — Westwood+, Veno, Illinois — ведут себя честнее. А BBRv3, когда доберётся до mainline, архитектурно закроет этот разрыв — но это всё равно нужно проверять в своей конфигурации, а не принимать на веру.
До тех пор tcp_westwood — не шаг назад.