Прикладной WebRTC #

Теперь, когда вы знаете, как работает WebRTC, пришло время строить с его помощью! Эта глава исследует, что люди создают с помощью WebRTC, и как они это делают. Вы узнаете все интересные вещи, происходящие с WebRTC. Мощь WebRTC дается ценой. Создание производственных сервисов WebRTC - это сложная задача. Эта глава попытается объяснить эти сложности, прежде чем вы с ними столкнетесь.

По случаям использования #

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

Видеоконференции #

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

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

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

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

Broadcasting #

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

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

WebRTC дает разработчикам больший контроль над компромиссом между задержкой и качеством. Если важнее, чтобы задержка никогда не превышала определенного порога, и вы готовы терпеть некоторые артефакты декодирования, вы можете настроить зрителя воспроизводить медиа сразу после его поступления. С другими протоколами, работающими поверх TCP, это не так просто. В браузере вы можете запросить данные, и все.

Удаленный доступ #

Удаленный доступ - это когда вы удаленно получаете доступ к другому компьютеру через WebRTC. Вы можете иметь полный контроль над удаленным хостом или, возможно, только над одним приложением. Это отлично подходит для выполнения вычислительно затратных задач, когда локальное оборудование не справляется. Например, для запуска новой видеоигры или программы САПР. WebRTC смог революционизировать это пространство тремя способами.

WebRTC можно использовать для удаленного доступа к хосту, который не имеет глобальной маршрутизации. Благодаря обходу NAT вы можете получить доступ к компьютеру, доступному только через STUN. Это отлично для безопасности и конфиденциальности. Вашим пользователям не нужно направлять видео через входной поток или “jump box”. Обход NAT также облегчает развертывание. Вам не нужно беспокоиться о переадресации портов или настройке статического IP заранее.

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

Доступность WebRTC в браузере стала огромным улучшением качества жизни. Вам не нужно загружать проприетарный клиент для начала сеанса. Все больше клиентов поставляются с встроенным WebRTC, smart TV теперь получают полноценные веб-браузеры.

Обмен файлами и обход цензуры #

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

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

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

Интернет вещей #

Интернет вещей (IoT) охватывает несколько различных вариантов использования. Для многих это означает сетевые подключенные камеры безопасности. Используя WebRTC, вы можете транслировать видео другому WebRTC-пиру, например, на телефон или в браузер. Другой вариант использования - подключение устройств и обмен данными с датчиков. Вы можете иметь два устройства в вашей локальной сети, обменивающиеся данными о климате, шуме или освещении.

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

Совместимость - еще одно преимущество для пространства IoT. WebRTC доступен на многих языках: C#, C++, C, Go, Java, Python, Rust и TypeScript. Это означает, что вы можете использовать язык, который лучше всего подходит вам. Вам также не нужно обращаться к проприетарным протоколам или форматам, чтобы подключить своих клиентов.

Мостовая передача медиа-протоколов #

У вас есть существующее оборудование и программное обеспечение, производящее видео, но вы пока не можете его обновить. Ожидание от пользователей загрузки проприетарного клиента для просмотра видео раздражает. Ответ - запустить WebRTC-мост. Мост переводит между двумя протоколами, чтобы пользователи могли использовать браузер с вашей устаревшей настройкой.

Многие форматы, с которыми разработчики создают мосты, используют те же протоколы, что и WebRTC. SIP часто предоставляется через WebRTC и позволяет пользователям совершать телефонные звонки из браузера. RTSP используется во многих устаревших камерах безопасности. Они оба используют одни и те же базовые протоколы (RTP и SDP), поэтому создание моста вычислительно недорого. Мост просто должен добавлять или удалять специфические для WebRTC вещи.

Мостовая передача протоколов данных #

Веб-браузер может работать только с ограниченным набором протоколов. Вы можете использовать HTTP, WebSockets, WebRTC и QUIC. Если вы хотите подключиться к чему-либо еще, вам нужен протокольный мост. Протокольный мост - это сервер, который преобразует внешний трафик в то, что может получить браузер. Популярный пример - использование SSH из браузера для доступа к серверу. Каналы данных WebRTC имеют два преимущества перед конкурентами.

Каналы данных WebRTC позволяют ненадежную и неупорядоченную доставку. В случаях, когда критична низкая задержка, это необходимо. Вы не хотите, чтобы новые данные блокировались старыми - это известно как блокировка головы очереди. Представьте, что вы играете в многопользовательский шутер от первого лица. Действительно ли вам важно, где был игрок две секунды назад? Если эти данные не пришли вовремя, нет смысла продолжать пытаться их отправлять. Ненадежная и неупорядоченная доставка позволяет использовать данные сразу после их поступления.

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

Телеоперация #

Телеоперация - это акт удаленного управления устройством через каналы данных WebRTC и отправки видео через RTP. Сегодня разработчики удаленно управляют автомобилями через WebRTC! Это используется для управления роботами на строительных площадках и доставки посылок. Использование WebRTC для этих задач имеет смысл по двум причинам.

Повсеместность WebRTC облегчает пользователям управление. Пользователю нужен только веб-браузер и устройство ввода. Браузеры даже поддерживают ввод с джойстиков и геймпадов. WebRTC полностью устраняет необходимость установки дополнительного клиента на устройство пользователя.

Распределенная CDN #

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

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

Топологии WebRTC #

WebRTC - это протокол для подключения двух агентов, так как же разработчики подключают сотни людей одновременно? Существует несколько различных способов сделать это, и у каждого есть свои плюсы и минусы. Эти решения в основном делятся на две категории: одноранговые (Peer-to-Peer) или клиент-серверные. Гибкость WebRTC позволяет нам создавать и те, и другие.

Один-к-Одному #

Один-к-Одному - это первый тип подключения, который вы будете использовать с WebRTC. Вы напрямую подключаете два WebRTC-агента, и они могут отправлять двунаправленные медиа и данные. Подключение выглядит так.

Полная сетка #

Полная сетка - это решение, если вы хотите создать конференц-связь или многопользовательскую игру. В этой топологии каждый пользователь устанавливает прямое подключение с каждым другим пользователем. Это позволяет вам создать приложение, но имеет некоторые недостатки.

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

Из-за этих соображений полная сетка лучше всего подходит для небольших групп. Для чего-либо большего лучше использовать клиент-серверную топологию.

Гибридная сетка #

Гибридная сетка - это альтернатива полной сетке, которая может смягчить некоторые ее проблемы. В гибридной сетке подключения устанавливаются не между всеми пользователями. Вместо этого медиа ретранслируется через пиров в сети. Это означает, что создателю медиа не нужно использовать столько пропускной способности для распространения медиа.

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

Блок селективной пересылки #

Блок селективной пересылки (SFU - Selective Forwarding Unit) также решает проблемы полной сетки, но совершенно по-другому. SFU реализует клиент-серверную топологию вместо одноранговой. Каждый WebRTC-пир подключается к SFU и загружает свои медиа. SFU затем пересылает эти медиа каждому подключенному клиенту.

С SFU каждому WebRTC-агенту нужно закодировать и загрузить свое видео только один раз. Бремя распространения его всем зрителям ложится на SFU. Подключение с SFU также гораздо проще, чем одноранговое. Вы можете запустить SFU по глобально маршрутизируемому адресу, что значительно упрощает подключение клиентов. Вам не нужно беспокоиться о сопоставлениях NAT. Вам все еще нужно убедиться, что ваш SFU доступен через TCP (либо через ICE-TCP, либо через TURN).

Создание простого SFU можно выполнить за выходные. Создание хорошего SFU, который может обрабатывать все типы клиентов, - это бесконечная задача. Настройка контроля перегрузки, исправление ошибок и оптимизация производительности - это непрерывный процесс.

MCU #

MCU (Multi-point Conferencing Unit) - это клиент-серверная топология, похожая на SFU, но с композицией выходных потоков. Вместо распространения исходящих медиа без изменений она перекодирует их в один поток.