Масштабирование живого класса: SFU, simulcast и лекция на 200 мест

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Чтобы живой онлайн-класс выдержал рост аудитории, мало купить сервер помощнее: нужно выбрать подходящую под аудиторию форму. Пока класс растёт от мини-группы на шесть человек до лекции на двести мест и трансляции на две тысячи зрителей, форма меняется трижды. Основа любого интерактивного класса – медиасервер SFU: он принимает одну копию каждой камеры и раздаёт её остальным участникам. Обслуживать на одной лекции и телефон в общежитии, и ноутбук в кампусе ему позволяет simulcast: отправитель шлёт сразу несколько вариантов качества, а сервер отдаёт каждому зрителю тот, который выдерживает его канал. Когда почти все смотрят и почти никто не говорит, как в настоящем лектории, платить за двустороннее видео для молчаливого большинства незачем. Зрителей переводят на дешёвый односторонний слой трансляции, а на дорогом интерактивном канале остаются только преподаватель и те, кто поднял руку. В статье – четыре формы класса, числа, которые их разделяют, и граница между тем, что стоит строить, и тем, что лучше купить. Текст рассчитан на читателя без технической подготовки; устройство протоколов разобрано в разделе Video Streaming, здесь мы его не пересказываем.

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

Если вы отвечаете за корпоративное обучение, основали EdTech-продукт или владеете каталогом курсов, рано или поздно ваш живой класс перерастёт формат встречи. В этот момент разом меняются затраты, качество видео и надёжность, и обычно это происходит посреди оплаченного пилота. Ошибка в выборе формы дорога в обе стороны: недостроите – и лекция на 200 человек зависнет; перестроите – и будете платить за двустороннее видео сотням учеников, которые только смотрят. Статья даёт словарь, чтобы ставить задачу инженерам, четыре формы живого класса и главный вопрос, от которого зависят и архитектура, и счёт: сколько человек на самом деле говорят? Это продолжение статьи WebRTC для живого обучения, где объяснялось, почему движок живого класса – WebRTC. Здесь речь о том, как этот движок выдерживает большую аудиторию.

Главный вопрос: сколько человек говорят?

Начните с одного числа, от которого зависят все дальнейшие решения. В живом классе две группы участников. Одни отправляют видео и звук: преподаватель, спикеры, ученики, которые включают микрофон, чтобы ответить. Другие только принимают. Назовём их отправителями и зрителями. Стоимость и архитектуру живого класса почти полностью определяет число отправителей, а не общее число людей.

Отправлять живое видео дорого и ненадёжно: камеру каждого отправителя нужно доставить на сервер, а оттуда раздать всем зрителям. Принимать видео, наоборот, дёшево, и эта задача давно решена: любой стриминговый сервис раздаёт видео огромной аудитории. Показать видео 200 людям несложно. Инженерная задача живого класса в другом: сколько человек отправляют видео одновременно и как раздать их потоки, не перегрузив ни ноутбук, ни бюджет.

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

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

Форма 1: почему мини-группа работает, а класс – нет (mesh)

Проще всего соединить класс так, чтобы каждый браузер отправлял своё видео напрямую каждому другому браузеру, без сервера посередине. Такая схема называется mesh (сетка): соединения образуют паутину, в которой все связаны со всеми. Для занятия на четверых это идеальный вариант: дёшево, приватно и обслуживать нечего.

С ростом аудитории mesh перестаёт работать по простой арифметической причине: каждый участник отдаёт свою камеру отдельно каждому из остальных. При 5 участниках каждый браузер отправляет 4 копии своего видео и принимает 4 – это посильно. При 20 участниках каждый браузер отправляет 19 копий и принимает 19, а обычный ноутбук на домашнем интернете не потянет девятнадцать исходящих видеопотоков одновременно. Исходящий канал и процессор упираются в предел примерно на шести-восьми активных отправителях.

Mesh вместе с двумя серверными топологиями подробно разобран в статье раздела Video Streaming топологии SFU, MCU и mesh. Нам достаточно одного вывода: больше ~6 отправителей mesh не выдерживает, поэтому любому реальному классу нужен сервер.

Форма 2: основа живого класса – SFU

Решение – поставить посередине сервер, чтобы ни один браузер не отправлял своё видео больше одного раза. Такой сервер называется Selective Forwarding Unit, или SFU, и название точно описывает его работу: он избирательно пересылает медиа. Каждый участник отправляет одну копию своей камеры на SFU, а SFU рассылает эти потоки всем, кому они нужны. Сколько бы людей ни было в классе, браузер отдаёт только один свой поток.

SFU похож на почтовое отделение класса. Двадцать учеников бросают в ящик по одному письму (своё видео), а отделение делает копии и разносит их адресатам. Ученику не нужно самому доставлять двадцать писем: он отправляет одно, остальное берёт на себя почта. Так и работает семинар на тридцать человек, где каждый может включить микрофон и заговорить.

Одно свойство SFU важно для бюджета, и его часто понимают неправильно: SFU не перекодирует видео, а пересылает полученные байты без изменений. (Более старая схема, MCU – Multipoint Control Unit, – как раз перекодирует: смешивает всех участников в одну общую картинку. Клиенту так проще, но серверу намного дороже, и задержка растёт, поэтому интерактивные классы строят на SFU.) Раз SFU только пересылает, его нагрузку на процессор определяет число потоков, а не их разрешение: переслать поток 4K стоит примерно столько же процессорного времени, сколько поток 360p (getstream.io, «Selective Forwarding Unit», 2026). Это пригодится, когда будем считать ёмкость.

Внутреннее устройство SFU – тема раздела Video Streaming. Как SFU работает и чем отличаются open-source-варианты (mediasoup, Janus, LiveKit, Jitsi, Pion), читайте в статьях топологии SFU, MCU и mesh и выбор SFU. Нас интересует учебная сторона: как одному SFU обслужить класс с разными устройствами и что делать, когда класс перерастает один сервер.

Форма 3: класс с разными устройствами – simulcast

Аналогия с почтой скрывает одну проблему: устройства в реальном классе разные. Один ученик сидит в кампусе на оптоволокне с 27-дюймовым монитором, другой подключается с телефона в поезде, где ловятся два деления сети, третий – с рабочего ноутбука с жёсткими корпоративными ограничениями. Камера преподавателя даёт один поток. Если SFU отправит его всем в полном качестве, телефон в поезде не справится и видео зависнет. Если всем отправить низкое качество, чтобы выдержал телефон, на 27-дюймовом мониторе лекция будет размытой.

Эту задачу решает simulcast (от simultaneous broadcast, одновременная передача). Браузер каждого отправителя кодирует и отправляет сразу несколько вариантов своей камеры, обычно три: высокого, среднего и низкого качества (например, 720p, 360p и 180p). SFU получает все три и каждому зрителю пересылает тот, который выдерживают его канал и экран. Телефон в поезде получает слой 180p, монитор в кампусе – 720p, и никому не приходится жертвовать качеством ради другого. Отправитель платит за это чуть большим исходящим трафиком, а сервер взамен обслуживает разнородный класс из одного источника.

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

Simulcast – стандартный механизм, он не привязан к конкретному вендору. Как браузер объявляет, что отправляет три слоя, и как помечает каждый из них, описано в интернет-стандарте RFC 8853 «Using Simulcast in SDP and RTP Sessions» (IETF, январь 2021). Он опирается на атрибут Restriction Identifier (RID) из RFC 8851 (IETF, январь 2021): этим атрибутом помечают слои и ограничивают их разрешение и битрейт. Поскольку это стандарт, simulcast поддерживают все основные браузеры: в 2026 году они по умолчанию используют его для кодеков VP8 и H.264.

Более новая альтернатива: SVC

Ту же задачу эффективнее решает более современная техника – Scalable Video Coding, или SVC. Simulcast отправляет три отдельных потока, а SVC – один многослойный поток, который сервер умеет разбирать на части: телефону пересылает только базовый слой, монитору в кампусе – все слои сразу. Три независимые копии не нужны, поэтому исходящий канал расходуется экономнее. Для WebRTC SVC описан в спецификации W3C «Scalable Video Coding (SVC) Extension for WebRTC». В 2026 году браузеры на Chromium по умолчанию используют его для более новых кодеков VP9 и AV1. Некоторые платформы (например, LiveKit) применяют simulcast для VP8/H.264 и автоматически переключаются на SVC для VP9/AV1.

Для учебного продукта неважно, какую из этих техник платформа использует внутри; важно, чтобы она была включена. Подробная механика simulcast и SVC, пространственные и временные слои и то, как SFU выбирает слой для каждого зрителя, – тема раздела Video Streaming, полная картина в статье simulcast, SVC и SFU. Без simulcast или SVC один ученик со слабой сетью ухудшает качество всему классу, поэтому до масштабирования убедитесь, что платформа их использует.

Сколько выдерживает один SFU? Ёмкость и каскадирование

Естественный вопрос: если раздачей занимается SFU, сколько учеников выдержит один сервер? Ответ всё тот же – зависит от того, сколько из них отправляет видео, – но ориентиры есть.

Нагрузку SFU определяет число пересылаемых потоков, поэтому ёмкость удобнее считать в потоках, а не в людях. Хорошо настроенный узел SFU пересылает порядка нескольких тысяч исходящих потоков. При грамотном развёртывании это примерно 500–800 одновременных участников, отправляющих видео, на узел, прежде чем упрётся пропускная способность или лимит соединений (sheerbit.com, «LiveKit Architecture Deep Dive», 2026; getstream.io, 2026). Семинар, где 30 человек отправляют видео и 30 принимают, – это меньше тысячи потоков, один узел справляется с запасом. Лекция, где отправляют 2 человека, а смотрят 500, – чуть больше тысячи исходящих потоков, тоже в пределах одного узла. Так что лекция на 200 мест, вопреки интуиции, – не сложный случай.

Если сессия действительно перерастает один сервер (тысячи участников или ученики по всей стране, от Калининграда до Владивостока), один гигантский сервер не покупают. Вместо этого несколько SFU соединяют так, чтобы они работали как один. Это называется каскадированием: SFU в разных регионах связаны между собой, каждый ученик подключается к ближайшему, а серверы пересылают потоки друг другу. Каскадирование и поднимает потолок, и снижает задержку: ученик во Владивостоке подключается к серверу на Дальнем Востоке, а не гонит медиа через всю страну до московского сервера преподавателя (webrtcHacks, «Improving Scale and Media Quality with Cascading SFUs», Борис Грозев). Эксплуатация каскадов – тема раздела Video Streaming, см. WebRTC на масштабе: каскады SFU и региональные мосты. Для учебного продукта достаточно запомнить: учеников из одного региона обслуживает один SFU, а группе, разбросанной по часовым поясам, нужны каскадированные SFU.

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

Форма 4: настоящий лекторий – слой трансляции

Теперь самый крупный случай. Идёт лекция: один преподаватель, пара ассистентов, которые иногда говорят, и 2000 записавшихся учеников, которые почти никогда не говорят. Может ли SFU обслужить 2000 человек, которые только смотрят? С каскадированием, пожалуй, может, но тогда вы платите за двустороннюю инфраструктуру реального времени, чтобы показать одностороннюю картинку. Инструмент выбран неудачно, и это видно по счёту.

Двум тысячам зрителей интерактивный движок вообще не нужен. Им нужно то, что любая стриминговая платформа давно доставляет дёшево: односторонний видеопоток. Поэтому класс делят на два слоя. В интерактивном слое преподаватель, ассистенты и вызванный к ответу ученик работают на WebRTC через SFU: задержка меньше секунды, настоящий диалог. Слой трансляции берёт собранное видео класса, переводит его из SFU в стриминговый формат и раздаёт молчаливому большинству через сеть доставки контента (CDN) – ту же распределённую сеть кэширующих серверов, которая доставляет видео по запросу. На одного зрителя это в разы дешевле интерактивного варианта.

Для слоя трансляции обычно берут Low-Latency HLS (LL-HLS) – версию стандартного протокола интернет-видео с задержкой примерно две-шесть секунд. Трансляция при этом остаётся дешёвой и хорошо работает с CDN, а схема «поднял руку в чате – вывели на сцену» не тормозит. (Стандарт Media over QUIC, или MoQ, который развивается в 2026 году, должен ещё сильнее сократить задержку трансляций; за ним стоит следить, но рабочий стандарт сегодня – LL-HLS.) Когда зрителя вызывают к ответу, его переводят со слоя трансляции на WebRTC, пока он говорит, а потом возвращают обратно. Такой гибрид из небольшого дорогого интерактивного ядра и большой дешёвой трансляционной части – стандартная схема для крупного живого обучения; её же используют live-commerce, киберспорт и вебинарные продукты с большой аудиторией.

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

Мост от WebRTC к трансляции и экономика CDN – тема раздела Video Streaming: читайте запись, вещание и мост WebRTC к HLS и архитектуру multi-CDN. Для учебного продукта главное решение – само разделение: на WebRTC остаются только отправители, а всех, кто только смотрит, переводят на слой трансляции.

Числа: сколько стоит каждая форма

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

Сначала все на SFU. Допустим, общее видео класса идёт со скоростью около 1,5 мегабита в секунду на зрителя (нормальное качество для лекции). Раздаём его 500 зрителям через облачный SFU:

• 1,5 мегабита/с × 500 зрителей = 750 мегабит в секунду исходящего трафика SFU.
• Занятие в 50 минут – это 3000 секунд. 750 мегабит/с × 3000 секунд = 2 250 000 мегабит.
• Делим на 8, чтобы получить мегабайты, и на 1000, чтобы получить гигабайты: 2 250 000 ÷ 8 ÷ 1000 ≈ 281 ГБ за одно занятие.
• Исходящий трафик SFU (реального времени) стоит ориентировочно 7,7–10 ₽ за ГБ в 2026 году (модели тарификации у облаков различаются, сверяйтесь с прайсом провайдера). При 8,5 ₽/ГБ: 281 ГБ × 8,5 ₽ ≈ 2 390 ₽ за занятие, и это только зрители.

Теперь те же 500 зрителей на слое трансляции (CDN). Байтов столько же, но трафик CDN для одностороннего стриминга на больших объёмах намного дешевле: ориентировочно 1,7–4,3 ₽ за ГБ, а при обязательстве по объёму – ещё меньше. При 2,6 ₽/ГБ: 281 ГБ × 2,6 ₽ ≈ 731 ₽ за занятие.

Разница за одно занятие кажется небольшой, около полутора тысяч рублей, пока не умножить её на реальный каталог. Двести таких лекций в неделю, сорок недель в году – это 200 × 40 = 8000 лекций. Разница (2 390 − 731) = 1 659 ₽ на лекцию превращается в 8000 × 1 659 ₽ ≈ 13,3 млн ₽ в год. Столько экономит перевод зрителей с SFU на слой трансляции, и это без учёта освободившейся серверной ёмкости. Ради этой экономии гибрид и существует: интерактивный трафик – отправителям, дешёвый трансляционный – зрителям.

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

Даже хорошо масштабируемый живой класс бесполезен для учебной команды, если не отвечает на вопрос «кто присутствовал и кто действительно завершил занятие?». В трансляции на 500 человек измерить завершение труднее, чем на семинаре на шестерых: большая часть аудитории находится на одностороннем слое, где событий интерактивного плеера меньше.

Подход тот же, что и во всём курсе: отправляйте структурированные учебные события. Для детальных событий видео есть стандарт xAPI Video Profile – профиль сообщества, построенный на Experience API (xAPI) 1.0.3, стандарте учебных данных. Он задаёт утверждения вроде «played», «paused», «seeked», «completed» и «terminated», которые плеер отправляет в Learning Record Store (хранилище xAPI-утверждений). Для живого класса заранее определите, что значит «присутствовал» и «завершил»: зашёл в первые десять минут, пробыл 80% времени, ответил хотя бы на один опрос, – и настройте оба слоя так, чтобы они отправляли подтверждающие это события. При большой аудитории события отправляют пакетами, иначе лекция на 2000 человек разом завалит хранилище записями. И помните: каждое такое утверждение описывает конкретного ученика, то есть это персональные данные. Learning Record Store и аналитическое хранилище должны находиться в России (ч. 5 ст. 18 152-ФЗ).

Механика трекинга видео разобрана в статье о трекинге видео через xAPI Video Profile, а смысл получившихся метрик – в метриках обучения 101. Специфика большой аудитории сводится к трём вещам: определить завершение до лекции, настроить отправку событий на обоих слоях и отправлять их пакетами.

Доступность при большой аудитории: один поток субтитров на всех

Субтитры нужны при любом размере класса, а большая аудитория одно в этой задаче упрощает, другое усложняет. Ориентир для живых субтитров в синхронном классе – Руководство по доступности веб-контента (WCAG) 2.1, критерий успеха 1.2.4 «Субтитры (в реальном времени)», уровень соответствия AA (W3C, 2018). На WCAG 2.1 построен ГОСТ Р 52872-2019, который становится обязательным, когда заказчик вписывает его в техническое задание. Вуз к тому же по ст. 79 273-ФЗ обязан создавать специальные условия для студентов с ОВЗ. У вуза, госзаказчика или крупной компании лекция без субтитров может не пройти приёмку.

Упрощает задачу то, что субтитры делаются один раз. Звук преподавателя расшифровывает один процесс распознавания речи в реальном времени, а готовый текст раздаётся всем зрителям на обоих слоях. Стоимость субтитров не зависит от числа зрителей: лекторий на 2000 мест обходится в субтитрах столько же, сколько семинар на 20. Сложнее со временем доставки: текст должен приходить синхронно с видео того слоя, на котором находится зритель, а у трансляции задержка две-шесть секунд, и раздачу субтитров нужно под неё подстроить. Распознавание речи и схема раздачи субтитров разобраны в разделе ИИ: см. живые субтитры и ASR на стороне SFU. Голос – персональные данные, поэтому распознавание оставляют в российском контуре (Yandex SpeechKit, SaluteSpeech или open-source-модели на своих серверах).

Топологии живого класса в сравнении

Ниже четыре формы сопоставлены с тем, что нужно учебной команде. Для неё ключевая строка – «Стандарты / трекинг»: занятие засчитывается, только если попадает в учебную запись.

Обратите внимание на две строки. Зрителей: ради неё и существует гибрид, ведь только слой трансляции дёшево масштабирует аудиторию, которая только смотрит, до тысяч человек. Качество на разных устройствах: поэтому simulcast или SVC обязателен, как только отправителей больше нескольких человек, – без него один слабый канал задаёт качество всем. Строка про стандарты во всех формах одинакова: какую топологию ни выбери, мост к учебной записи строить всё равно придётся.

Частая ошибка: путать число людей с числом отправителей

Самая дорогая ошибка масштабирования в живом обучении – рассчитывать архитектуру по общему числу людей, а не по числу тех, кто действительно отправляет видео. Команда слышит «нужно поддержать класс на 500 человек» и разворачивает мощный кластер SFU, чтобы посадить всех 500 в двустороннюю сетку. В итоге она платит за интерактивный трафик 498 учеников, которые никогда не включат микрофон, и строит галерею из сотен окон, которую всё равно никто не разглядит. Бывает и наоборот: команда делает чисто трансляционную лекцию на 500 человек, а потом выясняется, что по методике нужны обсуждения в сессионных залах, где говорят все, а односторонний слой этого не умеет.

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

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

Вторая ошибка менее заметна: выпустить продукт без simulcast или SVC и узнать об этом только на пилоте, когда один ученик на гостиничном Wi-Fi подвешивает семинар всем. Включайте многослойное кодирование с первого дня: это самая дешёвая страховка в живом обучении.

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

Мы делаем заказные продукты для живого обучения, и с клиентом обычно сначала говорим о топологии: если правильно выбрать форму в начале, продукт останется по карману и тогда, когда класс вырастет. Рекомендация «строить или покупать» у нас та же, что в этой статье: медиадвижок не стройте никогда. SFU, simulcast, управление перегрузкой, каскадирование и мост к трансляции – узкая специализация, которой годами занимаются отдельные инфраструктурные команды, open-source-проекты (mediasoup, Janus, LiveKit OSS, Jitsi) и российские платформы реального времени. Берите этот слой готовым и разворачивайте в российском облаке или на своих серверах. Бюджет разработки тратьте на то, что превращает видеозвонок в учебный класс: вызов к ответу, посещаемость и завершение как часть учебной записи, сессионные залы, субтитры и мост к вашей системе управления обучением. Выводы этой статьи (считать по числу отправителей, включать simulcast, делить лекцию на интерактивный и трансляционный слои) мы вынесли из проектов с видео реального времени, которыми занимаемся с 2005 года: видеоконференции, стриминг, e-learning и телемедицина.

Главное

• Архитектуру живого класса определяет число отправителей видео, а не общее число людей.
• Mesh годится для мини-группы; больше ~6 активных отправителей он не выдерживает, поэтому реальному классу нужен SFU.
• SFU пересылает по одной копии каждой камеры; его стоимость растёт с числом потоков, а не с разрешением.
• Simulcast или SVC позволяет одному SFU обслужить класс с разными устройствами; без них самый слабый канал задаёт качество всем.
• Большую лекцию делят на интерактивный слой WebRTC и дешёвый односторонний слой трансляции (LL-HLS через CDN).
• Перевод зрителей с SFU на слой трансляции на крупном каталоге экономит порядка десятка миллионов рублей в год.
• Медиадвижок не стройте сами: берите готовый, а силы разработчиков направьте на учебный слой. Данные учеников и распознавание речи оставляйте в России.

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

• Запись живых занятий и постобработка для каталога
• Эталонная архитектура живого обучения: полная картина
• Simulcast, SVC и SFU (раздел Video Streaming)