WebRTC против веб-сокетов: если WebRTC может делать видео, аудио и данные, зачем мне веб-сокеты? [закрыто]

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

Вещи как:

• Из-за того, что WebRTC является новым, он доступен только в некоторых браузерах, в то время как WebSockets, по-видимому, доступен в большем количестве браузеров.

• Масштабируемость - Websockets использует сервер для сессии, а WebRTC выглядит как p2p.

• Мультиплексирование / несколько чатов - используется в видеовстречах Google+, и я по-прежнему просматриваю демонстрационные приложения о том, как их реализовать.

• Сервер - Websockets требуется RedisSessionStore или RabbitMQ для масштабирования на нескольких машинах.

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

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

WebSocket, с другой стороны, предназначен для двунаправленной связи между клиентом и сервером. Потоковое аудио и видео можно передавать через WebSocket (см., Например, здесь ), но технология и API-интерфейсы не предназначены для эффективной и надежной потоковой передачи, как это делает WebRTC.

Как уже говорилось в других ответах, WebSocket может использоваться для сигнализации.

Я веду список ресурсов WebRTC : настоятельно рекомендую начать с просмотра презентации ввода-вывода Google о WebRTC в 2013 году .

WebSockets:

• Утвержден стандарт IETF (6455) с поддержкой всех современных браузеров и даже устаревших браузеров, использующих полифилл web-socket-js.

• Использует HTTP-совместимое рукопожатие и порты по умолчанию, что значительно упрощает использование с существующей инфраструктурой межсетевого экрана, прокси-сервера и веб-сервера.

• Гораздо проще API браузера. В основном один конструктор с парой обратных вызовов.

• Только клиент / браузер на сервере.

• Поддерживает только надежный, упорядоченный транспорт, поскольку он построен на TCP. Это означает, что отбрасывание пакетов может задержать все последующие пакеты.

WebRTC:

• Только начинает поддерживаться Chrome и Firefox. MS предложила несовместимый вариант. Компонент DataChannel еще не совместим с Firefox и Chrome.

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

• Транспортный уровень настраивается с помощью приложения, которое может выбирать, является ли соединение исправным и / или надежным.

• Сложный и многослойный браузер API. Существуют библиотеки JS для предоставления более простого API, но они молоды и быстро меняются (как и сам WebRTC).

Веб-сокеты используют протокол TCP.

WebRTC - это в основном UDP.

Таким образом, основной причиной использования WebRTC вместо Websocket является задержка. С потоковой передачей через веб-сокет вы будете иметь либо высокую задержку, либо прерывистое воспроизведение с низкой задержкой. С WebRTC вы можете добиться низкого времени задержки и плавного воспроизведения, что является критически важным для VoIP-коммуникаций.

Просто попробуйте проверить эти технологии с потерей сети, то есть 2%. Вы увидите большие задержки в потоке Websocket.

webRTC или веб-сокеты? Почему бы не использовать оба.

При построении видео / аудио / текстового чата, webRTC, безусловно, является хорошим выбором, поскольку он использует одноранговую технологию, и как только соединение установлено и работает, вам не нужно передавать связь через сервер (если не используется TURN).

При настройке связи через webRTC вы должны задействовать какой-то механизм сигнализации. Websockets мог бы быть хорошим выбором здесь, но webRTC - способ пойти для видео / аудио / текстовой информации. Чаты оформлены в сигнализации.

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

Безопасность - это один аспект, который вы пропустили.

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

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

В зависимости от вашего приложения это может иметь или не иметь значения.

Если вы отправляете большие объемы данных, возможно, стоит подумать об экономии затрат на пропускную способность облака из-за P2P-архитектуры webRTC.

Сравнивать websocket и webrtc несправедливо.

Websocket основан на вершине TCP. Граница пакета может быть обнаружена из информации заголовка пакета websocket в отличие от tcp.

Как правило, webrtc использует websocket. Сигнализация для webrtc не определена, это зависит от поставщика услуг, какой тип сигнализации он хочет использовать. Это может быть SIP, HTTP, JSON или любое текстовое / двоичное сообщение.

Сигнальные сообщения могут быть отправлены / получены с помощью веб-сокета.

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

Websocket и WebRTC могут использоваться вместе, Websocket в качестве сигнального канала WebRTC, а webrtc - это видео / аудио / текстовый канал, также WebRTC может быть в UDP также в ретрансляции TURN, ретрансляция TURN поддерживает TCP HTTP и HTTPS. Многие проекты используют Websocket и WebRTC вместе.