Термин
BBR
Алгоритм управления перегрузками от Google напрямую моделирует пропускную способность «бутылочного горлышка» и минимальный RTT, а не реагирует на потери пакетов. Обеспечивает более высокую пропускную способность на каналах с потерями и меньшую задержку при нагрузке.
BBR – Bottleneck Bandwidth and Round-trip propagation time – Google представила в 2016 году, и за два года BBR заменил CUBIC по умолчанию во всех собственных сервисах компании. В отличие от CUBIC, который определяет перегрузку по потерям пакетов, BBR непрерывно оценивает два ключевых параметра пути: доступную пропускную способность узкого места (по скорости доставки) и минимальный RTT (по наблюдаемым значениям RTT). Затем BBR регулирует темп отправки данных в соответствии с произведением пропускной способности и задержки (bandwidth-delay product), удерживая в сети ровно столько данных, чтобы заполнить канал без создания очередей.
Для стриминга практическая выгода проявляется в сотовых и Wi-Fi-сетях. CUBIC воспринимает случайные радиопотери как признак перегрузки и снижает скорость, теряя пропускную способность. BBR продолжает передавать данные на оценочной скорости и компенсирует потери ретрансляциями. В результате достигается стабильный throughput на каналах, которые ранее «залипали» на 20 % от своей ёмкости. BBRv2 (2019) добавил явную справедливость по отношению к потокам CUBIC; BBRv3 (2023) улучшил оценку пропускной способности и управление темпом передачи при переменной перегрузке.
BBR доступен в ядре Linux начиная с версии 4.9, используется в реализациях QUIC и HTTP/3 от Google, а также опционально – на большинстве крупных CDN. Минус: BBR может быть агрессивнее CUBIC по отношению к себе в сценариях с общим буфером, что приводит к несправедливости между потоками внутри CDN POP. Большинство операторов применяют BBR на стороне сервера (где они контролируют оба конца соединения) и оставляют CUBIC на стороне клиента.
Считаете параметры для своего продукта?
Поможем собрать энкодер-леддер и посчитать стоимость доставки – до старта разработки.