WebRTC vs Websockets: Якщо WebRTC може робити відео, аудіо та дані, навіщо мені потрібні вебсокети? [зачинено]

Тому я хочу створити додаток для чату, який дозволить відео, аудіо та текст. Я витратив деякий час на дослідження Websockets та WebRTC, щоб вирішити, який використовувати. Оскільки в WebRTC є багато програм для відео та аудіо, це здається розумним вибором, але чи варто ще розглянути інші речі? Не соромтеся поділитися своїми думками.

Такі речі:

• Оскільки новий WebRTC доступний лише в деяких браузерах, тоді як WebSockets, здається, є у більшості браузерів.

• Масштабованість - Websockets використовує сервер для сеансу, а WebRTC, схоже, p2p.

• Мультиплексування / кілька чат - використовується в Google+ Hangouts, і я все ще переглядаю демонстраційні програми, як їх реалізувати.

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

WebRTC призначений для високопродуктивного, високоякісного зв'язку відео, аудіо та довільних даних. Іншими словами, для додатків точно так, як ви описуєте.

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

З іншого боку, WebSocket призначений для двостороннього спілкування між клієнтом та сервером. Можливе потокове передавання аудіо та відео через WebSocket (див. Тут, наприклад), але технологія та API не розроблені по суті для ефективного, надійного потоку таким чином, яким є WebRTC.

Як було сказано в інших відповідях, WebSocket можна використовувати для передачі сигналів.

Я підтримую перелік ресурсів WebRTC : настійно рекомендую почати, ознайомившись з презентацією Google I / O 2013 про WebRTC.

WebSockets:

• Ратифікований стандарт IETF (6455) з підтримкою всіх сучасних браузерів і навіть застарілих браузерів за допомогою полі-заповнення web-socket-js.

• Використовує сумісні з HTTP порти рукостискання та типові порти, що значно полегшує використання з існуючою інфраструктурою брандмауера, проксі та веб-сервера.

• Набагато простіший API браузера. В основному один конструктор з парою зворотних викликів.

• Клієнт / браузер лише для сервера.

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

WebRTC:

• Chrome і Firefox лише починають підтримуватися. МС запропонував несумісний варіант. Компонент DataChannel ще не сумісний між Firefox та Chrome.

• WebRTC - це браузер для веб-переглядача в ідеальних обставинах, але навіть тоді майже завжди потрібен сервер сигналізації для встановлення з'єднань. Зараз найпоширеніші рішення сервера сигналізації використовують WebSockets.

• Транспортний шар може бути налаштований з додатком, здатним вибрати, чи є з'єднання впорядкованим та / або надійним.

• Складний і багатошаровий API браузера. Є JS lib для надання більш простого API, але вони молоді та швидко мінливі (як і сам WebRTC).

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

WebRTC - це головним чином UDP.

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

Просто спробуйте протестувати ці технології з втратою мережі, тобто 2%. Ви побачите великі затримки в потоці Websocket.

webRTC або websockets? Чому б не використовувати обидва.

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

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

Але, як ви згадуєте, не кожен браузер підтримує webRTC, тому веб-розетки іноді можуть бути хорошим резервом для цих браузерів.

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

За допомогою Websockets дані мають проходити через центральний веб-сервер, який зазвичай бачить увесь трафік і може отримати доступ до нього.

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

Залежно від вашої заявки це може не мати значення.

Якщо ви надсилаєте велику кількість даних, можливо, варто також врахувати економію витрат на пропускну здатність хмари через архітектуру P2P webRTC.

Порівнювати websocket і webrtc несправедливо.

Вебсокет базується на версії TCP. Межу пакета можна виявити за інформацією заголовка пакету websocket на відміну від tcp.

Зазвичай webrtc використовує websocket. Сигналізація для webrtc не визначена, це залежить від того, який тип сигналізації він хоче використовувати. Це може бути SIP, HTTP, JSON або будь-яке текстове / двійкове повідомлення.

Повідомлення сигналізації можна надсилати / приймати за допомогою веб-розетки.

Webrtc є частиною однорангового зв'язку. Всі ми знаємо, що перш ніж створювати з'єднання "одноранговий", потрібен процес рукостискання, щоб встановити зв'язок "одноранговий". І веб-розетки відіграють роль процесу рукостискання.

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