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 можно использовать для всех трёх паттернов, описанных в этой статье, – и выбор между ними остаётся за вами, а не за браузером.

«О терминологии. В литературе по WebRTC термины «peer-to-peer» и «Mesh» означают одно и то же, когда в звонке участвует больше двух человек. Термин «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-звонке медиа не проходят через серверы в плоскости управления оператора (сигнализация – да, но она передаёт только метаданные, а не сам медиапоток). Для некоторых режимов соответствия нормативным требованиям это различие принципиально.
• Прототипы, демо, юнит-тесты. Mesh – это то, что вы используете, когда нужно быстро организовать рабочий звонок за один вечер, отложив вопросы масштабирования на потом.

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

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

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

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

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

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

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

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

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

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

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

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

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

SFU: сервер пересылает поток без изменений

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

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

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

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

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

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

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

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

В мире 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.

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

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

Каскадные SFU: как преодолеть ограничения одного сервера

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

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

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

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

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

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

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

Распространённое заблуждение – думать, что «WebRTC peer-to-peer» означает полное отсутствие сервера. Сервер в WebRTC-звонке всегда присутствует: signalling-сервер, через который браузеры обмениваются SDP offer/answer; STUN-сервер, с помощью которого пир узнаёт свой публичный IP-адрес; 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, которую мы ещё используем, оправдана: мост для записи объединяет выход SFU в единый композитный файл архива, при этом живой поток остаётся в режиме SFU.

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

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

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

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

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

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

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

CTA

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