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

TL;DR

Один Selective Forwarding Unit, или SFU, исчерпывает свои возможности при числе одновременных видеоучастников от 500 до 1500 на одну машину – и этот предел никак не связан с самим протоколом WebRTC, а определяется исключительно производительностью CPU и сетевой карты сервера. Ответ 2026 года – каскад SFU: сеть региональных медиасерверов, где каждый участник подключается к ближайшему узлу, а узлы обмениваются трафиком между собой по бэкбону дата-центра. Такой подход превращает SFU-слой в распределённую систему, масштабируемую за счёт добавления узлов, а не за счёт покупки более мощного оборудования.

Когда аудитория выходит за рамки конференции, где каждый зритель одновременно и участник – например, town hall на 50 000 слушателей или live-стрим шопинга на 100 000 покупателей – архитектура снова меняется: теперь используется мост SFU → HLS, который транслирует интерактивный WebRTC-трафик через CDN на read-only-аудиторию с помощью Low-Latency HLS или chunked CMAF.

Третья ось масштабирования в 2026 году уже не зависит от людей: голосовые и видеоагенты на основе ИИ – построенные на LiveKit Agents 1.5, Pipecat 1.0, Vocode и новой волне интеграций OpenAI Realtime, Google Live API и Anthropic Realtime – подключаются к WebRTC-комнатам как headless-участники, открывая ту же архитектуру SFU + мост для нового класса real-time-нагрузок.

Почему это важно

Если вы продакт-менеджер, основатель или операционный руководитель компании, которая занимается конференциями, телемедициной, e-learning, live-шопингом, видео в контакт-центре или продуктами с ИИ-агентами, то способность системы выдержать удвоение трафика или, наоборот, «упасть» почти полностью зависит от архитектурных решений, принятых задолго до появления этого трафика. Уверенный покупатель должен чётко отвечать на три ключевых вопроса: сколько одновременных участников может обслуживать система, прежде чем понадобится добавить сервер; что произойдёт, если один из серверов выйдет из строя; и как изменится поведение системы, когда ИИ-агенты начнут участвовать в сессии наравне с людьми. Эта статья отвечает на эти три вопроса для нетехнического читателя, указывает старшему инженеру нужные кодовые пути и ссылки и даёт рабочую ментальную модель каждого значимого паттерна масштабирования WebRTC в 2026 году.

Где один SFU перестаёт масштабироваться

Selective Forwarding Unit – это устройство в центре многоточечного WebRTC-звонка, которое принимает медиаотказы от каждого участника, решает, какие потоки кому направлять, и пересылает их. Подробнее о топологиях – Mesh, MCU, SFU – см. SFU, MCU, Mesh: три топологии WebRTC.

Один SFU – это один процесс, работающий на одной машине. Его ограничения носят физический характер, и при нагрузке они проявляются в следующем порядке.

Первый потолок – CPU. Хотя SFU не выполняет транскодирование, он разбирает RTP-заголовки в каждом входящем пакете, шифрует SRTP в каждом исходящем, обрабатывает RTCP-обратную связь и поддерживает актуальность ICE-согласия для каждого соединения peer-to-peer. Современный x86-сервер с 32 ядрами и поддержкой AES-NI спокойно пересылает 600–1200 видеопотоков по 1 Мбит/с, прежде чем ядра достигнут предела загрузки. Mediasoup, SFU на C++/Node.js, в продакшене при хорошей настройке обеспечивает около 500–800 одновременных видеоучастников на узел; SFU LiveKit на Go – в том же диапазоне; C-движок Janus при аккуратной настройке выдаёт больше. Цифры варьируются в зависимости от кодека, количества simulcast-слоёв и структуры звонка, но порядок величины остаётся тем же.

Второй потолок – сеть. NIC на 10 Гбит/с при 80% загрузке передаёт 1 ГБ/с медиа. Видеопоток со скоростью 1 Мбит/с потребляет около 125 КБ/с исходящего трафика на одного подписчика. Конференция из 100 участников, где каждый подписан на всех остальных, даёт 100 × 99 ≈ 9900 потоков исходящего трафика в секунду; при 1 Мбит/с на каждый – это 9,9 Гбит/с, что полностью загружает 10-гигабитный канал. Картина жёсткая: исходящий трафик растёт как O(N²) в full-mesh-конференциях, потому что каждый из N участников подписан на N−1 других. LastN-форвардинг (см. ниже) ломает эту квадратичную зависимость; без него сетевая карта становится узким местом.

Третий потолок – операционный. Один SFU – это одна точка отказа. Если процесс падает, рушатся все активные звонки. Та же ситуация при kernel panic. Та же – при региональном сбое облака. Дальше нескольких сотен пользователей ни одна продакшн-команда такой риск не принимает.

Архитектура «один SFU» – правильный выбор для туториала, MVP и любого продукта, пик одновременных участников в котором не превышает нескольких сотен. Дальше архитектура должна меняться.

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

Каскад SFU: стандартный паттерн масштабирования в 2026

Каскадная архитектура SFU заменяет один медиасервер на меш из медиасерверов, которые обмениваются трафиком между собой. Участник подключается к SFU, наиболее близкому к нему – географически, по задержке или по уровню нагрузки, – и этот SFU передаёт его медиа другим SFU, у которых есть подписчики в той же комнате. С точки зрения пользователя каскадная система выглядит так же, как единый SFU; с точки зрения инфраструктуры нагрузка распределяется по столько узлов, сколько оператор готов оплатить.

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

LiveKit называет эту архитектуру распределённым мешем и использует её по умолчанию в облачном продукте; Jitsi Videobridge называет её Octo и включает в Jitsi Meet для всех конференций, превышающих настраиваемый порог; mediasoup предоставляет примитив Pipe Transport, который соединяет два экземпляра SFU на уровне API, оставляя сборку каскада приложению; Janus достигает аналогичного эффекта с помощью плагина VideoRoom с multistream-форвардингом. Twilio Video до закрытия в 2024 году работал на каскаде; Daily.co использует каскад; SFU Cloudflare Realtime изначально построен на каскаде, поскольку edge-серверы Cloudflare распределены по своей природе. К 2026 году каскадный режим присутствует в каждом продакшн-уровневом SFU – либо встроенным образом, либо в виде примитивов, которые собирает приложение.

Как каскад работает на самом деле

Чтобы каскад обеспечивал заявленные свойства по латентности и надёжности, должны быть выполнены три условия.

Первое – маршрутизация «комната → узел»: при входе нового участника в комнату система должна определить, к какому узлу его подключить. Две распространённые стратегии – локальность участника (подключение к ближайшему узлу) и аффинность комнаты (подключение к узлу, где уже находится больше всего участников этой комнаты). В продакшне эти подходы комбинируют: выбирают ближайший узел, если только его использование не приведёт к появлению лишнего каскадного хопа, который можно избежать, выбрав другой узел. Роутер LiveKit использует Redis для координации; Octo в Jitsi – центральный bridge selector; mediasoup оставляет выбор сигнальному слою приложения.

Второе – межузловой транспорт: как SFU A пересылает медиаучастника на SFU B. Pipe Transport в mediasoup использует обычный RTP по UDP внутри общей сети дата-центра; LiveKit применяет внутренний протокол на базе QUIC; Octo в Jitsi – собственный UDP-релей. Общая идея: межузловой хоп – это не обычный WebRTC-пиринг. Здесь нет DTLS-рукопожатия для каждого потока, нет ICE и нет повторной SRTP-шифровки – ведь оба узла находятся в доверенной сети, а накладные расходы полного DTLS-SRTP на каждый поток в каскаде были бы катастрофическими. Аутентификация между узлами происходит один раз – при запуске, обычно с помощью mTLS или общего HMAC-ключа.

Третье – целостность сессии: когда участник из Токио заходит в комнату, где уже присутствует участник из Франкфурта, SFU в Токио должен вовремя узнать о наличии франкфуртского участника и наоборот, чтобы новый участник успел подписаться. Это распределённая задача управления состоянием, которую решает слой координации; типичные решения – Redis, etcd, Apache ZooKeeper. В продакшене синхронизация происходит за доли секунды: новый участник видит текущий состав через 50–200 мс после подключения.

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

Чем каскад не является

Каскад – это не федерация: WebRTC-платформы разных организаций, обменивающиеся медиа через границы доверия (рабочая группа rtcweb в IETF исследовала федерацию, но в продакшене она остаётся редкостью). Каскад – это одна платформа, которая работает с одной комнатой на нескольких физических площадках.

Каскад – это не горизонтальное масштабирование сигнального слоя: добавление web-серверов перед SFU. Сигнал легко масштабируется горизонтально (stateless HTTP + WebSocket), и любой серьёзный WebRTC-решение масштабирует сигнал отдельно от медиа. Но для медиа-слоя нужен каскад – одной балансировкой сигнала ёмкость медиа не увеличить.

И каскад – это не multi-region failover. Каскад работает по принципу «актив-актив»: каждый регион обрабатывает живой трафик. Failover – побочный эффект, который каскад обеспечивает почти бесплатно: при потере одного региона звонок не прерывается, а лишь деградирует – участники автоматически переподключаются к ближайшему доступному узлу.

LastN и передача по доминирующему говорящему

Даже при использовании каскада счёт за сеть на 100-местной конференции остаётся неадекватным, если каждый участник получает видео от всех остальных. LastN – это оптимизация, которую применяют почти все современные SFU: каждому подписчику доставляются видео только от N самых активных говорящих в данный момент. Аудио остальных участников по-прежнему миксуется (аудио обходится дешевле); ограничивается только видеопоток.

Алгоритм определения доминирующего говорящего, опубликованный Jitsi в 2015 году (Politis, Tsioutas, Mavridis – «Last N: Relevance-Based Selectivity for Forwarding Video in Multimedia Conferences»), – фактически базовая ссылка: он работает на основе RTP-расширения заголовка audio-level (RFC 6464) без декодирования аудио, ранжирует участников по недавней голосовой активности, а SFU передаёт только топ-N видеопотоков каждому подписчику. Измерения Jitsi того времени показали: SFU с LastN при N = 10 потреблял на 45% меньше CPU и на 63% меньше пропускной способности, чем тот же SFU без LastN. На современном оборудовании эти цифры на порядок ниже, но соотношение остаётся прежним: LastN превращает сетевую нагрузку с O(N²) до O(N), а это – разница между конференцией на 100 участников и на 1000.

В каскадной топологии LastN работает на каждом узле: каждый региональный SFU вычисляет доминирующих говорящих по всей комнате (используя тот же сигнал audio-level, который получает от каждого другого узла), и передаёт локальным подписчикам только их потоки. Вычисление доминирующих – глобальное; решение о передаче – локальное. Это вторая причина, по которой каскад масштабируется: между узлами передаётся каждый аудиопоток (аудио недорого – Opus 32 кбит/с × 100 участников × 3 узла укладывается в 10 Мбит/с), но только доминирующие N видеопотоков.

В сочетании с simulcast и SVC (подробнее в Simulcast и SVC в SFU) LastN позволяет SFU выбирать для каждого подписчика, какой пространственный слой какого доминирующего говорящего отправлять. Подписчику с телефона передаётся низкоразрешающий слой активного говорящего; подписчику с десктопа в сетке 4-уп – средний слой четырёх говорящих. Один SFU, одна комната, разные нагрузки.

Численный пример: масштабирование 100-местной конференции

Посчитаем стоимость масштабирования 100-местной конференции с использованием паттернов и без них.

Наивная звезда, один SFU, без LastN. Каждый участник транслирует видеопоток со скоростью 1 Мбит/с и подписан на всех остальных. Выходной трафик SFU: 100 × 99 × 1 Мбит/с = 9,9 Гбит/с. Один сетевой интерфейс на 10 Гбит/с полностью загружен; при такой нагрузке звонок не может вместить более ~80 участников на данном оборудовании. Дневной объём исходящего трафика при использовании 4 часов в день: 9,9 Гбит/с × 4 ч × 3600 с × 1 ГБ / 8 Гбит ≈ 17,8 ТБ/день на один звонок.

Тот же звонок, LastN N=4. Каждый подписчик получает 4 самых активных участника + миксованное аудио от всех. Выходной трафик SFU на одного подписчика: 4 × 1 Мбит/с + 100 × 32 кбит/с (аудио) = 7,2 Мбит/с. Общий выходной трафик SFU: 100 × 7,2 Мбит/с = 720 Мбит/с. Сетевой интерфейс 10 Гбит/с теперь загружен на 7%; звонок спокойно размещается на одном сервере. Ежедневный исходящий трафик: ~1,3 ТБ/день – в 14 раз меньше.

Тот же звонок, LastN N=4, каскад на трёх региональных SFU (33 участника на регион). Каждый региональный SFU форвардит: 4 видео активных × 33 локальных подписчика = 132 локальных видеопотока, плюс 4 видео активных, разделяемых между узлами = 4 × 2 межузловых хопа = 8 межузловых видеопотоков. Egress на регион: 132 × 1 Mbps + 33 × 100 × 32 kbps = 232 Mbps. Межузловой egress на пару: 4 × 1 Mbps + 67 × 32 kbps аудио (нелокальных участников) = 6,1 Mbps. Архитектура теперь выдерживает падение региона (один узел выходит из строя – звонок деградирует, но не падает), обеспечивает токийским участникам локальную латентность, а расход трафика «на регион в час» составляет около 104 ГБ – треть от объёма, который потребляла одна SFU-LastN-модель, распределённая по трём регионам.

Цифры – иллюстративные; реальные значения в продакшене зависят от кодека, количества simulcast-слоёв, накладных расходов RTCP и используемого межузлового протокола. Но порядок величины верный, и паттерн универсален: LastN обеспечивает первый прирост в 10 раз, каскад – второй.

Архитектура «100 000 зрителей»: мост SFU → HLS

Каскад SFU масштабирует конференции – звонки, в которых большинство участников ещё и публикуют контент, – до нескольких тысяч человек. Но есть и другая задача масштабирования: town hall, прямые трансляции шопинга, спортивные watch-along, где небольшая группа ведущих транслирует контент для десятков или сотен тысяч зрителей, почти никто из которых ничего не публикует. WebRTC не подходит для такой аудитории по двум причинам.

Первая – экономика. Трансляция на 100 000 зрителей через каскадный SFU-меш означает 100 000 активных peer-соединений, каждое из которых требует отдельного DTLS-состояния, проверки свежести ICE-согласия, RTCP-обратной связи и SRTP-контекста. Расходы на CPU и память на стороне SFU становятся критичными, а затраты на исходящий трафик не уступают CDN. У WebRTC отсутствует кэширующий слой, в то время как у CDN он есть.

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

Продакшн-паттерн 2026 – мост SFU → HLS: SFU продолжает обслуживать публикующих и небольшую интерактивную аудиторию (ведущих, панелистов, VIP, агентов контакт-центра – всех, для кого критична латентность в пределах sub-second), а подключённый к SFU упаковщик преобразует поток активного говорящего в Low-Latency HLS или chunked-CMAF, который CDN доставляет остальной аудитории. Такой мост обеспечивает задержку 2–5 секунд glass-to-glass через LL-HLS – медленнее, чем 100–300 мс у WebRTC, но всё ещё достаточно оперативно, чтобы реакции в чате воспринимались синхронно, и при этом на порядки дешевле в распространении. Упаковщик подключается к SFU как обычный подписчик: входит в комнату, получает раскладку активного говорящего и выдаёт LL-HLS-сегменты на origin, откуда CDN – Cloudflare Stream, Fastly, AWS CloudFront, Akamai – раздают их дальше.

Этот паттерн – архитектура продукта livestreaming у LiveKit (см. их пост WebRTC vs HLS с цифрами 2026), архитектура продукта Mux Real-Time Streaming, архитектура Daily.co Egress. Cloudflare Realtime SFU интегрируется с Cloudflare Stream для достижения того же эффекта. Паттерн настолько стал стандартным, что новые семейства протоколов – см. Media over QUIC – изначально проектируются так, чтобы переход между режимами был менее заметным, обеспечивая единую транспортную основу для интерактивного и вещательного медиа.

Подробная механика моста – как RTP-кадры SFU превращаются в CMAF-сегменты, как формируется раскладка активного говорящего и как работает аудиомикширование – описана в Запись, broadcasting и мост WebRTC → HLS. Аспект работы reader’а с LL-HLS – в LL-HLS подробный разбор.

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

ИИ-агенты входят в комнату

До 2023 года каждый участник WebRTC-комнаты был человеком с браузером. К 2024 году первое поколение ИИ-голосовых агентов – Vapi, Retell, Vocode – начало подключаться к комнатам как headless-участники через WebSocket. В 2025 году фреймворк LiveKit Agents 1.0 и Pipecat 1.0 от Daily формализовали этот паттерн: OpenAI представил Realtime API, Google – Live API, Anthropic – мультимодальный realtime-voice, и все они были спроектированы так, чтобы легко интегрироваться с агент-фреймворками и подключаться к WebRTC-комнатам как peer-участники. В 2026 году «ИИ-агент-участник» стал рутинной нагрузкой на той же SFU-инфраструктуре, что и обычные человеческие звонки.

ИИ-агент в WebRTC-комнате с точки зрения механики – это простейший пиринговый узел. Он работает как процесс где-то в системе (обычно в том же дата-центре, что и региональный SFU, чтобы минимизировать количество переходов), присоединяется к комнате как участник, подписывается на одну или несколько аудиодорожек от людей, публикует свою аудиодорожку и запускает внутри voice-агент pipeline: voice-activity detection (VAD) для определения окончания речи, speech-to-text (STT) для транскрипции сказанного, large language model (LLM) для генерации ответа и text-to-speech (TTS), который преобразует ответ обратно в аудио и отправляет его через публикуемый трек агента. В простейшем случае агент никогда не видит видеокадров; но уже в 2026 году всё чаще видит – потому что API уровня GPT-4o «Realtime» принимают видео, и LLM выполняет базовое визуальное рассуждение в рамках одного и того же запроса.

LiveKit Agents 1.5 – самый удобный для развёртывания фреймворк

LiveKit Agents – open source, работает на Python 3.11+ и на момент релиза 1.5 в апреле 2026 года является самым распространённым фреймворком для создания агентов поверх WebRTC. Архитектура трёхслойная: Worker регистрируется на сервере LiveKit, сервер диспатчит worker в Room при входе пользователя, после чего worker запускает VoicePipelineAgent, который оркестрирует VAD/STT/LLM/TTS через модули с возможностью подмены (plug-and-swap).

Релиз 1.5 добавил две важные для продакшена фичи: адаптивную обработку прерываний – агента можно прервать в середине реплики, воспроизведение TTS останавливается, частичная транскрипция фиксируется в контексте LLM, а следующий пользовательский ход обрабатывается корректно, – и нативную поддержку Model Context Protocol (MCP), которая позволяет агенту вызывать внешние инструменты (поиск в базе клиентов, бронирование календаря, подтверждение платежа) в рамках одного хода без отдельной оркестрации.

Поскольку LiveKit Agents входит как обычный участник, каскадный SFU-меш распределяет трафик агентов так же, как и человеческий. Флот worker-ов крутится в каждом регионе; токийский человек получает токийского агента; латентность остаётся sub-second.

Pipecat 1.0 – vendor-neutral альтернатива

Pipecat достиг версии 1.0 14 апреля 2026 года, поддерживается Daily.co и полностью vendor-нейтрален. Pipecat – pipeline-ориентированный: вы описываете направленный граф процессоров – VAD, STT, LLM, TTS, бизнес-логику – и аудиофреймы проходят через него. Эта модель гибче, чем у LiveKit Agents, а опыт развёртывания шире: Pipecat-воркер умеет работать по WebRTC (через SDK Daily или любой WebRTC-адаптер транспорта), по SIP (для телефонной связи), по WebSocket или даже по MQTT – для embedded-сценариев. Платой за такую гибкость становится отсутствие встроенного медиасервера – его нужно подключать отдельно, в отличие от LiveKit Agents и LiveKit SFU, спроектированных как единый стек.

Калькулятор 2026: выбирайте LiveKit Agents, если WebRTC и единый стек от одного вендора подходят; выбирайте Pipecat, если требуется телефония или встроенный транспорт, либо команда хочет гибко комбинировать поставщиков STT/LLM/TTS. Оба фреймворка могут сосуществовать и взаимодействовать на границе комнаты: LiveKit-комната может принять Pipecat-агента, если он использует адаптер транспорта LiveKit.

Vocode и остальные

Vocode – более старая платформа, написанная на Python, изначально тесно связанная со своей инфраструктурой, но сейчас тоже стала vendor-нейтральной. Retell, Vapi, Bland.ai, Dograh – коммерческие SaaS-продукты, построенные на тех же базовых компонентах, каждый со своим медиасервером. В продакшене типовой подход – использовать управляемый фреймворк (например, LiveKit Agents или Pipecat) для нового проекта и принять, что один-два vendor API окажутся привязаны к поставщику.

Что меняет ИИ-агент в SFU

Присутствие агента в комнате изменяет три аспекта на уровне SFU.

Первое – геометрия подписок. Типовой звонок 1-на-1 с голосовым агентом контакт-центра включает одного клиента, одного агента и два аудиопотока (от клиента и от агента). Типовой multi-party-звонок с участием агента – три клиента и один агент, то есть четыре участника. При этом количество аудиопотоков зависит от схемы подключения: шесть (если каждый подписан на всех – как в mesh), или меньше – при использовании LastN. Агент при этом является обычным участником с точки зрения SFU.

Второе – бюджет латентности. Человек-к-человеку живёт в 300 мс glass-to-glass. Звонок с агентом имеет более жёсткий бюджет на стороне агента, потому что пользователь воспринимает паузу «LLM думает» как неловкость, если она переваливает ~800 мс от конца речи до старта ответа. Из этих 800 мс STT + LLM + TTS на стороне агента съедают большинство; WebRTC-round-trip в агент и обратно должен быть невидим. Каскад SFU помогает здесь ровно так же, как и в человеческом звонке: worker агента крутится в том же регионе, межузловой хоп не нужен на леге человек-агент, бюджет остаётся целым.

Третье – масштаб. Worker-агент вычислительно на порядок дороже человеческого участника (GPU под LLM, GPU под TTS, сеть под STT-API). Серьёзный продукт на основе агента масштабирует флот worker’ов отдельно от флота SFU, часто размещая GPU-инстансы у другого облачного провайдера, а SFU воспринимает их просто как участников. Автомасштабирование флота worker’ов настраивается по уровню одновременных звонков; LiveKit Agents и Pipecat предоставляют референсные автоскейлеры.

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

Четыре оси масштабирования рядом

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

Правильный ответ – объединение строк 1, 2, 3 для любого серьёзного конференц-решения; 1–4 для broadcast или live-торговли; 1, 2, 3, 5 для агента; все пять – для продукта «агент + broadcast» (live-торговая комната 2026, где ИИ-агент отвечает на вопросы покупателей со стороны трансляции).

Где Фора Софт

Фора Софт разрабатывает решения на основе WebRTC для конференций, телемедицины, e-learning, видео в контакт-центрах, live-штопинга, видеонаблюдения и AR/VR с 2005 года – более 250 проектов. Каскад SFU – архитектурный выбор по умолчанию в каждом проекте, где требуется поддержка нескольких сотен одновременных участников. Мост SFU → HLS – стандартная реализация для live-штопинга и телемедицинских grand rounds, где небольшая группа вещает на широкую аудиторию. ИИ-агент – самая новая направление: LiveKit Agents и Pipecat – два стека, которые команда сейчас внедряет чаще всего; выбор между ними зависит от того, предусмотрена ли в спецификации интеграция с телефонией. Каждый пример «Где Фора Софт» в статьях Блока 8 отражает один и тот же паттерн: отрасли – реальные, точки внедрения в продакшн – реальные, архитектурные решения – те, что описаны в этой статье.

Типичная ошибка WebRTC при масштабировании

Самая частая ошибка в продакшене, с которой мы сталкиваемся при анализе архитектуры WebRTC в условиях масштабирования, – деплой каскада без слоя координации, устойчивого к отказу узла. Сам каскад по сути прост: каждый современный SFU предоставляет базовый примитив. Сложность – в реестре состояния комнат, который сообщает каждому узлу, какие другие узлы обслуживают участников в каких комнатах. Один Redis перед мешем из четырёх регионов – это единая точка отказа, которая сводит на нет весь смысл каскада. Проблему решают либо кластером Redis с кворумом, либо etcd в качестве бэкенда реестра, либо распределённой стейт-библиотекой вроде Hazelcast – то есть любой системой, в которой потеря одной машины в слое координации не парализует весь меш. Мы видели архитектуры, где каскад был идеально спроектирован, а слой координации – всего лишь одним инстансом t3.medium; когда этот инстанс перезагружался для установки security-патчей в 03:00, все звонки во всех четырёх регионах обрывались. Каскад – это система; слой координации – её часть. Его нужно масштабировать так, чтобы он имел тот же blast-радиус, что и весь флот SFU.

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

• Один SFU исчерпывается при нагрузке около 500–1500 видеоучастников на узел – первым лимитом становится CPU в плотных комнатах, а сеть – в звездообразных broadcast-сценариях.
• LastN с simulcast или SVC превращает O(N²)-выходной трафик в O(N) и остаётся самым эффективным решением – универсальным стандартом по умолчанию в 2026 году.
• Каскадные SFU-решения – продакшн-паттерн при нагрузке свыше нескольких сотен участников; межузловые соединения проходят по бэкбону дата-центра, а не через публичный интернет.
• Трансляция на 100 000 зрителей реализуется через мост SFU → HLS, а не через WebRTC-распространение – уровень задержки смещается с 300 мс до 2–5 секунд, а стоимость снижается на порядок.
• ИИ-агенты – рутинные участники WebRTC-комнат в 2026 году; масштабирование worker-флота агентов происходит независимо от флота SFU; LiveKit Agents 1.5 и Pipecat 1.0 – два доминирующих фреймворка.
• Слой координации (Redis, etcd, Hazelcast) – часть каскада, его размерность должна соответствовать blast-radius’у флота SFU.

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

• SFU, MCU, Mesh: три топологии WebRTC – топологический контекст, на котором построена эта статья.
• Выбор SFU: mediasoup, Janus, LiveKit, Jitsi, Pion – сравнение возможностей и производительности по конкретным решениям.
• Запись, broadcasting и мост WebRTC → HLS – подробное описание механизма преобразования в формате broadcast.

Призыв к действию

• Обсудите с инженером по стримингу вашу архитектуру WebRTC при масштабировании: связаться с Фора Софт.
• Ознакомьтесь с нашими кейсами в конференциях, телемедицине, live-торговле и продуктах с ИИ-агентами: fora-soft.ru.
• Скачайте чек-лист WebRTC Scale-Up Pre-Flight (30-пунктный продакшн-чек-лист по 6 направлениям: базовый SFU, LastN/simulcast, дизайн каскада, слой координации, broadcast-мост, флот ИИ-агентов): Скачать PDF.