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

221

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

Вещи как:

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

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

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

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

1ManStartup
источник

Ответы:

273

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

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

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

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

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

Сэм Даттон
источник
2
Спасибо за подробный ответ ... любое обновление почти два года спустя?
Crashalot
2
Я рекомендую взглянуть на ресурсы, связанные с выше - см. G.co/webrtc .
Сэм Даттон
3
Кроме того, не то, что (я считаю) WebRTC может быть сконфигурирован , чтобы быть менее строгими о порядке пакетов и прочем, так что это может быть намного быстрее , это вы не возражаете некоторые потери пакетов и т.д. (т.е. имеющей последние данные важнее , чем все данные): stackoverflow.com/a/13051771/993683
1
Я думаю, что ключевые слова здесь в то время . Функция резервирования опроса в Socket.io теперь избыточна, так что у вас остается библиотека с тонкими пластинами, которая имеет простые в реализации функции с ужасной производительностью. Не начинай меня: D.
Лука
1
@SamDutton, неужели сервер может работать как пир и использовать один конец самого RTCDataChannel? Как таковой для современного веб-программирования я не вижу никакого преимущества веб-сокета вообще? RTCDataChannel - это UDP / реальное время?
Pacerier
71

WebSockets:

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

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

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

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

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

WebRTC:

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

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

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

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

канак
источник
4
Поддержка браузера WebRTC теперь намного лучше. caniuse.com/#search=WebRTC
смокинг
59

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

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

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

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

ankitr
источник
2
Для тех, кто заинтересован, этот материал объясняется далее здесь: stackoverflow.com/a/13051771/993683
39

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

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

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

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

Микаэль Холмгрен
источник
11

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

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

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

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

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

Тим Пантон
источник
1
Это ошибочное мнение, что WebRTC является строго одноранговым протоколом. Это начинает видеть широкое использование в промышленности как альтернатива VOIP на основе сервера.
photicSphere
Кроме того, когда мы реализуем WebSocket в качестве медиапотока WebRTC, он использует SIP, а SIP - это простой текстовый протокол, который используется для VoIP.
М. Ростами
10

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

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

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

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

Остин
источник
6

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

Рохит Ядав
источник
3

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

linkingvision
источник