Несмотря на то, что WebRTC —это протокол, разработанный для выполнения одной задачи - установления мультимедийных соединений с низким пингом и высоким уровнем безопасности, одной из его лучших особенностей является гибкость. Даже если перед вами стоит довольно четко сформулированная задача создания приложения для видеоконференций, возможности открыты.
Вы можете полностью перейти на p2p, развернуть бэкенд медиасервера (их существует довольно много) или комбинировать эти подходы по своему вкусу. Вы можете выбрать желаемые функции и найти множество способов их реализации. Наконец, вы можете свободно выбирать между надежным бэкендом или масштабируемой сеткой медиасерверов, созданной по одному из многочисленных шаблонов.
Со всеми этими свободами в вашем распоряжении, выбор лучшего варианта может быть — и будет — непростым. Позвольте немного прояснить это для вас:
___
Представим, что сейчас Новый год. Или выберите любое другое массовое мероприятие по вручению подарков. У вас довольно много друзей, разбросанных по всему городу, но все слишком заняты, чтобы устраивать вечеринку с обменом подарками. Поэтому вы и ваши друзья решили, что каждый получит свои подарки, когда заглянет друг к другу.
P2P
Когда вы хотите обменяться чем-то со своими приятелями, неважно, рождественский ли это подарок или прямая видеотрансляция, очевидным способом является одноранговый обмен. Каждый из ваших друзей приходит к вам в гости и получает свою коробку, а затем вы посещаете всех в ответ. Просто и легко.
Для чата WebRTC это означает, что все участники разговора напрямую связаны друг с другом, а хост служит лишь местом встречи (или адресной книгой, в нашем рождественском примере).
Эта схема отлично работает, пока
- ваша группа довольно маленькая
- все физически в состоянии дотянуться друг до друга
Каждый подарок из нашего примера требует определенного времени и усилий: как минимум, вам нужно доехать до места (или подождать, пока кто-то приедет к вам), открыть дверь, отдать коробку и поздравить с Рождеством.
- если в группе 4 человека, то каждому из вас нужно время, чтобы обработать 6 подарков — 3 отдать, 3 взять.
- когда вас 5 человек, необходимо позаботиться о 8 подарках на человека.
- когда ваша группа увеличится до 6 человек, в вашем рождественском списке дел будет уже 10 подарков.
В какой-то момент подарков будет много: количество входящих и исходящих подарков вырастет чересчур сильно для комфортной работы.
То же самое касается видеозвонков: каждый отдельный поток P2P должен быть закодирован и отправлен или декодирован и отображен в реальном времени — каждая операция требует доли производительности вашей системы, пропускной способности сети и емкости батареи. Эта доля может быть вполне разумной для видео высокого качества: если конференция 2 на 2 или даже 5 на 5 будет нормально работать на любом относительно современном устройстве, то 10 на 10 одноранговых FullHD звонков съедят плюс-минус 50 Мбит/с пропускной способности и создадут достаточно большую нагрузку даже на процессор среднего и высокого уровня.
Теперь о физической возможности дотянуться. Представьте, что один из ваших друзей недавно переехал в элитный закрытый поселок. Они могут свободно въезжать и выезжать — так что они доберутся до вашей парадной двери за своими подарками, но ваши шансы добраться до их дома за своим подарком невелики.
Если говорить о WebRTC, то речь идет о корпоративных сетях с NAT и\or VPN. Вы можете связаться с большинством узлов внутри сети, но при этом останетесь недосягаемы снаружи. В любом случае, ваши собеседники могут не видеть вас, или наоборот. Или вовсе никто никого не увидит.
И наконец — если вы все решите сложить подарки в кучу для шикарной фотографии в Instagram, каждому придется самому создавать и коробки и фотографию: подарки находятся дома у получателей.
WebRTC: peer-to-peer означает отсутствие записи (или любых других функций, используемых один раз за звонок) на стороне сервера вообще.
P2P — примеры
Google Meet и безопасные мобильные приложения для видеозвонков без каких-либо функций на стороне сервера, таких как запись видео.
Именно здесь на помощь приходят медиасерверы.
Медиасервер
Вернемся к воображаемому Рождеству. У вас огромная компания друзей, и вы решили, что весь праздничный сезон проведете в ожидании кого-то или в поездке куда-то. Чтобы сэкономить время, вы платите местной кофейне, чтобы она служила узлом распределения подарков.
С этого момента всем членам вашей группы, чтобы оставить или получить подарки, нужно добраться до одного места — кофейни.
Именно так работают медиасерверы WebRTC. Они принимают мультимедийные потоки вызывающих сторон и доставляют их всем в конференц-зале.
Некоторое время назад медиасерверы WebRTC были двух видов: SFU (устройство селективной переадресации) и MCU (устройство многоточечной конференц-связи\\\ многоточечного управления). На сегодняшний день большинство коммерческих решений и решений с открытым исходным кодом предлагают функции как SFU, так и MCU. Поэтому оба термина теперь описывают возможности и модели использования, а не типы продуктов.
Что это такое?
SFU / Selective Forwarding Unit
Бармен в кофейне отслеживает все подарки, поступающие в заведение, и звонит их получателям, если их ждет что-то новое. Получив такой звонок, вы заходите в магазин, выпиваете "чино", получаете свою коробку и возвращаетесь домой.
Плохая новость: бармен звонит вам, чтобы сообщить про один подарок за раз. Так что, если новых подарков три, вам придется отправиться в путь три раза подряд. Если их двадцать... вы, наверное, поняли, о чем идет речь. Как вариант, вы можете посещать это место с определенной периодичностью, самостоятельно проверяя новые поступления.
Кроме того, по мере развития вашего подарочного марафона ухудшается качество кофе: чем больше людей присоединяется, тем больше времени и усилий бармен тратит на раздачу подарков вместо кофеина. Помните: один подарок — один звонок из магазина.
Медиасервер, работающий как устройство выборочной переадресации, позволяет участникам звонка отправлять свои видеопотоки только один раз — на сам сервер. Бэкенд клонирует этот поток и доставляет его каждому участнику звонка.
Благодаря SFU каждый клиент потребляет почти в два раза меньше пропускной способности, процессорной мощности и заряда батареи, чем при одноранговом вызове:
- для звонка на 4 пользователей: 1 исходящий поток, 3 входящих (вместо 3 входящих, 3 исходящих для p2p).
- для звонка на 5 пользователей: 1 исходящий поток, 4 входящих (было бы 4 и 4 в p2p)
- для 10-пользовательского вызова: 1 исходящий поток, 9 входящих (9 входящих, 9 исходящих — p2p).
Недостаток проявляется при соотношении пользователей на звонок, близком к 20. "Селективный" в SFU означает, что это устройство не пересылает медиа массово — оно доставляет медиа по каждому запросу. И, поскольку WebRTC всегда является протоколом p2p, даже если есть сервер, каждый одновременный поток является отдельным соединением. Так, для видеовстречи 10 пользователей сервер должен поддерживать 10 входящих ("принимающих видео") и 90 исходящих соединений, каждое из которых требует вычислительной мощности, пропускной способности и, в конечном итоге, денег. Но...
SFU — масштабируемость
После того как владелец кофейни начнет сердиться на интенсивность обмена подарками, вы можете сделать следующий шаг и заплатить еще нескольким магазинам по соседству, чтобы они присоединились к обмену.
В зависимости от загруженности конкретного магазина, некоторые дарители или получатели подарков могут быть направлены в другой, менее переполненный магазин. Сеть может разрастаться практически до бесконечности, поскольку каждый магазин может либо направить посылку адресату, либо в альтернативное место получения.
Правила пересылки очень гибкие. Например, Johnson's coffee хранит подарки для ваших друзей с фамилиями, начинающимися с A — F, Smartducks занимается посылками для жителей центра города, а Randy's Cappuccino перешлет ваше поздравление с Рождеством всем, кто отправил свой первый подарок с прошлого четверга.
Подход "один поток - одно соединение", предлагаемый паттерном SFU, имеет особенность, которая перекрывает почти все его минусы. Это свойство — масштабируемость.
Точно так же, как вы пересылаете поток пользователя другому участнику, вы можете переслать его на другой сервер. Учитывая это, архитектура back end может быть настроена на рост и сокращение в зависимости от количества пользователей, конференций и интенсивности трафика.
Например, если слишком много клиентов запрашивают определенный поток с одного узла, вы можете создать новый, клонировать поток там и распространять его с нового незанятого места.
Или, в случае, если вы ожидаете ажиотажа на массивной конференции (например, около 20-30 пользователей потокового вещания и сотни подписчиков только для просмотра), вы можете назначить две отдельные группы медиасерверов, одна из которых будет обрабатывать входящие потоки, а другая — доставлять их подписчикам. В этом случае любые скачки нагрузки на стороне просмотра будут иметь нулевой эффект на прием видео, и наоборот.
SFU — примеры
Skype и почти все другие мобильные мессенджеры с возможностью проведения видеоконференций и записи видеозвонков используют схему SFU на бэкенде.
Получение видео от других пользователей в виде отдельных потоков дает возможность адаптивного UX, позволяет регулировать качество каждого потока и повышает общую стабильность звонков в нестабильной среде сотовой сети.
MCU / Multipoint Conference Unit
Дарить подарки — значит заводить друзей, верно? Теперь почти каждый в городе — ваш приятель и участвует в обмене подарками. В кофейне, где происходит обмен, возникает отличная идея: почему бы нам не сложить все подарки для конкретного человека в огромный ящик с его именем. Более того, теперь происходит некое праздничное волшебство: как только появляются новые подарки для кого-то, они сами собой появляются в соответствующих ящиках.
Тем не менее, рождественское волшебство кажется более сложной работой, чем приготовление кофе: возможно, им даже придется нанять больше людей для наложения заклинаний на ящики с подарками. И даже с дополнительными волшебниками на службе, нет никаких шансов, что вы сможете изменить порядок содержимого ящиков так, чтобы ваша вторая половинка увидела ваш подарок первой — все получат одно и то же.
Что ж, некоторые из функций, связанных с MCU, действительно напрашиваются на каламбур, связанный с аббревиатурой, общей с Киновселенной Marvel (Marvel Cinematic Universe). Определенно, здесь замешано что-то чудесное. Медиасервер в роли MCU должен держать только 20 соединений для конференции из 10 пользователей, вместо 100 соединений SFU — один вход, один выход для каждого пользователя. Как это происходит? Он объединяет все видео и аудио, которые должен получить пользователь, в один поток и доставляет его конкретному клиенту. Именно так делаются конференции Zoom: с MCU даже компьютер низшего уровня способен обслуживать живую конференцию на 100 пользователей.
Однако за волшебство приходится платить. Компоновка нескольких видео- и аудиопотоков в реальном времени гораздо больше снижает производительность, чем любой шаблон переадресации. Еще больше, если вам нужно каким-то образом исключить собственный голос и изображение из объединенной сетки, которую они получают — для каждого из пользователей.
Другой недостаток, хотя и устранимый, заключается в том, что объединенная сетка одинакова для всех, кто получает видео — независимо от разрешения экрана, соотношения сторон или чего-либо еще. Если есть необходимость иметь разные макеты для мобильных и настольных устройств — вам придется компоновать видео дважды.
MCU — масштабируемость
По сравнению с SFU, модель MCU имеет значительно меньший потенциал масштабирования: составление видео с сабсекундными задержками не позволяет "на лету" перераспределять нагрузку для конкретной конференции. Тем не менее, в виртуализированной среде можно автозапускать дополнительные серверные экземпляры для новых вызовов или, для еще большей эффективности, назначить дополнительный блок SFU для перераспределения композитного видео.
MCU — примеры
Zoom и большинство его альтернатив для массовых видеоконференций работают на базе MCU-подобных бэкендов. В противном случае видеозвонки webRTC для 25+ участников были бы доступны только для устройств класса high-end.
Многабукаф: что и зачем я использую?
~2-4 пользователя на один звонок — P2P
Плюсы:
- низкие затраты на издержки
- легкое масштабирование
- самый короткий TTM
- потенциально самая безопасная
Минусы:
- для звонков 5+ пользователей — качество может ухудшаться на слабых устройствах
- высокое использование полосы пропускания (может быть критичным для мобильных пользователей)
- нет записи на стороне сервера, видеоаналитики и других расширенных функций.
Приложения:
- частные \ групповые звонки
- видеоассистенты и продажи
5-20 пользователей на звонок — SFU
Плюсы:
- легко масштабируется при одновременном увеличении количества звонков
- сохраняет гибкость UX, обеспечивая функции на стороне сервера
- может иметь резервирование узлов по дизайну: таким образом, наиболее устойчив к спешке
Минусы:
- довольно интенсивный трафик и высокая производительность на стороне клиента
- может потребоваться композитный MCU-подобный сервис для записи звонков.
Примеры использования:
- электронное обучение: семинары и виртуальные классы
- корпоративные коммуникации: совещания и пресс-центры
20+ пользователей на звонок — MCU \ MCU + SFU
Плюсы:
- наименьшая нагрузка на устройства на стороне клиента
- возможность обслуживания самых больших аудиторий
- легко записывается (на стороне сервера / на стороне клиента)
Минусы:
- наибольший простой и эксплуатационные расходы
- пропускная способность одного вызова ограничена производительностью конкретного сервера
- наименее настраиваемый макет
Примеры использования:
- потоковая трансляция крупных мероприятий
- социальные сети
- онлайн-медиа
Комментарии