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

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.

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.

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).

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.

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.

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.

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.

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.

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.