Väčšina materiálu je zapnutá WebRTC sa zameriava na aplikačnú úroveň písania kódu a neprispieva k pochopeniu technológie. Pokúsme sa to ponoriť hlbšie a zistiť, ako k spojeniu dochádza, čo je deskriptor relácie a kandidáti, na čo slúžia OMÁČKA a OTOČTE server.

WebRTC

Úvod

WebRTC je technológia založená na prehliadači, ktorá umožňuje pripojenie dvoch klientov na účely prenosu videa. Hlavnými funkciami sú podpora interného prehľadávača (žiadne zabudované technológie tretích strán, ako napr Adobe Flash) a možnosť pripojenia klientov bez použitia ďalších serverov - pripojenie peer-to-peer(Ďalej, p2p).

Nadviazať spojenie p2p- dosť náročná úloha, pretože počítače nie sú vždy verejné IP adresy, to znamená adresy na internete. Kvôli malému množstvu IPv4 adries (a z bezpečnostných dôvodov) bol vyvinutý mechanizmus NAT, ktorý umožňuje vytváranie súkromných sietí napríklad pre domáce použitie. Mnoho domácich smerovačov teraz podporuje NAT a vďaka tomu majú všetky domáce zariadenia prístup na internet, hoci poskytovatelia internetu ho obvykle poskytujú IP adresa. Verejné IP adresy sú na internete jedinečné, ale súkromné ​​nie. Tak sa pripoj p2p- ťažké.

Aby ste tomu lepšie porozumeli, zvážte tri situácie: oba uzly sú v rovnakej sieti (Obrázok 1), oba uzly sú v rôznych sieťach (jeden v súkromí, druhý na verejnosti) (Obrázok 2) a oba uzly sú v rôznych súkromných sieťach s rovnakými IP adresy (Obrázok 3).

Obrázok 1: Oba uzly v rovnakej sieti

Obrázok 2: Uzly v rôznych sieťach (jeden v súkromí, druhý na verejnosti)

Obrázok 3: Uzly v rôznych súkromných sieťach, ale s číselne rovnakými adresami

Na obrázkoch vyššie označuje prvé písmeno dvojmiestneho zápisu typ uzla (p = rovesník, r = router). Na prvom obrázku je situácia priaznivá: uzly v ich sieti sú sieťou úplne identifikované IP adresy, a preto sa môžu navzájom priamo spojiť. Na druhom obrázku máme dve rôzne siete s podobným počtom uzlov. Tu sa objavujú smerovače (routery), ktoré majú dve sieťové rozhrania - vo vlastnej sieti a mimo vlastnej siete. Preto majú dve IP adresy. Bežné uzly majú iba jedno rozhranie, cez ktoré môžu komunikovať iba vo vlastnej sieti. Ak prenášajú údaje niekomu mimo ich sieť, tak iba pomocou NAT vo vnútri smerovača (smerovača), a preto sú pre ostatných viditeľné pod IP adresa smerovača je ich externý IP adresa. Teda na uzle p1 tam je interiér IP = 192.168.0.200 a externý IP = 10.50.200.5 a posledná adresa bude tiež externá pre všetky ostatné uzly v sieti. Podobná situácia pre uzol p2... Preto ich spojenie nie je možné, ak používate iba ich interné (vaše) IP adresy. Môžete použiť externé adresy, to znamená adresy smerovačov, ale keďže všetky uzly v rovnakej súkromnej sieti majú rovnakú externú adresu, je to dosť ťažké. Tento problém sa rieši pomocou mechanizmu NAT

Čo sa stane, ak sa rozhodneme prepojiť uzly prostredníctvom ich interných adries? Dáta nebudú smerovať mimo sieť. Pre zvýšenie efektu si môžete predstaviť situáciu znázornenú na poslednom obrázku - oba uzly majú rovnaké interné adresy. Ak ich používajú na komunikáciu, potom bude každý uzol komunikovať sám so sebou.

WebRTCúspešne zvláda takéto problémy pomocou protokolu ICE, ktorá však vyžaduje použitie ďalších serverov ( OMÁČKA, OTOČTE). To všetko nižšie.

Dve fázy WebRTC

Na pripojenie dvoch uzlov pomocou protokolu WebRTC(alebo jednoducho RTC ak sú dva spojené iPhone„A) Na nadviazanie spojenia je potrebné vykonať niekoľko predbežných krokov. Toto je prvá fáza - nadviazanie spojenia. Druhou fázou je prenos video údajov.

Malo by sa hneď povedať, že hoci aj technológia WebRTC vo svojej práci využíva mnoho rôznych spôsobov komunikácie ( TCP a UDP) a táto technológia má flexibilné prepínanie medzi nimi nemá protokol na prenos údajov o pripojení... To neprekvapuje, pretože spájajú dva uzly p2p nie také ľahké. Preto je potrebné nejaké mať dodatočné spôsob prenosu údajov, ktorý nijako nesúvisí WebRTC... Môže to byť soketový prenos, protokol HTTP, môže to byť dokonca protokol SMTP alebo ruská pošta. Tento prevodový mechanizmus počiatočné dáta volali signál... Nie je potrebné sprostredkovať veľa informácií. Všetky údaje sa prenášajú ako text a sú rozdelené do dvoch typov - SDP a Ľadový kandidát... Prvý typ sa používa na vytvorenie logického spojenia a druhý pre fyzické. Viac o tomto všetkom neskôr, ale nateraz je treba si to len pamätať WebRTC dá nám nejaké informácie, ktoré bude treba odovzdať do iného uzla. Hneď ako prenesieme všetky potrebné informácie, uzly sa budú môcť spojiť a naša pomoc už nebude viac potrebná. Teda signalizačný mechanizmus, ktorý musíme implementovať oddelene, bude použitý iba pri pripojeni, a nebudú použité pri prenose video údajov.

Poďme sa teda pozrieť na prvú fázu - fázu nastavenia pripojenia. Skladá sa z niekoľkých bodov. Zvážme túto fázu najskôr pre uzol, ktorý iniciuje pripojenie, a potom pre čakajúcu.

• Iniciátor (volajúci - volajúci):
  1. Ponuka na zahájenie prenosu video dát (createOffer)
  2. Získanie vášho SDP SDP)
  3. Získanie vášho Ľadový kandidát Ľadový kandidát)
• Čakajúci hovor ( volaný):
  1. Získanie miestneho (vlastného) mediálneho toku a jeho nastavenie na prenos (getUserMediaStream)
  2. Prijatie ponuky na spustenie video prenosu dát a vytvorenie odpovede (createAnswer)
  3. Získanie vášho SDP objekt a jeho prenos cez signalizačný mechanizmus ( SDP)
  4. Získanie vášho Ľadový kandidát objekty a ich prenos cez signalizačný mechanizmus ( Ľadový kandidát)
  5. Prijímanie vzdialeného (cudzieho) mediálneho toku a jeho zobrazovanie na obrazovke (onAddStream)

Rozdiel je iba v druhom bode.

Napriek zjavnej nejasnosti krokov sú v skutočnosti tri z nich: odoslanie vlastného mediálneho toku (položka 1), nastavenie parametrov pripojenia (položky 2-4), príjem mediálneho toku niekoho iného (položka 5). Najťažší je druhý krok, pretože sa skladá z dvoch častí: založenia fyzický a logické spojenia. Prvý naznačuje spôsobom, pozdĺž ktorého musia pakety ísť, aby sa dostali z jedného hostiteľa do druhého. Druhá naznačuje video / audio parametre- akú kvalitu použiť, aké kodeky použiť.

Psychicky na javisku createOffer alebo createAnswer by sa mali kombinovať s fázami prenosu SDP a Ľadový kandidát predmety.

Základné entity

Mediálne toky (MediaStream)

Hlavnou entitou je mediálny tok, to znamená prúd obrazových a zvukových údajov, obrazu a zvuku. Existujú dva typy streamov médií - lokálny a vzdialený. Lokálne prijíma údaje zo vstupných zariadení (kamera, mikrofón) a vzdialené po sieti. Každý uzol má teda lokálny aj vzdialený tok. IN WebRTC existuje rozhranie pre streamy MediaStream a je tam aj podrozhranie LocalMediaStream konkrétne pre lokálne vlákno. IN JavaScript môžete naraziť iba na prvé, a ak použijete libjingle, potom môžete naraziť na druhú.

IN WebRTC vo vlákne je pomerne zložitá hierarchia. Každý stream môže pozostávať z niekoľkých mediálnych stôp ( MediaTrack), ktoré môžu pozostávať z niekoľkých mediálnych kanálov ( MediaChannel). A samotných mediálnych tokov môže byť tiež niekoľko.

Zvážme všetko v poriadku. Aby sme to dosiahli, nezabúdajme na príklad. Povedzme, že chceme preniesť nielen video seba, ale aj video nášho stola, na ktorom je kúsok papiera, na ktorý ideme niečo napísať. Potrebujeme dve videá (my + stôl) a jedno audio (my). Je zrejmé, že my a tabuľka by sme mali byť rozdelení do rôznych vlákien, pretože tieto údaje sú pravdepodobne navzájom slabo závislé. Preto budeme mať dve MediaStream„A - jeden pre nás a druhý pre stôl. Prvý bude obsahovať obrazové aj zvukové údaje, zatiaľ čo druhý bude obsahovať iba video (obrázok 4).

Obrázok 4: Dva rôzne prúdy médií. Jeden pre nás, jeden pre náš stôl

Okamžite je zrejmé, že mediálny stream by mal obsahovať minimálne schopnosť obsahovať údaje rôznych typov - obrazové a zvukové. Toto sa v technológii zohľadňuje, a preto sa každý typ údajov implementuje prostredníctvom mediálnej stopy. MediaTrack... Mediálna stopa má zvláštnu vlastnosť milý, ktorá určuje, čo je pred nami - obraz alebo zvuk (obrázok 5)

Obrázok 5: Mediálne toky pozostávajú z mediálnych stôp

Ako sa všetko stane v programe? Vytvoríme dva mediálne toky. Potom vytvoríme dve video stopy a jednu zvukovú stopu. Poďme získať prístup k kamerám a mikrofónu. Povedzme každej stope, ktoré zariadenie má použiť. Pridajme do prvého mediálneho toku video a zvukovú stopu a do druhého mediálneho toku video stopu z inej kamery.

Ako však rozlišujeme mediálne toky na druhom konci spojenia? Za týmto účelom má každý mediálny stream túto vlastnosť štítok- štítok streamu, jeho názov (obrázok 6). Mediálne stopy majú rovnakú vlastnosť. Aj keď sa na prvý pohľad zdá, že video od zvuku sa dá rozlíšiť aj inak.

Obrázok 6: Mediálne toky a stopy sú označené štítkami

Ak teda možno mediálne stopy identifikovať pomocou štítku, prečo by sme pre náš príklad používali namiesto jedného dva mediálne toky? Môžete predsa prenášať jeden mediálny stream a používať v ňom rôzne stopy. Prišli sme k dôležitej vlastnosti mediálnych streamov - k nim synchronizovať mediálne stopy. Rôzne mediálne toky sa nesynchronizujú navzájom, ale v rámci každého mediálneho toku všetky stopy sa hrajú súčasne.

Ak teda chceme, aby sa naše slová, naše emócie na tvári a náš kúsok papiera reprodukovali súčasne, stojí za to použiť jeden mediálny prúd. Ak to nie je také dôležité, potom je výhodnejšie použiť rôzne prúdy - obraz bude plynulejší.

Ak je počas prenosu potrebné deaktivovať stopu, môžete použiť nehnuteľnosť povolené mediálne stopy.

Na konci zvážte stereofónny zvuk. Ako viete, stereofónny zvuk sú dva rôzne zvuky. A musia sa tiež prenášať osobitne. Na tento účel sa používajú kanály MediaChannel... Zvuková stopa môže mať veľa kanálov (napr. 6, ak potrebujete zvuk 5 + 1). Kanály vo vnútri mediálnej stopy, samozrejme, tiež synchronizované... Na video sa zvyčajne používa iba jeden kanál, ale niekoľko sa dá použiť napríklad na prekrytie reklám.

Zhrnúť: na prenos obrazových a zvukových údajov používame mediálny prúd. V rámci každého mediálneho toku sú synchronizované údaje. Ak nepotrebujeme synchronizáciu, môžeme použiť viac mediálnych tokov. V každom mediálnom streame sa nachádzajú dva typy mediálnych stôp - pre video a pre zvuk. Spravidla neexistujú viac ako dve stopy, ale môže ich byť viac, ak potrebujete preniesť niekoľko rôznych videí (partnera a jeho stola). Každá stopa môže pozostávať z niekoľkých kanálov, ktoré sa zvyčajne používajú iba na stereofónny zvuk.

V najjednoduchšej situácii videochatu budeme mať jeden prúd miestnych médií, ktorý bude pozostávať z dvoch stôp - videostopy a zvukovej stopy, pričom každá z nich bude pozostávať z jedného hlavného kanála. Video stopa je pre kameru, audio stopa pre mikrofón a mediálny tok je kontajnerom oboch.

Deskriptor relácie (SDP)

Rôzne počítače budú mať vždy rôzne fotoaparáty, mikrofóny, grafické karty a ďalšie vybavenie. Existuje veľa parametrov, ktoré majú. To všetko je potrebné koordinovať pre mediálny prenos údajov medzi dvoma sieťovými uzlami. WebRTC to robí automaticky a vytvorí špeciálny objekt - deskriptor relácie SDP... Odovzdajte tento objekt do iného uzla a môžu sa odovzdať mediálne údaje. Iba zatiaľ neexistuje žiadne spojenie s iným uzlom.

Na tento účel sa používa akýkoľvek signalizačný mechanizmus. SDP môžu byť prenášané aj cez zásuvky, dokonca aj osobou (povedzte to inému uzlu telefonicky), dokonca aj ruskou poštou. Je to veľmi jednoduché - dostanete hotové SDP a treba to preposlať. A po prijatí na druhej strane - previesť na oddelenie WebRTC... Deskriptor relácie je uložený ako text a dá sa vo vašich aplikáciách zmeniť, ale zvyčajne to nie je potrebné. Napríklad pri pripájaní základného telefónu je niekedy potrebné vynútiť výber požadovaného zvukového kodeku.

Zvyčajne pri vytváraní spojenia musíte uviesť napríklad nejaký druh adresy URL... To tu nie je potrebné, pretože vy sami budete posielať údaje do cieľa prostredníctvom signalizačného mechanizmu. Naznačovať WebRTCčo chceme nainštalovať p2p pripojenie, musíte zavolať funkciu createOffer. Po vyvolaní tejto funkcie a jej udelení zvláštnosti zavolaj späť„Vytvorí sa písmeno A. SDP objekt a prešiel do toho istého zavolaj späť... Všetko, čo sa od vás vyžaduje, je preniesť tento objekt cez sieť do iného uzla (partnera). Potom na druhom konci prídu údaje cez signalizačný mechanizmus, konkrétne tento SDP objekt. Tento deskriptor relácie je pre tento uzol cudzí a preto nesie užitočné informácie. Prijatie tohto objektu je signálom na nadviazanie spojenia. Preto s tým musíte súhlasiť a zavolať funkciu createAnswer. Je to úplný analóg createOffer. Späť k vášmu zavolaj späť odovzdá miestny deskriptor relácie a bude ho treba signalizovať späť.

Stojí za zmienku, že funkciu createAnswer môžete volať až po prijatí cudzej správy SDP objekt. Prečo? Pretože miestny SDP objekt, ktorý sa vygeneruje pri volaní createAnswer, sa musí spoliehať na diaľkový ovládač SDP objekt. Iba v takom prípade je možné zosúladiť vaše nastavenia videa s nastaveniami partnera. Pred prijatím miestneho mediálneho toku tiež nevolajte createAnswer a createOffer - nebudú mať do čoho písať SDP objekt .

Odv WebRTC je tu možnosť úpravy SDP objekt, potom po získaní lokálneho deskriptora musí byť nainštalovaný. Môže sa zdať trochu čudné, čo sa musí prenášať WebRTCčo nám ona sama dala, ale taký je protokol. Ak získate vzdialený deskriptor, musíte si ho nainštalovať tiež. Preto musíte na jeden uzol nastaviť dva deskriptory - svoj vlastný a cudzí (tj. Miestny a vzdialený).

Po tomto podanie ruky uzly si uvedomujú vzájomné želania. Napríklad ak uzol 1 podporuje kodeky A a B a uzol 2 podporuje kodeky B a C., potom, pretože každý uzol pozná svoje vlastné deskriptory a deskriptory niekoho iného, ​​oba uzly vyberú kodek B(Obrázok 7). Teraz je zavedená logika pripojenia a môžu sa prenášať mediálne toky, ale je tu ďalší problém - uzly sú stále spojené iba signalizačným mechanizmom.

Obrázok 7: Rokovanie o kodeku

Ľadoví kandidáti

Technológie WebRTC sa nás snaží zmiasť svojou novou metodikou. Pri vytváraní spojenia nie je uvedená adresa uzla, ku ktorému sa chcete pripojiť. Najskôr nainštalované logické spojenie skôr ako fyzický, aj keď sa to vždy dialo opačne. Ale to sa nebude zdať čudné, ak nezabudneme, že používame signalizačný mechanizmus tretej strany.

Spojenie teda už bolo nadviazané (logické spojenie), ale zatiaľ neexistuje cesta, cez ktorú by uzly siete mohli prenášať údaje. Nie je to tu také jednoduché, ale začnime jednoducho. Nech sú uzly v tej istej súkromnej sieti. Ako už vieme, môžu sa navzájom ľahko spojiť pomocou svojho vnútra IP adresy (alebo prípadne iné, ak sa nepoužívajú) TCP / IP).

Cez niektoré zavolaj späť„a WebRTC informuje nás Ľadový kandidát predmety. Prichádzajú tiež v textovej podobe a rovnako ako v prípade deskriptorov relácií, je potrebné ich jednoducho odoslať prostredníctvom signalizačného mechanizmu. Ak deskriptor relácie obsahoval informácie o našich nastaveniach na úrovni kamery a mikrofónu, potom kandidáti obsahujú informácie o našom umiestnení v sieti. Preneste ich do iného uzla a on sa s nami bude môcť fyzicky spojiť, a keďže už má deskriptor relácie, bude sa logicky môcť pripojiť a údaje budú „prúdiť“. Ak nám nezabudne poslať svoj kandidátsky objekt, teda informáciu o tom, kde sa v sieti nachádza, potom sa s ním dokážeme spojiť. Tu si všimnite ešte jeden rozdiel od klasickej interakcie klient-server. Komunikácia so serverom HTTP prebieha podľa schémy požiadaviek a odpovedí, klient odosiela dáta na server, ktorý ich spracuje a odošle cez adresa uvedená v pakete žiadosti... IN WebRTC potreba vedieť dve adresy a spojte ich z oboch strán.

Rozdiel od deskriptorov relácií je v tom, že je potrebné nastaviť iba vzdialených kandidátov. Úpravy sú tu zakázané a nemôžu byť prospešné. V niektorých implementáciách WebRTC kandidátov je potrebné nainštalovať až po nastavení deskriptorov relácií.

Prečo bol iba jeden deskriptor relácie, ale kandidátov môže byť veľa? Pretože umiestnenie v sieti je možné určiť nielen podľa jej interných IP adresa, ale aj externá adresa smerovača, a nie nevyhnutne jedna, ako aj adresy OTOČTE servery. Zvyšok tejto časti bude venovaný podrobnej diskusii o kandidátoch a spôsobe pripojenia uzlov z rôznych súkromných sietí.

Dva uzly sú teda v tej istej sieti (obrázok 8). Ako ich identifikujete? Cez IP adresy. Nijak inak. Je pravda, že stále môžete použiť rôzne transporty ( TCP a UDP) a rôzne porty. Toto sú informácie obsiahnuté v kandidátskom objekte - IP, PRÍSTAV, DOPRAVA a niektoré ďalšie. Nechajme napríklad použiť UDP doprava a 531 prístav.

Obrázok 8: Dva uzly sú v rovnakej sieti

Potom, ak sme v uzle p1 potom WebRTC dá nám taký objekt kandidáta - ... Toto nie je presný formát, ale iba schéma. Ak sme v uzle p2, potom kandidátom je - ... Prostredníctvom signalizačného mechanizmu p1 prijme kandidáta p2(to znamená umiestnenie uzla p2, a to jeho IP a PRÍSTAV). Potom p1 sa môže spojiť s p2 priamo. Presnejšie, p1 pošle údaje na adresu 10.50.150.3:531 v nádeji, že sa dostanú p2... Nezáleží na tom, či táto adresa patrí k uzlu p2 alebo nejaky prostrednik. Jedinou dôležitou vecou je, že údaje sa budú posielať na túto adresu a môžu byť dostupné p2.

Zatiaľ čo uzly sú v rovnakej sieti - všetko je jednoduché a ľahké - každý uzol má iba jeden kandidátsky objekt (vždy myslíme jeho vlastný, to znamená jeho umiestnenie v sieti). Keď budú uzly, bude tu oveľa viac kandidátov rôzne sietí.

Prejdime k zložitejšiemu prípadu. Jeden uzol bude za smerovačom (presnejšie za NAT) a druhý uzol bude v rovnakej sieti s týmto smerovačom (napríklad na internete) (obrázok 9).

Obrázok 9: Jeden hostiteľ za NAT, druhý nie

Tento prípad má konkrétne riešenie problému, ktorý teraz zvážime. Domáci router obvykle obsahuje tabuľku NAT... Toto je špeciálny mechanizmus navrhnutý tak, aby uzly v súkromnej sieti smerovača mohli pristupovať napríklad k webovým stránkam.

Predpokladajme, že webový server je priamo pripojený k internetu, to znamená, že je verejný IP* adresa. Nech je to uzol p2... Uzol p1(webový klient) zašle požiadavku na adresu 10.50.200.10 ... Najskôr údaje idú do smerovača R1, alebo skôr na jeho interiér rozhranie 192.168.0.1 ... Potom si router pamätá zdrojovú adresu (adresa p1) a zadá ju do osobitnej tabuľky NAT, potom zmení zdrojovú adresu na svoju vlastnú ( p1 → R1). Ďalej svojim spôsobom externý rozhranie, smerovač odosiela údaje priamo na webový server p2... Webový server údaje spracuje, vygeneruje odpoveď a odošle ich späť. Odošle sa do smerovača R1, pretože je to on, kto je na spiatočnej adrese (router zmenil adresu na svoju vlastnú). Router prijíma údaje, pozerá sa do tabuľky NAT a odošle údaje do uzla p1... Router tu funguje ako sprostredkovateľ.

Čo však v prípade, ak niekoľko uzlov z internej siete súčasne pristupuje k externej sieti? Ako bude smerovač vedieť, komu poslať odpoveď späť? Tento problém je vyriešený pomocou prístavy... Keď smerovač nahradí adresu hostiteľa vlastnou, nahradí tiež port. Ak dva uzly pristupujú na internet, router nahradí ich zdrojové porty znakom rôzne... Keď sa paket z webového servera vráti späť do smerovača, smerovač to pochopí podľa portu, ktorému je tento paket priradený. Pozri príklad nižšie.

Späť k technológiám WebRTC, alebo skôr k jeho časti, ktorá používa ICE protokol (teda Ľad kandidáti). Uzol p2 má jedného kandidáta (jeho umiestnenie v sieti - 10.50.200.10 ) a uzol p1 za smerovačom NAT budú mať dvaja kandidáti - miestni ( 192.168.0.200 ) a kandidát na smerovač ( 10.50.200.5 ). Prvý z nich nie je užitočný, ale od tej doby sa generuje WebRTC zatiaľ nevie nič o vzdialenom hostiteľovi - môže alebo nemusí byť v rovnakej sieti. Druhý kandidát sa bude hodiť a ako už vieme, prístav bude hrať dôležitú úlohu (dostať sa cez NAT).

Vstup do tabuľky NAT generované iba vtedy, keď dáta opustia internú sieť. Preto uzol p1 najskôr musíte preniesť údaje a až potom po týchto údajoch uzla p2 bude schopný dosiahnuť uzol p1.

Na praxi obidva uzly bude pozadu NAT... Vytvorenie záznamu v tabuľke NAT každého smerovača musia uzly niečo poslať do vzdialeného uzla, ale tentokrát sa ani prvý nemôže dostať k druhému, ani naopak. Je to spôsobené tým, že uzly nepoznajú svoje vonkajšie IP adresy a odosielanie dát na interné adresy je nezmyselné.

Ak sú však známe externé adresy, potom sa spojenie ľahko vytvorí. Ak prvý uzol odosiela údaje do smerovača druhého uzla, smerovač ich od svojej tabuľky bude ignorovať NAT je stále prázdny. Avšak v smerovači prvého uzla v tabuľke NAT je potrebný záznam. Ak teraz druhý uzol odosiela údaje do smerovača prvého uzla, smerovač ich úspešne prenesie do prvého uzla. Teraz tabuľka NAT druhý router potrebuje dáta.

Problém je v tom, že aby ste zistili svoj vonkajší IP adresa, potrebujete uzol umiestnený vo verejnej sieti. Na vyriešenie tohto problému sa používajú ďalšie servery, ktoré sú priamo pripojené k internetu. S ich pomocou sa tiež vytvárajú drahocenné záznamy v tabuľke. NAT.

STUN a TURN servery

Pri inicializácii WebRTC musíte určiť dostupné OMÁČKA a OTOČTE servery, ktoré budeme ďalej nazývať ICE servery. Ak nie sú zadané žiadne servery, potom iba uzly v jednej sieti (pripojené k nej bez NAT). Hneď je potrebné poznamenať, že pre 3g- musia byť použité siete OTOČTE servery.

OMÁČKA server Je to jednoducho server na internete, ktorý vracia spiatočnú adresu, to znamená adresu uzla odosielateľa. Uzol za adresami smerovača OMÁČKA server prejsť NAT... Balík, ktorý prišiel OMÁČKA server, obsahuje zdrojovú adresu - adresu smerovača, to znamená externú adresu nášho uzla. Táto adresa OMÁČKA server a odošle späť. Uzol teda prijíma svoje externé IP adresa a port, cez ktorý je prístupný zo siete. Ďalej WebRTC pomocou tejto adresy sa vytvorí ďalší kandidát (externá adresa smerovača a portu). Teraz v tabuľke NAT smerovač má položku, ktorá odosiela pakety odoslané smerovaču na požadovanom porte do nášho uzla.

Pozrime sa na tento proces na príklade.

Príklad (práca servera STUN)

OMÁČKA server bude označený s1... Router, ako predtým, prešiel R1 a uzol - skrz p1... Budete tiež musieť postupovať podľa tabuľky NAT- označujeme to ako r1_nat... Táto tabuľka navyše zvyčajne obsahuje veľa záznamov z rôznych uzlov podsiete - nebudú sa zobrazovať.

Takže na začiatku máme prázdny stôl r1_nat.

Tabuľka 2: Hlavička balíka

Uzol p1 pošle tento paket smerovaču R1(bez ohľadu na to, ako sa dajú v rôznych podsietiach použiť rôzne technológie). Router musí zmeniť zdrojovú adresu Src IP, pretože adresa uvedená v pakete zjavne nie je vhodná pre externú podsieť, sú navyše adresy z tohto rozsahu vyhradené a žiadna adresa na internete takúto adresu nemá. Router vykoná v pakete zámenu a vytvorí nový záznam vo svojej tabuľke r1_nat... Aby to urobil, musí prísť s číslom portu. Pripomeňme, že keďže niekoľko uzlov v rámci podsiete má prístup k externej sieti, tabuľka NAT musia byť uložené ďalšie informácie, aby smerovač mohol určiť, pre ktorý z týchto niekoľkých uzlov je spätný paket zo servera určený. Nechajte smerovač prísť s portom 888 .

Upravená hlavička balíka:

Tabuľka 4: Tabuľka NAT bola aktualizovaná o nový záznam

Tu IP adresa a port podsiete sú úplne rovnaké ako v pôvodnom pakete. Vskutku, po postbacke, musíme mať spôsob, ako ich úplne obnoviť. IP adresa externej siete je adresa smerovača a port sa zmenil na ten, ktorý vynašiel smerovač.

Skutočný port, do ktorého je hostiteľ p1 prijíma spojenie - to samozrejme 35777 , ale server odosiela údaje do fiktívne prístav 888 , ktoré router zmení na skutočný 35777 .

Smerovač teda zmenil zdrojovú adresu a port v hlavičke paketu a pridal záznam do tabuľky NAT... Teraz je paket odoslaný cez sieť na server, to znamená na uzol s1... Pri vchode, s1 má takýto balík:

Src IP	Src PORT	Cieľová IP	Dest PORT
10.50.200.5	888	12.62.100.200	6000

Tabuľka 5: Server STUN prijal paket

Celkom OMÁČKA server vie, že dostal paket z adresy 10.50.200.5:888 ... Teraz server pošle túto adresu späť. Stojí za to sa tu zastaviť a ešte raz sa pozrieť na to, na čo sme sa práve pozreli. Tabuľky vyššie sú úryvkom z nadpis balíček, vôbec nie z jeho obsah... Nehovorili sme o obsahu, pretože to nie je také dôležité - je to nejako opísané v protokole OMÁČKA... Teraz okrem názvu zvážime aj obsah. Bude to jednoduché a bude obsahovať adresu smerovača - 10.50.200.5:888 , hoci sme to vzali nadpis balíček. Nerobí sa to často, zvyčajne sa protokoly nestarajú o informácie o adresách hostiteľa, je len dôležité, aby sa pakety doručovali na určené miesto. Tu sa pozeráme na protokol, ktorý ustanovuje cestu medzi dvoma uzlami.

Takže teraz máme druhý paket, ktorý ide opačným smerom:

Tabuľka 7: Server STUN odošle paket s týmto obsahom

Ďalej paket cestuje po sieti, kým nedosiahne externé rozhranie smerovača. R1... Router chápe, že paket nie je určený pre neho. Ako to chápe? Toto je možné nájsť iba v prístave. Prístav 888 nepoužíva pre svoje vlastné účely, ale používa pre tento mechanizmus NAT... Preto sa router pozerá na túto tabuľku. Pozrie sa na stĺpec Externý PORT a hľadá reťazec, ktorý sa zhoduje Dest PORT z prichádzajúceho balíka, to je 888 .

Interná IP	Interný PORT	Externá IP	Externý PORT
192.168.0.200	35777	10.50.200.5	888

Tabuľka 8: Tabuľka NAT

Máme šťastie, taká linka existuje. Keby sme nemali šťastie, paket by sa jednoducho zahodil. Teraz musíte pochopiť, ktorý z uzlov v podsieti by mal odoslať tento paket. Urobte si čas, znovu si pripomeňme dôležitosť portov v tomto mechanizme. Súčasne dvaja hostitelia v podsiete mohli odosielať požiadavky do externej siete. Potom, ak pre prvý uzol smerovač prišiel s portom 888 , potom by na druhý prišiel s prístavom 889 ... Predpokladajme, že je to tak, teda tabuľka r1_nat vyzerá takto:

Tabuľka 10: Smerovač falšuje adresu prijímača

Src IP	Src PORT	Cieľová IP	Dest PORT
12.62.100.200	6000	192.168.0.200	35777

Tabuľka 11: Router zmenil adresu prijímača

Paket dorazí do uzla úspešne p1 a pri pohľade na obsah balíka sa uzol dozvie o svojich externých IP adresa, to znamená adresa smerovača v externej sieti. Pozná tiež port, cez ktorý smerovač prechádza NAT.

Čo bude ďalej? Na čo sa to všetko používa? Výhoda je záznam v tabuľke r1_nat... Ak teraz niekto pošle smerovač R1 balíček s portom 888 , potom smerovač presmeruje tento paket na uzol p1... Tak vznikol malý úzky priechod do skrytého uzla. p1.

Z vyššie uvedeného príkladu môžete získať určitú predstavu o diele NAT a podstata OMÁČKA server. Spravidla ide o mechanizmus ICE a OMRAČENIE / OTOČENIE servery sú zamerané iba na prekonanie obmedzení NAT.

Medzi uzlom a serverom môže byť viac ako jeden smerovač. V takom prípade uzol dostane adresu smerovača, ktorý ako prvý vstúpi do rovnakej siete ako server. Inými slovami, získame adresu routera, ku ktorému je pripojený OMÁČKA server. Pre p2p komunikácia je práve to, čo potrebujeme, ak nezabudneme na skutočnosť, že každý smerovač pridá do tabuľky riadok, ktorý potrebujeme NAT... Preto bude spiatočná cesta opäť rovnako hladká.

OTOČTE server je vylepšený OMÁČKA server. Z toho by sa malo okamžite čerpať OTOČTE server môže fungovať a ako OMÁČKA server. Existujú však aj výhody. Ak p2p komunikácia nie je možná (ako v 3g siete), potom sa server prepne do režimu prenosu ( štafeta), to znamená, že funguje ako sprostredkovateľ. Samozrejme, že nie o hocijakých p2p potom to nie je otázka, ale mimo rámca mechanizmu ICE uzly si myslia, že komunikujú priamo.

V akých prípadoch je to nevyhnutné OTOČTE server? Prečo nie dosť OMÁČKA server? Faktom je, že existuje niekoľko odrôd NAT... Rovnako nahrádzajú IP adresa a port, niektoré z nich však majú zabudovanú dodatočnú ochranu proti „neoprávnenej manipulácii“. Napríklad v symetrický stôl NAT Uložia sa ďalšie 2 parametre - IP a port vzdialeného hostiteľa. Paket z externej siete prechádza NAT do internej siete, iba ak sa zdrojová adresa a port zhodujú s údajmi uvedenými v tabuľke. Preto zameranie s OMÁČKA server zlyhá - tabuľka NAT uloží adresu a port OMÁČKA server a keď smerovač prijme paket od WebRTC partnera, zbaví ho, pretože je „sfalšovaný“. Nepochádzalo to z OMÁČKA server.

Touto cestou OTOČTE server je potrebný, keď sú obaja partneri pozadu symetrický NAT(každý za svoje).

Krátke zhrnutie

Tu je niekoľko vyhlásení o entitách WebRTC to treba mať vždy na pamäti. Sú podrobne opísané vyššie. Ak sa vám niektoré z vyhlásení nezdajú úplne jasné, prečítajte si znova príslušné odseky.

• Mediálny prúd
  • Obrazové a zvukové údaje sa zhromažďujú do mediálnych tokov
  • Mediálne toky synchronizujú tvorené mediálne stopy
  • Rôzne mediálne toky sa navzájom nesynchronizujú
  • Mediálne toky môžu byť lokálne a vzdialené, k miestnemu sa zvyčajne pripája kamera a mikrofón, vzdialené prijímajú údaje zo siete v zakódovanej podobe
  • Existujú dva typy mediálnych stôp - pre video a pre audio
  • Mediálne stopy sa dajú zapnúť / vypnúť
  • Mediálne stopy sa skladajú z mediálnych kanálov
  • Mediálne stopy synchronizujú mediálne kanály, ktoré tvoria
  • Mediálne toky a mediálne stopy majú štítky, podľa ktorých je možné ich rozlíšiť
• Deskriptor relácie
  • Deskriptor relácie sa používa na logické pripojenie dvoch hostiteľov
  • Deskriptor relácie ukladá informácie o dostupných metódach kódovania obrazových a zvukových údajov
  • WebRTC využíva externý signalizačný mechanizmus - úlohu preposielania deskriptorov relácií ( sdp) pripadá na aplikáciu
  • Mechanizmus logického spojenia pozostáva z dvoch etáp - viet ( ponuka) a odpovedať ( odpoveď)
  • Generovanie deskriptora relácie je nemožné bez použitia miestneho mediálneho toku v prípade ponuky ( ponuka) a je nemožné bez použitia deskriptora vzdialenej relácie v prípade odpovede ( odpoveď)
  • Výsledný deskriptor musí byť daný implementácii WebRTC a nezáleží na tom, či je tento deskriptor získaný na diaľku alebo lokálne z rovnakej implementácie WebRTC
  • Je možné mierne upraviť deskriptor relácie
• Kandidáti
  • Kandidát ( Ľadový kandidát) Je adresa uzla v sieti
  • Adresa uzla môže byť vlastná, alebo to môže byť adresa smerovača alebo OTOČTE server
  • Kandidátov je vždy veľa
  • Kandidát sa skladá z IP adresa, prístav a typ prepravy ( TCP alebo UDP)
  • Kandidáti sa používajú na nadviazanie fyzického spojenia medzi dvoma uzlami v sieti
  • Kandidátov je tiež potrebné vyslať prostredníctvom signalizačného mechanizmu
  • Kandidáti musia byť tiež prevedení na implementácie WebRTC ale iba na dialku
  • V niektorých implementáciách WebRTC kandidátov je možné odovzdať až po nastavení deskriptora relácie
• OMÁČKA / OBRAT / ĽAD / NAT
  • NAT- mechanizmus poskytovania prístupu do externej siete
  • Domáce smerovače udržiavajú špeciálnu tabuľku NAT
  • Smerovač nahrádza adresy v paketoch - zdrojovú adresu za svoju, ak ide o paket do externej siete, a adresu prijímača na adresu hostiteľa v internej sieti, ak paket pochádzal z externej siete
  • Poskytovať viackanálový prístup k externej sieti NAT používa porty
  • ICE- obtokový mechanizmus NAT
  • OMÁČKA a OTOČTE servery - pomocníci pri obchádzaní NAT
  • OMÁČKA server umožňuje vytvárať potrebné záznamy v tabuľke NAT a tiež vráti externú adresu uzla
  • OTOČTE server sumarizuje OMÁČKA mechanizmus a robí to vždy funkčným
  • V najhorších prípadoch OTOČTE server sa používa ako sprostredkovateľ ( štafeta), t. j p2p premení na komunikáciu klient-server-klient.

Účelom tohto článku je zoznámiť sa s jeho štruktúrou a princípom fungovania pomocou ukážkovej vzorky videorozhovoru peer-to-peer (videorozhovor p2p). Na tento účel použijeme ukážku viacužívateľského videochatu webrtc.io-demo. Je možné ho stiahnuť z odkazu: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

Je potrebné poznamenať, že GitHub je web alebo webová služba na spoločný vývoj webových projektov. Na ňom môžu vývojári zverejňovať kódy svojho vývoja, diskutovať o nich a komunikovať medzi sebou. Na tejto stránke navyše niektoré veľké IT spoločnosti hosťujú svoje oficiálne úložiská. Služba je pre projekty typu open source bezplatná. GitHub je úložiskom knižníc otvoreného zdroja.

Takže ukážkovú ukážku videochatu peer-to-peer stiahnutú z GitHubu umiestnime na jednotku C osobného počítača do vytvoreného adresára pre našu aplikáciu „webrtc_demo“.

Obr. jeden

Ako vyplýva zo štruktúry (obr. 1), videohovor typu peer-to-peer sa skladá z klientských skriptov script.js a server-side server.js, implementovaných v programovacom jazyku JavaScript. Skript (knižnica) webrtc.io.js (CLIENT) - poskytuje organizáciu komunikácie v reálnom čase medzi prehľadávačmi v schéme peer-to-peer: „klient-klient“ a webrtc.io.js (CLIENT) a webrtc .io.js (SERVER) pomocou protokolu WebSocket zabezpečujú plne duplexnú komunikáciu medzi prehliadačom a webovým serverom podľa architektúry „klient-server“.

Skript webrtc.io.js (SERVER) je zahrnutý v knižnici webrtc.io a nachádza sa v adresári node_modules \ webrtc.io \ lib. Rozhranie videorozhovoru index.html je implementované v HTML5 a CSS3. Obsah súborov aplikácie webrtc_demo je možné zobraziť v jednom z editorov html, napríklad „Notepad ++“.

Skontrolujeme, ako funguje videochat v súborovom systéme PC. Ak chcete spustiť server (server.js) na počítači PC, musíte si nainštalovať runtime node.js. Node.js umožňuje spustenie kódu JavaScript mimo prehľadávača. Môžete si stiahnuť node.js z odkazu: http://nodejs.org/ (verzia v0.10.13 dňa 15.7.13). Na hlavnej stránke webu node.org kliknite na tlačidlo sťahovania a prejdite na stránku http://nodejs.org/download/. Pre používateľov systému Windows si najskôr stiahnite súbor win.installer (.msi), potom spustite program win.installer (.msi) na počítači PC a nainštalujte súbory nodejs a „npm package manager“ do adresára Program Files.

Obr. 2

Node.js teda pozostáva z vývojového a exekučného prostredia pre kód JavaScript, ako aj zo sady interných modulov, ktoré je možné nainštalovať pomocou správcu balíkov npm alebo správcu.

Ak chcete nainštalovať moduly, musíte spustiť príkaz v príkazovom riadku z adresára aplikácie (napríklad „webrtc_demo“): npm install module_name... Počas inštalácie modulov manažér npm vytvorí priečinok node_modules v adresári, z ktorého bola vykonaná inštalácia. V tomto procese nodejs automaticky pripája moduly z adresára node_modules.

Po nainštalovaní node.js teda otvorte príkazový riadok a pomocou správcu balíkov npm aktualizujte expresný modul v priečinku node_modules adresára webrtc_demo:

C: \ webrtc_demo> npm install express

Expresný modul je webový rámec pre node.js alebo webový rámec pre vývoj aplikácií. Ak chcete mať globálny prístup k expresom, môžete si ich nainštalovať takto: npm install -g express.

Potom aktualizujeme modul webrtc.io:

C: \ webrtc_demo> npm nainštalovať webrtc.io

Potom na príkazovom riadku spustite server: server.js:

C: \ webrtc_demo> uzol server.js

Obr. 3

Server pracuje úspešne (Obrázok 3). Teraz pomocou webového prehľadávača môžete získať prístup na server pomocou adresy IP a stiahnuť webovú stránku index.html, z ktorej webový prehľadávač extrahuje kód skriptu klienta - script.js a kód skriptu webrtc.io.js, a popraviť ich. Aby videohovor typu peer-to-peer fungoval (na nadviazanie spojenia medzi dvoma prehľadávačmi), je potrebné z dvoch prehľadávačov, ktoré podporujú webrtc, kontaktovať signalizačný server bežiaci na node.js pomocou adresy IP.

Vďaka tomu sa otvorí rozhranie klientskej časti komunikačnej aplikácie (videochat) so žiadosťou o povolenie prístupu ku kamere a mikrofónu (obr. 4).

Obr. štyri

Po kliknutí na tlačidlo „Povoliť“ sú fotoaparát a mikrofón spojené pre multimediálnu komunikáciu. Okrem toho môžu byť textové údaje komunikované prostredníctvom rozhrania videochatu (obr. 5).

Obr. päť

Je potrebné poznamenať, že. Server signalizuje a jeho účelom je predovšetkým nadviazať spojenie medzi prehľadávačmi používateľov. Node.js sa používa na spustenie skriptu server.js, ktorý poskytuje signalizáciu WebRTC.

WebRTC je dnes najhorúcejšou technológiou na streamovanie zvuku a videa v prehľadávačoch. Konzervatívne technológie ako HTTP Streaming a Flash sú vhodnejšie na distribúciu zaznamenaného obsahu (video na požiadanie) a sú z hľadiska vysielania v reálnom čase a online výrazne nižšie ako WebRTC, t. kde je vyžadovaná minimálna latencia videa, čo umožňuje divákom vidieť, čo sa deje „naživo“.

Možnosť vysokokvalitnej komunikácie v reálnom čase pochádza zo samotnej architektúry WebRTC, kde sa na prenos video streamov používa protokol UDP, ktorý je štandardným základom pre prenos videa s minimálnymi oneskoreniami a je široko používaný v komunikačných systémoch v reálnom čase.

Latencia komunikácie je dôležitá v systémoch online vysielania, webinároch a iných aplikáciách, kde sa vyžaduje interaktívna komunikácia so zdrojom videa, koncovými používateľmi a riešením.

Ďalším dobrým dôvodom na vyskúšanie WebRTC je určite trend. V súčasnosti každý prehliadač Android Chrome podporuje túto technológiu, ktorá zaručuje milióny zariadení pripravených sledovať vysielanie bez inštalácie ďalšieho softvéru alebo konfigurácií.

Aby sme mohli vyskúšať technológiu WebRTC v praxi a spustiť na nej jednoduché online vysielanie, použili sme softvér Flashphoner WebRTC Media & Broadcasting Server. Funkcie deklarujú schopnosť vysielať toky WebRTC v režime one-to-many, ako aj podporu pre IP kamery a systémy sledovania videa prostredníctvom protokolu RTSP; v tomto prehľade sa zameriame na webové vysielanie a ich vlastnosti.

Inštalácia servera WebRTC pre médiá a vysielanie

Pretože pre Windows neexistovala serverová verzia a nechcel som inštalovať virtuálny stroj ako VMWare + Linux, nemohol som testovať online vysielanie na domácom počítači so systémom Windows. Aby sme ušetrili čas, rozhodli sme sa pre inštanciu cloudového hostingu, ako je tento:

Bol to procesor Centos x86_64 verzie 6.5 bez predinštalovaného softvéru v amsterdamskom datacentre. Jediné, čo máme k dispozícii, je teda server a ssh prístup k nemu. Pre tých, ktorí poznajú príkazy konzoly Linux, je inštalácia servera WebRTC sľubná ako jednoduchá a bezbolestná. Čo sme teda urobili:

1. Stiahnutie archívu:

$ wget https: //site/download-wcs5-server.tar.gz

2. Rozbaliť:

$ tar -xzf download-wcs5-server.tar.gz

3. Inštalácia:

$ cd FlashphonerWebCallServer

Počas inštalácie zadajte adresu IP servera: XXX.XXX.XXX.XXX

4. Aktivovať licenciu:

$ cd / usr / local / FlashphonerWebCallServer / bin

$. / activation.sh

5. Spustiť server WCS:

$ service webcallserver štart

6. Skontrolujte denník:

$ tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log

7. Skontrolujte, či sú zavedené dva procesy:

$ ps aux | grep Flashphoner

Inštalačný proces je dokončený.

Testovanie online vysielania WebRTC

Testovanie vysielania sa ukázalo ako jednoduchá záležitosť. Okrem servera existuje webový klient, ktorý sa skladá z tucta súborov Javascript, HTML a CSS a počas fázy inštalácie sme ho nasadili do priečinka / var / www / html. Jediné, čo bolo treba urobiť, bolo zadať adresu IP servera do konfigurácie flashphoner.xml, aby mohol webový klient nadviazať spojenie so serverom prostredníctvom serverov HTML5 Websockets. Popíšme si proces testovania.

1. V prehliadači Chrome otvorte testovaciu stránku index.html klienta:

2. Ak chcete spustiť vysielanie, musíte stlačiť tlačidlo „Štart“ v strede obrazovky.
Predtým, ako to urobíte, musíte skontrolovať, či je webová kamera pripojená a pripravená na použitie. Na webovú kameru nie sú kladené žiadne špeciálne požiadavky, použili sme napríklad štandardnú vstavanú kameru notebooku s rozlíšením 1280 × 800.

Prehliadač Chrome určite požiada o prístup ku kamere a mikrofónu, aby používateľ pochopil, že jeho video bude odoslané na internetový server, a umožní mu to.

3. Rozhranie predstavuje úspešné vysielanie obrazového toku z kamery na server WebRTC. V pravom hornom rohu indikátor indikuje, že stream smeruje na server, v dolnom rohu je tlačidlo Stop na zastavenie odosielania videa.

Všimnite si odkaz v poli nižšie. Obsahuje jedinečný identifikátor tohto streamu, takže sa k zobrazeniu môže pripojiť každý. Tento odkaz stačí otvoriť v prehliadači. Ak ho chcete skopírovať do schránky, kliknite na tlačidlo „Kopírovať“.

V skutočných aplikáciách, ako sú webináre, prednášky, online video vysielanie alebo interaktívna televízia, budú vývojári musieť implementovať distribúciu tohto identifikátora určitým skupinám divákov, aby sa mohli pripojiť k potrebným streamom, ale to je logika aplikácie. Server médií a vysielania WebRTC neovplyvňuje to, ale zaoberá sa iba distribúciou videa.

5. Pripojenie je nadviazané a divák vidí stream na obrazovke. Teraz môže pomocou ovládacích prvkov v pravom dolnom rohu poslať odkaz niekomu inému, zastaviť prehrávanie streamu alebo zapnúť režim celej obrazovky.

Výsledky testovania servera WebRTC online vysielania

Počas testov vyzerala latencia perfektne. Ping do dátového centra bol asi 100 milisekúnd a latencia bola pre oko neviditeľná. Môžeme teda predpokladať, že skutočné oneskorenie je rovnaké 100 plus alebo mínus niekoľko desiatok milisekúnd pre čas ukladania do vyrovnávacej pamäte. V porovnaní s videom Flash: v takýchto testoch sa Flash nespráva tak dobre ako WebRTC. Pokiaľ teda pohybujete rukou v podobnej sieti, potom je pohyb na obrazovke viditeľný až po jednej / dvoch sekundách.

Pokiaľ ide o kvalitu, poznamenávame, že niekedy môžete odlíšiť kocky od pohybov. To je v súlade s povahou kodeku VP8 a jeho hlavným účelom - poskytovať video komunikáciu v reálnom čase s prijateľnou kvalitou a bez oneskorenia v komunikácii.

Inštalácia a konfigurácia servera je celkom jednoduchá, na jeho spustenie nepotrebujete žiadne vážne znalosti okrem znalostí Linuxu na úrovni pokročilého používateľa, ktorý dokáže z konzoly vykonávať príkazy pomocou ssh a používať textový editor. Vo výsledku sa nám podarilo zaviesť medzi mnohými online vysielanie medzi mnohými. Pripojenie ďalších divákov k streamu tiež nespôsobilo problémy.

Kvalita vysielania sa ukázala ako celkom prijateľná pre webové semináre a online vysielanie. Jediná vec, ktorá vyvolala určité otázky, bolo rozlíšenie videa. Fotoaparát podporuje 1280 × 800, ale rozlíšenie na testovacom obrázku je veľmi podobné 640 × 480. Túto otázku si zrejme treba s vývojármi vyjasniť.

Video na testovanie vysielania z webovej kamery
cez server WebRTC

WebRTC je API poskytované prehliadačom, ktoré vám umožňuje organizovať P2P pripojenie a prenášať údaje priamo medzi prehľadávačmi. Na internete existuje pomerne veľa návodov na písanie vlastných videorozhovorov pomocou WebRTC. Napríklad tu je článok o Habrém. Všetky sú však obmedzené na spojenie dvoch klientov. V tomto článku sa pokúsim hovoriť o tom, ako organizovať pripojenie a výmenu správ medzi tromi alebo viacerými používateľmi pomocou WebRTC.

Rozhranie RTCPeerConnection je spojenie typu peer-to-peer medzi dvoma prehľadávačmi. Na pripojenie troch alebo viacerých používateľov bude potrebné zorganizovať sieť typu mesh (sieť, v ktorej je každý uzol pripojený k všetkým ostatným uzlom).
Použijeme nasledujúcu schému:

1. Pri otváraní stránky skontrolujte prítomnosť ID miestnosti v umiestnenie.haš
2. Ak nie je zadané ID miestnosti, vygenerujeme nové
3. Posielame signalizačnému serveru správu, že sa chceme pripojiť k určenej miestnosti
4. Signalizačný server zasiela oznámenie o novom používateľovi zvyšným klientom v tejto miestnosti.
5. Klienti, ktorí sú už v miestnosti, posielajú nováčikovi ponuku SDP
6. Nováčik reaguje na ponuku

0. Signalizačný server

Ako viete, aj keď WebRTC poskytuje spojenie P2P medzi prehľadávačmi, na výmenu správ služieb vyžaduje ďalší prenos. V tomto príklade je takýmto prenosom server WebSocket napísaný v Node.JS pomocou socket.io:

Var socket_io = require ("socket.io"); module.exports = function (server) (var users = (); var io = socket_io (server); io.on ("connection", function (socket) (// Nový užívateľ sa chce pripojiť k miestnosti socket.on (" room ", function (message) (var json = JSON.parse (message); // Pridať socket do zoznamu používateľov users = socket; if (socket.room! == undefined) (// Ak je socket už v niektorej miestnosti ju ukončite socket.leave (socket.room);) // Zadajte požadovanú miestnosť socket.room = json.room; socket.join (socket.room); socket.user_id = json.id; // Odoslať ostatným klientom v tejto miestnosti správu o pripojení nového účastníka k socket.broadcast.to (socket.room) .emit ("new", json.id);)); // správa súvisiaca s WebRTC (ponuka SDP, odpoveď SDP alebo kandidát na ICE) socket.on ("webrtc", function (message) (var json = JSON.parse (message); if (json.to! == undefined && users! == undefined) (// Ak správa obsahuje príjemcovi a tomuto príjemcovi známemu na serveri, pošleme správu iba jemu ... users.emit ("webrtc", správa); ) else (// ... inak, považujte správu za broadcast socket.broadcast.to (socket.room) .emit ("webrtc", message);))); // Niekto odpojil socket.on ("odpojiť", function () (// Keď sa klient odpojí, informujte o tom ostatných socket.broadcast.to (socket.room) .emit ("leave", socket.user_id); vymazať používateľov;)); )); );

1.index.html

Zdrojový kód samotnej stránky je dosť priamy. Schválne som nevenoval pozornosť rozloženiu a iným krásam, keďže o tom tento článok nie je. Ak ju chce niekto urobiť krásnou, nebude to ťažké.

2.main.js

2.0. Získavanie odkazov na prvky stránky a rozhrania WebRTC

var chatlog = document.getElementById ("chatlog"); var message = document.getElementById ("správa"); var connection_num = document.getElementById ("connection_num"); var room_link = document.getElementById ("room_link");

Na označenie rozhraní WebRTC musíme stále používať predpony prehliadača.

Var PeerConnection = window.mozRTCPeerConnection || window.webkitRTCPeerConnection; var SessionDescription = window.mozRTCSessionDescription || window.RTCSessionDescription; var IceCandidate = window.mozRTCIceCandidate || window.RTCIceCandidate;

2.1. Určenie ID miestnosti

Tu potrebujeme funkciu na vygenerovanie jedinečnej miestnosti a ID užívateľa. Na tieto účely použijeme UUID.

Funkcia uuid () (var s4 = function () (návrat Math.floor (Math.random () * 0x10000) .toString (16);); návrat s4 () + s4 () + "-" + s4 () + "-" + s4 () + "-" + s4 () + "-" + s4 () + s4 () + s4 ();)

Teraz skúsme z adresy vytiahnuť ID miestnosti. Ak žiadny nie je zadaný, vygenerujeme nový. Na stránke zobrazíme odkaz na aktuálnu miestnosť a v jednom kroku vygenerujeme ID aktuálneho používateľa.

Var ROOM = location.hash.substr (1); if (! ROOM) (ROOM = uuid ();) room_link.innerHTML = " Odkaz na izbu"; var ME = uuid ();

2.2. WebSocket

Ihneď po otvorení stránky sa pripojíme k nášmu signalizačnému serveru, pošleme požiadavku na vstup do miestnosti a zadáme spracovateľov správ.

// Naznačujeme, že keď je správa uzavretá, malo by sa o tom odoslať upozornenie na server var socket = io.connect ("", ("synchronizácia odpojiť pri načítaní": true)); socket.on ("webrtc", socketReceived); socket.on ("nový", socketNewPeer); // Okamžite pošlite žiadosť o vstup do miestnosti socket.emit ("room", JSON.stringify ((id: ME, room: ROOM))); // Pomocná funkcia na odosielanie správ s adresou súvisiacich s WebRTC funkcia sendViaSocket (type, message, to) (socket.emit ("webrtc", JSON.stringify ((id: ME, to: to, type: type, data: message)) ));)

2.3. Nastavenia PeerConnection

Väčšina poskytovateľov internetových služieb poskytuje NAT prostredníctvom internetového pripojenia. Vďaka tomu je priame spojenie menej triviálne. Pri vytváraní spojenia musíme určiť zoznam serverov STUN a TURN, ktoré sa prehliadač pokúsi použiť na prechod NAT. Označíme tiež niekoľko ďalších možností pripojenia.

Var server = (iceServers: [(url: "stun: 23.21.150.121"), (url: "stun: stun.l.google.com: 19302"), (url: "turn: numb.viagenie.ca", poverenie: „vaše heslo sa zobrazí tu“, používateľské meno: „ [chránené e-mailom]")]); var options = (voliteľné: [(DtlsSrtpKeyAgreement: true), // požadované pre pripojenie medzi prehliadačom Chrome a Firefoxom (RtpDataChannels: true) // požadované pre prehliadač Firefox na použitie rozhrania DataChannels API])

2.4. Pripojenie nového používateľa

Keď je do miestnosti pridaný nový rovnocenný server, server nám pošle správu Nový... Podľa manipulátorov správ uvedených vyššie sa funkcia bude volať socketNewPeer.

Var rovesníci = (); function socketNewPeer (data) (peers = (candidateCache :); // Create a new connection var pc = new PeerConnection (server, options); // Initialize it initConnection (pc, data, "offer"); // Save the peer v zozname peers peers.connection = pc; // Vytvorte DataChannel, prostredníctvom ktorého sa budú vymieňať správy var channel = pc.createDataChannel ("mychannel", ()); channel.owner = data; peers.channel = channel; // Nainštalujte obslužné rutiny udalostí channel bindEvents (channel); // Vytvorte ponuku SDP pc.createOffer (function (offer) (pc.setLocalDescription (offer);));) function initConnection (pc, id, sdpType) (pc.onicecandidate = function ( event) (if (event.candidate) (// Keď sa nájde nový kandidát ICE, pridajte ho do zoznamu na ďalšie odoslanie peers.candidateCache.push (event.candidate);) else (// Keď je detekcia kandidáta dokončená, obsluha sa znovu zavolá, ale bez kandidáta // V takom prípade najskôr pošleme ponuku SDP rovesníkovi, príp. Odpoveď SDP (v závislosti od parametra funkcie) ... sendViaSocket (sdpType, pc.localDescription, id); // ... a potom všetci predtým nájdení kandidáti na ICE pre (var i = 0; i< peers.candidateCache.length; i++) { sendViaSocket("candidate", peers.candidateCache[i], id); } } } pc.oniceconnectionstatechange = function (event) { if (pc.iceConnectionState == "disconnected") { connection_num.innerText = parseInt(connection_num.innerText) - 1; delete peers; } } } function bindEvents (channel) { channel.onopen = function () { connection_num.innerText = parseInt(connection_num.innerText) + 1; }; channel.onmessage = function (e) { chatlog.innerHTML += "

"; }; }

2.5. Ponuka SDP, odpoveď SDP, kandidát ICE

Keď je prijatá jedna z týchto správ, zavoláme zodpovedajúcu obsluhu správ.

Funkcia socketReceived (data) (var json = JSON.parse (data); switch (json.type) (prípad "candidate": remoteCandidateReceived (json.id, json.data); break; case "offer": remoteOfferReceived (json. id, json.data); break; case "answer": remoteAnswerReceived (json.id, json.data); break;))

2.5.0 Ponuka SDP

function remoteOfferReceived (id, data) (createConnection (id); var pc = peers.connection; pc.setRemoteDescription (new SessionDescription (data)); pc.createAnswer (function (answer) (pc.setLocalDescription (answer);)); ) funkcia createConnection (id) (if (peers === nedefinované) (peers = (candidateCache :); var pc = nový PeerConnection (server, možnosti); initConnection (pc, id, "odpoveď"); peers.connection = pc ; pc.ondatachannel = function (e) (peers.channel = e.channel; peers.channel.owner = id; bindEvents (peers.channel);)))

2.5.1 Odpoveď SDP

function remoteAnswerReceived (id, data) (var pc = peers.connection; pc.setRemoteDescription (new SessionDescription (data));)

2.5.2 Kandidát na ICE

funkcia remoteCandidateReceived (id, data) (createConnection (id); var pc = peers.connection; pc.addIceCandidate (new IceCandidate (data));)

2.6. Posielam správu

Stlačením tlačidla Pošli funkcia sa volá poslať správu... Všetko, čo robí, je prechádzať zoznamom podobných aplikácií a pokúsiť sa všetkým poslať určenú správu.