SFU, MCU и Mesh: три топологии WebRTC

TL;DR

Передавать медиа между участниками WebRTC-звонка можно ровно тремя способами: каждый участник связывается напрямую с каждым другим (Mesh), все участники подключаются к серверу, который сводит их потоки в один общий (MCU), либо все участники подключаются к серверу, который пересылает их потоки нетронутыми всем остальным (SFU). Эти три варианта по-разному распределяют клиентскую полосу пропускания, стоимость сервера, гибкость раскладки и задержку. В 2026 году SFU – это выбор по умолчанию практически для любого группового звонка более чем на четырёх человек, Mesh выживает только в созвонах на 2-4 участника без бюджета на сервер, а MCU отступил в нишу legacy-интеграций, broadcast-композитинга и тех редких случаев, когда приёмник не способен декодировать несколько потоков. Каскадные SFU в нескольких регионах – это то, как один зал на пятьдесят человек превращается в миллион одновременных пользователей; топология под капотом при этом остаётся прежней.

Зачем это знать

Если вы делаете видеопродукт – телемедицину, e-learning, OTT-контрольную, WebRTC-панель видеонаблюдения, ИИ-голосового агента, говорящего с людьми, – вы выбираете одну из трёх этих топологий в первый же день. Этот выбор задаёт стоимость сервера, потолок масштабирования, нижнюю границу задержки и то, что пользовательский интерфейс может показать на экране. Ошибка на уровне архитектуры не компенсируется никакой полировкой фронтенда. Эта статья объясняет каждую топологию с нуля, показывает арифметику полосы пропускания, называет момент, когда каждая ломается, и даёт дерево принятия решений, которое можно показать продакт-менеджеру.

Что такое «топология», простыми словами

Топология в контексте видеозвонка реального времени – это форма линий, соединяющих людей в комнате. Видео должно как-то добраться от камеры каждого говорящего до экрана каждого слушателя. Вопрос в том, идут ли эти линии напрямую между людьми, или они проходят через машину посередине, и если да, то что эта машина делает с потоками по пути.

Полезная аналогия из жизни: групповой разговор в комнате. На маленькой кухне четверо друзей слышат друг друга напрямую – никому не нужно ничего повторять. На городском собрании микрофон и колонки усиливают каждого выступающего, чтобы было слышно в задних рядах. На теледебатах редактор в аппаратной берёт сигналы со всех камер, выбирает нужный, сводит звук и транслирует один общий сигнал телезрителям. Кухня – это Mesh, колонки – это Selective Forwarding Unit, аппаратная – это Multipoint Control Unit. Принципы такие же и в программе, а компромиссы переносятся почти один к одному.

WebRTC, семейство протоколов, на которых работает браузерное видео, не предписывает топологию. Архитектурный документ для браузерного RTC, IETF RFC 8825, описывает протокол с позиции одного браузера и явно оставляет многосторонние схемы на усмотрение приложения. Поэтому один и тот же JavaScript-API можно использовать для всех трёх паттернов в этой статье – и поэтому выбор между ними остаётся вашей задачей, а не браузера.

«О терминологии. «Peer-to-peer» и «Mesh» в литературе по WebRTC означают одно и то же, когда в звонке больше двух человек. «P2P» иногда употребляется узко – только для случая «двое в звонке», где сервера в медиа-пути действительно нет. В этой статье мы используем Mesh и отмечаем места, где терминология в индустрии расходится.»

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

Mesh: каждый участник говорит с каждым

Самая простая топология – она же самая старая. В Mesh-звонке каждый участник открывает по одному WebRTC-соединению с каждым другим участником. Медиа-сервера в пути нет. Каждый браузер захватывает свою камеру и микрофон, кодирует байты по одному разу на адресата и отправляет копию напрямую каждому пиру. Параллельно каждый браузер принимает отдельные потоки от всех пиров и локально декодирует их.

Привлекательность очевидна. Инфраструктуру строить не нужно, серверы оплачивать не нужно, договариваться о co-location тоже. Вы пишете JavaScript, браузеры делают работу, оператор платит только за маленький signalling-сервер, через который браузеры находят друг друга. Для двух участников это правильная топология – Mesh показывают в каждом туториале по WebRTC именно потому, что WebRTC изначально проектировался именно под этот сценарий.

Арифметика полосы, которая убивает Mesh

Проблемы начинаются с третьего участника и становятся катастрофическими к шестому. Каждый участник Mesh-комнаты из N человек загружает по одному потоку на каждого другого – то есть N − 1 исходящих потоков. И принимает N − 1 входящих.

Подставим цифры. Скромный 720p-поток на 30 кадрах в секунду – это около 1.5 Мбит/с. В звонке на четверых каждый участник загружает 1.5 × 3 = 4.5 Мбит/с и принимает столько же. На шестерых – 1.5 × 5 = 7.5 Мбит/с в обе стороны. На типичном домашнем подключении 2026 года – 30 Мбит/с вниз, 10 Мбит/с вверх – шестеро в звонке умещаются впритык. Седьмой участник выталкивает всех за потолок аплоада, кадры начинают теряться, и звонок ощутимо деградирует для всех.

CPU растёт в том же ритме. Браузер каждого участника параллельно крутит N − 1 видео-энкодеров и N − 1 декодеров, и каждый отъедает свой кусок процессора. Chrome исторически разрешал не более десяти одновременных peer-соединений на вкладку. Публичная рекомендация рабочей группы WebRTC сходится к пяти участникам как практическому потолку Mesh.

Где Mesh всё ещё уместен

Списать Mesh в архив – соблазнительно, но это ошибка. В 2026 году есть реальные продакшен-кейсы, где Mesh – правильный ответ:

• Звонки на двоих – телефония, консультации один-на-один, видеоприёмы врач–пациент. Два эндпоинта, никакого сервера, минимальная возможная задержка. Это самый сильный аргумент за Mesh, и он никуда не денется.
• Звонки с требованиями приватности, при которых оператор не должен видеть медиа. Mesh-звонок не проходит ни через какой сервер в контрольной плоскости оператора (signalling – да, но signalling – это метаданные, не медиа). Для некоторых режимов compliance это различие критично.
• Прототипы, демо, юнит-тесты. Mesh – это то, что вы пишете, когда нужно поднять рабочий звонок за один вечер, а вопрос масштабирования отложить.

Честный итог: Mesh подходит для N ≤ 4 без продакшн-нагрузки. Выше – арифметика полосы беспощадна, и кто-то в комнате уже на пути к плохому звонку.

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

MCU: каждый участник говорит с сервером, который сводит потоки

Multipoint Control Unit – это топология, которую вещатели использовали ещё до WebRTC и которую аппаратные системы видеоконференц-связи (Polycom, Cisco TelePresence, Tandberg) поставляли все 2000-е. Это самый старый ответ на многосторонние звонки, который не ломается на пятом участнике.

Архитектура концептуально проста. Каждый участник открывает одно WebRTC-соединение с MCU-сервером. Загружает один медиа-поток. Сервер декодирует все входящие потоки, сводит их – звук суммируется, видео композитится в сетку или active-speaker layout, поверх накладываются титры – и переэнкодит результат в один композитный поток. Этот один поток сервер отправляет обратно каждому участнику.

С точки зрения клиента в звонке ровно два медиа-потока: один наружу, один внутрь. Полоса на одного участника постоянна – 2 × bitrate – и не зависит от размера комнаты. CPU постоянен: один энкод плюс один декод. Браузер пользователя даже не знает, сколько ещё людей в звонке – он видит одно видео.

Что MCU даёт и что стоит

Цена этой элегантности платится сервером – и платится тяжело. MCU обязан декодировать каждый входящий поток – N декодеров параллельно на комнату – затем композитить (это GPU- и CPU-ёмкая обработка видео) и переэнкодить вывод, часто по одному разу на участника, если у каждого своя раскладка или своё качество. Одна комната на 12 человек может загрузить целый физический сервер.

Цифры по стоимости впечатляют. Индустриальные оценки ставят MCU-развёртывания примерно в 10-50 раз дороже на одного участника при той же нагрузке, что SFU. Развёртывание на 1000 человек, которое в SFU стоит $400 в месяц в облаке, в MCU обойдётся в $4 000 – $20 000. Задержка тоже выше: цикл decode-mix-re-encode добавляет 200-400 мс поверх сетевой задержки, против 100-200 мс у SFU. Для разговорного звонка это уводит вас за порог glass-to-glass в 400 мс, после которого разговор уже не ощущается естественным.

Зачем тогда вообще использовать MCU в 2026? Остаются два валидных сценария:

• Композитный вывод в legacy-системы. Если звонок должен попасть в broadcast-аппаратную, в запись, которая ожидает один H.264-файл, в RTMP-relay или на SIP-эндпоинт, не умеющий принимать несколько потоков, – MCU становится естественным мостом. Выход сведения и есть тот файл, который нужен вещателю.
• Устройства, которые не могут декодировать несколько одновременных потоков. Старые приставки, некоторые автомобильные инфотейнменты, embedded-панели видеонаблюдения с одним аппаратным декодером. MCU делает всю математику на сервере, чтобы устройству не пришлось.

Для всего остального – современных браузеров, современных телефонов, всего, что выходит в 2026 году с аппаратным видеодекодером – стоимость MCU больше не окупается его удобством.

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

SFU: сервер пересылает поток нетронутым

Selective Forwarding Unit – это топология, которая выиграла. На SFU в основе работают все современные платформы видеоконференц-связи: Zoom, Google Meet, Microsoft Teams, Discord, WebRTC-ingest у Twitch, все свежие телемедицинские и e-learning продукты. В WebRTC-сообществе сложился консенсус: SFU – выбор по умолчанию для любого группового звонка крупнее четырёх человек и правильная стартовая точка почти для любого нового продукта.

Архитектура – зеркальное отражение MCU в одном конкретном смысле: сервер никогда не декодирует медиа. Каждый участник загружает один поток на SFU. SFU держит этот поток зашифрованным, в исходном закодированном виде, и пересылает каждому участнику, который на него подписан. Каждый участник принимает N − 1 потоков от SFU и декодирует их локально.

На первый взгляд звучит как худшее из двух миров. Клиент снова декодирует N − 1 потоков (CPU как у Mesh) и принимает N − 1 потоков (download как у Mesh). Серверу нужно терминировать каждое соединение (работа как у MCU). В чём выигрыш?

Два ключевых отличия смещают баланс:

1. Аплоад больше не Mesh. Каждый участник загружает ровно один поток, а не N − 1. Аплоад – асимметричная и дефицитная сторона любого домашнего и мобильного канала. Именно это изменение позволяет SFU-звонкам масштабироваться до десятков участников на потребительском железе там, где Mesh ломается на пятом.
2. CPU-цена сервера крошечная. SFU в литературе описывают как «byte shifter» – его задача в том, чтобы терминировать WebRTC-соединение, расшифровать транспорт, по заголовкам понять, какому подписчику предназначен пакет, перешифровать его для каждого подписчика и переслать. В сами байты видео он не смотрит. Одно ядро CPU обрабатывает потоки на сотни consumer-ов; один хорошо настроенный mediasoup-воркер тянет 500-800 одновременных видеоучастников на узел.

Именно эта математика делает SFU продакшн-grade. Стоимость сервера на участника – примерно на порядок ниже MCU; SFU добавляет 100-200 мс задержки против 200-400 у MCU; гибкость раскладки практически неограничена, потому что её решает клиент.

Гибкая раскладка – это и есть главная фича

Легко зациклиться на арифметике полосы и упустить ту часть SFU, которая важна заказчикам. Поскольку клиент принимает потоки каждого выступающего по отдельности, приложение в рантайме само выбирает, кого показывать большим, кого запинить, кого вывести в spotlight, кто в галерее, а кто скрыт. Пользователь меняет раскладку мгновенно, без round-trip-а к серверу. Ведущий может выделить одного участника; другой зритель – запинить другого; оба сценария работают без участия сервера в композитинге.

В мире MCU раскладка решается на сервере, запекается в композит, и изменение для одного пользователя означает отдельный re-encode под него. В мире SFU раскладка – это CSS-сетка. Поэтому современный web-интерфейс видеоконференций выглядит так, как выглядит.

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

Simulcast и SVC: как SFU обслуживает разнородную комнату

В реальном звонке всегда есть участник на гигабитной оптике, участник на медленном гостиничном Wi-Fi и участник с телефона на 4G. Один и тот же 1080p-поток они потреблять не могут. SFU должен отправить каждому подписчику качество, которое его канал вытянет – и при этом не переэнкодить, потому что иначе это станет MCU и сожрёт преимущество в цене.

Трюк в том, чтобы заставить отправителя параллельно произвести несколько качеств и дать SFU выбрать. Способа два:

• Simulcast – отправитель кодирует одно и то же видео три раза в разных разрешениях и битрейтах (обычно 1080p на 2.5 Мбит/с, 360p на 600 кбит/с, 180p на 150 кбит/с) и загружает все три на SFU как отдельные потоки. SFU решает, какой из трёх отправлять каждому подписчику, основываясь на обратной связи о доступной полосе. Simulcast поддерживается во всех ведущих SFU и используется по умолчанию в клиентских SDK LiveKit.
• Scalable Video Coding (SVC) – отправитель производит один слоистый битстрим, из которого можно «снять» нижние слои, не теряя возможности декодировать. SFU может выкинуть слои индивидуально под подписчика. SVC эффективнее simulcast по битам в проводе (меньше данных кодируется в сумме) и в это направление движется индустрия, особенно с появлением аппаратной поддержки SVC в AV1.

Решение «какой слой отправить какому подписчику» принимается на основе обратной связи congestion-control. SFU следит за обратной связью каждого подписчика (через Transport-wide Congestion Control или REMB) и переключает слои вверх-вниз. Два подписчика, смотрящие одного выступающего, в один и тот же момент могут получать разные качества.

Именно эта часть превращает SFU из элегантной архитектуры в продакшн-grade систему. Подробному разбору simulcast и SVC у нас посвящена отдельная статья (Simulcast и SVC: как SFU обслуживает разнородную аудиторию).

Каскадные SFU: как выйти за потолок одного сервера

Один SFU-узел – в зависимости от реализации, CPU и кодека – тянет от 500 до нескольких тысяч одновременных видеоучастников. Дальше нужны ещё узлы. Паттерн такой: ставите SFU в нескольких регионах, соединяете их между собой по приватному backbone и пускаете участников на ближайший. Потоки делают максимум один прыжок – от регионального SFU издателя к региональному SFU подписчика, – а потом разлетаются локально.

Так масштабируется LiveKit Cloud – глобально распределённая mesh-сетка SFU-узлов, координирующихся через Redis, с медиа, проходящим по оптимизированному backbone. Так исследование 2018 года про «Cascading SFU» (Boris Grozev в Jitsi, до сих пор референсная работа) стало продакшн-архитектурой. Сессия может вырасти с одной комнаты на пятьдесят человек до миллиона одновременных пользователей без смены типа топологии – под капотом всё ещё SFU, просто их много, и они работают как один.

Каскадирование, региональные мосты и интеграцию с ИИ-агентами мы разбираем в WebRTC в масштабе: каскадные SFU, региональные мосты, ИИ-агенты.

Сравнительная таблица, которую можно показать стейкхолдеру

Таблица ниже – версия этой статьи, которую можно вставить в one-pager. Числа – индустриальные оценки 2026 года из продакшн-развёртываний; они смещаются ±10-20% в зависимости от выбора кодека и точной настройки, но порядок величины устойчив.

Самая важная строка – про upload. N − 1 загрузок ломают Mesh. Один upload делает SFU победителем.

Частая ошибка: «P2P» ≠ «без сервера»

Стойкое заблуждение – что «WebRTC peer-to-peer» означает полное отсутствие сервера. Сервер в WebRTC-звонке есть всегда: signalling-сервер, через который браузеры обмениваются SDP offer/answer; STUN-сервер, через который пир узнаёт свой публичный адрес; TURN-сервер, который ретранслирует медиа, когда прямое соединение не удаётся установить из-за строгого NAT.

Подвох в TURN. В коммерческих Mesh-развёртываниях на мобильных операторах и в корпоративных сетях 15-30% звонков не могут установить прямое соединение и должны идти через TURN. Трафик TURN – это оплачиваемый сервис. То есть «P2P» развёртывание, обещавшее ноль серверных затрат, на самом деле платит за TURN-трафик в четверти случаев, а часто и больше.

Это не отменяет Mesh как топологию. Это значит, что экономическая модель Mesh – «TURN-трафик на треть звонков», а не «бесплатно». А TURN-трафик в масштабе вполне сопоставим по стоимости с SFU. Механику разбираем в NAT, файрволы, STUN, TURN, ICE: как WebRTC реально доходит до телефона.

Рабочий пример: выбираем топологию для телемедицинского продукта

Представим телемедицинский продукт с тремя типами звонков:

1. Консультации врач-пациент. Двое, без записи, минимальная возможная задержка. Mesh. Отсутствие SFU в пути означает, что ни одно постороннее звено не касается зашифрованного медиа; история приватности для HIPAA и аналогичных режимов чище.
2. Консультации со специалистами. Лечащий врач, пациент и один-два специалиста. До четырёх сторон, эпизодическая запись для клинической документации. SFU. Запись поднимает даже маленькие звонки на серверный путь; раз уж вы платите за SFU – пользуйтесь.
3. Лекции на обходах. Один врач читает 50 ординаторам. SFU – с simulcast – плюс выход SFU направляется в pipeline записи для архива лекций. И вот здесь та единственная функция MCU, которую мы ещё используем, оправдана: bridge для записи сводит выход SFU в один композитный файл архива, при том что живой звонок остаётся SFU.

Такой продукт крутит все три топологии в одной кодовой базе. Архитектура – не «выбери одну», а «выбери правильную под тип звонка». Так устроены зрелые WebRTC-продукты.

Где здесь Фора Софт

С 2005 года мы делаем продукты реального времени с видео, с WebRTC в центре практики с момента стабилизации стандарта. Дерево решений выше – это разговор, который мы ведём с каждым новым продуктом: телемедицина и e-learning нуждаются в Mesh-приватности для двусторонних звонков и в SFU-гибкости для всего остального; видеоконференц-связь и виртуальные классы по умолчанию работают на каскадных SFU; OTT и broadcast-аппаратные всё ещё требуют где-то в пайплайне MCU для композитного вывода в студию. Выбор правильной топологии под тип звонка – один из первых разговоров в discovery-спринте, потому что он задаёт историю стоимости и масштаба на ближайшие два года продукта.

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

• Топологии три: Mesh (прямые peer-соединения), MCU (сервер сводит), SFU (сервер пересылает).
• N − 1 uploads в Mesh ломают его выше пяти участников; ниже – Mesh корректен.
• MCU держит клиентскую полосу постоянной, но стоит в 10-50 раз больше SFU и добавляет 200-400 мс задержки.
• SFU – выбор по умолчанию практически для всех групповых звонков в 2026: малая нагрузка на клиента, малая на сервер, полная свобода раскладки.
• Каскадные SFU по регионам масштабируют сессию от одной комнаты до миллионов без смены типа топологии.
• Simulcast и SVC позволяют SFU обслуживать разнородную комнату без re-encode.

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

• WebRTC без зауми – семейство протоколов, на котором всё это стоит.
• mediasoup, Janus, LiveKit, Jitsi Videobridge, Pion: как выбрать SFU – когда ясно, что нужен SFU, какой именно.
• WebRTC в масштабе: каскадные SFU, региональные мосты, ИИ-агенты – когда одного SFU перестаёт хватать.

CTA

• Обсудите задачу с инженером по стримингу – 30-минутный звонок, на котором мы пройдёмся по правильной топологии под ваш продукт.
• Посмотрите наши кейсы – реальные телемедицинские, e-learning и OTT-развёртывания, которые мы запустили.
• Скачайте one-pager по выбору топологии – PDF на одну страницу: арифметика полосы, диапазоны стоимости, потолок на комнату для каждой топологии.