Chat cu mai mulți utilizatori folosind WebRTC. Chat video peer-to-peer bazat pe WebRTC Folosind webrtc js

Astăzi, WebRTC este tehnologia fierbinte pentru streaming audio și video în browsere. Tehnologiile conservatoare, precum HTTP Streaming și Flash, sunt mai potrivite pentru distribuirea conținutului înregistrat (video la cerere) și sunt semnificativ inferioare WebRTC în ceea ce privește transmisiile în timp real și online, de exemplu. unde este necesară o latență video minimă pentru a permite spectatorilor să vadă „în direct” ce se întâmplă.

Posibilitatea unei comunicații de înaltă calitate în timp real provine din arhitectura WebRTC în sine, unde protocolul UDP este utilizat pentru a transporta fluxuri video, care este baza standard pentru transmiterea video de la întârzieri minimeși utilizat pe scară largă în sistemele de comunicații în timp real.

Latența comunicării este importantă în sistemele de difuzare online, seminarii web și alte aplicații care necesită comunicare interactivă cu sursa video, utilizatorii finali și necesită o soluție.

Un alt motiv bun pentru a încerca WebRTC este că este cu siguranță o tendință. Astăzi toată lumea Android Chrome browserul acceptă această tehnologie, care garantează milioane de dispozitive gata să vizioneze emisiunea fără a instala niciun software sau configurații suplimentare.

Pentru a testa tehnologia WebRTC în acțiune și pentru a lansa o simplă difuzare online pe ea, am folosit software-ul server Flashphoner WebRTC Media & Broadcasting Server. Caracteristicile indică capacitatea de a difuza fluxuri WebRTC în modul unu-la-mulți, precum și suport pentru camere IP și sisteme de supraveghere video prin protocolul RTSP; În această recenzie ne vom concentra asupra transmisiunilor web-web și a caracteristicilor acestora.

Instalarea WebRTC Media & Broadcasting Server

Pentru că pentru sisteme Windows nu exista o versiune de server și nu am vrut să instalez o mașină virtuală precum VMWare+Linux, așa că am vrut să testez transmisiile online acasă computer Windows nu a mers. Pentru a economisi timp, am decis să luăm o instanță găzduire în cloud ca aceasta:

Era Centos x86_64 versiunea 6.5 fără niciun software preinstalat în centrul de date din Amsterdam. Astfel, tot ce avem la dispoziție este serverul și accesul ssh la acesta. Pentru cei care sunt familiarizați cu jocurile pentru consolă comenzi Linux, instalarea unui server WebRTC promite a fi simplă și nedureroasă. Deci ce am facut:

1. Descărcați arhiva:

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

2. Despacheta:

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

3. Instala:

$cd FlashphonerWebCallServer

În timpul instalării, introduceți adresa IP a serverului: XXX.XXX.XXX.XXX

4. Activați licența:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activare.sh

5. Porniți serverul WCS:

$service webcallserver pornire

6. Verificați jurnalul:

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

7. Verificați dacă cele două procese sunt în vigoare:

$ps aux | grep Flashphoner

Procesul de instalare este finalizat.

Testarea emisiunilor online WebRTC

Testarea emisiunilor s-a dovedit a fi o chestiune simplă. Pe lângă server, există un client web, care constă dintr-o duzină de Javascript, HTML și fișiere CSSși a fost implementat de noi în folderul /var/www/html în timpul etapei de instalare. Singurul lucru care trebuia făcut a fost să introduceți adresa IP a serverului în configurația flashphoner.xml, astfel încât clientul web să poată stabili o conexiune cu serverul prin HTML5 Websockets. Să descriem procesul de testare.

1. Deschideți pagina client de testare index.html în browser Chrome e:

2. Pentru a începe difuzarea, trebuie să faceți clic pe butonul „Start” din mijlocul ecranului.
Înainte de a face acest lucru, trebuie să vă asigurați că camera web este conectată și gata de utilizare. Cerințe speciale fără cameră web, de exemplu, am folosit camera standard încorporată într-un laptop cu o rezoluție de 1280x800.

Browserul Chrome va cere cu siguranță acces la cameră și microfon, astfel încât utilizatorul să înțeleagă că videoclipul său va fi trimis pe serverul de Internet și permite acest lucru.

3. Interfața reprezintă o difuzare cu succes a fluxului video de la cameră către serverul WebRTC. În colțul din dreapta sus, un indicator indică faptul că fluxul merge către server în colțul de jos există un buton „Oprire” pentru a opri trimiterea videoclipului.

Vă rugăm să rețineți linkul din caseta de mai jos. Conține un identificator unic pentru acest flux, astfel încât oricine se poate alătura vizionarii. Doar deschideți acest link în browser. Pentru a o copia în clipboard, faceți clic pe butonul „Copiere”.

ÎN aplicații reale precum webinarii, prelegeri, transmisii video online sau TV interactiv, dezvoltatorii vor trebui să implementeze distribuirea acestui identificator către anumite grupuri de telespectatori, astfel încât să se poată conecta la fluxurile necesare, dar aceasta este logica aplicației. WebRTC Media & Broadcasting Server nu îl afectează, ci doar distribuie videoclipuri.

5. Conexiunea este stabilită și spectatorul vede fluxul pe ecran. Acum poate trimite linkul către altcineva, poate opri redarea fluxului sau poate porni modul ecran complet, folosind comenzile din colțul din dreapta jos.

Rezultatele testării serverului de difuzare online WebRTC

În timpul testelor, latența părea perfectă. Ping-ul către centrul de date a fost de aproximativ 100 de milisecunde, iar întârzierea a fost invizibilă pentru ochi. De aici, putem presupune că întârzierea reală este aceeași 100 plus sau minus câteva zeci de milisecunde pentru timpul de tamponare. Comparativ cu Video flash: Flash nu funcționează la fel de bine ca WebRTC în aceste teste. Deci, dacă vă mutați mâna pe o rețea similară, mișcarea de pe ecran poate fi văzută numai după una sau două secunde.

În ceea ce privește calitatea, observăm că cuburile se pot distinge uneori prin mișcări. Acest lucru este în concordanță cu natura codecului VP8 și cu scopul său principal - de a oferi comunicații video în timp real cu o calitate acceptabilă și fără întârzieri de comunicare.

Serverul este destul de ușor de instalat și de configurat rularea acestuia nu necesită alte abilități serioase în afară de cunoștințe de Linux la nivelul unui utilizator avansat care poate executa comenzi din consolă prin ssh și utilizează; editor de text. Drept urmare, am reușit să stabilim o difuzare online one-to-many între browsere. De asemenea, conectarea spectatorilor suplimentari la flux nu a pus probleme.

Calitatea difuzării s-a dovedit a fi destul de acceptabilă pentru webinarii și transmisiunile online. Singurul lucru care a ridicat unele întrebări a fost rezoluția video. Camera acceptă 1280x800, dar rezoluția din imaginea de test este foarte asemănătoare cu 640x480. Aparent, această problemă trebuie clarificată cu dezvoltatorii.

Videoclip despre testarea transmisiei de la o cameră web
prin serverul WebRTC

Salutare prieteni, după cum știți deja, vă actualizăm în mod regulat cu noile tehnologii, astăzi vă voi prezenta WebRTC, o tehnologie dezvoltată de de Google, care permite utilizatorilor să vorbească direct în video și audio în browser fără a necesita utilizarea site-urilor web sau aplicațiilor plug-in. Conexiunea directă video și audio între utilizatori se realizează direct în browser.
Tehnologia WebRTC este acceptată în Mozilla Firefox browsere Google Chrome și orice sistem de operare, Opera se va alătura în curând.
Ce este WebRTC și ce?
WebRTC este prescurtarea de la Web Real Time Communication, această tehnologie vă permite să deschideți chat-uri audio și video direct în browser fără a fi nevoie de alte plugin-uri, aplicații sau servicii de pe Internet pentru a face acest lucru. Conexiunea se face direct din browser în browser.
Dacă serviciile cunoscute (Skype, Yahoo Messenger, Apple FaceTime, Google Hago etc.) necesită un server care conectează utilizatorii pentru a iniția și gestiona traficul. Folosind aceste servicii trebuie să ne înregistrăm și să stabilim o listă de clienți și contacte.
Cu WebRTC nu avem nevoie de servere, aplicații sau servere care se conectează pentru a interceda.
Avantajele WebRTC:
1. Nu mai sunt aplicații care consumă resurse și baterie.
2. Chaturile sunt mai private (relativ vorbind).
3. Modul de contact se poate face local, mai degrabă decât serverele Flos US pentru conexiuni locale.
4. Simplitate, ușurință în utilizare.
5. Posibilitatea dezvoltării ulterioare în alte direcții.
6. Comunicarea este stabilă și nu depinde de conexiunile externe, care uneori sunt extrem de instabile.
În tutorial am folosit un demo pe care cei de la Google l-au dezvoltat, acest demo este destul de simplu, funcții mai avansate și mai mult conexiuni rapide pot folosi una dintre aplicațiile care acceptă WebRTC, sunt mai ușor de utilizat. În curând vom face și un tutorial despre aplicațiile WebRTC.
Cum se utilizează demo-ul WebRTC?
Foarte simplu faceți clic pe linkul de mai jos, acesta va genera automat un chat. pentru a lega această cameră, trebuie să trimiți iubitul/iubita cu care vrei să iei legătura.
Iubit/iubita și a ta, dar ar trebui să le folosești doar pe cele mai recente versiuni Mozilla Firefox sau Google Chrome.

Demo WebRTC(Audio-video introductiv prin chat)

Atenţie:
Demo-ul nu este foarte stabil, produs doar în scop demonstrativ. Poate fi folosit pentru o perioadă limitată de timp, timp în care pot apărea mici erori de conectare.
Dacă aveți probleme de conexiune, încercați să creați un alt chat.

Majoritatea materialului pe WebRTC se concentrează pe nivelul aplicației de codificare și nu contribuie la înțelegerea tehnologiei. Să încercăm să mergem mai adânc și să aflăm cum are loc conexiunea, ce sunt descriptorul de sesiune și candidații, pentru ce sunt necesari aceștia STUNŞi ÎNTOARCE server.

WebRTC

Introducere

WebRTC este o tehnologie orientată spre browser care vă permite să conectați doi clienți pentru transferul de date video. Caracteristici principale: suport intern pentru browser (nu este nevoie de tehnologii implementate de terți, cum ar fi adobe flash ) și capacitatea de a conecta clienți fără a utiliza servere suplimentare - conexiune de la persoană la persoană(mai departe, p2p).

Stabiliți o conexiune p2p- o sarcină destul de dificilă, deoarece computerele nu au întotdeauna public IP adrese, adică adrese de pe Internet. Datorită cantității mici IPv4 adrese (și din motive de securitate), a fost dezvoltat un mecanism NAT, care vă permite să creați rețele private, de exemplu, pentru uz casnic. Multe routere de acasă acceptă acum NATși datorită acestui fapt, toate dispozitivele de acasă au acces la Internet, deși furnizorii de internet oferă de obicei unul IP adresa. Public IP adresele sunt unice pe Internet, dar adresele private nu sunt. Prin urmare conectează-te p2p- dificil.

Pentru a înțelege mai bine acest lucru, luați în considerare trei situații: ambele noduri sunt în aceeași rețea (Figura 1), ambele noduri sunt pe rețele diferite (unul este privat, celălalt este public) (Figura 2)și ambele noduri sunt pe rețele private diferite cu același IP adrese (Figura 3).

Figura 1: Ambele noduri din aceeași rețea

Figura 2: Noduri în diferite rețele (unul în privat, unul în public)

Figura 3: Noduri din rețele private diferite, dar cu adrese egale numeric

În figurile de mai sus, prima literă din notația cu două caractere indică tipul de nod (p = egal, r = router). În prima figură, situația este favorabilă: nodurile din rețeaua lor sunt complet identificate de rețea IP adrese și, prin urmare, se pot conecta direct între ele. În a doua figură avem două rețele diferite cu numere de noduri similare. Aici apar routerele (routere), care au două interfețe de rețea - în interiorul rețelei și în afara rețelei lor. De aceea au două IP adrese. Nodurile obișnuite au o singură interfață prin care pot comunica doar în cadrul rețelei lor. Dacă transmit date către cineva din afara rețelei lor, atunci numai folosind NATîn interiorul routerului (routerului) și, prin urmare, vizibil celorlalți sub IP adresa routerului este a lor extern IP adresa. Astfel, la nod p1 Există interior IP = 192.168.0.200 Şi extern IP = 10.50.200.5 , iar ultima adresă va fi, de asemenea, externă tuturor celorlalte noduri din rețeaua sa. O situație similară pentru nod p2. Prin urmare, conexiunea lor este imposibilă dacă le folosiți doar intern (propriul) IP adrese. Puteți utiliza adrese externe, adică adrese de router, dar deoarece toate nodurile din aceeași rețea privată au aceeași adresă externă, acest lucru este destul de dificil. Această problemă este rezolvată folosind mecanismul NAT

Ce se va întâmpla dacă decidem să conectăm nodurile prin adresele lor interne? Datele nu vor părăsi rețeaua. Pentru a spori efectul, vă puteți imagina situația prezentată în ultima figură - ambele noduri au aceleași adrese interne. Dacă le folosesc pentru a comunica, atunci fiecare nod va comunica cu el însuși.

WebRTC face față cu succes unor astfel de probleme folosind protocolul GHEAŢĂ, care, totuși, necesită utilizarea de servere suplimentare ( STUN, ÎNTOARCE). Mai multe despre toate acestea mai jos.

Două faze ale WebRTC

Pentru a conecta două noduri printr-un protocol WebRTC(sau doar RTC, dacă doi comunică iPhone‘a) este necesar să se efectueze unele acțiuni prealabile pentru a stabili o conexiune. Aceasta este prima fază - stabilirea unei conexiuni. A doua fază este transmisia de date video.

Merită spus imediat că, deși tehnologie WebRTC folosește multe în munca sa în diverse moduri comunicatii ( TCPŞi UDP) și are comutare flexibilă între ele, această tehnologie nu are un protocol pentru transmiterea datelor de conexiune. Nu este surprinzător, deoarece conectați două noduri p2p nu atat de usor. Prin urmare, este necesar să aveți câteva adiţional o metodă de transmitere a datelor care nu are nicio legătură cu WebRTC. Ar putea fi un transfer de socket, un protocol HTTP, ar putea fi chiar un protocol SMTP sau Poșta Rusă. Acest mecanism de transmisie iniţială se numesc date semnal. Nu trebuie transmise prea multe informații. Toate datele sunt transmise sub formă de text și sunt împărțite în două tipuri - SDPŞi Candidat de gheață. Primul tip este folosit pentru a stabili o conexiune logică, iar al doilea pentru o conexiune fizică. Mai multe despre toate acestea mai târziu, dar deocamdată este doar important să ne amintim asta WebRTC ne va oferi câteva informații care vor trebui transmise la un alt nod. De îndată ce transferăm toate informatiile necesare, nodurile se vor putea conecta și nu va mai fi nevoie de ajutorul nostru. Deci mecanismul de semnalizare pe care trebuie să-l implementăm este separat, va fi folosit numai atunci când este conectat, dar nu va fi folosit la transmiterea datelor video.

Deci, să luăm în considerare prima fază - faza de stabilire a conexiunii. Este format din mai multe puncte. Să ne uităm la această fază mai întâi pentru nodul care inițiază conexiunea și apoi pentru cel care așteaptă.

  • Inițiator (apelant - apelant):
    1. Oferiți să începeți transferul de date video (createOffer)
    2. Primindu-l pe al tău SDP SDP)
    3. Primindu-l pe al tău Candidat de gheață Candidat de gheață)
  • Apel în așteptare ( apelat):
    1. Primirea unui flux media local (dvs.) și setarea acestuia pentru transmisie (getUserMediaStream)
    2. Primirea unei oferte pentru a începe transferul de date video și crearea unui răspuns (createAnswer)
    3. Primindu-l pe al tău SDP obiect și transmiterea acestuia printr-un mecanism de semnalizare ( SDP)
    4. Primindu-l pe al tău Candidat de gheață obiecte și transmiterea lor printr-un mecanism de semnalizare ( Candidat de gheață)
    5. Primirea unui flux media de la distanță (străin) și afișarea lui pe ecran (onAddStream)

Singura diferență este în al doilea punct.

În ciuda complexității aparente a pașilor, există de fapt trei dintre ei: trimiterea propriului flux media (articolul 1), setarea parametrilor de conexiune (articolele 2-4), primirea fluxului media altcuiva (articolul 5). Pasul cel mai dificil este cel de-al doilea pas, deoarece constă din două părți: stabilirea fizicŞi logic conexiuni. Primul indică cale, de-a lungul căruia pachetele trebuie să călătorească pentru a ajunge de la un nod de rețea la altul. Al doilea indică parametrii video/audio– ce calitate să folosești, ce codecuri să folosești.

Stadiul mental createOffer sau createRăspuns trebuie conectat la etapele de transmisie SDPŞi Candidat de gheață obiecte.

Entități de bază

Fluxuri media (MediaStream)

Entitatea principală este fluxul media, adică fluxul de date video și audio, imagine și sunet. Există două tipuri de fluxuri media - locale și la distanță. Cel local primește date de la dispozitivele de intrare (cameră, microfon), iar cel la distanță prin rețea. Astfel, fiecare nod are atât un fir local, cât și unul la distanță. ÎN WebRTC există o interfață pentru fire MediaStreamși există și o subinterfață LocalMediaStream special pentru thread-ul local. ÎN JavaScriptîl poți întâlni doar pe primul și dacă îl folosești libjingle, atunci s-ar putea să îl întâlnești pe al doilea.

ÎN WebRTC Există o ierarhie destul de confuză în cadrul firului. Fiecare flux poate consta din mai multe piese media ( MediaTrack), care la rândul său poate consta din mai multe canale media ( MediaChannel). Și pot exista, de asemenea, mai multe fluxuri media în sine.

Să privim totul în ordine. Pentru a face acest lucru, să ținem cont de un exemplu. Să spunem că vrem să transmitem nu doar un videoclip cu noi înșine, ci și un videoclip al mesei noastre, pe care se află o bucată de hârtie pe care urmează să scriem ceva. Vom avea nevoie de două videoclipuri (noi + tabel) și unul audio (noi). Este clar că noi și tabelul ar trebui să fim împărțiți în fire diferite, deoarece aceste date sunt probabil puțin dependente unele de altele. Prin urmare, vom avea două MediaStream‘a – unul pentru noi și unul pentru masă. Primul va conține atât date video, cât și audio, iar al doilea va conține doar video (Figura 4).

Figura 4: Două fluxuri media diferite. Unul pentru noi, unul pentru masa noastră

Este imediat clar că un flux media trebuie să includă cel puțin capacitatea de a conține date diferite tipuri- video și audio. Acest lucru este luat în considerare în tehnologie și, prin urmare, fiecare tip de date este implementat printr-o pistă media MediaTrack. Piesele media au o proprietate specială fel, care determină ce avem în fața noastră – video sau audio (Figura 5)

Figura 5: Fluxurile media constau din piese media

Cum se va întâmpla totul în program? Vom crea două fluxuri media. Apoi vom crea două piese video și o pistă audio. Să obținem acces la camere și microfon. Să spunem fiecărei piese ce dispozitiv să folosească. Să adăugăm o pistă video și audio la primul flux media și o pistă video de la o altă cameră la al doilea flux media.

Dar cum distingem fluxurile media la celălalt capăt al conexiunii? Pentru a face acest lucru, fiecare flux media are proprietatea eticheta– eticheta fluxului, numele acestuia (Figura 6). Piesele media au aceeași proprietate. Deși la prima vedere pare că videoclipul poate fi distins de sunet în alte moduri.

Figura 6: Fluxurile și melodiile media sunt identificate prin etichete

Deci, dacă melodiile media pot fi identificate printr-o etichetă, atunci de ce trebuie să folosim două fluxuri media pentru exemplul nostru, în loc de unul? La urma urmei, puteți transmite un flux media, dar utilizați diferite piese în el. Am ajuns la o proprietate importantă a fluxurilor media - ei sincroniza piese media. Diferitele fluxuri media nu sunt sincronizate între ele, dar în cadrul fiecărui flux media toate piesele sunt redate simultan.

Astfel, dacă vrem ca cuvintele noastre, emoțiile noastre faciale și bucata noastră de hârtie să fie redate simultan, atunci merită să folosiți un flux media. Dacă acest lucru nu este atât de important, atunci este mai profitabil să folosiți diferite fluxuri - imaginea va fi mai netedă.

Dacă o piesă trebuie oprită în timpul transmisiei, puteți folosi proprietatea activat piese media.

În cele din urmă, merită să ne gândim la sunetul stereo. După cum știți, sunetul stereo este două sunete diferite. Și trebuie să fie transferate și separat. Canalele sunt folosite pentru aceasta MediaChannel. O pistă audio media poate avea mai multe canale (de exemplu, 6 dacă aveți nevoie de 5+1 audio). Există și canale în interiorul pieselor media, desigur. sincronizate. Pentru video, de obicei este utilizat un singur canal, dar mai multe pot fi folosite, de exemplu, pentru suprapunerea publicității.

Pentru a rezuma: Folosim un flux media pentru a transmite date video și audio. În cadrul fiecărui flux media, datele sunt sincronizate. Putem folosi mai multe fluxuri media dacă nu avem nevoie de sincronizare. În interiorul fiecărui flux media există două tipuri de piese media - pentru video și pentru audio. De obicei, nu există mai mult de două piese, dar pot fi mai multe dacă trebuie să transmiteți mai multe videoclipuri diferite(interlocutorul și masa lui). Fiecare piesă poate consta din mai multe canale, care este de obicei folosit doar pentru sunet stereo.

În cea mai simplă situație de chat video, vom avea un flux media local, care va consta din două piese - o pistă video și o pistă audio, fiecare dintre acestea fiind compusă dintr-un canal principal. Piesa video este responsabilă pentru cameră, pista audio este pentru microfon, iar fluxul media este containerul pentru ambele.

Descriptor de sesiune (SDP)

U diferite calculatoareÎntotdeauna vor exista camere diferite, microfoane, plăci video și alte echipamente. Există multe opțiuni pe care le au. Toate acestea trebuie coordonate pentru transferul media de date între două noduri de rețea. WebRTC face acest lucru automat și creează un obiect special - un descriptor de sesiune SDP. Treceți acest obiect către alt nod și datele media pot fi transferate. Numai că nu există încă nicio legătură cu un alt nod.

Pentru aceasta este folosit orice mecanism de semnalizare. SDP poate fi transmis fie prin prize, fie de persoană (spuneți-l unui alt nod prin telefon), fie prin Russian Post. Este foarte simplu - vă vor oferi un gata făcut SDPși trebuie trimis. Și la primire pe cealaltă parte - transfer la departament WebRTC. Descriptorul de sesiune este stocat ca text și poate fi modificat în aplicațiile dvs., dar acest lucru nu este în general necesar. De exemplu, când conectați desktop ↔ telefon, uneori trebuie să forțați selectarea sunetul dorit codec

De obicei, atunci când stabiliți o conexiune, trebuie să specificați un fel de adresă, de exemplu URL. Nu este nevoie de acest lucru aici, deoarece prin mecanismul de semnalizare tu însuți vei trimite datele la destinație. Pentru a indica WebRTC ce vrem să instalăm p2p conexiune trebuie să apelați funcția createOffer. După ce a apelat această funcție și i-ai dat un special sună din nou‘a va fi creat SDP obiect şi transferat la acelaşi sună din nou. Tot ceea ce vă este necesar este să transferați acest obiect prin rețea către un alt nod (interlocutor). După aceasta, datele vor ajunge la celălalt capăt prin mecanismul de semnalizare și anume acesta SDP obiect. Acest descriptor de sesiune pentru acest nod este străin și, prin urmare, poartă informatii utile. Primirea acestui obiect este un semnal de pornire a conexiunii. Prin urmare, trebuie să fiți de acord cu acest lucru și să apelați funcția createAnswer. Este un analog complet al createOffer. Înapoi la a ta sună din nou va trece descriptorul de sesiune local și va trebui să fie transmis înapoi prin mecanismul de semnalizare.

Este de remarcat faptul că puteți apela funcția createAnswer numai după ce ați primit-o pe a altcuiva SDP obiect. De ce? Pentru că local SDP obiectul care va fi generat atunci când createAnswer este apelat trebuie să se bazeze pe telecomandă SDP obiect. Numai în acest caz este posibil să vă coordonați setările video cu setările interlocutorului dvs. De asemenea, nu ar trebui să apelați createAnswer și createOffer înainte de a primi fluxul media local - nu vor avea nimic la care să scrie SDP obiect .

Din moment ce în WebRTC se poate edita SDP obiect, apoi după primirea mânerului local acesta trebuie instalat. Acest lucru poate părea puțin ciudat de transmis WebRTC ceea ce ea însăși ne-a dat, dar acesta este protocolul. Când se primește un mâner de la distanță, acesta trebuie de asemenea instalat. Prin urmare, trebuie să instalați doi descriptori pe un nod - al dvs. și al altcuiva (adică, local și la distanță).

După aceasta strângeri de mână nodurile știu unul despre dorințele celuilalt. De exemplu, dacă nodul 1 acceptă codecuri OŞi B, și nodul 2 acceptă codecuri BŞi C, atunci, deoarece fiecare nod își cunoaște descriptorii proprii și ai altora, ambele noduri vor alege codecul B(Figura 7). Logica de conectare este acum stabilită și fluxurile media pot fi transmise, dar există o altă problemă - nodurile sunt încă conectate doar printr-un mecanism de semnalizare.


Figura 7: Negocierea codecului

Candidat de gheață

Tehnologie WebRTCîncercând să ne confunde cu noua lui metodologie. La stabilirea unei conexiuni, adresa nodului la care doriți să vă conectați nu este specificată. Instalat mai întâi logic conexiune, nu fizic, deși întotdeauna s-a făcut invers. Dar acest lucru nu va părea ciudat dacă nu uităm că folosim un mecanism de semnalizare terță parte.

Deci, conexiunea a fost deja stabilită (conexiune logică), dar încă nu există o cale pe care nodurile rețelei să poată transmite date. Nu este chiar atât de simplu, dar să începem simplu. Lăsați nodurile să fie în aceeași rețea privată. După cum știm deja, ei se pot conecta cu ușurință unul cu celălalt în funcție de interiorul lor IP adrese (sau poate către alte persoane, dacă nu sunt utilizate TCP/IP).

După unii sună din nou'Şi WebRTC ne spune Candidat de gheață obiecte. Ele vin, de asemenea, sub formă de text și, ca și descriptorii de sesiune, pur și simplu trebuie să fie trimise printr-un mecanism de semnalizare. Dacă descriptorul de sesiune conținea informații despre setările noastre la nivel de cameră și microfon, atunci candidații conțin informații despre locația noastră în rețea. Transmite-le la un alt nod și se va putea conecta fizic la noi și, deoarece are deja un descriptor de sesiune, se va putea conecta în mod logic și datele vor „fluge”. Dacă își amintește să ne trimită obiectul său candidat, adică informații despre locul în care se află el însuși în rețea, atunci vom putea să ne conectăm cu el. Să remarcăm aici încă o diferență față de interacțiunea clasică client-server. Comunicarea cu server HTTP are loc conform schemei cerere-răspuns, clientul trimite date către server, care le prelucrează și le trimite prin adresa specificată în pachetul de solicitare. ÎN WebRTC trebuie sa stiu două adreseși conectați-le pe ambele părți.

Diferența față de descriptorii de sesiune este că doar candidații la distanță trebuie să fie instalați. Editarea aici este interzisă și nu poate aduce niciun beneficiu. În unele implementări WebRTC candidații trebuie să fie instalați numai după ce au fost setați descriptori de sesiune.

De ce a existat un singur descriptor de sesiune, dar ar putea fi mulți candidați? Deoarece locația în rețea poate fi determinată nu numai de interiorul acesteia IP adresa, dar și adresa externă a routerului, și nu neapărat doar una, precum și adresele ÎNTOARCE servere. Restul paragrafului va fi dedicat unei discuții detaliate despre candidați și despre modul de conectare a nodurilor din diferite rețele private.

Deci, două noduri sunt în aceeași rețea (Figura 8). Cum să le identificăm? Prin utilizarea IP adrese. Nu mai mult. Adevărat, puteți folosi în continuare mijloace de transport diferite ( TCPŞi UDP) și diferite porturi. Acestea sunt informațiile conținute în obiectul candidat - IP, PORT, TRANSPORT si inca una. Să folosim, de exemplu UDP transport si 531 port.

Figura 8: Două noduri sunt în aceeași rețea

Atunci dacă suntem la nod p1, Asta WebRTC ne va transmite un astfel de obiect candidat - . Acesta nu este un format exact, doar o diagramă. Dacă suntem într-un nod p2, atunci candidatul este - . Printr-un mecanism de semnalizare p1 va primi un candidat p2(adică locația nodului p2, anume a lui IPŞi PORT). După care p1 se poate conecta cu p2 direct. Mai corect, p1 va trimite datele la adresa 10.50.150.3:531 în speranţa că vor ajunge p2. Nu contează dacă adresa aparține nodului p2 sau vreun intermediar. Singurul lucru important este că datele vor fi trimise prin această adresă și pot ajunge p2.

Atâta timp cât nodurile sunt în aceeași rețea, totul este simplu și ușor - fiecare nod are un singur obiect candidat (însemnând întotdeauna propriul său, adică locația sa în rețea). Dar vor fi mult mai mulți candidați când nodurile vor fi introduse diferit retelelor.

Să trecem la un caz mai complex. Un nod va fi situat în spatele routerului (mai precis, în spatele NAT), iar al doilea nod va fi situat în aceeași rețea cu acest router (de exemplu, pe Internet) (Figura 9).

Figura 9: Un nod este în spatele NAT, celălalt nu

Acest caz are o soluție specială la problemă, pe care acum o vom lua în considerare. Router de acasă de obicei conține un tabel NAT. Acesta este un mecanism special conceput pentru a permite nodurilor din interiorul rețelei private a routerului să acceseze, de exemplu, site-uri web.

Să presupunem că serverul web este conectat direct la Internet, adică are un public IP* adresa. Să fie acesta un nod p2. Nod p1(client web) trimite o solicitare la adresa 10.50.200.10 . Mai întâi datele merg la router r1, sau mai bine zis pe a lui interior interfata 192.168.0.1 . După care, routerul își amintește adresa sursă (adresa p1) și îl introduce într-un tabel special NAT, apoi schimbă adresa sursă la a ta( p1 → r1). Mai departe, în felul meu extern interfață, routerul trimite date direct către serverul web p2. Serverul web prelucrează datele, generează un răspuns și îl trimite înapoi. Se trimite la router r1, deoarece el este cel care se află în adresa de retur (routerul a înlocuit adresa cu propria sa). Routerul primește date și se uită la tabel NATși transmite datele către nod p1. Routerul acţionează ca un intermediar aici.

Ce se întâmplă dacă mai multe noduri din rețeaua internă accesează simultan rețea externă? Cum va înțelege routerul cui să trimită răspunsul înapoi? Această problemă este rezolvată folosind porturi. Când un router înlocuiește adresa gazdă cu propria sa, acesta înlocuiește și portul. Dacă două noduri accesează Internetul, atunci routerul își înlocuiește porturile sursă cu diferit. Apoi, când pachetul de la serverul web revine la router, routerul va înțelege prin port cui este alocat. acest pachet. Exemplu de mai jos.

Să revenim la tehnologie WebRTC, sau mai degrabă, la partea din acesta care folosește GHEAŢĂ protocol (deci Gheaţă candidați). Nod p2 are un singur candidat (locația sa în rețea – 10.50.200.10 ), și nodul p1, care se află în spatele unui router cu NAT, va avea doi candidați - local ( 192.168.0.200 ) și router candidat ( 10.50.200.5 ). Primul nu este util, dar este totuși generat, din moment ce WebRTC nu știe încă nimic despre nodul la distanță - poate fi sau nu în aceeași rețea. Al doilea candidat va veni la îndemână și, după cum știm deja, portul va juca un rol important (de a trece prin NAT).

Intrare la tabel NAT generate numai atunci când datele părăsesc rețeaua internă. Prin urmare nodul p1 trebuie să transmită mai întâi datele și numai după aceea datele nodului p2 va putea ajunge la nod p1.

În practică ambele noduri va fi în urmă NAT. Pentru a crea o înregistrare într-un tabel NAT ale fiecărui router, nodurile trebuie să trimită ceva către nodul de la distanță, dar de data aceasta nici primul nu poate ajunge la cel de-al doilea și nici invers. Acest lucru se datorează faptului că nodurile nu își cunosc exteriorul IP adrese, iar trimiterea datelor către adrese interne este inutilă.

Cu toate acestea, dacă adresele externe sunt cunoscute, conexiunea se va stabili cu ușurință. Dacă primul nod trimite date către routerul celui de-al doilea nod, routerul le va ignora, deoarece tabelul său NAT gol deocamdată. Cu toate acestea, în routerul primului nod din tabel NAT Am nevoie de o înregistrare. Dacă acum al doilea nod trimite date către routerul primului nod, atunci routerul le va transfera cu succes la primul nod. Acum masa NAT al doilea router are nevoie de date.

Problema este că pentru a-ți recunoaște exteriorul IP adresa, aveți nevoie de un nod situat în rețea partajată. Pentru a rezolva această problemă, se folosesc servere suplimentare care sunt conectate direct la Internet. Cu ajutorul lor, sunt create și înregistrări apreciate în tabel NAT.

Servere STUN și TURN

La inițializare WebRTC trebuie să indicați cele disponibile STUNŞi ÎNTOARCE servere, pe care le vom numi în continuare GHEAŢĂ servere. Dacă serverele nu sunt specificate, atunci numai nodurile din aceeași rețea (conectate la aceasta fără NAT). Este imediat de remarcat faptul că pt 3g-trebuie folosite rețele ÎNTOARCE servere.

STUN server este pur și simplu un server de pe Internet care returnează o adresă de retur, adică adresa nodului expeditorului. Nodul situat în spatele routerului accesează STUN server pe care să îl parcurgeți NAT. Pachetul la care a ajuns STUN server, conține adresa sursă - adresa routerului, adică adresa externă a nodului nostru. Această adresă STUN server și îl trimite înapoi. Astfel, nodul își primește exteriorul IP adresa și portul prin care este accesibil din rețea. Următorul, WebRTC folosind această adresă se creează un candidat suplimentar (adresa ruterului extern și port). Acum în tabel NAT Routerul are o intrare care permite pachetelor trimise către router pe portul necesar să treacă la nodul nostru.

Să ne uităm la acest proces cu un exemplu.

Exemplu (operare server STUN)

STUN vom desemna serverul prin s1. Routerul, ca înainte, prin r1, iar nodul – prin p1. De asemenea, va trebui să urmați tabelul NAT– să o notăm ca r1_nat. În plus, acest tabel conține de obicei multe înregistrări de la noduri diferite subrețele - nu vor fi listate.

Deci, la început avem o masă goală r1_nat.

Tabelul 2: Antet pachet

Nod p1 trimite acest pachet către router r1(indiferent cum, acestea pot fi utilizate în diferite subrețele tehnologii diferite). Routerul trebuie să schimbe adresa sursei Src IP, deoarece adresa specificată în pachet nu este în mod evident potrivită pentru o subrețea externă, mai mult, adresele dintr-un astfel de interval sunt rezervate și nici o singură adresă de pe Internet nu are o astfel de adresă; Routerul face o înlocuire în pachet și creează noua intrareîn masa ta r1_nat. Pentru a face acest lucru, el trebuie să vină cu un număr de port. Să ne amintim că, deoarece mai multe noduri dintr-o subrețea pot accesa rețeaua externă, atunci în tabel NAT trebuie păstrat Informații suplimentare, astfel încât routerul să poată determina care dintre aceste câteva noduri este destinat pachetului de returnare de la server. Lasă routerul să vină cu un port 888 .

Antetul pachetului modificat:

Tabelul 4: Tabelul NAT a fost actualizat cu o nouă intrare

Aici IP adresa și portul pentru subrețea sunt exact aceleași cu pachetul original. De fapt, la postback, trebuie să avem o modalitate de a le restaura complet. IP adresa pentru reteaua externa este adresa routerului, iar portul s-a schimbat in cel inventat de router.

Portul real către care nodul p1 acceptă conexiunea - aceasta, desigur, 35777 , dar serverul trimite date către fictiv port 888 , care va fi schimbat de router cu cel real 35777 .

Deci, routerul a înlocuit adresa sursă și portul în antetul pachetului și a adăugat o intrare în tabel NAT. Acum pachetul este trimis prin rețea către server, adică către nod s1. La intrare, s1 are acest pachet:

Src IP Src PORT Dest IP Dest PORT
10.50.200.5 888 12.62.100.200 6000

Tabelul 5: Pachetul primit de serverul STUN

Total STUN serverul stie ca a primit un pachet de la adresa 10.50.200.5:888 . Acum serverul trimite această adresă înapoi. Merită să ne oprim aici și să aruncăm o altă privire la ceea ce tocmai ne-am uitat. Tabelele de mai sus sunt un fragment din antet pachet, deloc din el conţinut. Nu am vorbit despre conținut, deoarece nu este atât de important - este cumva descris în protocol STUN. Acum vom lua în considerare, pe lângă titlu, și conținutul. Va fi simplu și va conține adresa routerului - 10.50.200.5:888 , desi am luat-o din antet pachet. Acest lucru nu se face des, de obicei protocoalelor nu le pasă de informațiile despre adresele nodurilor, este important doar ca pachetele să fie livrate la destinația dorită. Aici ne uităm la un protocol care stabilește o cale între două noduri.

Deci acum avem un al doilea pachet care merge în direcția opusă:

Tabelul 7: Serverul STUN trimite un pachet cu acest conținut

Apoi, pachetul călătorește prin rețea până ajunge la interfata externa router r1. Routerul înțelege că pachetul nu este destinat acestuia. Cum înțelege el asta? Acest lucru poate fi determinat doar de port. Port 888 nu o folosește în scopuri personale, ci o folosește pentru mecanism NAT. Prin urmare, routerul se uită la acest tabel. Uită-te la coloană PORT externși caută un șir care se potrivește Dest PORT din pachetul primit, adică 888 .

IP intern PORT intern IP extern PORT extern
192.168.0.200 35777 10.50.200.5 888

Tabelul 8: Tabelul NAT

Suntem norocoși, o astfel de linie există. Dacă am avea ghinion, pachetul ar fi pur și simplu aruncat. Acum trebuie să înțelegeți ce nod din subrețea ar trebui să trimită acest pachet. Nu trebuie să ne grăbim, să ne amintim din nou importanța porturilor în acest mecanism. În același timp, două noduri de pe subrețea ar putea trimite cereri către rețeaua externă. Apoi, dacă pentru primul nod routerul a venit cu un port 888 , apoi pentru al doilea ar veni cu un port 889 . Să presupunem că s-a întâmplat asta, adică tabelul r1_nat arata asa:

Tabelul 10: Routerul înlocuiește adresa receptorului

Src IP Src PORT Dest IP Dest PORT
12.62.100.200 6000 192.168.0.200 35777

Tabelul 11: Routerul a schimbat adresa receptorului

Pachetul ajunge cu succes la nod p1și uitându-se la conținutul pachetului, nodul învață despre exteriorul acestuia IP adresa, adică adresa routerului din rețeaua externă. Știe și portul prin care trece routerul NAT.

Ce urmează? La ce folosesc toate astea? Beneficiul este o intrare în tabel r1_nat. Dacă acum cineva trimite la router r1 pachet cu port 888 , apoi routerul va redirecționa acest pachet către nod p1. Astfel, a fost creat un mic pasaj îngust către nodul ascuns p1.

Din exemplul de mai sus vă puteți face o idee despre cum funcționează NATși esență STUN server. În general, mecanismul GHEAŢĂŞi STUN/TURN serverele au ca scop tocmai depășirea limitărilor NAT.

Între nod și server nu pot exista un singur router, ci mai multe. În acest caz, nodul va primi adresa routerului care este primul care accesează aceeași rețea ca și serverul. Cu alte cuvinte, obținem adresa routerului la care este conectat STUN server. Pentru p2p comunicarea este exact ceea ce avem nevoie, dacă nu uităm faptul că fiecare router va adăuga rândul de care avem nevoie la tabel NAT. Prin urmare, drumul înapoi va fi din nou la fel de lin.

ÎNTOARCE serverul este îmbunătățit STUN server. De aici ar trebui să se învețe imediat că orice ÎNTOARCE serverul poate funcționa și cum STUN server. Cu toate acestea, există și avantaje. Dacă p2p comunicarea este imposibilă (cum ar fi în 3g rețele), apoi serverul trece în modul repetitor ( releu), adică funcționează ca intermediar. Desigur, despre nimic p2p atunci nu se pune problema, ci în afara cadrului mecanismului GHEAŢĂ nodurile cred că comunică direct.

În ce cazuri este necesar ÎNTOARCE server? De ce nu este suficient STUN servere? Faptul este că există mai multe soiuri NAT. Se înlocuiesc în mod egal IP adresa și portul, dar unele dintre ele au încorporate protectie suplimentara din „falsificare”. De exemplu, în simetric masă NATÎncă 2 parametri sunt salvați - IPși portul nodului la distanță. Un pachet din rețeaua externă trece prin NAT către rețeaua internă numai dacă adresa sursă și portul se potrivesc cu cele înregistrate în tabel. Prin urmare, focalizarea STUN serverul eșuează - tabel NAT stochează adresa și portul STUN server și când routerul primește un pachet de la WebRTC interlocutor, îl renunță pentru că este „falsificat”. El nu a venit din STUN server.

Astfel ÎNTOARCE este necesar un server când sunt localizați ambii interlocutori simetric NAT(fiecare la el).

Scurt rezumat

Iată câteva declarații despre entități WebRTC care trebuie ținut mereu în minte. Ele sunt descrise în detaliu mai sus. Dacă vreuna dintre afirmații nu vi se pare complet clară, recitiți paragrafele relevante.

  • Flux media
    • Datele video și audio sunt împachetate în fluxuri media
    • Fluxurile media sincronizează melodiile media care alcătuiesc
    • Fluxurile media diferite nu sunt sincronizate între ele
    • Fluxurile media pot fi locale și la distanță, cel local este de obicei conectat la o cameră și un microfon, cei la distanță primesc date din rețea în formă criptată
    • Există două tipuri de piese media - pentru video și pentru audio.
    • Piesele media au capacitatea de a activa/dezactiva
    • Piesele media constau din canale media
    • Piesele media sincronizează canalele media care alcătuiesc
    • Fluxurile media și melodiile media au etichete prin care pot fi distinse
  • Mânerul de sesiune
    • Descriptorul de sesiune este folosit pentru a conecta logic două noduri de rețea
    • Descriptorul de sesiune stochează informații despre modalități disponibile codificarea datelor video și audio
    • WebRTC folosește un mecanism de semnalizare extern - sarcina de a transmite descriptori de sesiune ( sdp) cade pe cerere
    • Mecanismul de conectare logică constă din două etape - propoziții ( oferi) si raspunde ( răspuns)
    • Generarea unui descriptor de sesiune nu este posibilă fără utilizarea unui flux media local în cazul unei propuneri ( oferi) și nu este posibil fără utilizarea unui handle de sesiune la distanță în cazul unui răspuns ( răspuns)
    • Descriptorul rezultat trebuie dat implementării WebRTC, și nu contează dacă acest descriptor este obținut de la distanță sau local din aceeași implementare WebRTC
    • Este posibil să editați ușor descriptorul de sesiune
  • Candidații
    • Candidatul ( Candidat de gheață) este adresa nodului din rețea
    • Adresa nodului poate fi propria dvs. sau poate fi adresa unui router sau ÎNTOARCE servere
    • Întotdeauna sunt mulți candidați
    • Candidatul este format din IP adresa, portul si tipul de transport ( TCP sau UDP)
    • Candidații sunt folosiți pentru a stabili o conexiune fizică între două noduri dintr-o rețea
    • De asemenea, candidații trebuie să fie trimiși printr-un mecanism de semnalizare
    • Candidații trebuie, de asemenea, să fie transferați la implementări WebRTC, dar numai la distanță
    • În unele implementări WebRTC candidații pot fi transmise numai după ce a fost setat descriptorul de sesiune
  • STUN/TURN/ICE/NAT
    • NAT– mecanism de asigurare a accesului la rețeaua externă
    • Routerele de acasă suportă o masă specială NAT
    • Routerul înlocuiește adresele din pachete - adresa sursă cu propria sa, dacă pachetul merge la o rețea externă, iar adresa receptorului cu adresa gazdă în rețeaua internă, dacă pachetul a venit dintr-o rețea externă
    • Pentru a oferi acces multicanal la rețeaua externă NAT folosește porturi
    • GHEAŢĂ– mecanism de bypass NAT
    • STUNŞi ÎNTOARCE servere – servere de ajutor pentru ocolire NAT
    • STUN serverul vă permite să creați înregistrările necesare în tabel NATși returnează, de asemenea, adresa externă a nodului
    • ÎNTOARCE serverul generalizează STUN mecanism și îl face să funcționeze mereu
    • În cele mai rele cazuri ÎNTOARCE serverul este folosit ca intermediar ( releu), adică p2p se transformă într-o comunicare client-server-client.