Videopozivi i streaming u stvarnom vremenu s WebRTC-om i SDK-ovima

  • WebRTC nudi audio, video i podatke u stvarnom vremenu s vrlo niskom latencijom koristeći getUserMedia, RTCPeerConnection i RTCDataChannel.
  • Za funkcioniranje u stvarnom svijetu potrebna mu je signalizacija, STUN/TURN i ICE, a skaliranje obično zahtijeva SFU-ove ili medijske poslužitelje.
  • SDK-ovi poput Agore, Twilia ili ZEGOCLOUD-a pojednostavljuju infrastrukturu po cijenu ponavljajućih troškova i ovisnosti o dobavljačima.
  • Sporedni projekt može započeti s SDK-om i razvijati se u vlastitu WebRTC infrastrukturu kako proizvod sazrijeva.

Videopozivi i streaming u stvarnom vremenu s WebRTC-om i SDK-ovima

Ako gradite JavaScript sporedni projekt A ako vam trebaju videopozivi, normalno je da imate nedoumice: Trebam li koristiti čisti WebRTC, SDK poput Agore, Twilia, Muxa ili Zegoclouda ili se u potpunosti usredotočiti na RN-WebRTC u React Nativeu? Loša vijest je da ne postoji jedno rješenje. Dobra vijest je da razumijete JavaScript u stvarnom vremenu, što vas stavlja u idealnu poziciju za donošenje informirane odluke i izbjegavanje kvarenja arhitekture.

U sljedećim retcima vidjet ćete, korak po korak, kako to funkcionira WebRTC InsideKoju ulogu igra Agora (i drugi slični pružatelji usluga)? Što znači postaviti vlastitu infrastrukturu (STUN/TURN, signalizacija, SFU, medijski poslužitelji…)? I koji su stvarni kompromisi između cijene, složenosti i skalabilnosti za videopozive i streaming u stvarnom vremenu?

Što je WebRTC i zašto je temelj svega?

WebRTC (web komunikacija u stvarnom vremenu) To je skup standarda otvorenog koda, API-ja i protokola koji omogućuju strujanje zvuka, videa i podataka u stvarnom vremenu izravno iz preglednika ili izvorne aplikacije, bez dodataka ili vanjskih aplikacija. Standardiziran je od strane W3C-a i IETF-a te ga podržavaju svi moderni preglednici: Chrome, Firefox, Safari, Edge, Opera i mnogi mobilni preglednici.

Njihova filozofija je jasna: omogućiti komunikaciju peer-to-peer (P2P) između korisnika s vrlo niskom latencijom, rješavajući sve neugodne mrežne probleme - kodeke, podrhtavanje, odjek, gubitak paketa, enkripciju itd. - iza kulisa. To uključuje sve od videopoziva jedan na jedan do sustava interaktivno strujanje sa stotinama ili tisućama gledatelja ako se to kombinira s pravom infrastrukturom.

aplikacija za pozivanje
Povezani članak:
Kako koristiti i stvoriti aplikaciju za pozive na Androidu: Ultimativni vodič za korisnike i razvojne programere

Ključni WebRTC API-ji: getUserMedia, RTCPeerConnection i RTCDataChannel

WebRTC se oslanja na tri glavna API-ja na strani preglednika koje ćete sigurno koristiti, bez obzira gradite li vlastito rješenje ili koristite SDK poput Agore:

  • MediaStream / getUserMedia: za snimanje videa i zvuka (kamera, mikrofon, pa čak i zaslon ili kartice).
  • RTCPeer veza: pregovarati i prenositi audio i video streamove između peerova.
  • RTCDataChannel: slanje proizvoljnih podataka (tekst, binarne datoteke, datoteke) s niskom latencijom između klijenata.

s getUserMedia Možete zatražiti pristup preglednika kameri i mikrofonu i primiti MediaStream koji zatim povezujete s elementom <video> s video.srcObject = stream. Možete se prijaviti ograničenja (rezolucija, broj sličica u sekundi, prednja/stražnja kamera itd.) i, ako se ti uvjeti ne ispune, dobit ćete pogreške poput OverconstrainedErrorza koje morate uspjeti ponuditi alternative (na primjer, smanjenje rezolucije s 1080p na 720p i primjena prilagodbi za poboljšati zvuk mikrofona).

API za RTCPeer veza To je srž poziva: obrađuje SDP (ponuda/odgovor) pregovore, ICE (zapanjujuća/okrenuta) prikupljanje kandidata, uspostavljanje veze i siguran prijenos putem SRTP-a. Iz svog koda jednostavno stvarate vezu, dodajete medijske zapise i reagirate na događaje kao što su onicecandidate u ontrack a ti se brineš za signalizaciju.

konačno, RTCDataChannel Omogućuje vam postavljanje podatkovnih kanala slično WebSocketu, ali od točke do točke i s preciznom kontrolom nad pouzdanošću i redoslijedom. Koristan je za video chat, dijeljenje datoteka, sinkronizaciju stanja igre ili suradnju u stvarnom vremenu. Sintaksa je poznata: dataChannel.send() y onmessage u prijemniku.

Signalizacija: „ljepilo“ koje WebRTC ne definira

Tipičan nesporazum: WebRTC ne uključuje signalizacijuRTCPeerConnection treba razmjenjivati ​​informacije, ali ne diktira kako. To morate sami definirati ili SDK treće strane to može apstrahirati za vas.

Parovi se šalju putem signalizacije:

  • Poruke za kontrolu sesije: započeti poziv, prekinuti vezu, pogreške.
  • Informacije o mrežiICE kandidati (otkrivene IP adrese/portovi).
  • Metapodaci medijaSDP ponude i odgovori s kodeksima, rezolucijama itd.

Ova signalizacija se obično implementira s WebSocketsSocket.IO, HTTP (anketiranje/dugo anketiranje), MQTT ili drugi dvosmjerni mehanizmi. Vrlo tipičan uzorak je Node.js poslužitelj s Utičnica.IO koji upravlja "sobama" i prosljeđuje poruke tip tekst/JSON između klijenata:

server: prima create or joinStvara sobu ako jedna ne postoji, podržava do dva klijenta (za osnovni videopoziv) i prosljeđuje poruke. message na ostale utičnice u sobi. Odgovorni ste za to da ne prekoračite maksimalni broj korisnika ili za dizajniranje vlastite logike sobe.

KupacPrilikom učitavanja stranice, traži naziv sobe (ili ga zaključuje iz URL-a), emitira create or joinPoslušajte događaje poput created, joined, full, ready i dogovara se s drugom stranom o pokretanju ili odbijanju poziva.

Ovaj uzorak je savršen za prototip ili sporedni projektPruža vam lagani signalni poslužitelj koji možete skalirati s klasterima i uravnoteživačima opterećenja ako je potrebno.

STUN, TURN, ICE: Prolazak kroz NAT-ove i vatrozidove bez pretjeranog opterećenja

U idealnom svijetu, dva korisnika bi uvijek bila na dostupnim mrežama i izravno se povezivala. U stvarnom svijetu postoje NAT-ovi, zaštitni zidovi, CGNAT od pružatelja internetskih usluga i paranoičnih korporativnih mreža. Tu nastupa ICE, kombinirajući STUN i TURN.

  • ONESVIJESTITI (Session Traversal Utilities for NAT) omogućuje klijentu da sazna svoj Javna IP adresa i portSTUN poslužitelj odgovara samo s tim informacijama.
  • SKRETANJE (Traversal korištenjem releja oko NAT-a) djeluje kao relejni poslužitelj medija kada ne postoji način za otvaranje izravnog P2P kanala. Audio/video promet prolazi kroz njega, pa troši propusnost poslužitelja i košta novac.
  • ICE (Interactive Connectivity Establishment) je odgovoran za testiranje svih mogućih kandidata (lokalnih adresa, koje odražavaju STUN i TURN releji) dok se ne pronađe održiva ruta.

U praksi, u vaš konfiguracijski objekt RTCPeerConnection dodajete niz iceServeri S STUN/TURN URI-jima, preglednik obavlja ostalo. Ako postavljate vlastitu infrastrukturu, morat ćete implementirati i održavati svoje STUN/TURN poslužitelje; ako koristite SDK poput Agore, Twilia ili Zegoclouda, oni su to već riješili i pripremili za produkciju.

Streaming u stvarnom vremenu s niskom latencijom: WebRTC vs HLS/DASH

Videopozivi i streaming u stvarnom vremenu s WebRTC-om i SDK-ovima

Kad pričamo prijenos uživo Postoje dva različita svijeta: protokoli temeljeni na HTTP-u (HLS, DASH) i WebRTC. HLS/DASH funkcionira preuzimanjem i reprodukcijom video segmenata s klijenta; to je savršeno za skalabilnost putem CDN-a, ali uvodi latencije od nekoliko sekundi (5-30 sekundi lako).

S druge strane, WebRTC koristi UDP + RTP i isporučuje video u "push" načinu rada od izvora do playera, s vrlo kratkim vremenima pokretanja i tipičnim latencijama ispod 500 ms (često ~250 ms) ako je mreža dobra. To postiže zahvaljujući:

  • Kontrola zagušenja integrirani, koji prilagođava brzinu prijenosa i rezoluciju u stvarnom vremenu prema gubitku paketa, jitteru ili RTT-u.
  • Korištenje učinkovitih kodeka (VP8, VP9, ​​​​H.264; sve više AV1) s hardversko ubrzanje kada je dostupno.
  • Mogućnost korištenja SVC-a (Scalable Video Coding) tako da prijemnik prima samo slojeve koje njegova mreža/uređaj može podržati.

Zato je WebRTC prirodan izbor za aukcije u stvarnom vremenu, klađenje na sport uživo, trgovanje, interaktivne igre, daljinska podrška, telemedicina, participativne virtualne učionice ili financijske nadzorne ploče koje si ne mogu priuštiti nekoliko sekundi kašnjenja.

Problem je što čisti P2P WebRTC ne skalira dobro za tisuće gledatelja; za to vam je potrebno SFU-ovi, medijski poslužitelji ili hibridne platformetu upravo dolaze do izražaja rješenja poput Flussonica, Agore ili sličnih.

Skaliranje izvan P2P-a: SFU-ovi, medijski poslužitelji i hibridne arhitekture

U videopozivu jedan na jedan, WebRTC radi besprijekorno. Ali ako počnete dodavati 10, 20 ili 100 korisnika, stvari se mijenjaju: svaki klijent mora slati/primati više streamova, njegov se CPU pregrijava, a mreža se ruši. Ovdje se pojavljuju tri klasična obrasca:

  • MCU (Višetočkovna upravljačka jedinica)Poslužitelj prima sve streamove, miksa ih i šalje jedan stream svakom klijentu. Prednost: mala potrošnja resursa na klijentu. Nedostaci: veliko opterećenje poslužitelja, manja individualna kontrola kvalitete.
  • SFU (Selektivna jedinica za prosljeđivanje)Poslužitelj prima streamove i selektivno ih prosljeđuje bez miješanja. Svaki gledatelj prima streamove koji su mu potrebni, moguće u različitim kvalitetama. Ovo je danas najčešće korišteni obrazac za videokonferencije za više korisnika i skalabilno interaktivno strujanje.
  • Hibridne arhitekture WebRTC + HLS/DASHWebRTC se koristi za unos i interakciju, dok HLS/DASH distribuira velikoj publici kojoj nije potrebna interakcija u stvarnom vremenu. To je ravnoteža između ultra niska latencija za „glumce“ i masovnu skalabilnost za „gledatelje“.

Medijski poslužitelji poput Flussonic Drugi pružaju potrebnu pozadinsku podršku: primaju WebRTC stream, po potrebi ga transkodiraju, prosljeđuju ga putem WebRTC-a drugim klijentima ili ga pretvaraju u HLS protokole za masovnu distribuciju. Ova vrsta infrastrukture je ono što u praksi omogućuje ići dalje od individualnih poziva bez potrebe za ponovnim izmišljanjem kotača.

Tipični slučajevi upotrebe: videopozivi, streaming, IoT i još mnogo toga

WebRTC je postao sveprisutan i vjerojatno ga koristite svaki dan, a da toga niste ni svjesni. Neki primjeri gdje se posebno dobro uklapa su... videopozivi i videokonferencije:

  • Videopozivi i videokonferencijeGoogle Meet, Jitsi, Slack, Microsoft Teams i mnogi drugi alati oslanjaju se na WebRTC (djelomično ili u potpunosti) za dijeljenje videa, zvuka i zaslona.
  • Usluge streaminga u stvarnom vremenuPlatforme poput Twitcha, Meta Livea, Vimeo Livestreama ili alati poput Streamyarda kombiniraju WebRTC za unos podataka i druge tehnologije za masovnu distribuciju.
  • Chat i slanje poruka s dijeljenjem datotekaZahvaljujući RTCDataChannelu možete imati chat u stvarnom vremenu, dijeljenje datoteka, sinkronizaciju statusa itd., bez centralnih medijskih poslužitelja.
  • Igre u oblaku i multiplayerUsluge poput GeForce NOW ili Xbox Cloud Gaming koriste slične tehnologije za interaktivni video; mnoge P2P igre koriste WebRTC za sinkronizaciju igranja.
  • IoT i nadzorPametne kamere, baby monitori, video zvona na vratima ili dronovi mogu slati videozapis u stvarnom vremenu na mobilne uređaje i preglednike koji koriste WebRTC.
  • Obrazovanje i telemedicina: virtualne učionice s bijelim pločama, kvizovima i dvosmjernim videom ili online medicinske konzultacije gdje su latencija i sigurnost ključni.

WebRTC sigurnost: enkripcija, dozvole i najbolje prakse

Sigurnost u WebRTC-u nije dodatna funkcija: ugrađena je. integrirano iz dizajnaSve medijske komponente su šifrirane, a API-ji rade samo sa sigurnih izvora (HTTPS ili localhost), iako je preporučljivo biti oprezan. prevare putem videopoziva.

  • DTLS-om (Datagram Transport Layer Security) šifrira podatke tijekom prijenosa.
  • SRTP (Secure Real-time Transport Protocol) štiti audio i video tako da se ne mogu lako manipulirati ili presresti.
  • Pristup kamera i mikrofon Zahtijeva izričito korisničko dopuštenje, s vidljivim vizualnim pokazateljima (ikone, obojene točkice itd.).
  • Budući da nema dodataka za instaliranje, rizik od zlonamjernog softvera prikriveni u proširenjima ili binarnim datotekama trećih strana.

Unatoč tome, morate se pobrinuti za vlastiti sloj: koristite HTTPS u cijelomPregledajte dopuštenja koja tražite, ažurirajte preglednike i biblioteke i ne zanemarujte sigurnost svog signalnog poslužitelja ili REST API-ja.

WebRTC u odnosu na druge tehnologije: VoIP, WebSockets i vlasničke platforme

Ako dolazite iz svijeta tradicionalnog VoIP-a, bit će vam poznati SIP, PBX, softphone i skupi serveri. WebRTC mijenja paradigmu: ne morate od korisnika zahtijevati da daje nikakve informacije. klijent za radnu površinu Nije potreban nikakav specifičan hardver; dovoljni su preglednik i relativno jednostavan signalni poslužitelj.

Protiv Tradicionalni VoIPWebRTC smanjuje opterećenje osnovne infrastrukture i otvara vrata aplikacijama izravno integriranim u web. U mnogim slučajevima možete ponovno koristiti svoj SIP backend putem pristupnika koji prevode signalizaciju u WebRTC.

oko WebSocketsTreba ih više promatrati kao komplementarne: idealne su za obavijesti, lagani chat ili ažuriranja statusa, ali ne i za intenzivne medije. WebRTC je optimiziran za zvuk/video u stvarnom vremenus kontrolom zagušenja, kodecima, jitter bufferom itd. U praksi mnogi projekti koriste WebSockets za signalizaciju i WebRTC za prijenos medija.

Ako ih usporedite s platformama poput Zoom, GoToMeeting ili WebExRazlika leži u modelu: ti alati su zatvorena rješenja, često s obveznim desktop aplikacijama i vlasničkim backendom. WebRTC je, s druge strane, temeljna tehnologija; možete izgraditi vlastiti "mini-Meet" na njemu ili ga integrirati s uslugama koje ga već koriste (poput Google Meeta ili Microsoft Teamsa).

Razvoj s WebRTC-om: stvarna složenost i uobičajene zamke

Iako API-ji na papiru izgledaju jednostavno, implementacija WebRTC-a od nule je složenija. Morat ćete se suočiti sa:

Kako koristiti Tor preglednik za pristup dubokom webu
Povezani članak:
Tor preglednik za Android: Napredne postavke i sigurna upotreba
  • Prilagođena signalizacijadizajniranje poruka, soba, upravljanje ponovnim vezama, ponovnim pokušajima, greškama.
  • Upravljanje LED/STUN/OKRETAImplementirajte servere, pratite korištenje TURN-a (koji troši propusnost), prilagodite vremenska ograničenja.
  • Kvaliteta usluge (QoS): prilagoditi brzine prijenosa podataka, rukovati nestabilnim mrežama, pregovarati o kodecima, otkriti kada se veza pogorša i reagirati.
  • eskaliraoPrijelaz s jednostavnog P2P-a na grupe, zatim na stotine korisnika, uvođenje SFU-ova ili medijskih poslužitelja bez narušavanja izvornog dizajna.
  • Compatibilidad entre navegadoresIako je situacija dobra, ipak ćete pronaći nijanse. Koristite adapter.js I dalje se toplo preporučuje.

U malom sporednom projektu, postavljanje Node servera sa Socket.IO i javnim STUN-om može biti dovoljno za 1:1 pozive ili vrlo male grupe. Ali ako vaša ideja raste i trebate velika gužvaBilo da se radi o finoj kontroli kvalitete, snimkama, analizi, transkripcijama ili monetizaciji, uskoro ćete morati razmotriti ili uključiti vlastiti medijski poslužiteljili prijeđite na specijaliziranog pružatelja usluga.

CDN u stvarnom vremenu s SDK-ovima: Agora, Twilio, Mux, ZEGOCLOUD…

Usluge poput Agora, Twilio, Mux, ZEGOCLOUD ili slične tehnologije grade sloj vrijednosti na WebRTC-u koji vam štedi mjesece rada i bezbroj glavobolja:

  • nude ti a globalna medijska mreža s SFU-ovima raspoređenim diljem svijeta, optimiziranim za nisku latenciju.
  • Sažetak OMAMUĆENJE/SKRETANJE, signaliziranje, ponovni pokušaji, ponovna povezivanja i složeno upravljanje mrežom.
  • Uključuju dobro održavane SDK-ove za web, iOS, Android, React Native i druge okvire.
  • Nude dodatne usluge kao što su snimanje, emitiranje na RTMP/HLS, moderiranje, statistika u stvarnom vremenu, kontrola kvalitete, korisničke uloge (voditelj, publika, govornik) itd.

Cijena je, kao što vjerojatno sumnjate, glavni problem: ako imate i malo novca mnogo minuta videa Ili, sa značajnim brojem istovremenih korisnika, račun vrtoglavo raste. Nadalje, postajete ovisni o njihovoj platformi i njezinoj cijeni ili promjenama API-ja.

U vašoj specifičnoj situaciji, s bogatim iskustvom u JavaScript u stvarnom vremenuRazumna je opcija započeti s SDK-om kako bi se ubrzao razvoj, validirao proizvod i saznalo više o njegovom modelu sobe, ulogama, životnom ciklusu streama i upravljanju stanjem. Kasnije, ako projekt krene i troškovi postanu problem, možete postupno migrirati dijelove rješenja na robusniju platformu. vlasnička WebRTC infrastruktura ili se osloniti na medijski poslužitelj tipa Flussonic za kontrolu distribucijskog sloja.

Najbolje prakse i alati za otklanjanje pogrešaka u WebRTC-u

Kako biste izbjegli da se izgubite u crnoj kutiji WebRTC-a, preporučljivo je osloniti se na alate koji već postoje u preglednicima i ekosustavu:

  • chrome: // webrtc-internals (o o:webrtc (u Firefoxu): ploča s detaljnom statistikom veza, brzina prijenosa podataka, gubitka paketa, aktivnih kodeka itd.
  • adapter.js: shim koji održava zajednica i koji ublažava razlike između preglednika i verzija.
  • test.webrtc.org: provjeriti kameru, mikrofon, mrežu i opću kompatibilnost na računalu.
  • Službeni uzorci na webrtc.github.io/samples: primjeri ograničenja, peer veza, podatkovnih kanala, dijeljenja zaslona… vrlo korisno za kopiranje obrazaca.

Također je dobra ideja strukturirati kod jasnim odvajanjem signalni sloj (utičnice, sobe, poruke) sloja Čisti WebRTC (stvaranje veze, upravljanje streamom, rukovatelji događajima). To vam omogućuje zamjenu signalizacijskog backenda ili medijskog poslužitelja bez ponovnog pisanja cijele klijentske logike.

Android i Linux
Povezani članak:
Android i Linux: Najbolje alternative za KDE Connect

Sa svim gore navedenim na stolu, za sporedni projekt koji tek počinje i gdje toliko cijenite vrijeme razvoja kao srednjoročni trošakNajuravnoteženija strategija obično je započeti s SDK-om za rad u stvarnom vremenu temeljenim na WebRTC-u koji vam omogućuje brzu iteraciju u React/React Nativeu, internaliziranje načina na koji rukuju ulogama, sesijama, životnim ciklusom streama i živim stanjima, te paralelno dublje istraživanje WebRTC-a "po koži" (getUserMedia, RTCPeerConnection, RTCDataChannel, signalizacija s Node+Socket.IO, STUN/TURN, SFU) kako ne biste bili zauvijek vezani za jednu platformu i kako biste mogli napraviti skok na prilagođenije rješenje kada proizvod to opravdava.