Какой тип архитектуры выбрать для видеочата: P2P, MCU или SFU?

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

Вы можете полностью перейти на p2p, развернуть бэкенд медиасервера (их существует довольно много) или комбинировать эти подходы по своему усмотрению. Выбирайте нужные функции и находите способы их реализации. Наконец, вы можете выбирать между надёжным бэкендом или масштабируемой сеткой медиасерверов, построенной по одному из многочисленных шаблонов.

Со всеми этими возможностями выбор наилучшего варианта может оказаться непростой задачей. Позвольте немного прояснить ситуацию для вас:

___

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

P2P

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

Для чата WebRTC это означает, что все участники разговора соединены напрямую, а хост выступает лишь как точка встречи (или адресная книга — в нашем рождественском примере).

Эта схема отлично работает, пока

• ваша группа довольно маленькая
• все физически могут дотянуться друг до друга

Каждый подарок из нашего примера требует определённого времени и усилий: как минимум, нужно доехать до места (или подождать, пока кто-то приедет к вам), открыть дверь, передать коробку и поздравить с Рождеством.

• если в группе 4 человека, то каждому из вас нужно время, чтобы раздать и получить по 3 подарка — всего по 6 подарков на человека
• когда вас пятеро, нужно позаботиться о восьми подарках на человека.
• когда ваша группа вырастет до 6 человек, в вашем рождественском списке дел будет уже 10 подарков.

В какой-то момент подарков станет слишком много: количество входящих и исходящих подарков вырастет настолько, что станет неудобно работать.

То же самое касается видеозвонков: каждый отдельный P2P-поток нужно закодировать и отправить или декодировать и отобразить в реальном времени — каждая операция требует части производительности системы, пропускной способности сети и заряда батареи. Эта нагрузка может быть вполне приемлемой для видео высокого качества: если видеоконференция 2 на 2 или даже 5 на 5 работает нормально на любом относительно современном устройстве, то 10 на 10 одноранговых FullHD-звонков потребуют около 50 Мбит/с пропускной способности и создадут значительную нагрузку даже на процессоры среднего и высокого класса.

Теперь о физической возможности добраться. Представьте, что один из ваших друзей недавно переехал в элитный закрытый посёлок. Он может свободно въезжать и выезжать — так что до вашей парадной двери доберётся без проблем, чтобы забрать подарки. А вот вам до его дома добраться будет непросто.

Если говорить о WebRTC, то речь идёт о корпоративных сетях с NAT и/или VPN. Вы можете подключиться к большинству узлов внутри сети, но при этом оставаться недоступными снаружи. В любом случае, ваши собеседники могут вас не видеть — или, наоборот, вы можете не видеть их. А может быть, вообще никто никого не увидит.

И наконец — если вы решите сложить подарки в кучу для красивой фотографии в Instagram, каждому придётся самому делать и коробки, и фото: подарки находятся дома у получателей.

WebRTC: peer-to-peer означает, что на стороне сервера вообще не происходит записи (или любых других одноразовых действий за звонок).

P2P — примеры

Google Meet и безопасные мобильные приложения для видеозвонков, не использующие серверные функции, такие как запись видео.

Именно здесь на помощь приходят медиасерверы.

Медиасервер

Вернёмся к воображаемому Рождеству. У вас большая компания друзей, и вы решили провести весь праздничный сезон в ожидании кого-то или в поездке. Чтобы сэкономить время, вы платите местной кофейне, чтобы она служила узлом распределения подарков.

С этого момента всем членам вашей группы, чтобы оставить или получить подарки, нужно прийти в одну точку — кофейню.

Именно так работают медиасерверы WebRTC. Они принимают мультимедийные потоки от участников и передают их всем в конференц-зале.

Некоторое время назад медиасерверы WebRTC делились на два типа: SFU (устройство селективной переадресации) и MCU (устройство многоточечной конференц-связи). Сегодня большинство коммерческих и open-source решений поддерживают функции и SFU, и MCU. Поэтому сейчас эти термины описывают возможности и модели использования, а не конкретные типы продуктов.

Что это такое?

SFU / Selective Forwarding Unit

Бармен в кофейне следит за всеми подарками, которые приходят в заведение, и звонит тем, кто должен их получить. Услышав звонок, вы заходите в магазин, пьёте «чино», забираете коробку и возвращаетесь домой.

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

Кроме того, по мере развития вашего подарочного марафона качество кофе ухудшается: чем больше людей присоединяется, тем больше времени и сил бариста тратит на раздачу подарков, а не на приготовление кофе. Помните: один подарок — один звонок из магазина.

Медиасервер, работающий как устройство выборочной переадресации, позволяет участникам звонка отправлять свои видеопотоки только один раз — на сам сервер. Бэкенд клонирует этот поток и раздаёт его каждому участнику звонка.

Благодаря SFU каждый клиент использует почти вдвое меньше пропускной способности, процессорной мощности и заряда батареи, чем при одноранговом вызове:

• для звонка на 4 пользователей: 1 исходящий поток, 3 входящих (вместо 3 входящих и 3 исходящих при p2p).
• для звонка на 5 пользователей: 1 исходящий поток, 4 входящих (в p2p было бы 4 и 4)
• для 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.

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

MCU / Multipoint Conference Unit

Дарить подарки — значит заводить друзей, верно? Теперь почти каждый в городе — ваш знакомый и участвует в обмене подарками. В кофейне, где это происходит, возникает отличная идея: почему бы не собрать все подарки для одного человека в большой ящик с его именем? Более того, теперь происходит настоящее праздничное волшебство: как только появляются новые подарки для кого-то, они сами попадают в нужные ящики.

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

Что ж, некоторые функции MCU действительно вызывают ассоциации с Marvel Cinematic Universe — аббревиатура-то совпадает. И тут действительно что-то волшебное происходит. Медиасервер в режиме MCU обслуживает конференцию из 10 участников всего 20 соединениями, а не 100, как в SFU, где каждому пользователю выделяется отдельный вход и выход. Как это работает? Он объединяет все видео- и аудиопотоки, которые должен получить конкретный участник, в один и отправляет его клиенту. Именно так устроены конференции в Zoom: даже слабый компьютер с MCU может поддерживать живую конференцию на 100 человек.

Однако за волшебство приходится платить. Компоновка нескольких видео- и аудиопотоков в реальном времени гораздо сильнее снижает производительность, чем любой шаблон переадресации. Особенно если нужно исключить свой голос и изображение из общей сетки — для каждого пользователя отдельно.

Другой недостаток, хотя и устранимый, заключается в том, что объединённая сетка одинакова для всех — независимо от разрешения экрана, соотношения сторон или других параметров. Если нужны разные макеты для мобильных и настольных устройств, придётся компоновать видео дважды.

MCU — масштабируемость

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

MCU — примеры

Zoom и большинство его альтернатив для массовых видеоконференций используют бэкенды, похожие на MCU. В противном случае видеозвонки на базе WebRTC для 25+ участников были бы доступны только на устройствах топового класса.

Многабукаф: что и зачем я использую?

2–4 пользователя на один звонок — P2P

Плюсы:

• низкие издержки
• легкое масштабирование
• самый короткий TTM
• потенциально самая безопасная

Минусы:

• для звонков с 5 и более участниками — качество может ухудшаться на слабых устройствах
• высокое использование полосы пропускания (может быть критичным для мобильных пользователей)
• нет записи на стороне сервера, видеоаналитики и других расширенных функций.

Приложения:

• частные и групповые звонки
• видеоассистенты и продажи

5–20 пользователей на звонок — SFU

Плюсы:

• легко масштабируется при росте числа одновременных звонков
• сохраняет гибкость UX, реализуя функции на стороне сервера
• может иметь резервирование узлов по дизайну: таким образом, он наиболее устойчив к сбоям

Минусы:

• довольно интенсивный трафик и высокая производительность на стороне клиента
• может потребоваться композитный MCU-подобный сервис для записи звонков.

Примеры использования:

• электронное обучение: семинары и виртуальные классы
• корпоративные коммуникации: совещания и пресс-центры

20+ пользователей на один звонок — MCU или MCU + SFU

Плюсы:

• наименьшая нагрузка на клиентские устройства
• возможность обслуживания самых больших аудиторий
• легко записывается (на стороне сервера / на стороне клиента)

Минусы:

• наибольшие простые и эксплуатационные расходы
• пропускная способность одного вызова ограничена производительностью конкретного сервера
• наименее настраиваемый макет

Примеры использования:

• потоковая трансляция крупных мероприятий
• социальные сети
• онлайн-медиа

‍