Rozmowy wideo i strumieniowanie w czasie rzeczywistym z WebRTC i zestawami SDK

Jeśli budujesz Projekt poboczny JavaScript A jeśli potrzebujesz połączeń wideo, normalne są wątpliwości: czy powinienem użyć czystego WebRTC, zestawu SDK takiego jak Agora, Twilio, Mux lub Zegocloud, czy postawić na RN-WebRTC w React Native? Zła wiadomość jest taka, że ​​nie ma jednego rozwiązania. Dobra wiadomość jest taka, że ​​rozumiesz JavaScript w czasie rzeczywistym, co daje Ci idealną pozycję do podjęcia świadomej decyzji i uniknięcia bałaganu w architekturze.

W poniższych linijkach zobaczysz krok po kroku jak to działa WebRTC InsideJaką rolę odgrywa Agora (i inni podobni dostawcy)? Co oznacza skonfigurowanie własnej infrastruktury (STUN/TURN, sygnalizacja, SFU, serwery multimedialne…)? I jakie są rzeczywiste kompromisy między kosztami, złożonością i skalowalnością połączeń wideo i transmisji strumieniowej w czasie rzeczywistym?

Czym jest WebRTC i dlaczego jest podstawą wszystkiego?

WebRTC (komunikacja internetowa w czasie rzeczywistym) To zestaw standardów, interfejsów API i protokołów open source, które umożliwiają strumieniowe przesyłanie dźwięku, obrazu i danych w czasie rzeczywistym bezpośrednio z przeglądarki lub aplikacji natywnej, bez wtyczek ani aplikacji zewnętrznych. Jest on standaryzowany przez W3C i IETF i obsługiwany przez wszystkie nowoczesne przeglądarki: Chrome, Firefox, Safari, Edge, Opera i wiele przeglądarek mobilnych.

Ich filozofia jest jasna: umożliwić komunikację peer-to-peer (P2P) między użytkownikami z bardzo niskim opóźnieniem, rozwiązując wszystkie niedogodne problemy sieciowe – kodeki, jitter, echo, utratę pakietów, szyfrowanie itp. – w tle. Obejmuje to wszystko, od wideorozmów jeden na jeden po system interaktywne przesyłanie strumieniowe z setkami lub tysiącami widzów, jeśli połączymy to z odpowiednią infrastrukturą.

Podobne artykuł:

Jak korzystać i tworzyć aplikację do połączeń na Androidzie: kompletny przewodnik dla użytkowników i programistów

Kluczowe interfejsy API WebRTC: getUserMedia, RTCPeerConnection i RTCDataChannel

Technologia WebRTC opiera się na trzech głównych interfejsach API po stronie przeglądarki, z których na pewno skorzystasz, niezależnie od tego, czy stworzysz własne rozwiązanie, czy skorzystasz z zestawu SDK, takiego jak Agora:

• MediaStream / getUserMedia: do przechwytywania obrazu i dźwięku (z kamery, mikrofonu, a nawet ekranu lub kart).
• Połączenie RTCPeer:negocjowanie i przesyłanie strumieni audio i wideo pomiędzy urządzeniami równorzędnymi.
• Kanał RTCData: do wysyłania dowolnych danych (tekstu, danych binarnych, plików) z niewielkim opóźnieniem między klientami.

z pobierzMediaUżytkownika Możesz poprosić przeglądarkę o dostęp do kamery i mikrofonu i otrzymać MediaStream który następnie kojarzysz z elementem <video> z video.srcObject = stream. Możesz złożyć wniosek ograniczenia (rozdzielczość, liczba klatek na sekundę, kamera przednia/tylna itp.) i jeśli nie zostaną one spełnione, pojawią się błędy takie jak OverconstrainedErrorw przypadku których musisz zapewnić alternatywy (na przykład zmniejszenie rozdzielczości z 1080p do 720p i zastosowanie korekt dla popraw dźwięk mikrofonu).

Interfejs API Połączenie RTCPeer To serce połączeń: obsługuje negocjacje SDP (oferta/odpowiedź), zbieranie kandydatów ICE (obezwładnianie/odwracanie), nawiązywanie połączenia i bezpieczną transmisję przez SRTP. Z poziomu kodu wystarczy utworzyć połączenie, dodać ścieżki multimedialne i zareagować na zdarzenia, takie jak: onicecandidate u ontrack a Ty zadbaj o oznakowanie.

Wreszcie, Kanał RTCData Umożliwia konfigurację kanałów danych podobnych do WebSocket, ale typu punkt-punkt, z precyzyjną kontrolą niezawodności i kolejności. Przydaje się do rozmów wideo, udostępniania plików, synchronizacji stanu gry lub współpracy w czasie rzeczywistym. Składnia jest znajoma: dataChannel.send() y onmessage w odbiorniku.

Sygnalizacja: „klej”, którego WebRTC nie definiuje

Typowe nieporozumienie: WebRTC nie obejmuje oznakowaniaRTCPeerConnection musi wymieniać informacje, ale nie dyktuje sposobu. Musisz to zdefiniować samodzielnie lub skorzystać z zewnętrznego zestawu SDK, który może to dla Ciebie stworzyć.

Pary są przesyłane poprzez sygnalizację:

• Wiadomości sterujące sesją:rozpocznij połączenie, rozłącz się, błędy.
• Informacje o sieci:Kandydaci ICE (odkryte adresy IP/porty).
• Metadane multimediów:SDP oferuje i odpowiada kodekami, rozdzielczościami itp.

To oznakowanie jest zazwyczaj wdrażane za pomocą WebSocketsSocket.IO, HTTP (polling/long-polling), MQTT lub inne mechanizmy dwukierunkowe. Bardzo typowym wzorcem jest serwer Node.js z Gniazdo.IO który zarządza „pokojami” i przekazuje wiadomości typ tekstu/JSON między klientami:

Serwer:otrzymuje create or joinTworzy pokój, jeśli nie istnieje, obsługuje do dwóch klientów (w przypadku podstawowej rozmowy wideo) i przekazuje wiadomości. message do pozostałych gniazdek w pomieszczeniu. Ponosisz odpowiedzialność za nieprzekroczenie maksymalnej liczby użytkowników lub za zaprojektowanie własnej logiki pomieszczenia.

KlientPodczas ładowania strony prosi o nazwę pokoju (lub wywnioskowuje ją z adresu URL) i emituje create or joinSłuchaj wydarzeń takich jak created, joined, full, ready i uzgadnia z drugą stroną nawiązanie lub odrzucenie połączenia.

Ten wzór jest idealny dla prototyp lub projekt pobocznyZapewnia lekki serwer sygnalizacyjny, który w razie potrzeby można skalować za pomocą klastrów i modułów równoważenia obciążenia.

OGŁUSZENIE, OBRÓCENIE, ZAMROŻENIE: Przechodzenie przez NAT-y i zapory sieciowe bez popadania w szaleństwo

W idealnym świecie dwóch użytkowników zawsze korzystałoby z dostępnych sieci i łączyłoby się bezpośrednio. W rzeczywistości istnieją NAT-y, zapory sieciowe, CGNAT od dostawców usług internetowych i paranoicznych sieci korporacyjnych. Tu właśnie wkracza ICE, łącząc STUN i TURN.

• Oszołomić (Narzędzia do przechodzenia sesji dla NAT) umożliwiają klientowi znalezienie swojego Publiczny adres IP i portSerwer STUN odpowiada wyłącznie tymi informacjami.
• SKRĘCAĆ (Przechodzenie przez NAT za pomocą przekaźników) działa jako serwer przekaźnikowy mediów, gdy nie ma możliwości otwarcia bezpośredniego kanału P2P. Ruch audio/wideo przechodzi przez niego, co zużywa przepustowość serwera i generuje koszty.
• ICE (Interactive Connectivity Establishment) jest odpowiedzialne za testowanie wszystkich możliwych kandydatów (adresów lokalnych, odzwierciedlonych w przekaźnikach STUN i TURN) aż do znalezienia odpowiedniej trasy.

W praktyce w obiekcie konfiguracji RTCPeerConnection dodajesz tablicę iceServers Dzięki identyfikatorom URI STUN/TURN przeglądarka zajmie się resztą. Jeśli skonfigurujesz własną infrastrukturę, będziesz musiał wdrożyć i utrzymywać serwery STUN/TURN; jeśli korzystasz z pakietu SDK, takiego jak Agora, Twilio lub Zegocloud, jest on już w tym procesie przygotowany i gotowy do wdrożenia.

Transmisja strumieniowa w czasie rzeczywistym o niskim opóźnieniu: WebRTC kontra HLS/DASH

Kiedy mówimy o Przekaz na żywo Istnieją dwa odrębne światy: protokoły oparte na protokole HTTP (HLS, DASH) i WebRTC. Protokoły HLS/DASH działają poprzez pobieranie i odtwarzanie segmentów wideo od klienta; jest to idealne rozwiązanie dla skalowalności przez CDN, ale wprowadza opóźnienia rzędu kilku sekund (z łatwością 5-30 sekund).

Z drugiej strony WebRTC wykorzystuje UDP + RTP i dostarcza wideo w trybie „push” ze źródła do odtwarzacza, z bardzo krótkim czasem uruchamiania i typowymi opóźnieniami poniżej 500 ms (często ~250 ms), jeśli sieć jest sprawna. Osiąga to dzięki:

• Kontrola zatorów zintegrowany, który dostosowuje szybkość transmisji i rozdzielczość w czasie rzeczywistym, zależnie od utraty pakietów, drgań sygnału lub czasu reakcji (RTT).
• Zastosowanie wydajnych kodeków (VP8, VP9, ​​H.264; coraz częściej AV1) z przyspieszenie sprzętowe jeśli dostępne.
• Możliwość wykorzystania SVC (Scalable Video Coding) tak, aby odbiornik odbierał tylko te warstwy, które obsługuje jego sieć/urządzenie.

Dlatego WebRTC jest naturalnym wyborem aukcje w czasie rzeczywistym, zakłady na żywo na wydarzenia sportowe, handel, gry interaktywne, pomoc zdalna, telemedycyna, wirtualne klasy z udziałem uczestników lub panele finansowe, które nie mogą sobie pozwolić na kilkusekundowe opóźnienie.

Problem polega na tym, że czysty P2P WebRTC nie skaluje się dobrze do tysięcy widzów; w tym celu potrzebne są Jednostki SFU, serwery multimedialne lub platformy hybrydowei właśnie tutaj pojawiają się rozwiązania takie jak Flussonic, Agora i podobne.

Skalowanie poza P2P: SFU, serwery multimedialne i architektury hybrydowe

Podczas wideorozmowy jeden na jeden WebRTC działa bez zarzutu. Ale jeśli dodasz 10, 20 lub 100 użytkowników, sytuacja się zmienia: każdy klient musi wysyłać/odbierać wiele strumieni, jego procesor się przegrzewa, a sieć ulega awarii. Wyłaniają się tu trzy klasyczne schematy:

• MCU (jednostka sterowania wielopunktowego)Serwer odbiera wszystkie strumienie, miksuje je i wysyła pojedynczy strumień do każdego klienta. Zaleta: niskie zużycie zasobów po stronie klienta. Wady: duże obciążenie serwera, mniejsza indywidualna kontrola jakości.
• SFU (Selektywna Jednostka Przekierowująca)Serwer odbiera strumienie i selektywnie je przesyła, nie mieszając ich. Każdy widz otrzymuje strumienie, których potrzebuje, prawdopodobnie w różnej jakości. Jest to obecnie najczęściej stosowany wzorzec. wideokonferencje wieloosobowe i skalowalnego interaktywnego przesyłania strumieniowego.
• Architektury hybrydowe WebRTC + HLS/DASHWebRTC służy do pobierania i interakcji, podczas gdy HLS/DASH dystrybuuje dane do dużych odbiorców, którzy nie potrzebują interakcji w czasie rzeczywistym. To balans między bardzo małe opóźnienie dla „aktorów” i masowa skalowalność dla „widzów”.

Serwery multimedialne takie jak Flusonic Inne zapewniają niezbędne zaplecze: odbierają strumień WebRTC, transkodują go w razie potrzeby, przesyłają przez WebRTC do innych klientów lub konwertują do protokołów typu HLS w celu masowej dystrybucji. To właśnie ten typ infrastruktury w praktyce umożliwia wyjście poza połączenia jeden do jednego bez konieczności wyważania otwartych drzwi.

Typowe przypadki użycia: rozmowy wideo, streaming, IoT i wiele więcej

WebRTC stał się wszechobecny i prawdopodobnie używasz go codziennie, nie zdając sobie z tego sprawy. Oto kilka przykładów, gdzie sprawdza się szczególnie dobrze: wideorozmowy i wideokonferencje:

• Rozmowy wideo i wideokonferencjeGoogle Meet, Jitsi, Slack, Microsoft Teams i wiele innych narzędzi opiera się na technologii WebRTC (częściowo lub całkowicie) do udostępniania obrazu, dźwięku i ekranu.
• Usługi przesyłania strumieniowego w czasie rzeczywistymPlatformy takie jak Twitch, Meta Live, Vimeo Livestream czy narzędzia takie jak Streamyard łączą w sobie WebRTC do przetwarzania i inne technologie do masowej dystrybucji.
• Czat i wiadomości z udostępnianiem plikówDzięki RTCDataChannel możesz prowadzić rozmowy na czacie w czasie rzeczywistym, udostępniać pliki, synchronizować statusy itp. bez konieczności korzystania z centralnych serwerów multimedialnych.
• Gry w chmurze i tryb wieloosobowyUsługi takie jak GeForce NOW czy Xbox Cloud Gaming wykorzystują podobne technologie do interaktywnego wideo; wiele gier P2P używa WebRTC do synchronizacji rozgrywki.
• IoT i nadzórInteligentne kamery, monitory dziecięce, wideodomofony lub drony mogą wysyłać wideo w czasie rzeczywistym do urządzeń mobilnych i przeglądarek wykorzystujących technologię WebRTC.
• Edukacja i telemedycyna: wirtualne klasy z tablicami, quizami i dwukierunkową transmisją wideo lub konsultacje medyczne online, gdzie opóźnienia i bezpieczeństwo mają kluczowe znaczenie.

Bezpieczeństwo WebRTC: szyfrowanie, uprawnienia i najlepsze praktyki

Bezpieczeństwo w WebRTC nie jest dodatkiem: jest wbudowane. zintegrowane z projektemWszystkie komponenty multimedialne są szyfrowane, a interfejsy API działają wyłącznie z bezpiecznych źródeł (HTTPS lub localhost), chociaż zaleca się zachowanie czujności. oszustwa za pośrednictwem połączeń wideo.

• DTLS (Datagram Transport Layer Security) szyfruje dane podczas przesyłu.
• SRTP (Secure Real-time Transport Protocol) chroni dane audio i wideo, uniemożliwiając ich łatwą manipulację lub przechwycenie.
• Dostęp do kamera i mikrofon Wymaga wyraźnej zgody użytkownika, z widocznymi wskaźnikami wizualnymi (ikony, kolorowe kropki itp.).
• Ponieważ nie ma żadnych wtyczek do zainstalowania, istnieje ryzyko złośliwe oprogramowanie zakamuflowane w rozszerzeniach stron trzecich lub plikach binarnych.

Mimo wszystko musisz zadbać o własną warstwę: użyj HTTPS w całymPrzejrzyj uprawnienia, o które prosisz, aktualizuj przeglądarki i biblioteki i nie zaniedbuj bezpieczeństwa serwera sygnalizacyjnego ani interfejsów API REST.

WebRTC kontra inne technologie: VoIP, WebSockets i zastrzeżone platformy

Jeśli korzystasz ze świata tradycyjnego VoIP, znasz SIP, PBX, softfony i drogie serwery. WebRTC zmienia paradygmat: nie musisz już wymagać od użytkownika podawania żadnych informacji. klient stacjonarny Nie potrzeba żadnego konkretnego sprzętu, wystarczą przeglądarka i stosunkowo prosty serwer sygnalizacyjny.

Przeciw Tradycyjny VoIPWebRTC zmniejsza obciążenie infrastruktury bazowej i otwiera drzwi do aplikacji bezpośrednio zintegrowanych z siecią. W wielu przypadkach można ponownie wykorzystać zaplecze SIP za pośrednictwem bram, które tłumaczą sygnalizację na WebRTC.

Odnośnie WebSocketsNależy je traktować raczej jako uzupełnienie: idealnie nadają się do powiadomień, prostych czatów czy aktualizacji statusu, ale nie do intensywnych multimediów. WebRTC jest zoptymalizowany pod kątem audio/wideo w czasie rzeczywistymz kontrolą przeciążenia, kodekami, buforem jittera itp. W praktyce wiele projektów wykorzystuje WebSockets do sygnalizacji i WebRTC do przesyłu multimediów.

Jeśli porównasz je do platform takich jak Zoom, GoToMeeting lub WebExRóżnica tkwi w modelu: te narzędzia to zamknięte rozwiązania, często z obowiązkowymi aplikacjami desktopowymi i zastrzeżonym zapleczem. Z drugiej strony, WebRTC to technologia fundamentalna; można na niej zbudować własny „mini-Meet” lub zintegrować go z usługami, które już z niej korzystają (takimi jak Google Meet czy Microsoft Teams).

Tworzenie oprogramowania z wykorzystaniem WebRTC: rzeczywista złożoność i typowe pułapki

Chociaż interfejsy API wydają się proste na papierze, wdrożenie WebRTC od podstaw jest bardziej skomplikowane. Będziesz musiał poradzić sobie z:

Podobne artykuł:

Przeglądarka Tor dla Androida: zaawansowane ustawienia i bezpieczne użytkowanie

• Niestandardowe oznakowanie: projektowanie wiadomości, pokoi, zarządzanie ponownymi połączeniami, ponownymi próbami, błędami.
• Zarządzanie lodem/oszołomieniem/obrótemWdrażaj serwery, monitoruj wykorzystanie protokołu TURN (który zużywa przepustowość), dostosuj limity czasu.
• Jakość usług (QoS):dostosowywanie przepływności bitowej, radzenie sobie z niestabilnymi sieciami, negocjowanie kodeków, wykrywanie pogorszenia jakości połączenia i reagowanie na nią.
• łuskowaty:przejście od prostych połączeń P2P do grup, a następnie do setek użytkowników, wprowadzenie SFU lub serwerów multimedialnych bez zmiany pierwotnego projektu.
• Kompatybilny z wszystkimi nawigatoramiChoć sytuacja jest dobra, nadal znajdziesz niuanse. Użyj adapter.js Nadal jest to bardzo zalecane.

W małym projekcie pobocznym skonfigurowanie serwera Node z Socket.IO i publicznym STUN-em może wystarczyć do połączeń 1:1 lub bardzo małych grup. Ale jeśli Twój pomysł się rozwinie i będziesz potrzebować duży tłumNiezależnie od tego, czy chodzi o kontrolę jakości, nagrania, analizę, transkrypcje czy monetyzację, wkrótce będziesz musiał rozważyć lub włączyć własny serwer multimedialnylub przejdź do specjalisty.

Sieć CDN w czasie rzeczywistym z zestawami SDK: Agora, Twilio, Mux, ZEGOCLOUD…

Usługi takie jak Agora, Twilio, Mux, ZEGOCLOUD lub podobne technologie tworzą warstwę wartości na bazie WebRTC, co pozwala zaoszczędzić miesiące pracy i niezliczone bóle głowy:

• oferują ci a globalna sieć medialna z jednostkami SFU rozmieszczonymi na całym świecie, zoptymalizowanymi pod kątem niskich opóźnień.
• Abstrakcyjny OGŁUSZENIE/SKRĘT, sygnalizacja, ponowne próby, ponowne połączenia i złożone zarządzanie siecią.
• Zawierają dobrze utrzymane zestawy SDK dla sieć, iOS, Android, React Native i inne struktury.
• Oferują dodatki takie jak: nagrywanie, transmisja do RTMP/HLS, moderacja, statystyki w czasie rzeczywistym, kontrola jakości, role użytkowników (gospodarz, publiczność, mówca) itp.

Koszt, jak zapewne podejrzewasz, jest głównym problemem: jeśli masz choć trochę pieniędzy, wiele minut wideo Albo, przy dużej liczbie jednoczesnych użytkowników, rachunek gwałtownie rośnie. Co więcej, stajesz się zależny od platformy, jej cen lub zmian API.

W Twojej konkretnej sytuacji, z dużym doświadczeniem w JavaScript w czasie rzeczywistymRozsądnym rozwiązaniem jest rozpoczęcie od zestawu SDK, aby przyspieszyć rozwój, zweryfikować produkt i poznać jego model przestrzeni, role, cykl życia strumienia i zarządzanie stanem. Później, gdy projekt nabierze tempa i koszty staną się problemem, można stopniowo migrować części rozwiązania na bardziej niezawodną platformę. zastrzeżona infrastruktura WebRTC lub polegać na serwerze multimedialnym typu Flussonic w celu kontrolowania warstwy dystrybucyjnej.

Najlepsze praktyki i narzędzia do debugowania WebRTC

Aby nie zgubić się w czarnej skrzynce WebRTC, warto skorzystać z narzędzi, które już istnieją w przeglądarkach i ekosystemie:

• chrome: // webrtc-internals (o o:webrtc (w przeglądarce Firefox): panel ze szczegółowymi statystykami połączeń, przepływności, utraty pakietów, aktywnych kodeków itp.
• adapter.js: utrzymywana przez społeczność łagodząca różnice między przeglądarkami i wersjami.
• test.webrtc.org:aby sprawdzić kamerę, mikrofon, sieć i ogólną kompatybilność na komputerze.
• Oficjalne próbki na webrtc.github.io/samples: przykłady ograniczeń, połączeń peer-to-peer, kanałów danych, udostępniania ekranu… bardzo przydatne przy kopiowaniu wzorców.

Dobrym pomysłem jest również struktura kodu poprzez wyraźne oddzielenie warstwa sygnalizacyjna (gniazda, pokoje, wiadomości) warstwy Czysty WebRTC (tworzenie połączeń, zarządzanie strumieniami, obsługa zdarzeń). Pozwala to na zastąpienie zaplecza sygnalizacyjnego lub serwera multimediów bez konieczności przepisywania całej logiki klienta.

Podobne artykuł:

Android i Linux: najlepsze alternatywy dla KDE Connect

Mając na uwadze wszystkie powyższe kwestie, w przypadku projektu pobocznego, który dopiero się rozpoczyna i w którym tak bardzo cenisz czas rozwoju jak średnioterminowy kosztNajbardziej zrównoważoną strategią jest zwykle rozpoczęcie od zestawu SDK czasu rzeczywistego bazującego na WebRTC, który umożliwia szybkie iterowanie w React/React Native, przyswojenie sposobu obsługi ról, sesji, cyklu życia strumienia i stanów na żywo, a także równoległe zagłębianie się w WebRTC „na ślepo” (getUserMedia, RTCPeerConnection, RTCDataChannel, sygnalizacja za pomocą Node+Socket.IO, STUN/TURN, SFU), aby nie być na zawsze przywiązanym do jednej platformy i móc przejść na bardziej niestandardowe rozwiązanie, gdy produkt to uzasadni.