Контроль перегрузки простыми словами: 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.х.

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 для потоковой передачи живого видео, явно настраивает компромисс между пропускной способностью и задержкой через параметр delta – именно поэтому она используется в mvfst (QUIC-стеке Meta) для реального времени, где каждая задержка в 30 мс напрямую влияет на время просмотра. Выбирайте CUBIC для локальных сетей, BBR – для публичного интернета, а для потокового видео в реальном времени – Copa или BBR; неправильный выбор незаметно снижает пропускную способность почти вдвое на каналах с 1 % потерь.

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

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

Что реально делает управление перегрузкой

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

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

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

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

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

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

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

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

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

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

Контроль перегрузки с использованием бинарного увеличения (CUBIC) – это контроллер перегрузки TCP по умолчанию в 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-сервер и не меняли настройки контроля перегрузки – у вас используется CUBIC.

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

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

Первое: CUBIC реагирует на потерю пакетов. Он не замедляется, пока не зафиксирует потерю. На проводном канале в дата-центре это нормально – потери означают переполненные очереди. Но на 4G-канале с 4 % потерь это катастрофа. Формула Матиса 1997 года даёт грубую оценку пропускной способности любого 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 Мбит/с – ни при каком кодировщике, ни при какой CDN, потому что любая потеря интерпретируется как перегрузка сети, и окно передачи резко сокращается.

Второе: CUBIC заполняет очереди. В роутере с буфером на мегабайты (а это большинство потребительских кабельных модемов – наследие подхода «больше = безопаснее», который вендоры внедрили десять лет назад) CUBIC спокойно наполняет этот буфер до тех пор, пока пакеты не начнут отбрасываться с хвоста. Очередь заполнена собственными пакетами CUBIC, каждый из которых увеличивает время кругового обхода. Это 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) и включённая в основную ветку Linux 6.x. Драфт обсуждается в рабочей группе по управлению перегрузками (Congestion Control Working Group, CCWG), имеет статус Experimental, срок действия истекает в сентябре 2026 года; это почти финальная версия, которую инженеры стриминговых сервисов могут использовать сегодня как авторитетную спецификацию.

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

Алгоритм последовательно проходит через четыре состояния в цикле:

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

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

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

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

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

Copa – претендент на основе задержки для реального времени видео

Copa была представлена на NSDI 2018 исследователями из MIT – Venkat Arun и Hari Balakrishnan. Это алгоритм на основе задержек: вместо потерь пакетов в качестве сигнала перегрузки Copa использует queueing delay – разницу между текущим RTT и минимальным RTT, зафиксированным недавно. Скорость передачи данных подстраивается так, чтобы поддерживать эту задержку на целевом уровне.

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

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

Почему Copa важна для видео – дело не в самом алгоритме в вакууме, а в том, где он применяется. В ноябрьском блоге инженеров Meta 2019 года описывается внедрение Copa для прямой загрузки видео на Android: «Copa улучшает пропускную способность и снижает задержку в большинстве сценариев по сравнению с BBR и CUBIC – двумя широко используемыми алгоритмами управления перегрузкой – и поэтому позволяет доставлять видео более высокого качества с меньшей задержкой. В результате Facebook фиксирует рост метрик конечного пользователя, таких как время просмотра». Реализация Copa в Meta интегрирована внутрь mvfst – их QUIC-стека; любой продукт, использующий mvfst для приёма данных, может подключить её одной строкой с указанием имени алгоритма.

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

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

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

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

Основатель спрашивает, почему при скорости 6 Мбит/с видео в разрешении 1080p постоянно перебуферивается на тестовом 4G-телефоне в Сеуле. Устройство показывает задержку (RTT) до origin-сервера 60 мс и потерю пакетов около 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 игнорирует потерю как сигнал перегрузки (интерпретирует её как случайную) и выравнивает скорость передачи в соответствии со своей оценкой пропускной способности узкого места – на реальном канале телефона она составляет около 25 Мбит/с. Пропускная способность растёт с 0,97 Мбит/с до примерно 18–22 Мбит/с по полевым измерениям – заметно выше целевых 6 Мбит/с.

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

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

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

Мы реализовали более 250 проектов с 2005 года: видео-стриминг, WebRTC-конференции, OTT, телемедицина, e-learning, видеонаблюдение, AR/VR – и в каждом из них кто-то тихо выбирал алгоритм управления перегрузками где-то в стеке. На WebRTC-решениях мы используем Google goog-cc (delay-based bandwidth estimator, близкий по идее к Copa) в связке с simulcast и SVC, чтобы плавно снижать оценку доступной полосы пропускания без прерывания звонка. На origin-серверах HLS и DASH по умолчанию применяем BBRv3 на edge-нодах, обслуживающих регионы с известными проблемами (рынки с приоритетом мобильной связи, спутниковые каналы, региональные провайдеры с глубокими буферами), а на внутренних каналах между дата-центрами оставляем CUBIC – там, где важна справедливость распределения полосы, а задержка не критична. На путях контрибуции с низкой задержкой – SRT, RIST, WHIP – настраиваем собственный протокол восстановления после потерь в паре с QUIC-алгоритмом управления перегрузками. Выбор никогда не сводится к «BBR везде»: он звучит так – «BBR там, где сеть плохая, CUBIC там, где сеть короткая и стабильная, поведение, близкое к Copa, – там, где приложение требует реального времени при загрузке».

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

• Включение 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.

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

• Управление перегрузкой – это алгоритм в TCP и QUIC, определяющий скорость передачи данных; его выбор влияет на пропускную способность при стриминге.
• CUBIC, используемый по умолчанию везде, теряет эффективность на каналах с потерями, поскольку интерпретирует любую потерю как признак перегрузки.
• BBR (draft-ietf-ccwg-bbr-05) не воспринимает потерю как основной сигнал и регулирует скорость на основе модели канала; он показывает лучшие результаты на каналах с потерями и высокой задержкой.
• Copa (NSDI 2018, используется в продакшене у Meta) явно настраивает баланс между пропускной способностью и задержкой через delta.
• В Linux переключайте sysctl tcp_congestion_control=bbr и включайте default_qdisc=fq.
• Тестируйте на реальных каналах с потерями перед запуском в продакшен – лабораторные условия не покажут реальной картины.

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

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

Что дальше

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