Обоснование одноранговой видеоконференции, даже если она не масштабируется с количеством участников

Похоже, что не так много приложений для видеоконференций используют одноранговые (P2P) архитектуры, и причина этого проста — они не масштабируются. Для некоторых приложений необходима масштабируемость, и они не могут быть построены с использованием таких соединений. Однако мы в Яхт.Чат считаем, что у нас есть веские причины попытаться заставить их работать. Вот 7 с половиной из них.

Архитектуры видеоконференцсвязи

Давайте начнем с объяснения того, как работает видеоконференция P2P и каковы ее альтернативы. Существует три способа создания приложения для видеоконференций: оно использует сеть P2P, блок выборочной пересылки (SFU) или блок управления многоточечной связью (MCU). В этом разделе я не буду вдаваться в какие-либо технические детали, но давайте кратко обсудим их, чтобы все были в курсе.

Пиринговый

Как можно себе представить, P2P означает, что все подключены ко всем, то есть каждый участник отправляет свой видеопоток (и свой аудиопоток) всем и взамен получает видеопоток от всех. Инициализация соединения между каждой парой одноранговых узлов называется процессом сигнализации. Только на этом этапе инициализации задействован центральный сервер, сервер сигнализации. Каждый одноранговый узел сообщает сигнальному серверу, как к нему можно подключиться, и сигнальный сервер пересылает эту информацию всем другим одноранговым узлам. Одноранговые узлы используют эту информацию для установления прямого соединения друг с другом, которое затем используется для передачи видеопотока. Глядя на изображение ниже, мы видим, что даже сеть P2P с 6 узлами уже имеет много подключений, поэтому становится ясно, почему P2P не масштабируется с количеством участников конференции.

Блок выборочной пересылки

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

Многоточечный блок управления

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

7 с половиной причин для одноранговой архитектуры

Хорошо, звучит так, будто MCU — лучший выбор? Ну, это не так просто. Есть веские причины для использования архитектуры P2P вместо SFU или MCU. Давайте посмотрим на них.

1. Самый простой способ начать

Настроить приложение для P2P-конференций проще, чем иметь дело с центральным сервером, который необходимо настроить. Теперь вы можете возразить, что мы только что узнали, что все еще задействован центральный сервер, сигнальный сервер. Хотя это правильно, сигнальный сервер легко настроить, поскольку он только пересылает информацию от одного участника к другому. Наш первый прототип видеоконференцсвязи на Яхте.Чат был запущен всего за несколько дней, что, конечно, было бы невозможно, если бы нам нужно было придумать, как заставить работать SFU или MCU. Выбор архитектуры P2P для нас означал более быстрое создание MVP и поиск продукта, подходящего для рынка.

2. Простое масштабирование одновременных видеоконференций

Хотя приложения P2P не масштабируются в зависимости от количества участников конференции, ваше приложение P2P легко масштабируется для множества отдельных конференций. Это сводится к тому, что не все пользовательские потоки проходят через ваш сервер. С другой стороны, сервер, на котором работает SFU или MCU, должен управлять многими потоками одновременно. Вам придется масштабировать свою инфраструктуру пропорционально количеству конференций, которые вы хотите провести. Использование архитектуры P2P меняет это в корне. На самом деле ваша инфраструктура (сервер сигнализации) будет использоваться только во время инициализации, когда она пересылает несколько килобайт данных. Вам не придется беспокоиться о масштабировании вашей инфраструктуры в течение длительного времени.

3. Разверните один раз, чтобы обслужить всех

Часть создания приложения для конференц-связи заключается в том, чтобы решить, на какой рынок/страну ориентироваться в первую очередь. Вы можете подумать, что местоположение вашего сервера подразумевает рынок, который вы можете обслуживать, особенно когда речь идет о чем-то чувствительном к задержке, например о видеоконференции. Но опять же, видеопотоки не отправляются на ваш сервер, а идут напрямую между всеми участниками конференции. Расположение вашего сервера не имеет большого значения. Допустим, вы развернули свой сигнальный сервер в Европе, пользователи в США будут иметь такой же опыт работы с вашим приложением, как и пользователи в Азии или Европе.

4. Экономическая эффективность

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

5. Качество видео

Отсутствие того, что видеопоток сначала направляется на центральный сервер, а затем на его приемник, обеспечивает отличные возможности видеоконференций. Прямой путь всегда будет быстрее и, следовательно, с меньшей задержкой. Кроме того, вы можете позволить участникам видеоконференции делиться своими видео (или, возможно, своим экраном) с высоким разрешением и высокой частотой кадров, так как вам не нужно заботиться о потенциальной сетевой нагрузке на ваш сервер.

6. Конфиденциальность

Чтобы люди могли использовать ваше приложение для конференц-связи, они должны иметь определенный уровень доверия к вам, особенно если вы еще не заслужили доверия. Они, безусловно, хотят убедиться, что вы сохраняете их конфиденциальность и не продаете содержание их разговоров, например, в рекламных целях. Основным преимуществом P2P-соединения является то, что оно может быть зашифровано сквозным шифрованием. На самом деле так и должно быть, если вы используете WebRTC. Во время процесса сигнализации, инициализации соединения, пара одноранговых узлов обменивается своими ключами, гарантируя, что только предполагаемый получатель может расшифровать видеопоток.

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

7. Улучшение устройств и сетей

Видеоконференции P2P не масштабируются, потому что вычисления и сетевой трафик перемещаются с центрального сервера на устройство каждого участника. Вопрос о том, сколько участников может вместиться в конференцию, — это вопрос о том, сколько вычислительных ресурсов их устройств и какой трафик может выдержать их сеть. Оба показателя со временем явно улучшаются. Сегодня P2P-конференции более осуществимы, чем когда-либо, и эта тенденция сохранится. Это, конечно, не изменит кардинально способ масштабирования P2P-конференций, но наличие еще 1-2 участников уже может иметь значение.

7.5 Окружающая среда

Некоторые поставщики приложений P2P даже заявляют, что подходы P2P несколько более экологичны и энергоэффективны. Что ж, вы, как провайдер, безусловно, сэкономите энергию, перенеся вычисления на устройства ваших пользователей. Сомнительно, действительно ли чистые энергозатраты на конференцию ниже. Если бы кто-то пытался обосновать «экологичность» P2P-конференций, это могло бы быть так: архитектура P2P делает видеоконференции доступными для большего числа людей, облегчая им работу из дома и экономя на поездках на работу.

Заключение

Плохая масштабируемость P2P-конференций — действительно единственный аргумент против их использования, но, конечно, тоже немаловажный. Вы должны спросить себя, нужно ли вам, чтобы в ваших конференциях одновременно участвовало более 5–6 участников. Если нет, вам могут подойти P2P-конференции.

Want to Know More About the Author?
We at Yacht.Chat went with a P2P architecture because it was just easier and faster to get started, not very deliberately we have to admit. But Yacht.Chat is not trying to replace big static meetings with a lot of participants and, therefore, it might work for us (Have a look here to see what we are doing).