WebRTC vs WebSocket: połączenie peer-to-peer czy serwer
WebRTC vs WebSocket
WebRTC vs WebSocket (a także webhooki i HTTP) | We.Inc
WebRTC vs WebSocket: media i kanały danych peer-to-peer kontra gniazdo klient-serwer, dlaczego WebRTC wciąż potrzebuje sygnalizacji, a także webhook vs WebSocket i HTTP vs WebSocket.
WebSocket utrzymuje jedno dwukierunkowe połączenie między przeglądarką a Twoim serwerem i każda wiadomość przechodzi przez ten serwer. WebRTC łączy przeglądarki bezpośrednio ze sobą, przesyłając dźwięk, obraz i dowolne dane szyfrowane za pomocą DTLS i SRTP. Często używa się ich razem: WebSocket przenosi wiadomości sygnalizacyjne, które zestawiają połączenie WebRTC.
Porównanie WebRTC i WebSocket
Pytanie
WebRTC
WebSocket
Kto z kim rozmawia
Przeglądarka z przeglądarką (peer-to-peer)
Przeglądarka z serwerem
Do czego służy
Dźwięk, obraz, udostępnianie ekranu, dane między peerami
Wiadomości między aplikacją a serwerem
Zestawienie połączenia
Oferta, odpowiedź i kandydaci ICE przez Twoją własną sygnalizację
Jeden handshake HTTP Upgrade
Opcje dostarczania
Kanały danych mogą być uporządkowane lub nie, niezawodne lub nie
Uporządkowane i niezawodne
Szyfrowanie
Zawsze włączone (DTLS, SRTP)
Tylko z wss://
Czy potrzebny jest serwer
Do sygnalizacji oraz przekaźniki TURN, gdy peery nie mogą połączyć się bezpośrednio
Tak, to on jest drugą stroną
Wybierz w poniższym pomocniku, co budujesz, a wskaże pasującą technologię wraz z uzasadnieniem. Omawia też dwa pytania, które często mieszają się z tym: webhooki, które działają między serwerami, oraz zwykłe żądania HTTP.
Wybierz funkcję najbliższą Twojej.
Przeczytaj, która technologia pasuje i dlaczego.
Przewiń do sekcji z kodem, aby zobaczyć szkic sygnalizacji i przykład kanału danych.
Skorzystaj z dwóch tabel na końcu, aby porównać webhooki i HTTP.
Nie sięgaj po WebRTC, by wysyłać aktualizacje z serwera. Serwer nie jest tam peerem, a WebSocket lub strumień zdarzeń jest znacznie prostszy.
Przed uruchomieniem rozmów zaplanuj budżet na przekaźnik TURN. Niektóre sieci blokują bezpośrednie połączenia między peerami i wtedy całe media płyną przez przekaźnik, za który płacisz.
Serwer sygnalizacyjny powinien być prosty: tylko przekazuje oferty, odpowiedzi i kandydatów. MDN opisuje ładunek jako czarną skrzynkę, której serwer nie musi rozumieć.
W grze lub przy przesyłaniu pozycji kursorów między peerami otwórz kanał danych z ordered ustawionym na false i maxRetransmits ustawionym na 0, aby spóźniony pakiet nigdy nie blokował nowszych.
Najczęściej zadawane pytania
Czy WebRTC zastępuje WebSockety?
Nie. WebRTC nie ma wbudowanego sposobu, by dwie przeglądarki się odnalazły, więc nadal potrzebujesz kanału do wymiany wiadomości konfiguracyjnych. Zwykle wybiera się WebSocket, choć MDN zaznacza, że zadziała dowolny transport.
Czy WebRTC może przesyłać zwykłe dane, a nie tylko obraz?
Tak. RTCPeerConnection.createDataChannel() otwiera kanał dla danych tekstowych lub binarnych między peerami, a jego API celowo przypomina API WebSocket, z metodą send() i zdarzeniem message.
Czym różni się webhook od WebSocketu?
Webhook to żądanie HTTP, które jeden serwer wysyła na adres URL innego serwera, gdy zajdzie zdarzenie, po czym połączenie się kończy. WebSocket to połączenie, które pozostaje otwarte, aby przeglądarka i serwer mogły stale się komunikować.
Czy WebSocket jest szybszy niż HTTP?
Przy wielu małych wiadomościach zwykle tak, bo handshake odbywa się raz, a każda kolejna wiadomość pomija nagłówki żądania. Do ładowania strony lub pliku właściwym narzędziem jest zwykłe HTTP, które korzysta z cache.
Czy WebRTC działa peer-to-peer nawet przy wielu osobach w rozmowie?
Każde połączenie łączy dwa peery, więc pełna siatka szybko rośnie wraz z dołączaniem osób. Wiele większych produktów do rozmów kieruje media przez serwer, który przekazuje strumienie, a ten działa poza samym przeglądarkowym API WebRTC.
Dlaczego WebRTC wciąż potrzebuje serwera
Zanim dwie przeglądarki się połączą, każda musi poznać opis sesji drugiej strony, czyli ofertę i odpowiedź SDP, oraz listę możliwych adresów sieciowych zwanych kandydatami ICE. Dostarczenie tych wiadomości WebRTC zostawia Tobie.
Po ich wymianie ICE sprawdza kandydatów, a STUN pomaga każdej stronie ustalić jej publiczny adres. Jeśli żadna bezpośrednia trasa nie działa, ruch przechodzi awaryjnie przez serwer TURN, który go przekazuje. Potem media płyną między peerami, a nie przez Twój serwer sygnalizacyjny.
Webhook vs WebSocket
Rozwiązują różne problemy. Webhook pozwala usłudze, na przykład operatorowi płatności lub hostingowi kodu, powiadomić Twój backend o zdarzeniu, wysyłając żądanie HTTP na zarejestrowany przez Ciebie adres URL. Nic nie pozostaje otwarte i nie bierze w tym udziału żadna przeglądarka.
WebSocket utrzymuje stałe łącze z przeglądarką użytkownika. Częsty wzorzec łączy oba: webhook informuje Twój serwer, że zamówienie zostało opłacone, a serwer przekazuje tę wiadomość na otwartą stronę klienta przez WebSocket.
HTTP vs WebSocket
Zwykłe HTTP to żądanie i odpowiedź: klient pyta, serwer odpowiada, a odpowiedzi GET mogą być cache'owane przez przeglądarki i CDN. To właściwy wybór domyślny dla stron, plików i większości wywołań API.
WebSocket zaczyna się jako żądanie HTTP, potem przełącza protokół odpowiedzią 101 i pozostaje otwarty. Sięgaj po niego tylko wtedy, gdy serwer musi wysyłać dane, o które klient nie prosił, albo wiadomości lecą tak często, że narzut każdego żądania ma znaczenie.
Zestawianie WebRTC przez WebSocket
Dzwoniący: utwórz ofertę i kanał danych
WebSocket tylko przekazuje wiadomości konfiguracyjne. Adres URL STUN to miejsce na wybrany przez Ciebie serwer.
Odbierający: odpowiedz i odbierz kanał
Druga strona otrzymuje kanał przez zdarzenie datachannel, zamiast go tworzyć.
Nieuporządkowany kanał bez ponowień dla stanu gry
Nie można ustawić jednocześnie maxRetransmits i maxPacketLifeTime, wybierz jedno.
Webhook vs WebSocket w skrócie
Webhook vs WebSocket
Pytanie
Webhook
WebSocket
Kto się łączy
Jeden serwer wywołuje inny serwer
Klient utrzymuje otwarte łącze z serwerem
Czas życia
Jedno żądanie HTTP na zdarzenie
Otwarte, dopóki któraś strona go nie zamknie
Kierunek
Od nadawcy do odbiorcy
W obie strony
Typowe zastosowanie
Zdarzenia płatności, repozytorium lub formularzy
Czat na żywo, dashboardy, obecność użytkowników
HTTP vs WebSocket w skrócie
HTTP vs WebSocket
Pytanie
Żądanie HTTP
WebSocket
Kto zaczyna wiadomość
Zawsze klient
Dowolna strona
Połączenie
Żądanie, potem odpowiedź
Przełączone odpowiedzią 101, potem pozostaje otwarte
Cache
Odpowiedzi GET i HEAD można cache'ować
Brak
Schematy URL
ws:// (port 80), wss:// (port 443)
Rozmowa wideo między dwiema osobami
WebRTC, z WebSocketem do sygnalizacji
Dźwięk i obraz powinny płynąć bezpośrednio między rozmówcami z niskim opóźnieniem. Mały serwer WebSocket przekazuje tylko ofertę, odpowiedź i kandydatów podczas zestawiania.
Pokój czatu grupowego w aplikacji webowej
WebSocket
Wiadomości trzeba przechowywać, moderować i wysyłać do wszystkich w pokoju, więc i tak należą do Twojego serwera. Jedno gniazdo na użytkownika to proste rozwiązanie.
Wysłanie dużego pliku do przeglądarki znajomego
Kanał danych WebRTC
Niezawodny, uporządkowany kanał danych przesyła bajty peer-to-peer, więc Twój serwer nigdy nie przechowuje ani nie przekazuje pliku, chyba że potrzebny jest TURN.
Szybkie ruchy w grze dla dwóch graczy
Kanał danych WebRTC, nieuporządkowany
Przy wyłączonym porządkowaniu i bez ponownych transmisji utracona aktualizacja pozycji jest pomijana, zamiast wstrzymywać nowsze. Jeśli potrzebujesz serwera sędziego, użyj zamiast tego WebSocketu do niego.
Operator płatności potwierdza zamówienie
Webhook
Serwer operatora wywołuje adres URL na Twoim serwerze, gdy płatność się powiedzie. Nie bierze w tym udziału żadna przeglądarka i nic nie musi pozostawać otwarte.
Załadowanie strony produktu i jej danych
Zwykłe HTTP
Wystarczy żądanie i odpowiedź, a odpowiedzi GET można cache'ować. Stałe połączenie dodałoby koszt bez żadnej korzyści.