Ja jūs veidojat JavaScript blakusprojekts Un, ja jums ir nepieciešami videozvani, ir normāli, ja rodas šaubas: vai man vajadzētu izmantot tīru WebRTC, SDK, piemēram, Agora, Twilio, Mux vai Zegocloud, vai arī pilnībā izmantot RN-WebRTC React Native vidē? Sliktā ziņa ir tā, ka nav viena risinājuma. Labā ziņa ir tā, ka jūs saprotat reāllaika JavaScript, kas jūs nostāda ideālā pozīcijā, lai pieņemtu pārdomātu lēmumu un izvairītos no arhitektūras sajaukšanas.
Turpmākajās rindās jūs soli pa solim redzēsiet, kā tas darbojas. WebRTC iekšpusēKāda loma ir Agora (un citiem līdzīgiem pakalpojumu sniedzējiem)? Ko nozīmē izveidot savu infrastruktūru (STUN/TURN, signalizācija, SFU, multivides serveri…)? Un kādi ir reālie kompromisi starp izmaksām, sarežģītību un mērogojamību videozvaniem un reāllaika straumēšanai?
Kas ir WebRTC un kāpēc tas ir visa pamatā?
WebRTC (tīmekļa reāllaika saziņa) Tas ir atvērtā pirmkoda standartu, API un protokolu kopums, kas nodrošina audio, video un datu straumēšanu reāllaikā tieši no pārlūkprogrammas vai vietējās lietotnes, bez spraudņiem vai ārējām lietojumprogrammām. To standartizē W3C un IETF, un to atbalsta visas mūsdienu pārlūkprogrammas: Chrome, Firefox, Safari, Edge, Opera un daudzas mobilās pārlūkprogrammas.
Viņu filozofija ir skaidra: veicināt komunikāciju vienādranga (P2P) starp lietotājiem ar ļoti zemu latentumu, nemanāmi risinot visas neērtās tīkla problēmas — kodekus, svārstības, atbalsi, pakešu zudumu, šifrēšanu utt. Tas ietver visu, sākot no individuāla videozvana līdz pat sistēmai, interaktīva straumēšana ar simtiem vai tūkstošiem skatītāju, ja to apvieno ar atbilstošu infrastruktūru.
Galvenie WebRTC API: getUserMedia, RTCPeerConnection un RTCDataChannel
WebRTC balstās uz trim galvenajām pārlūkprogrammas puses API, kuras noteikti izmantosiet neatkarīgi no tā, vai veidojat savu risinājumu vai izmantojat SDK, piemēram, Agora:
- MediaStream / getUserMedia: lai uzņemtu video un audio (kamera, mikrofons un pat ekrāns vai cilnes).
- RTCPeerConnection: lai vienotos un pārsūtītu audio un video plūsmas starp vienaudžiem.
- RTCDataChannel: lai nosūtītu patvaļīgus datus (tekstu, bināros failus, failus) ar zemu latentumu starp klientiem.
ar getUserMedia Varat pieprasīt pārlūkprogrammas piekļuvi kamerai un mikrofonam un saņemt MediaStream kuru pēc tam saistāt ar elementu <video> ar video.srcObject = stream. Jūs varat pieteikties ierobežojumi (izšķirtspēja, kadru ātrums, priekšējā/aizmugurējā kamera utt.), un, ja šie nosacījumi netiek izpildīti, jūs saņemsiet tādas kļūdas kā OverconstrainedErrorkurām jums jāspēj piedāvāt alternatīvas (piemēram, samazinot izšķirtspēju no 1080p uz 720p un piemērojot korekcijas uzlabot mikrofona audio).
API saskarne RTCPeerConnection Tā ir izsaukumu sirds: tā apstrādā SDP (piedāvājuma/atbildes) sarunas, ICE (apdullināšanas/pagriešanas) kandidātu savākšanu, savienojuma izveidi un drošu pārraidi, izmantojot SRTP. No sava koda jūs vienkārši izveidojat savienojumu, pievienojat multivides ierakstus un reaģējat uz tādiem notikumiem kā onicecandidate u ontrack un jūs rūpējaties par izkārtnēm.
Visbeidzot, RTCDataChannel Tas ļauj iestatīt datu kanālus līdzīgi kā WebSocket, bet tieši no punkta uz punktu un ar precīzu uzticamības un secības kontroli. Tas ir noderīgi video tērzēšanai, failu koplietošanai, spēles stāvokļa sinhronizācijai vai sadarbībai reāllaikā. Sintakse ir pazīstama: dataChannel.send() y onmessage uztvērējā.
Signalizācija: “līme”, ko WebRTC nedefinē
Tipisks pārpratums: WebRTC neietver norādesRTCPeerConnection ir jāapmainās ar informāciju, taču tas nenosaka, kā to darīt. Jums tas ir jādefinē pašam, vai arī trešās puses SDK to var jums abstrahēt.
Pāri tiek nosūtīti, izmantojot signalizāciju:
- Sesijas vadības ziņojumi: sākt zvanu, pārtraukt zvanu, kļūdas.
- Tīkla informācijaICE kandidāti (atklātās IP adreses/porti).
- Multivides metadatiSDP piedāvā un atbild ar kodekiem, izšķirtspējām utt.
Šī zīme parasti tiek ieviesta ar WebSocketsSocket.IO, HTTP (aptauja/ilgā aptauja), MQTT vai citi divvirzienu mehānismi. Ļoti tipisks modelis ir Node.js serveris ar Socket.IO kas pārvalda “istabas” un pārsūta ziņojumus teksta/JSON tips starp klientiem:
Serveris: saņem create or joinTas izveido telpu, ja tādas nav, atbalsta līdz diviem klientiem (pamata videozvanam) un pārsūta ziņojumus. message uz citām kontaktligzdām telpā. Jūs esat atbildīgs par to, lai netiktu pārsniegts maksimālais lietotāju skaits vai lai tiktu izstrādāta jūsu telpas loģika.
KlientsIelādējot lapu, tā pieprasa telpas nosaukumu (vai secina to no URL), tā izstaro create or joinKlausieties tādus notikumus kā created, joined, full, ready un vienojas ar otru pusi par zvana sākšanu vai noraidīšanu.
Šis raksts ir ideāli piemērots prototips vai blakusprojektsTas nodrošina vieglu signalizācijas serveri, ko var mērogot ar klasteriem un slodzes līdzsvarotājiem, ja nepieciešams.
APDULLINĀŠANA, PAGRIEZIENS, AIZLEDOŠANA: NAT un ugunsmūru pārvarēšana, nekļūstot trakam
Ideālā pasaulē divi lietotāji vienmēr atrastos pieejamos tīklos un izveidotu tiešu savienojumu. Reālajā pasaulē ir NAT, ugunsmūri, CGNAT no interneta pakalpojumu sniedzējiem un paranoiskiem korporatīvajiem tīkliem. Šeit noder ICE, apvienojot STUN un TURN.
- Apdullināt (Session Traversal Utilities for NAT) ļauj klientam noskaidrot tā Publiskā IP adrese un portsSTUN serveris atbild tikai ar šo informāciju.
- Pagrieziens (Šķērsošana, izmantojot relejus ap NAT) darbojas kā releja serveris multivides, ja nav iespējams atvērt tiešu P2P kanālu. Caur to iet audio/video datplūsma, tāpēc tā patērē servera joslas platumu un ir dārga.
- ICE (Interaktīvās savienojamības izveide) ir atbildīga par visu iespējamo kandidātu (lokālo adrešu, ko atspoguļo STUN, TURN releji) testēšanu, līdz tiek atrasts dzīvotspējīgs maršruts.
Praksē savā RTCPeerConnection konfigurācijas objektā jūs pievienojat masīvu ar iceServers Ar STUN/TURN URI pārlūkprogramma paveiks pārējo. Ja izveidojat savu infrastruktūru, jums būs jāizvieto un jāuztur savi STUN/TURN serveri; ja izmantojat tādu SDK kā Agora, Twilio vai Zegocloud, viņi to jau ir nokārtojuši un sagatavojuši darbam ražošanas vidē.
Zema latentuma reāllaika straumēšana: WebRTC salīdzinājumā ar HLS/DASH
Kad mēs runājam par tiešraide Pastāv divas atšķirīgas pasaules: uz HTTP balstīti protokoli (HLS, DASH) un WebRTC. HLS/DASH darbojas, lejupielādējot un atskaņojot video segmentus no klienta; tas ir ideāli piemērots mērogojamībai, izmantojot CDN, taču tas ievieš vairāku sekunžu latentums (viegli 5–30 sekundes).
Savukārt WebRTC izmanto UDP + RTP un piegādā video "push" režīmā no avota uz atskaņotāju ar ļoti īsu palaišanas laiku un tipiskiem latentumiem, kas norādīti zemāk 500 ms (bieži vien ~250 ms), ja tīkls ir labs. Tas tiek panākts, pateicoties:
- Sastrēgumu kontrole integrēts, kas reāllaikā pielāgo bitu pārraides ātrumu un izšķirtspēju atbilstoši pakešu zudumam, svārstībām vai RTT.
- Efektīvu kodeku (VP8, VP9, H.264; arvien vairāk AV1) izmantošana ar aparatūras paātrinājums kad pieejams.
- Iespēja izmantot SVC (mērogojamu video kodēšanu), lai uztvērējs saņemtu tikai tos slāņus, kurus atbalsta tā tīkls/ierīce.
Tāpēc WebRTC ir dabiska izvēle reāllaika izsoles, tiešraides sporta totalizatori, tirdzniecība, interaktīvas spēles, attālināts atbalsts, telemedicīna, līdzdalīgas virtuālās klases vai finanšu informācijas paneļi, kas nevar atļauties vairāku sekunžu aizkavi.
Problēma ir tā, ka tīrs P2P WebRTC nav labi mērogojams tūkstošiem skatītāju; tam jums ir nepieciešams SFU, multivides serveri vai hibrīdplatformastieši tur noder tādi risinājumi kā Flussonic, Agora vai līdzīgi.
Mērogošana ārpus P2P: SFU, multivides serveri un hibrīdas arhitektūras
Individuālā videozvanā WebRTC darbojas nevainojami. Taču, ja sākat pievienot 10, 20 vai 100 lietotājus, lietas mainās: katram klientam ir jānosūta/jāsaņem vairākas straumes, tā procesors pārkarst un tīkls avarē. Šeit rodas trīs klasiskas tendences:
- MCU (daudzpunktu vadības bloks)Serveris saņem visas straumes, tās miksē un nosūta vienu straumi katram klientam. Priekšrocība: zems resursu patēriņš klienta pusē. Trūkumi: liela servera slodze, mazāk individuālas kvalitātes kontroles.
- SFU (selektīvā pāradresācijas vienība)Serveris saņem straumes un selektīvi pārsūta tās, nejaucot tās. Katrs skatītājs saņem nepieciešamās straumes, iespējams, dažādās kvalitātēs. Šis ir visbiežāk izmantotais modelis mūsdienās vairāku lietotāju videokonferences un mērogojamu interaktīvu straumēšanu.
- Hibrīda arhitektūras WebRTC + HLS/DASHWebRTC tiek izmantots informācijas pārnešanai un mijiedarbībai, savukārt HLS/DASH izplata informāciju lielām auditorijām, kurām nav nepieciešama reāllaika mijiedarbība. Tas ir līdzsvars starp īpaši zems latentums “aktieriem” un milzīga mērogojamība “skatītājiem”.
Multivides serveri, piemēram Flusoniskais Citi nodrošina nepieciešamo aizmugursistēmu: tie saņem WebRTC plūsmu, nepieciešamības gadījumā to pārkodē, pārsūta, izmantojot WebRTC, citiem klientiem, vai pārveido HLS tipa protokolos masveida izplatīšanai. Šāda veida infrastruktūra praksē ļauj pārsniegt individuālos zvanus, neizgudrojot riteni no jauna.
Tipiski lietošanas gadījumi: videozvani, straumēšana, lietu internets (IoT) un daudz kas cits
WebRTC ir kļuvis visuresošs, un jūs, iespējams, to lietojat katru dienu, to neapzinoties. Daži piemēri, kur tas īpaši labi iederas, ir... videozvani un videokonferences:
- Videozvani un videokonferencesGoogle Meet, Jitsi, Slack, Microsoft Teams un daudzi citi rīki video, audio un ekrāna kopīgošanai izmanto WebRTC (daļēji vai pilnībā).
- Reāllaika straumēšanas pakalpojumiTādas platformas kā Twitch, Meta Live, Vimeo Livestream vai rīki, piemēram, Streamyard, apvieno WebRTC satura uzņemšanai un citas tehnoloģijas masveida izplatīšanai.
- Tērzēšana un ziņojumapmaiņa ar failu koplietošanuPateicoties RTCDataChannel, jūs varat tērzēt reāllaikā, koplietot failus, sinhronizēt statusu utt. bez centrāliem multivides serveriem.
- Mākoņspēles un vairāku spēlētāju režīmsTādi pakalpojumi kā GeForce NOW vai Xbox Cloud Gaming izmanto līdzīgas tehnoloģijas interaktīvam video; daudzas P2P spēles izmanto WebRTC, lai sinhronizētu spēles gaitu.
- IoT un novērošanaViedās kameras, bērnu monitori, video durvju zvani vai droni var sūtīt reāllaika video mobilajām ierīcēm un pārlūkprogrammām, izmantojot WebRTC.
- Izglītība un telemedicīnavirtuālās klases ar tāfelēm, viktorīnām un divvirzienu video vai tiešsaistes medicīniskās konsultācijas, kurās latentums un drošība ir ļoti svarīgas.
WebRTC drošība: šifrēšana, atļaujas un labākā prakse
WebRTC drošība nav papildu funkcija: tā ir iebūvēta. integrēts jau no dizainaVisi multivides komponenti ir šifrēti, un API darbojas tikai no drošiem avotiem (HTTPS vai localhost), lai gan ieteicams būt modriem. krāpniecība, izmantojot videozvanus.
- DTLS (Datagrammu transporta slāņa drošība) šifrē datus pārsūtīšanas laikā.
- SRTP (Drošs reāllaika transporta protokols) aizsargā audio un video, lai tos nevarētu viegli manipulēt vai pārtvert.
- Piekļuve kamera un mikrofons Tam nepieciešama nepārprotama lietotāja atļauja ar redzamiem vizuāliem indikatoriem (ikonām, krāsainiem punktiem utt.).
- Tā kā nav jāinstalē spraudņi, pastāv risks, ka ļaunprātīgu programmatūru nomaskēts trešo pušu paplašinājumos vai bināros failos.
Pat ja tā, jums ir jārūpējas par savu slāni: izmantojiet HTTPS visāPārskatiet pieprasītās atļaujas, regulāri atjauniniet pārlūkprogrammas un bibliotēkas un neaizmirstiet par signalizācijas servera vai REST API drošību.
WebRTC salīdzinājumā ar citām tehnoloģijām: VoIP, WebSockets un patentētas platformas
Ja jūs nākat no tradicionālās VoIP pasaules, jūs pazīstat SIP, PBX, programmatūras telefonus un dārgus serverus. WebRTC maina paradigmu: jums nav jāpieprasa lietotājam sniegt jebkādu informāciju. darbvirsmas klients Nav nepieciešama īpaša aparatūra; pietiek ar pārlūkprogrammu un relatīvi vienkāršu signalizācijas serveri.
Pret Tradicionālais VoIPWebRTC samazina pamata infrastruktūras slodzi un paver durvis lietojumprogrammām, kas ir tieši integrētas tīmeklī. Daudzos gadījumos jūs varat atkārtoti izmantot savu SIP aizmugursistēmu, izmantojot vārtejas, kas pārvērš signālus uz WebRTC.
Respecto WebSocketsTie drīzāk būtu jāuztver kā papildinoši: tie ir ideāli piemēroti paziņojumiem, vieglai tērzēšanai vai statusa atjauninājumiem, bet ne intensīvai multivides lietošanai. WebRTC ir optimizēts reāllaika audio/videoar pārslodzes kontroli, kodekiem, svārstību buferi utt. Praksē daudzi projekti signalizācijai izmanto WebSockets un multivides pārsūtīšanai WebRTC.
Ja salīdzina tos ar tādām platformām kā Zoom, GoToMeeting vai WebExAtšķirība slēpjas modelī: šie rīki ir slēgti risinājumi, bieži vien ar obligātām darbvirsmas lietotnēm un patentētu aizmugursistēmu. Savukārt WebRTC ir pamattehnoloģija; jūs varat izveidot savu "mini-Meet" uz tās vai integrēties ar pakalpojumiem, kas to jau izmanto (piemēram, Google Meet vai Microsoft Teams).
Izstrāde ar WebRTC: reāla sarežģītība un bieži sastopamas kļūdas
Lai gan API uz papīra šķiet vienkārši, WebRTC ieviešana no nulles ir sarežģītāka. Jums būs jātiek galā ar:
- Pielāgotas izkārtnes: ziņojumu, telpu izstrāde, atkārtotas savienošanas, atkārtotu mēģinājumu un kļūdu pārvaldība.
- LEDUS/APDULLINĀŠANAS/APGRIEŠANAS pārvaldībaIzvietot serverus, uzraudzīt TURN izmantošanu (kas patērē joslas platumu), pielāgot taimautus.
- Pakalpojuma kvalitāte (QoS)pielāgot bitu pārraides ātrumu, apstrādāt nestabilus tīklus, vienoties par kodekiem, noteikt savienojuma pasliktināšanos un reaģēt.
- Mērogošana: pāriet no vienkārša P2P uz grupām, pēc tam uz simtiem lietotāju, ieviest SFU vai multivides serverus, nepārkāpjot sākotnējo dizainu.
- Saderība entre navegadoresLai gan situācija ir laba, jūs joprojām atradīsiet nianses. Izmantojiet. adapteris.js Tas joprojām ir ļoti ieteicams.
Nelielā blakusprojektā Node servera iestatīšana ar Socket.IO un publisku STUN varētu būt pietiekama individuāliem zvaniem vai ļoti mazām grupām. Taču, ja jūsu ideja aug un jums ir nepieciešams liels pūlisNeatkarīgi no tā, vai tā ir precīza kvalitātes kontrole, ieraksti, analīze, transkripcijas vai monetizācija, drīz vien jums būs jāapsver vai jāiekļauj savu multivides serverivai pāriet pie specializēta pakalpojumu sniedzēja.
Reāllaika CDN ar SDK: Agora, Twilio, Mux, ZEGOCLOUD…
Tādi pakalpojumi kā Agora, Twilio, Mux, ZEGOCLOUD vai līdzīgas tehnoloģijas izveido vērtības slāni virs WebRTC, kas ietaupa jūsu mēnešiem ilgu darbu un neskaitāmas galvassāpes:
- viņi piedāvā jums a globālais mediju tīkls ar SFU, kas izplatīti visā pasaulē un ir optimizēti zemai latentuma funkcijai.
- Kopsavilkums APDULLINĀŠANA/APGRIEŠANA, signalizācija, atkārtoti mēģinājumi, atkārtota savienošana un sarežģīta tīkla pārvaldība.
- Tie ietver labi uzturētus SDK priekš tīmeklis, iOS, Android, React Native un citi ietvari.
- Tie nodrošina papildu funkcijas, piemēram, ierakstīšana, apraide uz RTMP/HLS, moderēšana, reāllaika statistika, kvalitātes kontrole, lietotāju lomas (vadītājs, auditorija, runātājs) utt.
Kā jūs droši vien nojaušat, galvenā problēma ir izmaksas: ja jums ir kaut nedaudz naudas daudzas minūtes video Vai arī, ja vienlaikus ir ievērojams lietotāju skaits, rēķins strauji pieaug. Turklāt jūs kļūstat atkarīgs no viņu platformas un tās cenas vai API izmaiņām.
Jūsu konkrētajā situācijā, ar lielu pieredzi Reāllaika JavaScriptSaprātīga iespēja ir sākt ar SDK, lai paātrinātu izstrādi, validētu produktu un uzzinātu par tā telpas modeli, lomām, straumes dzīves ciklu un stāvokļa pārvaldību. Vēlāk, ja projekts uzņem apgriezienus un izmaksas kļūst par problēmu, varat pakāpeniski migrēt risinājuma daļas uz stabilāku platformu. patentēta WebRTC infrastruktūra vai paļauties uz Flussonic tipa multivides serveri, lai kontrolētu izplatīšanas slāni.
WebRTC atkļūdošanas labākā prakse un rīki
Lai neapmaldītos WebRTC melnajā kastē, ieteicams paļauties uz rīkiem, kas jau pastāv pārlūkprogrammās un ekosistēmā:
- hroms: // webrtc-internals (o par:webrtc (Firefox pārlūkprogrammā): panelis ar detalizētu savienojumu, bitu pārraides ātruma, pakešu zuduma, aktīvo kodeku u. c. statistiku.
- adapteris.js: kopienas uzturēts starplikas elements, kas izlīdzina atšķirības starp pārlūkprogrammām un versijām.
- tests.webrtc.org: lai pārbaudītu kameras, mikrofona, tīkla un vispārējo saderību ierīcē.
- Oficiālie paraugi vietnē webrtc.github.io/samples: ierobežojumu, līdzinieku savienojumu, datu kanālu, ekrāna koplietošanas piemēri… ļoti noderīgi modeļu kopēšanai.
Tāpat ir ieteicams strukturēt kodu, skaidri atdalot signalizācijas slānis (ligzdas, telpas, ziņojumi) no slāņa Tīrs WebRTC (savienojuma izveide, straumes pārvaldība, notikumu apstrādātāji). Tas ļauj aizstāt signalizācijas aizmugursistēmu vai multivides serveri, nepārrakstot visu klienta loģiku.
Ar visu iepriekš minēto uz galda, blakusprojektam, kas tikai sākas un kurā jūs tik ļoti novērtējat izstrādes laiks kā vidēja termiņa izmaksasVislīdzsvarotākā stratēģija parasti ir sākt ar reāllaika SDK, kas balstīts uz WebRTC, kas ļauj ātri atkārtot React/React Native, internalizēt to, kā tie apstrādā lomas, sesijas, straumes dzīves ciklu un tiešraides stāvokļus, un paralēli padziļināti iedziļināties WebRTC "pa virspusēji" (getUserMedia, RTCPeerConnection, RTCDataChannel, signalizācija ar Node+Socket.IO, STUN/TURN, SFU), lai nebūtu mūžīgi piesaistīts vienai platformai un varētu pāriet uz pielāgotāku risinājumu, kad produkts to attaisno.