WebRTC для живого обучения: почему это стандарт и его подводные камни

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

Кратко

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

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

Если вы руководите корпоративным обучением, запускаете EdTech-продукт или владеете каталогом курсов, живое занятие – место, где самый дорогой ресурс, время преподавателя, встречается с учениками в реальном времени. И движок под этим занятием почти всегда WebRTC. Если понимать, почему он стал стандартом и где незаметно ломается, пилот закончится внедрением на всех площадках заказчика, а не провалом на непроверенном файрволе учебного заведения. Статья даёт руководителю, далёкому от разработки, словарь для постановки задачи инженерам, четыре конкретных риска для бюджета и границу «создать или купить», которая убережёт от разработки инфраструктуры, которую стоило арендовать или взять из open source. Это инженерное продолжение статьи виртуальный класс: там речь шла о том, что такое класс, а здесь – почему его движок WebRTC и что в нём ломается.

Что такое WebRTC

Начнём с простого. WebRTC (Web Real-Time Communication) – встроенная в браузер технология для передачи живого аудио, видео и данных между людьми с очень малой задержкой. Когда ученик нажимает на ссылку занятия и через мгновение его камера появляется рядом с камерой преподавателя – без скачивания и плагинов, – это работает WebRTC. Это не приложение, которое нужно установить, а возможность, уже встроенная в Chrome, Safari, Firefox, Edge и Яндекс Браузер.

Два факта делают WebRTC настоящим стандартом, а не продуктом одного вендора, и оба важны, когда вы строите на нём учебную платформу. Во-первых, браузерная часть – формальный веб-стандарт: WebRTC 1.0 – рекомендация W3C, утверждённая 26 января 2021 года. Она определяет JavaScript-интерфейсы для медиа реального времени во всех браузерах (W3C, «WebRTC 1.0: Real-Time Communication Between Browsers», Recommendation, 2021). Во-вторых, сетевая часть – стек интернет-протоколов, описанный IETF; общий обзор даёт RFC 8825 «Overview: Real-Time Protocols for Browser-Based Applications» (IETF, 2021). Обе половины – открытые стандарты, поэтому ни одна компания не может лишить вас WebRTC, а зайти на занятие может любой совместимый браузер.

Как именно работают эти протоколы, здесь не разбираем – это задача раздела Video Streaming. За подробностями (как браузеры находят друг друга, как шифруется медиа, как сервер раздаёт одно видео многим) обращайтесь к статьям WebRTC без зауми и топологии SFU, MCU и mesh. Здесь нас интересует один вопрос: почему WebRTC – правильный движок для живого занятия и какие ловушки ждут именно в обучении?

Почему WebRTC победил в обучении в реальном времени

Три свойства – в порядке важности для преподавания.

1. Задержка меньше секунды делает занятие живым

Ключевое понятие здесь – задержка (latency): время между событием на одной стороне и его появлением на другой. Для трансляции несколько секунд задержки незаметны: вы смотрите, а не разговариваете. Для преподавания задержка губительна. Когда преподаватель спрашивает «есть вопросы?» и ждёт, полсекунды задержки превращаются в неловкие паузы и перебивания. Когда ученик отвечает, а преподаватель реагирует с опозданием, диалог, на котором держится живое занятие, рассыпается.

Переведём числа в ощущения. WebRTC рассчитан на задержку от камеры до экрана (glass-to-glass) заметно меньше секунды – обычно несколько сотен миллисекунд при нормальном соединении, а рабочие системы через медиасервер нередко укладываются в 150 миллисекунд. Круговая задержка 200 миллисекунд ощущается как обычный разговор. Задержка в 2 секунды – как спутниковый звонок, где все постоянно перебивают друг друга. Ровно в этом разница между WebRTC и протоколами вещания вроде HLS (на нём работает большинство видео по запросу) с задержкой 5–30 секунд. Для интерактивных частей занятия – обсуждений, поднятых рук, опросов, совместного решения задач – задержка меньше секунды не приятный бонус, а условие, без которого занятие вообще не работает.

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

2. Браузер вместо установки – это больше учеников на занятии

Вторая причина – барьер входа. На занятие по WebRTC ученик заходит по ссылке. Не нужно скачивать приложение, одобрять плагин или писать заявку в IT-службу, чтобы что-то установили на служебный или учебный ноутбук. Звучит как мелочь, но в учебном продукте от этого зависит, сколько учеников придёт и дойдёт до конца курса. Каждый шаг установки между «нажал ссылку» и «я на занятии» отсеивает часть учеников: тех, у кого закрытый рабочий ноутбук, тех, кто зашёл с незнакомого устройства, и тех, кто просто сдаётся. WebRTC работает в браузере, а доступ к камере и микрофону запрашивает через стандартный интерфейс Media Capture and Streams (W3C, «Media Capture and Streams»), так что этот барьер исчезает полностью.

3. Встроенный канал данных обслуживает всё остальное

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

Как ученик подключается к занятию (и почему учебные сети этому мешают)

Чтобы понять подводные камни, хватит упрощённой картины того, как два браузера находят друг друга; детали оставим разделу Video Streaming.

Когда ученик заходит на занятие, его браузер пытается найти прямой путь к остальным участникам. Большинство домашних и мобильных сетей прячут устройства за роутером с помощью NAT (Network Address Translation), поэтому браузеру нужна помощь, чтобы узнать свой публичный адрес. Небольшой и дешёвый вспомогательный STUN-сервер (Session Traversal Utilities for NAT, IETF RFC 8489) сообщает браузеру, как его видит внешний мир, а механизм ICE (Interactive Connectivity Establishment, IETF RFC 8445) перебирает все возможные пути, пока один не сработает. Когда прямой путь найден, медиа идёт от браузера к браузеру или от браузера к серверу, STUN больше не нужен, а стоит всё это почти ничего.

Проблема – в сетях, которые не дают прямого пути. Многие школы, вузы, больницы и компании держат строгие файрволы, которые пропускают только обычный веб-трафик на портах 80 и 443. В таких сетях ICE не находит прямого маршрута, и единственный способ соединиться – ретранслировать каждый пакет аудио и видео через сервер, доступный обеим сторонам. Это TURN-сервер (Traversal Using Relays around NAT, IETF RFC 8656); обычно его настраивают на работу поверх TLS на порту 443, чтобы трафик выглядел как обычный защищённый веб-трафик и проходил через файрвол. TURN срабатывает всегда, поэтому служит страховкой. Но через него идёт каждый байт медиа, и именно здесь появляются счета.

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

Подводный камень 1: стоимость TURN-релея в учебных и корпоративных сетях

Эта ловушка подстерегает команды, которые тестировали только на домашнем Wi-Fi. В дружелюбной сети большая часть медиа идёт напрямую, и серверные расходы ничтожны. Но заметная доля реальных учеников – как раз те, кто сидит в сетях школ, кампусов и компаний, куда вы больше всего хотите продавать, – находится за файрволами, которые вынуждают использовать TURN-релей. Ретранслированное медиа оплачивается по облачным тарифам на исходящий трафик, а живое занятие передаёт много данных.

Посчитаем. Возьмём одного ученика, чьё медиа идёт через релей:

• Разумный поток живого занятия – около 1 мегабита в секунду на отдачу (камера ученика) и 1,5 мегабита в секунду на приём (преподаватель и несколько видимых одноклассников), то есть примерно 2,5 мегабита в секунду через релей.
• Занятие на 50 минут – это 3000 секунд. 2,5 мегабита/с × 3000 секунд = 7500 мегабит.
• Делим на 8, чтобы получить мегабайты: 7500 ÷ 8 = 937,5 мегабайт ≈ 0,94 ГБ ретранслированного медиа на одного ученика за одно занятие.

Теперь масштабируем. Представьте класс из 25 учеников в закрытой сети учебного заведения, где через релей идёт каждый:

• 25 учеников × 937,5 МБ ≈ 23,4 ГБ за одно занятие.
• Исходящий трафик в облаке стоит ориентировочно 7,7–10 ₽ за ГБ в 2026 году; модели тарификации у провайдеров сильно различаются, поэтому сверяйтесь с прайсом своего облака. При 8,5 ₽/ГБ: 23,4 ГБ × 8,5 ₽ = ≈ 199 ₽ за занятие.

Сумма кажется пустяковой, пока не умножить её на реальное расписание. Двести классов, пять дней в неделю, сорок недель в год – это 200 × 5 × 40 = 40 000 занятий. По 198,9 ₽ за каждое: 40 000 × 198,9 ₽ ≈ 8,0 млн ₽ в год только на релей-трафик, сверх всех прочих расходов. Вывод не в том, что WebRTC дорогой. Релей – переменная статья, которая растёт вместе с вашими худшими сетями, поэтому смоделируйте её до того, как называть цену контракта, и проектируйте систему так, чтобы прямые соединения работали везде, где возможно. Снизить этот счёт помогают меньшее разрешение видео для ретранслируемых участников, ограничение числа одновременно принимаемых потоков и собственные TURN-серверы в российских дата-центрах ближе к ученикам. В стране с одиннадцатью часовыми поясами последнее важно вдвойне: релей в одном столичном ЦОДе съедает у ученика из Владивостока заметную часть бюджета задержки.

Подводный камень 2: масштабирование от встречи к лекторию

Вторая ловушка – считать, что небольшое демо на WebRTC масштабируется линейно. Это не так, и причина в архитектуре.

Простейшая схема WebRTC соединяет всех со всеми напрямую – это mesh. Для четырёх человек такая схема годится, на тридцати она рушится: каждый браузер должен отправлять своё видео всем остальным и принимать видео от всех. Исходящего канала и процессора ноутбука перестаёт хватать где-то на 6–8 активных отправителях видео. Семинар на 30 человек, не говоря уже о лектории на 200 мест, на mesh не работает.

Решение – медиасервер. Selective Forwarding Unit (SFU) – сервер, которому каждый участник отправляет одну копию своего видео, а SFU пересылает нужные потоки нужным людям; ни одному браузеру не приходится отправлять видео больше одного раза. SFU спокойно справляется с семинаром на 30 человек, где говорить может каждый, и масштабируется до сотен зрителей, если камеры включены лишь у нескольких. Для настоящего лектория (один преподаватель и 500+ слушателей) добавляют односторонний слой трансляции, чаще всего low-latency HLS, который получает поток от SFU. Тогда несколько активных участников остаются на WebRTC, а молчаливая аудитория смотрит дешёвый и хорошо масштабируемый поток. Такой гибрид – WebRTC для взаимодействия плюс трансляция для охвата – стандартная схема для больших живых занятий.

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

SFU, simulcast (отправка нескольких вариантов качества, чтобы каждый зритель получал тот, что подходит его каналу) и мост к трансляции – темы уровня протокола, и они относятся к разделу Video Streaming. Учебная сторона решения разобрана в статье масштабирование живого класса: SFU, simulcast и лекция на 200 мест, внутреннее устройство – в статье simulcast, SVC и SFU. Для обучения вывод простой: топология зависит от размера класса и от того, сколько людей реально говорят, поэтому определитесь с ней до выбора инструмента.

Подводный камень 3: запись

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

Запись в браузере на компьютере преподавателя ломается предсказуемо: она пропадает при закрытии вкладки, не может надёжно захватить всех участников в большом классе и даёт один файл, который не проиндексирует ни одна учебная система. В рабочих системах запись идёт на сервере. Компонент записи подключается к сессии как молчаливый участник или забирает потоки прямо из SFU и пишет их в объектное хранилище. Затем отдельный конвейер обрезает запись, собирает раскладку с участниками, перекодирует результат в форматы каталога и публикует через сеть доставки контента (CDN) для просмотра по запросу. Ничто из этого не относится к живому звонку: это вторая система, которую нужно построить или купить. А поскольку на записи лица и голоса учеников, то есть их персональные данные, хранилище записей должно находиться в России (ч. 5 ст. 18 152-ФЗ).

Для учебного продукта запись – учебный материал, который должен попасть в историю обучения ученика. Подробные события просмотра фиксирует xAPI Video Profile – профиль поверх Experience API (xAPI), стандарта учебных данных. Он определяет структурированные утверждения вроде «played», «paused», «seeked» и «completed», так что просмотр записи занятия попадает в ту же аналитику, что и любое другое видео курса (ADL, xAPI Video Profile; Experience API 1.0.3). Как сессия WebRTC превращается в видео по запросу, разобрано в статьях запись живых занятий и постобработка для каталога и, на уровне протокола, запись WebRTC и мост к HLS; слой трекинга – в статье трекинг видео через xAPI Video Profile. Закладывайте конвейер записи как полноценную подсистему, а не как галочку.

Подводный камень 4: субтитры и соответствие требованиям

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

Чтобы субтитровать живое занятие на WebRTC, аудио передают в сервис распознавания речи в реальном времени и доставляют текст ученикам с минимальной задержкой. Этот конвейер затрагивает аудиоинженерию и модели ИИ, которые разбираются в других разделах. Голоса учеников – персональные данные, поэтому распознавание держите в российском контуре: Yandex SpeechKit (в том числе в гибридной поставке на своих серверах), SaluteSpeech или open-source-модели вроде Whisper на собственных GPU. О распознавании речи и раздаче субтитров – в статье живые субтитры и ASR на стороне SFU, об аудиоконвейере для него – в статье аудиоконвейер WebRTC от и до. Вывод для обучения: субтитры – требование, которое закладывают с самого начала, а не функция, которую прикручивают после вопроса заказчика.

Пара слов о безопасности, потому что заказчики об этом спрашивают. Медиа WebRTC шифруется по умолчанию: спецификация требует передавать аудио и видео поверх SRTP, а соединение защищать через DTLS, так что живое занятие защищено в канале связи без дополнительной работы (IETF RFC 8827, «WebRTC Security Architecture»; RFC 8826, «Security Considerations for WebRTC»). Подробности – в статье безопасность WebRTC: DTLS и SRTP. Шифрование в канале не снимает других требований: записи, журналы посещаемости и расшифровки, по которым можно опознать ученика, подпадают под 152-ФЗ, а образовательной организации ПП 1678 предписывает использовать ПО видеоконференцсвязи, созданное по законодательству РФ и (или) включённое в реестр российского ПО (п. 21).

WebRTC и альтернативы для живого обучения

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

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

Цифры: стоимость WebRTC в учебном продукте и выбор «создать или купить»

«Создать или купить» – финансовое решение в технической обёртке, поэтому честно разберём слои. Реальных путей три, и правильный ответ почти всегда – их сочетание.

Не создавайте сам медиадвижок WebRTC. Браузерный стек, SFU, simulcast, управление перегрузкой и TURN – многолетняя специализация, которую поддерживают выделенные инфраструктурные команды и open-source-проекты (mediasoup, Janus, LiveKit OSS, Jitsi). Писать всё это заново имеет смысл, только если инфраструктура реального времени и есть ваш продукт. Всем остальным движок достаётся готовым: либо управляемая платформа реального времени или SDK российской ВКС (Voximplant, TrueConf SDK, SaluteJazz SDK) с оплатой за минуту участника и за трафик, либо собственное развёртывание open-source SFU плюс TURN-серверы в российском облаке (Yandex Cloud, Cloud.ru, Selectel, VK Cloud) или на своих серверах.

Стройте поверх учебный слой. Роли, посещаемость как учебные данные, постоянные малые группы, доска, конвейер «запись – каталог», интеграция субтитров и мост к системе управления обучением (LMS) – вот чем продукт для живого обучения действительно выделяется и куда должен идти бюджет разработки. Оценка этого слоя расписана в статье виртуальный класс и в модели стоимости платформы обучения этого раздела.

Честно смоделируйте эксплуатационные расходы. Регулярный счёт определяют две переменные статьи: релей и трафик из подводного камня 1 (растут вместе с вашими худшими сетями) и конвейер записи и хранения из подводного камня 3. Управляемая платформа прячет их в цене за минуту; собственный SFU показывает их как облачные счета, которые нужно прогнозировать. В любом случае главная переменная – трафик, а главный риск – недооценить, сколько учеников окажется за релеем.

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

Частая ошибка: демо прошло, а пилот провалился

Самая дорогая ошибка в живом обучении – тестировать не в той сети. Команда собирает прототип на WebRTC, проверяет его на офисном Wi-Fi и домашнем интернете, видит чёткое видео с задержкой меньше секунды и решает, что сложная часть позади. Потом начинается пилот в колледже. Половина учеников сидит в сети учебного заведения, где закрыто всё, кроме порта 443, и каждый из них уходит на TURN-релей, который никто не нагружал и не закладывал в бюджет. На потоковую лекцию приходят 180 студентов, и прототип на mesh, отлично работавший с восемью разработчиками, не выдерживает. Преподаватель просит запись прошлой недели, а её нет: записывала вкладка браузера, и она упала на шестой минуте. А на приёмке заказчик возвращает работу, потому что в техническом задании были живые субтитры.

Каждый из этих провалов был предсказуем. Тестируйте в тех сетях, куда собираетесь продавать, – за закрытым файрволом учебного заведения или компании, а не только дома. Выбирайте топологию по реальным размерам классов, с первого дня считайте запись и субтитры подсистемами и закладывайте счёт за релей до подписания договора. Задайте на планёрке вопрос: «что будет в сети, где нужен TURN, на нашем самом большом реальном занятии, если кому-то понадобится запись с субтитрами?» Если вы не можете ответить на все четыре части вопроса, к пилоту вы не готовы.

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

Мы разрабатываем продукты для живого обучения на заказ, и под большинством из них работает WebRTC. Поэтому главный совет клиентам у нас тот же, что в этой статье: не переписывайте медиадвижок, берите его у проверенной инфраструктуры или из open source и вкладывайте бюджет в учебный слой, который делает класс классом. Подводные камни из статьи для нас не теория: стоимость TURN-релея в закрытых сетях, схема масштабирования лектория и конвейер «запись – каталог» – уроки, полученные на собственных проектах в видеоконференциях, стриминге, e-learning и телемедицине с 2005 года. Когда к нам приходит команда из сферы обучения, первый разговор обычно о том, какой способ доставки нужен каждому типу занятий и во сколько реально обойдётся релей-трафик. Если решить эти два вопроса рано, продукт для живого обучения останется доступным по цене и при росте.

Главное

• WebRTC – стандартный движок живого обучения: задержка меньше секунды, вход из браузера без установки, встроенный канал данных.
• Задержка – главная причина, по которой в интерактиве WebRTC выигрывает у протоколов вещания: занятие – это разговор, а не трансляция.
• Части учеников в закрытых сетях всегда нужен TURN-релей; посчитайте счёт за трафик до того, как назвать цену, и размещайте TURN ближе к ученикам.
• Mesh ломается после ~6 отправителей видео; для семинаров нужен SFU, для лекториев – гибрид со слоем трансляции.
• Запись и живые субтитры – подсистемы, а не галочки; проектируйте обе с первого дня (WCAG 2.1 SC 1.2.4, ГОСТ Р 52872-2019), а записи и распознавание речи держите в России.
• Не создавайте медиадвижок: берите его готовым, а разработку тратьте на учебный слой.

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

• Масштабирование живого класса: SFU, simulcast и лекция на 200 мест
• Запись живых занятий и постобработка для каталога
• WebRTC без зауми (раздел Video Streaming)