Doar despre WebRTC

Cea mai mare parte a materialului pe WebRTC este axat pe codificarea stratului de aplicații și nu este propice pentru o înțelegere a tehnologiei. Să încercăm să meargă mai adânc și de a afla modul în care conexiunea care folosesc această sesiune și candidați, care au nevoie de servere STUN și virajului.

Figura 1: Cele două noduri pe aceeași rețea

Figura 2: nodurile din diferite rețele (unul în particular, un alt public)

WebRTC se descurcă cu succes cu astfel de probleme, folosind protocolul ICE. care, totuși, necesită utilizarea de servere suplimentare (STUN. TURN). Despre toate acestea de mai jos.

Cele două faze WebRTC

Astfel, considerăm prima faza - faza de stabilirea conexiunii. Se compune din mai multe elemente. Luați în considerare această primă fază a nodului care inițiază conexiunea, și apoi așteaptă.

Singura diferență este în al doilea paragraf.

Mental pas createOffer sau createAnswer SDP trebuie să fie conectate la fazele de transmisie și obiectele candidate gheață.

flux media (MediaStream), mânerul sesiunii (SDP) și candidați (candidat Ice) - Mai multe detalii unele entități, și anume să fie luate în considerare.

entităţile cheie

fluxuri media (MediaStream)

WebRTC există o ierarhie destul de complicată în cadrul fluxului. Fiecare fir poate consta din mai multe piste media (Mediatrack), care la rândul lor, pot consta din mai multe canale media (MediaChannel). Da ei înșiși și fluxuri media pot fi oarecum prea.

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

Figura 5: fluxuri media constau din piese media

Figura 6: fluxurile media și căile sunt identificate prin etichete

De exemplu, în cazul în care o piesă media poate fi identificat printr-o etichetă, atunci de ce avem nevoie de acest exemplu folosesc fluxul de două mass-media, în loc de unul? După un flux media singur poate fi transmis și de a folosi piese diferite în ea. Am ajuns la proprietățile critice ale fluxurilor media - acestea sincroniza urmări mass-media. Diferite fluxuri media nu sunt sincronizate unul cu celălalt, dar în cadrul fiecărei mass-media flux toate piesele sunt reproduse simultan.

Astfel, dacă dorim cuvintele noastre, emoțiile noastre pe fața ei, și bucata noastră de hârtie reprodus în același timp, este necesar să se utilizeze un flux media unică. În cazul în care acest lucru nu este atât de important, este avantajos să se utilizeze diferite fluxuri - imaginea va fi mai buna 4.

În cazul în care un fel de pistă trebuie să fie oprit în timpul transferului, puteți utiliza funcția activată pista media.

descriptor sesiunii (SDP)

Deoarece WebRTC au capacitatea de a edita obiect PSD, atunci ar trebui să fie setat la primirea unui descriptor local. Acest lucru poate parea un pic ciudat, trebuie să transferați WebRTC că ea ne-a dat, dar este protocolul. acesta trebuie să fie, de asemenea, setat la primirea unui descriptor de la distanță. Prin urmare, trebuie să instalați pe același nod doi descriptori - și altele (adică local și la distanță).

După o astfel de strângere de mână nodurile sunt conștienți de dorințele celuilalt. De exemplu, dacă nodul 1 suportă codecuri și B. A și nodul 2 suportă codec-uri B și C. apoi, din moment ce fiecare nod cunoaște adversarul și descrierile sale, ambele noduri vor alege codec B (Figura 7). Logica de conectare este acum setată, și puteți transfera fluxurile media, dar există o altă problemă - nodurile sunt încă legați printr-un mecanism de semnalizare.

Figura 7: Alinierea codecurile

Candidații (candidat Ice)

Spre deosebire de descriptori sesiune este că trebuie să instalați doar candidații la distanță. Editarea nu este permisă și nu poate aduce nici un beneficiu. În unele implementări, candidații WebRTC trebuie instalate numai după instalarea mânerelor 9 sesiuni.

Figura 8: Două noduri pe aceeași rețea

În timp ce nodurile din aceeași rețea - toate pur și simplu și ușor - fiecare nod are un singur obiect candidat (se referă întotdeauna la propria lui, adică, locația în rețea). Dar candidații vor fi mult mai mare în cazul în care nodurile sunt localizate în rețele diferite.

Ne întoarcem acum la un caz mai complicat. Un nod va fi în spatele router (sau mai precis, pentru NAT), și un al doilea nod va fi în aceeași rețea ca acest router (de exemplu, Internetul) (Figura 9).

Figura 9: Un nod pentru NAT, cealaltă nu

Acest caz are o soluție specială pentru problema, pe care o considerăm acum. Acasă router-ul conține, de obicei, masa de NAT. Acest mecanism special conceput pentru noduri în rețea privată router-ar putea aplica, de exemplu, site-uri web.

Să ne întoarcem la tehnologia WebRTC. sau, mai degrabă, la partea care utilizează protocolul ICE (deci candidați Ice). Nodul p2 este un 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 - locale (192.168.0.200) și router candidat (10.50.200.5). Primul nu este util, dar este, cu toate acestea, generate ca WebRTC încă nu știe nimic despre site-ul de la distanță - poate fi în aceeași rețea, dar poate nu. Al doilea candidat este util, și, după cum știm deja, va fi important port (să treacă prin NAT).

Scrierea în tabelul de NAT este generat numai atunci când datele provin din rețeaua internă. Prin urmare, nodul p1 trebuie să transfere mai întâi datele, și numai după aceea datele nodul p2 pot ajunge la p1 nod.

STUN și serverul TURN

Când inițializarea WebRTC trebuie să specifice STUN disponibile și Nap serverele pe care le vom fi numite servere ICE. Dacă serverul nu va fi specificat, va fi capabil să se conecteze nodurile pe aceeași rețea (conectat la acesta, fără a NAT) numai. Imediat trebuie remarcat faptul că, pentru 3G -Net folosesc în mod necesar servere virajului.

Să considerăm acest proces prin exemplul.

Exemplu (STUN server de lucru)

STUN server este notat cu s1. Router, ca și mai înainte, prin r1. un nod - prin p1. Veți avea nevoie, de asemenea, să monitorizeze tabela NAT - acesta este notat ca r1_nat. Și în acest tabel conține, de obicei, o mulțime de înregistrări dintr-o subrețea diferite noduri - ele nu vor fi conduse.

Deci, la început, avem un r1_nat tabel gol.

Ce urmează? Care este beneficiul tuturor? Beneficii - un record în tabelul r1_nat. Acum, dacă cineva va fi trimis la router r1 pachetul la portul 888 router-ul va transmite nodul de pachete p1. Astfel, pentru a crea un mic pasaj îngust la un nod p1 ascuns.

Din exemplul de mai sus, puteți obține o idee despre server NAT și, în esență, STUN. În general, mecanismul de ICE și server STUN / TURN are ca scop tocmai depășirea limitărilor NAT.

Server TURN - este îmbunătățit serverul STUN. Acest lucru se trase imediat că orice server TURN poate funcționa ca un server STUN. Cu toate acestea, există, de asemenea, avantaje. În cazul în care comunicarea p2p este imposibilă (cum ar fi în rețelele 3G), serverul devine un mod repetor (releu), adică, acționează ca un intermediar. Desigur, despre orice p2p atunci noi nu vorbim, dar în afara nodurilor mecanism ICE cred că ei comunică în mod direct.

Astfel, este nevoie de server TURN, în cazul în care sunteți amândoi în spatele simmetrichnymNAT (pentru fiecare om sa).

scurt rezumat

Iată câteva declarații despre entități WebRTC. care ar trebui să păstreze întotdeauna în minte. Detaliile sunt descrise mai sus. Dacă unele dintre afirmațiile pe care nu par a fi destul de clar, re-citit punctele relevante.

Din moment ce toate nodurile din rețea același router. # 8617;

Acest exemplu de benzi desenate este întotdeauna util pentru a păstra în minte să se diferențieze între comunicare în tehnologie WebRTC de semnal de comunicație # 8617;

Foarte simplist. De fapt, PSD - este singurele date care sunt transmise, și care face parte din candidați. # 8617;

Sincronizarea petrecut întotdeauna timp suplimentar. # 8617;

În zilele de candidați Vanilla Ice au fost adoptate în cadrul PSD. astfel încât conexiunea este deja acolo. # 8617;

Se poate doar de acord, nu poți refuza. În caz de refuz, pur și simplu ignora cererea de conectare. # 8617;

De exemplu, pentru conectarea la ftp ftp-clienti cu TCP -Server primul -compus (pentru protocolul de strat de transport protocol la nivel de aplicație poate fi considerată fizică) și numai apoi transferate prin FTP (de exemplu logica protocol). # 8617;

Aceasta este realizarea libjingle și unele browsere. Acest lucru se datorează faptului că candidații fac parte din PSD și obiectul este înregistrată în ea. # 8617;