Контроль перегрузки простыми словами: BBR, CUBIC, Copa и почему это важно

Опубликовано: 2026-05-20 · Время чтения: 18 мин · Автор: Николай Сапунов, CEO Фора Софт

Последняя сверка: 2026-05-20 со стандартами и публикациями: IETF RFC 5681 (TCP Congestion Control, сентябрь 2009), RFC 9438 (CUBIC for Fast and Long-Distance Networks, август 2023 – Standards Track, заменяет RFC 8312), draft-ietf-ccwg-bbr-05 (BBR Congestion Control, март 2026), Arun, Balakrishnan «Copa: Practical Delay-Based Congestion Control for the Internet» (NSDI 2018), RFC 9000 (QUIC, май 2021), RFC 8085 (UDP Usage Guidelines, март 2017), RFC 9002 (QUIC Loss Detection and Congestion Control, май 2021), документация сетевой подсистемы Linux kernel 6.x.

TL;DR

Congestion control – это алгоритм внутри TCP и QUIC, который решает, насколько быстро отправитель загоняет пакеты в сеть, не уронив её; каждое TCP- и QUIC-соединение крутит такой алгоритм, и выбор меняет поведение видеопотока, когда сеть переполнена. CUBIC, дефолт в Linux, Windows и Apple, ищет ёмкость сети, разгоняясь, пока не увидит потерю пакета, и тогда отступает – устойчиво, справедливо к самому себе и катастрофично для пропускной способности на мобильных линках. BBR, алгоритм от Google, стандартизуемый сейчас в IETF (draft-ietf-ccwg-bbr-05) и поставляемый как BBRv3 в Linux 6.x, строит модель «узкое место + минимальный RTT» и кадрирует выход к этой модели, давая примерно +45 % пропускной способности на 4G и +120 % на спутниковых линках при меньшем bufferbloat. Copa, придуманная в MIT и развёрнутая Meta для загрузки live-видео, явно настраивает компромисс throughput vs latency через параметр delta – именно поэтому она живёт в mvfst (QUIC-стэк Meta) для real-time ingest, где каждые 30 мс задержки конвертируются в watch-time. Выбирайте CUBIC для LAN, BBR для публичного интернета, Copa или BBR для real-time видео; неверный выбор тихо в два раза урезает пропускную способность на линке с 1 % потерь.

Зачем это понимать

Стриминговый продукт живёт или умирает по тому, как он ведёт себя на плохой сети, а алгоритм, решающий «что такое плохо», – это congestion control. Дефолт на свеже-развернутом Linux-сервере в 2026 году – всё ещё CUBIC, который на 4G-линке с 4 % потерь зажмёт 1080p ниже 2 Mbps; формула Mathis'а не интересуется размером вашей encoder-лестницы. Переключение того же сервера на BBR поднимает ту же сеть выше 6 Mbps без единой правки в коде приложения. Возьмите Copa на real-time upload – и Meta пишет, что watch time растёт. Ничего из этого не требует менять плеер; выбор – это одна строка в sysctl.conf или одна опция в setsockopt. Эта статья даёт четыре факта: что вообще делает congestion control, чем отличаются три алгоритма, активно деплоящиеся в 2026, какой подходит под какую стриминговую задачу, и как протестировать переключение на своей инфраструктуре до того, как оно уедет в прод.

Что реально делает congestion control

Прежде чем называть алгоритмы – слой, который под ними. Две конечные точки, разговаривающие через публичный интернет, не знают заранее, какая полоса между ними, и у них нет центральной инстанции, которая бы это им сказала. Путь идёт через Wi-Fi, домашний роутер, кабельный модем, CMTS, двух транзитников, пиринг, edge CDN – и, возможно, спутниковый хоп – у каждого свои буферы, своя queueing discipline и своё кросс-трафик. Доступная полоса меняется каждые несколько сотен миллисекунд. Задача отправителя – наполнять трубу, но не переполнять её, потому что в момент переполнения очереди у роутера платят все потоки на этом роутере вместе.

Алгоритм congestion control – это код внутри транспортного слоя на отправителе, который в реальном времени решает, сколько байт держать «в полёте» между отправителем и получателем. Он работает один раз на ACK, иногда раз в RTT, и подкручивает число под названием congestion window (или, в современных алгоритмах, скорость отправки). Если он угадывает слишком мало – вы теряете полосу. Если слишком много – провоцируете потери и bufferbloat: пакеты копятся в очереди узкого места, каждый RTT удлиняется, и бюджет задержки на ваше видео тает.

Любой транспорт, работающий поверх интернета – TCP, QUIC, SCTP, слои восстановления потерь у SRT и RIST – крутит алгоритм congestion control. Выбор – не философия. Он напрямую задаёт ваш пол пропускной способности, пол задержки и насколько честно ваше видео делит линк с чужим Zoom-звонком.

Нажмите, чтобы увеличить

Три семейства алгоритмов

В поле сегодня три семейства congestion control, и каждый алгоритм, который вы встретите, сидит в одном из них. Знание семейства сообщает – ещё до первого бенчмарка – как алгоритм поведёт себя на линке с потерями.

Первое семейство – loss-based (на основе потерь). Отправитель разгоняет окно, пока не увидит потерянный пакет – это сигнал «сеть полна». Тогда он отступает. Reno, NewReno и CUBIC – loss-based. Эти алгоритмы прекрасно работают на проводных, почти не-потерянных сетях 1990-х, под которые их и спроектировали, и катастрофически деградируют, когда потери вызваны чем угодно кроме перегрузки – Wi-Fi помехами, хэндовером сотовой сети, ослаблением солнечного сигнала на спутниковом линке.

Второе семейство – model-based (на основе модели; также rate-based или delivery-rate-based). Отправитель скользящим окном измеряет пропускную способность узкого места и round-trip time и кадрирует выход к этой оценке. Потеря пакета – сигнал, но не единственный; алгоритм верит в свою измеренную модель первой. BBR – model-based. Так же устроен congestion controller от Google для QUIC.

Третье семейство – delay-based (на основе задержки). Отправитель следит за RTT и читает его рост как сигнал «очереди растут». Он замедляется до того, как теряется хоть один пакет. Vegas, Compound TCP, FAST TCP, LEDBAT и Copa – delay-based. Delay-based алгоритмы выигрывают в задержке, но исторически проигрывают в пропускной способности, когда делят линк с loss-based: loss-based наполняет очередь, delay-based видит рост RTT и вежливо отступает, а loss-based забирает всю полосу. Copa явно решает эту проблему competitive mode, который переключает поведение, когда детектирует соседей-наполнителей буфера.

CUBIC – дефолт, который уже у вас

Congestion Control Using Binary Increase (CUBIC) – это TCP congestion controller по умолчанию в Linux (с ядра 2.6.19, 2006), Windows (с Server 2016 / Windows 10) и macOS / iOS (с macOS 10.12, 2016). RFC 9438, опубликованный в августе 2023, переводит CUBIC из статуса Informational в Standards Track и заменяет более ранний RFC 8312. Если вы поднимаете Linux-сервер и не трогаете настройки congestion control – у вас CUBIC.

Дизайн CUBIC основан на одном наблюдении: исходный TCP Reno после потери растит congestion window на один пакет за RTT, что на 100 мс RTT и 10 Gbps long-fat-network линке требует 50 минут, чтобы заново заполнить трубу после одного дропа. Это было неприемлемо для дата-центров и магистральных сетей начала 2000-х, поэтому авторы CUBIC заменили линейный рост Reno на кубический полином: после потери окно падает на 30 % (параметр beta = 0.7 от пика), затем регроится по кривой W(t) = C × (t − K)³ + W_max, где K – время, за которое кубическая кривая дошла бы до предыдущего пика. Форма даёт медленный, аккуратный рост у предыдущего максимума (чтобы сразу не вызвать потери снова) и агрессивный рост вдалеке от пика (чтобы быстро заполнить трубу при настоящем изменении ёмкости).

У математической стройности два следствия, которые надо знать.

Первое: CUBIC срабатывает на потерю. Он не замедляется, пока не увидит дроп. На проводном дата-центровом линке это нормально – дропы означают полные очереди. На 4G-линке с 4 % потерь это катастрофа. Формула Mathis'а 1997 года даёт оценку «на коленке» пропускной способности любого loss-triggered TCP: throughput ≤ MSS / (RTT × √loss). Подставим MSS = 1460 байт, RTT = 60 мс, loss = 0.04: throughput ≤ 1460 / (0.06 × 0.2) байт/с ≈ 121 667 байт/с ≈ 0.97 Mbps. Примерно один мегабит. CUBIC-отправитель не может протолкнуть в этот линк больше ~1 Mbps, никогда, ни при каком энкодере, ни при какой CDN – потому что любая потеря интерпретируется как congestion и окно схлопывается.

Второе: CUBIC наполняет очереди. В роутере с буфером в мегабайты (а это большинство потребительских кабельных модемов – наследие реакции «больше = безопаснее» от вендоров десять лет назад) CUBIC спокойно наполняет этот буфер до тех пор, пока пакеты не начнут отбрасываться с хвоста. Очередь полна собственных пакетов CUBIC'а, каждый из которых добавляет к round-trip time. Это bufferbloat, и рост RTT может превратить проводной 20-миллисекундный линк в 400-миллисекундный без единой потери пакета – просто медленный. ABR-алгоритмы плеера сверху тогда неправильно прочитают пропускную способность и переключатся вниз по лестнице, хотя ёмкость узкого места не изменилась.

При всех этих минусах у CUBIC есть одна большая добродетель: справедливость к самому себе. Два CUBIC-потока, делящие линк, сходятся к примерно равным долям за несколько RTT. Это свойство – intra-protocol fairness – причина, по которой IETF перевёл CUBIC в Standards Track, и причина, по которой большинство CDN и облачных провайдеров до сих пор оставляют его дефолтом. Если вы не знаете, что на той стороне линка, CUBIC – дипломатичный выбор.

BBR – модель-основанный претендент

Bottleneck Bandwidth and Round-trip propagation time (BBR) был опубликован Google в 2016 году и прошёл три ревизии: BBRv1 (2016), BBRv2 (анонс 2019, в проде Google к 2021) и BBRv3 – версия, которая стандартизуется в IETF draft-ietf-ccwg-bbr-05 (март 2026) и поднята в mainline Linux 6.x. Драфт обсуждается в Congestion Control Working Group (CCWG), статус Experimental, истечение – сентябрь 2026; это близкий к финалу драфт, который стриминговые инженеры могут читать сегодня как авторитативную спецификацию.

Тезис BBR: сеть не даёт вам чистого сигнала «остынь». Потеря – это шумный прокси. RTT – тоже шумный прокси. Полезные сигналы два: максимальная delivery rate, которую может выдать узкое место (BtlBw), и минимальный round-trip time на пути (RTprop). Если отправитель знает оба, он может pace'ить ровно на BtlBw и держать ровно один bandwidth-delay product данных в полёте (BDP = BtlBw × RTprop). В этой рабочей точке узкое место загружено полностью, очереди пусты, а round-trip latency остаётся на минимуме.

Алгоритм крутит четыре состояния в цикле:

• Startup – экспоненциальный рост скорости (удвоение за RTT), пока не получается найти более высокие delivery rate.
• Drain – pace вниз, чтобы слить очередь, случайно созданную в Startup.
• ProbeBW – основное steady-state: pace на оценке BtlBw, периодически толкаем скорость вверх на 25 % на один RTT для проверки доступной полосы, потом возвращаемся.
• ProbeRTT – раз в ~10 секунд, ронять in-flight данные до четырёх пакетов на 200 мс, чтобы заново измерить RTprop без шума от очередей.

Поведение на линке с потерями – это и есть смысл BBR. Поскольку алгоритм не читает потерю как «вы достигли ёмкости» – только как данные для модели – BBR продолжает таскать полосу на 4G-линке с 4 % потерь вместо того, чтобы коллапсировать. Опубликованные Google измерения показывают, что BBRv3 даёт +45 % пропускной способности на 4G LTE (20 мс RTT), +20 % на Wi-Fi (5 мс RTT) и впечатляющие +120 % на спутниковых линках (600 мс RTT) – всё против CUBIC.

BBR – это также congestion controller выбора для QUIC. RFC 9002 (companion RFC к 9000, описывающий loss-recovery и congestion control в QUIC) приводит CUBIC-подобную референсную реализацию, но продакшен-стэк Google для QUIC использует BBR, а Cloudflare quiche и Meta mvfst оба поставляют BBR как first-class опцию. Любое вендорское «низколатентное стриминговое HTTP/3» в 2026 – это BBR под капотом.

Два предостережения. BBR в некоторых конфигурациях делит линк с CUBIC нечестно – ранние измерения BBRv1 показывали, что он мог зажать CUBIC-поток на линке с глубоким буфером; v2/v3 это смягчают за счёт реакции на потери и ECN, но дисциплина – «тестируйте в своём деплое». Второе: pacing BBR требует точных таймштампов и queueing discipline, уважающего их. На Linux канонический рецепт – tcp_congestion_control = bbr плюс default_qdisc = fq; qdisc fq даёт pacing BBR'а ту самую per-flow планировку, которую он ждёт. Пропустите fq – и измеренные победы BBR'а испарятся.

Нажмите, чтобы увеличить

Copa – delay-based претендент для real-time видео

Copa была опубликована на NSDI 2018 Venkat Arun и Hari Balakrishnan из MIT. Это delay-based алгоритм: вместо потери в качестве congestion-сигнала Copa смотрит на queueing delay (разница между текущим RTT и минимальным RTT, наблюдавшимся недавно) и подстраивает скорость отправки так, чтобы держать эту задержку у целевого значения.

Определяющая фича – единственная ручка настройки: delta. Скорость отправки Copa вычисляется как λ = 1 / (delta × queueing_delay). Низкая delta (скажем, 0.1) позволяет алгоритму терпеть больше queueing и ставит пропускную способность в приоритет. Высокая delta (скажем, 1.0) ужесточает таргет по задержке, принимая меньшую пропускную способность. Приложение выбирает компромисс; алгоритм его обеспечивает.

Copa крутит два режима. В default mode она минимизирует функцию полезности U = log(throughput) − delta × log(queueing_delay) и ведёт себя как поток с низкой задержкой и низким queue-buildup. В competitive mode, который включается, когда детектируются соседи-наполнители буфера (она смотрит, как часто queueing delay падает до нуля), Copa переключается на более loss-based поведение, чтобы взять свою честную долю. Без competitive mode Copa-поток, делящий роутер с CUBIC-потоком, проигрывает каждый раз; с ним – держит честную долю.

Почему Copa важна для видео – не сам алгоритм в вакууме, а куда он развёрнут. Engineering blog Meta в ноябре 2019 описал продакшн-деплой Copa для live-загрузки видео на Android: «Copa улучшает пропускную способность и задержку в большинстве сценариев по сравнению с BBR и CUBIC – двумя широко используемыми алгоритмами congestion control – и поэтому позволяет доставлять видео лучшего качества с меньшей задержкой. В результате Facebook видит улучшение end-user метрик (watch time)». Реализация Copa у Meta живёт внутри mvfst, её QUIC-стэка; любой продукт, использующий mvfst для ingest, может включить её одной строкой имени алгоритма.

Слабость Copa симметрична слабости BBR. Ручку delta приложение настраивает само, а правильное значение зависит от линка. Meta тюнит delta динамически; наивный деплой с delta = 0.5 на спутниковом линке недоиспользует ёмкость. Статья Copa+ (IEEE, 2022) предлагает адаптивный delta и ужесточённый критерий входа в competitive mode.

Сравнительная таблица для команды

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

Разобранный пример: 1080p на 4G с 4 % потерь

Основатель спрашивает, почему 6 Mbps верхняя ступень 1080p ребуферится на тестовом 4G-телефоне в Сеуле. Телефон рапортует 60 мс RTT до origin и долю потерь около 4 % на пике.

Шаг один: применяем Mathis к CUBIC. throughput ≤ MSS / (RTT × √loss) = 1460 / (0.06 × √0.04) = 1460 / (0.06 × 0.2) = 1460 / 0.012 = 121 667 байт/с = 0.97 Mbps. CUBIC-отправитель на CDN edge не может протолкнуть в этот телефон больше ~1 Mbps. ABR-лестница не может выбрать 6 Mbps; плеер уходит на 720p или ниже, и ребуферинг становится проблемой наполнения буфера уже в этих рамках.

Шаг два: переключаем CDN edge на BBR. Тот же линк, тот же RTT, те же 4 % потерь. BBR игнорирует потерю как congestion-сигнал (читает её как случайную) и pace'ит к своей оценке пропускной способности узкого места, которая на реальном линке телефона – около 25 Mbps. Пропускная способность вырастает с 0.97 Mbps до примерно 18–22 Mbps в полевых измерениях – заметно выше целевых 6 Mbps.

Шаг три: коллега спрашивает, не зажмёт ли BBR CUBIC-соседа на той же соте. Честный ответ: зависит от глубины буфера соты, версии BBR и кросс-трафика. Целевое поведение BBRv3 – и то, что Google показал на слайдах IETF 119 в апреле 2024 – это «примерно честно» к CUBIC на представительной смеси путей. Правильный тест продуктовой команды – A/B в поле, а не теоретический аргумент.

Этот же пример – аргумент за QUIC. CDN edge может оставить CUBIC для HTTP/2 поверх TCP и одновременно отдавать тот же контент через QUIC поверх HTTP/3 с BBR в роли congestion controller'а. Большинство плееров в 2026 договариваются на HTTP/3, когда он предложен – hls.js, Shaka, dash.js и нативный Apple HLS плеер на iOS 17+.

Где живёт Фора Софт

Мы поставили 239+ проектов с 2005 года: видео-стриминг, WebRTC-конференции, OTT, телемедицина, e-learning, видеонаблюдение, AR/VR – и в каждом из них кто-то тихо выбирал congestion control где-то в стэке. На WebRTC-продуктах мы крутим Google goog-cc (delay-based bandwidth estimator, близкий по идее к Copa) и пара его с simulcast и SVC, чтобы съезжать вниз по оценке полосы без заморозки звонка. На HLS- и DASH-origin'ах мы по умолчанию ставим BBRv3 на edge-нодах, смотрящих в известно-плохие регионы (mobile-first рынки, спутник, региональные ISP с глубокими буферами), и оставляем CUBIC на интра-ДЦ линках, где fairness важна, а цена в задержке несущественна. На путях контрибуции с низкой задержкой – SRT, RIST, WHIP – мы тюним собственный loss-recovery протокола в связке с QUIC-congestion controller'ом, на котором он сидит. Выбор никогда не «BBR везде»; он «BBR там, где сеть плохая, CUBIC там, где сеть короткая и чистая, Copa-подобное поведение там, где приложение – real-time upload».

Типичные ошибки

• Включение BBR без fq. tcp_congestion_control = bbr без default_qdisc = fq означает, что вычисленный алгоритмом pacing не превращается в реальный шейпинг на выходе. Победы испаряются. Нужны обе настройки.
• Сравнение CUBIC и BBR на чистом лабораторном линке. Линк с 0 % потерь, 10 мс RTT и 1 Gbps – единственное место, где CUBIC и BBR выглядят почти одинаково. Тестируйте на реальной сети – хотя бы один тестовый путь должен иметь 1 % потерь, 80 мс RTT и роутер с парой мегабайт буфера.
• Чтение старых статей про BBRv1 как описания сегодняшнего. Несправедливость к CUBIC, переагрессия на мелком буфере, отсутствие ECN-реакции – всё это разобрано в v2 (2019–2021) и v3 (2022–2026). Читайте draft-ietf-ccwg-bbr-05 для актуального поведения.
• Полагать, что дефолт облака – то, что вам нужно. AWS, GCP, Azure и крупные CDN позволяют выбирать congestion control по региону или по LB. Дефолт обычно CUBIC. Он рассчитан на general-purpose веб, а не на стриминг.
• Выбор Copa в задаче, где нельзя настроить delta. Без тюнинга delta Copa теряет пропускную способность, иногда сильно. Если у вас нет телеметрии, чтобы её настроить, BBR – безопаснее.
• Игнорирование QUIC-стороны. TCP congestion control – одна настройка; QUIC congestion control – отдельная, часто на уровне приложения (mvfst, quiche, ngtcp2). Обе должны быть выставлены и обе должны соответствовать задаче.

Как протестировать переключение до прода

Три шага, по порядку, на реальной инфраструктуре.

1. Возьмите edge-ноду, не отдающую трафик пользователям, и переключите её TCP congestion controller (и qdisc, если Linux) с CUBIC на BBR или Copa-реализацию. Проверьте sysctl net.ipv4.tcp_congestion_control и пакетным захватом. На QUIC – поменяйте имя алгоритма в конфиге приложения.

1. Направьте трафик на эту ноду минимум с трёх тестовых точек, представительных для аудитории: проводной ДЦ-клиент (чистый baseline), 4G/5G мобильный (представительный lossy) и трансконтинентальный (представительный high-RTT). Используйте плеер с throughput-телеметрией – Mux Data, Conviva, Bitmovin Analytics или собственный – и снимайте перцентили пропускной способности, rebuffer rate и time-to-first-frame не меньше 24 часов.

1. Сравнивайте с матчедной CUBIC-когортой. 5 % разница в throughput или rebuffer – порог, ниже которого нельзя доверять A/B при менее ~5 000 сессий на ветку; размер теста подбирайте под этот порог. Раскатывайте только когда сравнение чистое.

Полный план теста – в скачиваемом BBR / CUBIC / Copa Decision Sheet.

Ключевые выводы

• Congestion control – это алгоритм внутри TCP и QUIC, который решает скорость отправки; выбор меняет стриминговую пропускную способность.
• CUBIC, дефолт везде, коллапсирует на lossy-линке, потому что читает любую потерю как congestion.
• BBR (draft-ietf-ccwg-bbr-05) не считает потерю первичным сигналом и pace'ит к модели пути; выигрывает на lossy и high-RTT.
• Copa (NSDI 2018, в проде у Meta) явно настраивает throughput-vs-delay через delta.
• На Linux переключайте sysctl tcp_congestion_control=bbr плюс default_qdisc=fq.
• Тестируйте на реальном lossy-пути до прода – лабораторный линк победу не покажет.

Что почитать дальше

• TCP, UDP и выбор, который делает каждый стриминговый протокол – транспортный слой ниже congestion control.
• QUIC: новый транспортный слой – где BBR живёт нативно в 2026.
• HTTP/1.1, HTTP/2, HTTP/3: что изменилось и что это значит для стриминга – прикладной протокол сверху.

Что дальше

• Поговорите с инженером по стримингу – забронируйте 30-минутный созвон по вашему CDN- и плеер-стэку.
• Смотрите кейсы – 239+ поставленных проектов в видео-стриминге, WebRTC, OTT, телемедицине, e-learning, видеонаблюдении и AR/VR.
• Скачайте BBR / CUBIC / Copa Decision Sheet – страничный референс для выбора алгоритма под линк.