WebRTC kontra Websockets: Jeśli WebRTC może robić wideo, audio i dane, dlaczego potrzebuję Websockets? [Zamknięte]

221

Więc chcę zbudować aplikację do czatowania, która pozwoli na wideo, audio i tekst. Spędziłem trochę czasu badając Websockets i WebRTC, aby zdecydować, którego użyć. Ponieważ WebRTC oferuje wiele aplikacji audio i wideo, wydaje się to rozsądnym wyborem, ale czy należy rozważyć inne kwestie? Podziel się swoimi przemyśleniami.

Rzeczy jak:

  • Ponieważ WebRTC jest nowy, jest dostępny tylko w niektórych przeglądarkach, podczas gdy WebSockets wydaje się być w większej liczbie przeglądarek.

  • Skalowalność - Websockets używa serwera do sesji, a WebRTC wydaje się być p2p.

  • Multipleksowanie / wiele czatów - używane w Hangoutach Google+. Nadal oglądam aplikacje demonstracyjne dotyczące sposobu implementacji.

  • Serwer - Websockets potrzebuje RedisSessionStore lub RabbitMQ do skalowania na wielu komputerach.

1ManStartup
źródło

Odpowiedzi:

273

WebRTC został zaprojektowany do wysokiej jakości komunikacji wideo, audio i dowolnych danych o wysokiej jakości. Innymi słowy, dla aplikacji dokładnie takich, jakie opisujesz.

Aplikacje WebRTC potrzebują usługi, za pomocą której mogą wymieniać metadane sieciowe i medialne, proces znany jako sygnalizacja. Jednak po zakończeniu sygnalizacji wideo / audio / dane są przesyłane strumieniowo bezpośrednio między klientami, co pozwala uniknąć kosztów wydajności przesyłania strumieniowego za pośrednictwem serwera pośredniczącego.

Z kolei WebSocket jest przeznaczony do dwukierunkowej komunikacji między klientem a serwerem. Możliwe jest przesyłanie strumieniowe audio i wideo przez WebSocket (patrz tutaj na przykład), ale technologia i interfejsy API nie są z natury zaprojektowane do wydajnego, niezawodnego przesyłania strumieniowego w sposób, w jaki działa WebRTC.

Jak powiedziano w innych odpowiedziach, do sygnalizacji można użyć WebSocket.

Prowadzę listę zasobów WebRTC : zdecydowanie zalecamy rozpoczęcie od prezentacji Google I / O 2013 o WebRTC.

Sam Dutton
źródło
2
Dzięki za szczegółową odpowiedź ... jakieś aktualizacje prawie dwa lata później?
Crashalot,
2
Polecam przyjrzeć się zasobom powiązanym z powyższym - patrz g.co/webrtc .
Sam Dutton,
3
Również nie że (wierzę) WebRTC może być skonfigurowany tak, aby być mniej rygorystyczne o kolejności pakietów i rzeczy, dzięki czemu może być znacznie szybciej to nie przeszkadza trochę utraty pakietów itd (czyli posiadające najnowsze dane jest ważniejsze niż mieć wszystko dane): stackoverflow.com/a/13051771/993683
1
Myślę, że słowa kluczowe są w tym czasie . Funkcja rezerwowa w sondowaniu przy użyciu Socket.io jest teraz nadmiarowa, więc masz bibliotekę cienką jak wafel, która ma łatwe do wdrożenia funkcje przy ogromnym koszcie wydajności. Nie zaczynaj mnie: D.
Łukasza
1
@SamDutton, na pewno serwer może podwoić się jako peer i użyć jednego końca samego RTCDataChannel? Jako taki w nowoczesnym programowaniu internetowym nie widzę żadnej przewagi websocket? skoro RTCDataChannel jest UDP / w czasie rzeczywistym?
Pacerier
71

WebSockets:

  • Ratyfikowany standard IETF (6455) ze wsparciem we wszystkich nowoczesnych przeglądarkach, a nawet starszych przeglądarkach korzystających z funkcji wypełniania stron internetowych typu JS.

  • Korzysta z uzgadniania HTTP i portów domyślnych, co znacznie ułatwia korzystanie z istniejącej zapory ogniowej, serwera proxy i infrastruktury serwera WWW.

  • Znacznie prostsze API przeglądarki. Zasadniczo jeden konstruktor z kilkoma wywołaniami zwrotnymi.

  • Tylko klient / przeglądarka do serwera.

  • Obsługuje tylko niezawodny transport w kolejności, ponieważ jest zbudowany na TCP. Oznacza to, że zrzuty pakietów mogą opóźnić wszystkie kolejne pakiety.

WebRTC:

  • Właśnie zaczynają być obsługiwane przez Chrome i Firefox. MS zaproponowało niezgodny wariant. Komponent DataChannel nie jest jeszcze kompatybilny między Firefox a Chrome.

  • WebRTC to przeglądarka do przeglądarki w idealnych okolicznościach, ale nawet wtedy prawie zawsze wymaga serwera sygnalizacyjnego do skonfigurowania połączeń. Najpopularniejsze rozwiązania serwerów sygnalizacyjnych wykorzystują obecnie WebSockets.

  • Warstwę transportową można skonfigurować za pomocą aplikacji, która może wybrać, czy połączenie jest prawidłowe i / lub niezawodne.

  • Złożony i wielowarstwowy interfejs API przeglądarki. Istnieją biblioteki JS zapewniające prostszy interfejs API, ale są one młode i szybko się zmieniają (podobnie jak sam WebRTC).

kanaka
źródło
4
Obsługa przeglądarek WebRTC jest teraz znacznie lepsza. caniuse.com/#search=WebRTC
tuxayo
59

Websockets używają protokołu TCP.

WebRTC to głównie UDP.

Zatem głównym powodem używania WebRTC zamiast Websocket jest opóźnienie. Dzięki przesyłaniu strumieniowemu przez websocket będziesz mieć wysokie opóźnienie lub przerywane odtwarzanie z niskim opóźnieniem. Dzięki WebRTC możesz osiągnąć niskie opóźnienia i płynne odtwarzanie, co jest kluczowe dla komunikacji VoIP.

Spróbuj po prostu przetestować tę technologię pod kątem utraty sieci, tj. 2%. Zobaczysz duże opóźnienia w strumieniu Websocket.

ankitr
źródło
2
Zainteresowanym wyjaśniono to tutaj: stackoverflow.com/a/13051771/993683
39

webRTC czy websockets? Dlaczego nie skorzystać z obu.

Podczas budowania czatu wideo / audio / tekstowego webRTC jest zdecydowanie dobrym wyborem, ponieważ wykorzystuje technologię peer to peer, a gdy połączenie jest już uruchomione, nie musisz przekazywać komunikacji przez serwer (chyba że używasz TURN).

Podczas konfigurowania komunikacji webRTC musisz zaangażować jakiś mechanizm sygnalizacyjny. Websockets może być dobrym wyborem tutaj, ale webRTC jest sposobem na uzyskanie informacji wideo / audio / tekstowych. Pokoje czatowe są realizowane w sygnalizacji.

Ale, jak wspomniałeś, nie każda przeglądarka obsługuje webRTC, więc websockets mogą czasami być dobrą rezerwą dla tych przeglądarek.

Mikael Holmgren
źródło
11

Bezpieczeństwo to jeden aspekt, za którym tęskniłeś.

Dzięki Websockets dane muszą przechodzić przez centralny serwer WWW, który zazwyczaj widzi cały ruch i ma do niego dostęp.

W przypadku WebRTC dane są szyfrowane od końca do końca i nie przechodzą przez serwer (z wyjątkiem czasami serwerów TURN, ale nie mają dostępu do treści przekazywanych wiadomości).

W zależności od aplikacji może to, ale nie musi mieć znaczenia.

Jeśli wysyłasz duże ilości danych, warto rozważyć oszczędność kosztów przepustowości chmury dzięki architekturze webRTC P2P.

Tim Panton
źródło
1
Błędne jest przekonanie, że WebRTC jest protokołem peer-to-peer. Zaczyna być szeroko stosowane w przemyśle jako oparta na serwerze alternatywa VOIP.
photicSphere
Ponadto, gdy implementujemy WebSocket jako przepływ mediów WebRTC, wykorzystuje on SIP, a SIP jest protokołem zwykłego tekstu, który został użyty do VoIP.
M. Rostami,
10

Porównanie websocket i webrtc jest niesprawiedliwe.

Websocket jest oparty na TCP. Granicę pakietu można wykryć na podstawie informacji nagłówka pakietu websocket, w przeciwieństwie do tcp.

Zazwyczaj webrtc korzysta z websocket. Sygnalizacja webrtc nie jest zdefiniowana, od usługodawcy zależy, jakiego rodzaju sygnalizacji chce użyć. Może to być SIP, HTTP, JSON lub dowolny komunikat tekstowy / binarny.

Komunikaty sygnalizacyjne można wysyłać / odbierać za pomocą gniazda sieciowego.

Austin
źródło
6

Webrtc jest częścią połączenia peer to peer. Wszyscy wiemy, że przed utworzeniem połączenia peer-to-peer, proces nawiązywania połączenia peer-to-peer wymaga procesu uzgadniania. I gniazda sieciowe odgrywają rolę procesu uzgadniania.

Rohit yadav
źródło
3

Websocket i WebRTC mogą być używane razem, Websocket jako kanał sygnałowy WebRTC, a webrtc to kanał wideo / audio / tekstowy, również WebRTC może być w UDP również w przekaźniku TURN, przekaźnik TURN obsługuje TCP HTTP również HTTPS. Wiele projektów korzysta jednocześnie z Websocket i WebRTC.

linkingvision
źródło