A WebRTC egy böngésző által biztosított API, amely lehetővé teszi a P2P kapcsolat megszervezését és a böngészők közötti közvetlen adatátvitelt. Az interneten számos oktatóanyag található arról, hogyan írhat saját videocsevegést a WebRTC használatával. Itt van például egy cikk Habréról. Mindazonáltal mindegyik két kliens összekapcsolására korlátozódik. Ebben a cikkben megpróbálok beszélni arról, hogyan lehet kapcsolatot és üzenetváltást megszervezni három vagy több felhasználó között a WebRTC használatával.

Az RTCPeerConnection felület egy peer-to-peer kapcsolat két böngésző között. Három vagy több felhasználó összekapcsolásához meg kell szerveznünk egy mesh hálózatot (olyan hálózatot, amelyben minden csomópont az összes többi csomóponthoz kapcsolódik).
A következő sémát fogjuk használni:

Az oldal megnyitásakor ellenőrizzük a szobaazonosító meglétét a location.hash-ben

Ha a szobaazonosító nincs megadva, hozzon létre egy újat

Egy jelzőszervernek küldünk egy üzenetet, hogy csatlakozni akarunk a megadott helyiséghez

A jelzőszerver új felhasználói értesítést küld a szobában lévő többi kliensnek

Azok az ügyfelek, akik már a szobában vannak, SDP-ajánlatot küldenek az újonnan érkezőnek

A jövevény válaszol az ajánlatra "s

0. Jelzőszerver

Mint ismeretes, bár a WebRTC lehetőséget biztosít a P2P kapcsolatra a böngészők között, a szolgáltatási üzenetek cseréjéhez még szükség van egy további szállításra. Ebben a példában az átvitel egy WebSocket-kiszolgáló, amelyet Node.JS-ben írnak a socket.io használatával:

var socket_io = igény("socket.io"); module.exports = function (szerver) ( var users = (); var io = socket_io(szerver); io.on("kapcsolat", function(socket) ( // Új felhasználót szeretne csatlakozni a szobához socket.on( "szoba ", function(message) ( var json = JSON. parse(message); // A socket hozzáadása a felhasználók listájához user = socket; if (socket.room !== undefined) ( // Ha a socket már valamelyik szobában hagyja el socket.leave(socket.room); ) // Adja meg a kért helyiséget socket.room = json.room; socket.join(socket.room); socket.user_id = json.id; // Küldés más ügyfeleknek ez a szoba üzenetet tartalmaz egy új résztvevőhöz való csatlakozásról socket.broadcast.to(socket.room).emit("new", json.id; )); // WebRTC-vel kapcsolatos üzenet (SDP ajánlat, SDP válasz vagy ICE jelölt) socket.on("webrtc", function(message) ( var json = JSON.parse(message); if (json.to !== undefined && users !== undefined) ( // Ha az üzenet a kiszolgáló által ismert címzett és ez a címzett, csak neki küldünk üzenetet... users.emit("webrtc", üzenet); ) else ( // ...egyébként tekintsük az üzenetet broadcast socket.broadcast.to(socket.room).emit("webrtc", üzenet); ) ); // Valaki megszakította a kapcsolatot socket.on("disconnect", function() ( // Ha egy kliens megszakad, értesítsen másokat socket.broadcast.to(socket.room).emit("leave", socket.user_id); felhasználók törlése; )); )); );

1. index.html

Maga az oldal forráskódja meglehetősen egyszerű. Szándékosan nem figyeltem az elrendezésre és más szép dolgokra, mivel ez a cikk nem erről szól. Ha valaki szépíteni akarja, az nem lesz nehéz.

WebRTC Chat Demo Csatlakozva 0 társhoz
Küld

2. main.js 2.0. Oldalelemekre és WebRTC-felületekre mutató hivatkozások lekérése var chatlog = document.getElementById("chatlog"); var üzenet = document.getElementById("üzenet"); var csatlakozási_szám = document.getElementById("kapcsolat_száma"); var room_link = document.getElementById("szoba_link");

A WebRTC felületek eléréséhez továbbra is böngésző előtagokat kell használnunk.

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

2.1. A szobaazonosító meghatározása

Itt szükségünk van egy függvényre, amely egyedi helyiséget és felhasználói azonosítót generál. Erre a célra az UUID-t fogjuk használni.

Függvény uuid () ( var s4 = function() ( return Math.floor(Math.random() * 0x10000).toString(16); ); return s4() + s4() + "-" + s4() + "-" + s4() + "-" + s4() + "-" + s4() + s4() + s4(); )

Most próbáljuk meg kinyerni a szobaazonosítót a címből. Ha ez nincs beállítva, akkor újat generálunk. Az oldalon megjelenítjük az aktuális szobára mutató hivatkozást, és ezzel egyidejűleg azonosítót generálunk az aktuális felhasználó számára.

VarROOM = location.hash.substr(1); if (!ROOM) ( ROOM = uuid(); ) room_link.innerHTML = "Hivatkozás a szobához"; varME = uuid();

2.2. webes aljzat

Az oldal megnyitásakor azonnal kapcsolódunk jelzőszerverünkhöz, kiküldjük a terembe való belépési kérelmet és megadjuk az üzenetkezelőket.

// Megadjuk, hogy az üzenet bezárásakor erről értesítést kell küldenünk a szervernek. var socket = io.connect("", ("sync disconnect on unload": true)); socket.on("webrtc", socketReceived); socket.on("új", socketNewPeer); // Azonnal küldjön egy kérést a szoba belépésére socket.emit("szoba", JSON.stringify((id: ME, room: ROOM))); // Segítő funkció a WebRTC függvényhez kapcsolódó címüzenetek küldéséhez sendViaSocket(type, message, to) ( socket.emit("webrtc", JSON.stringify((id: ME, to: to, type: type, data: message )) ));)

2.3. Peer kapcsolat beállításai

A legtöbb internetszolgáltató NAT-on keresztül biztosít internetkapcsolatot. Emiatt a közvetlen kapcsolat nem válik annyira triviálissá. A kapcsolat létrehozásakor meg kell adnunk a STUN és TURN szerverek listáját, amelyeket a böngésző megpróbál a NAT megkerülésére használni. Meghatározunk egy párat is további beállítások kapcsolódni.

Var szerver = ( iceServers: [ (url: "stun:23.21.150.121"), (url: "stun:stun.l.google.com:19302"), (url: "turn:numb.viagenie.ca", hitelesítő adatok: "ide megy a jelszava", felhasználónév: " [e-mail védett]") ] ); var options = ( opcionális: [ (DtlsSrtpKeyAgreement: true), // szükséges a Chrome és a Firefox közötti kapcsolathoz (RtpDataChannels: true) // szükséges a Firefoxban a DataChannels API használatához ] )

2.4. Új felhasználó csatlakoztatása

Amikor egy új társat adnak a szobához, a szerver új üzenetet küld nekünk. A fenti üzenetkezelők szerint a socketNewPeer függvény meghívásra kerül.

var peers = (); függvény socketNewPeer(data) ( peers = (candidateCache: ); // Új kapcsolat létrehozása var pc = new PeerConnection(server, options); // Inicializálja initConnection(pc, data, "ajánlat"); // Tárolja a peer a listában peers peers.connection = pc; // Hozzon létre egy DataChannel-t, amelyen keresztül üzenetek cserélődnek. var channel = pc.createDataChannel("mychannel", ()); channel.owner = adatok; peers.channel = csatorna; // Set eseménykezelők csatorna bindEvents(channel); // SDP-ajánlat létrehozása pc.createOffer(function(ajánlat) ( pc.setLocalDescription(ajánlat); )); ) function initConnection(pc, id, sdpType) ( pc.onicecandidate = function (event) ( if (event.candidate) ( // Ha új ICE jelöltet talál, adja hozzá a listához további küldéshez peers.candidateCache.push(event.candidate); ) else ( // Amikor a jelöltek felfedezése befejeződött, a kezelő újra meghívásra kerül, de jelölt nélkül // Ebben az esetben először SDP-ajánlatot vagy SDP-választ küldünk a peer-nek (a függvény paraméterétől függően)... sendViaSocket(sdpType, pc.localDescription, id ); // ...és ezután az összes korábban talált ICE jelölt (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 += "Peer says: " + e.data + ""; }; }

2.5. SDP ajánlat, SDP válasz, ICE jelölt

Ha ezek közül az üzenetek egyike érkezik, felhívjuk a megfelelő üzenetkezelőt.

Függvény socketReceived(data) ( var json = JSON.parse(data); kapcsoló (json.type) ( "jelölt" eset: remoteCandidateReceived(json.id, json.data); szünet; kis- és nagybetű "ajánlat": remoteOfferReceived(json. id, json.data); break; kis- és nagybetű "válasz": remoteAnswerReceived(json.id, json.data); break; ) )

2.5.0 SDP ajánlatfüggvény remoteOfferReceived(id, data) ( createConnection(id); var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); pc.createAnswer(function(válasz) ( pc.setLocalDescription(válasz) ); )); ) function createConnection(id) ( if (peers === undefined) ( peers = (candidateCache: ); var pc = new PeerConnection(server, options); initConnection(pc, id, "answer"); peers.connection = pc; pc.ondatachannel = function(e) ( peers.channel = e.channel; peers.channel.owner = id; bindEvents(peers.channel); ) ) ) 2.5.1 SDP válaszfüggvény remote AnswerReceived(id , data) ( var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); ) 2.5.2 ICE jelölt függvény remoteCandidateReceived(id, data) ( createConnection(id); var pc = peers.connection; pc. addIceCandidate(új IceCandidate(data)); ) 2.6. Üzenet küldése

Ha a Küldés gombra kattint, a SendMessage funkció meghívódik. Mindössze annyit tesz, hogy végigmegy a partnerek listáján, és megpróbálja mindenkinek elküldeni a megadott üzenetet.

Az európai internetezők két részre oszlanak: az allenbachi (Németország) Közvélemény-elemző Intézet felmérése szerint a Skype, a chat- és azonnali üzenetküldő rendszerek 16,5 millió felnőtt és gyermek, 9 millió ember mindennapi életének szerves részévé váltak. esetről esetre veszik igénybe ezeket a szolgáltatásokat, és 28 millióan nem nyúlnak hozzájuk.

Ez változhat, mivel a Firefox immár integrálja a valós idejű kommunikációs technológiát (WebRTC), valamint magát a klienst. Az audio- és videocsevegés indítása most nem nehezebb, mint egy webhely megnyitása. Az olyan szolgáltatások viszont, mint a Facebook és a Skype, külön klienst használó megoldásokra és fiók létrehozására támaszkodnak.

A WebRTC nem csak egyszerűen használható. Ezzel a módszerrel még közvetlen kapcsolatot is létesíthet két böngésző között. Így a hang- és képadatok nem haladnak át olyan szerveren, ahol túlterhelés léphet fel, vagy amelynek rendszergazdája nem különösebben érzékeny a magánéletre vagy az adatvédelemre. A közvetlen kapcsolatnak köszönhetően a WebRTC nem igényel regisztrációt ill fiók bármely szolgáltatásban.

Beszélgetés indításához csak a linket kell követnie. A kommunikáció privát marad, mivel az adatfolyam titkosítva van. Valós idejű kommunikáció böngészőn keresztül Google 2011-ben kezdett aktívan részt venni, amikor közzétette WebRTC implementációjának forráskódját.

Röviddel ezután a Chrome és a Firefox megkapta a saját WebRTC motorját. Jelenleg azok mobil lehetőségek mind ezzel a technológiával, mind az alkalmazások által használt Android 5.0-val telepített WebView 3.6 motorral.

A valós idejű kommunikációhoz a megfelelő JavaScript felületeket kell megvalósítani a webes megjelenítőben. A GetUserMedia használata szoftver aktiválja a rögzítést hang- és videoforrásokból, azaz webkamerából és mikrofonból. Az RTCPeerConnection felelős a kapcsolat létrehozásáért, valamint magáért a kommunikációért.

Párhuzamosan a böngésző integrációjával munkacsoport A World Wide Web Consortium (W3C) szorgalmazza a WebRTC szabványosítási folyamatát. 2015-ben kell elkészülnie.

A WebRTC megelégszik kevéssel

A WebRTC szolgáltatás használata nem igényel sok erőforrást, mivel a szerver csak a haverokat köti össze. A kapcsolat létrehozása sem különösebben nehéz. Először a böngésző jelzi a WebRTC szervernek, hogy hívás kezdeményezését tervezi. HTTPS hivatkozást kap a szervertől - a kapcsolat titkosított. A felhasználó elküldi ezt a linket beszélgetőpartnerének. A böngésző ezután engedélyt kér a felhasználótól a webkamera és a mikrofon eléréséhez.

A másik féllel való közvetlen streaming kapcsolat létrehozásához a böngésző megkapja IP-címét és konfigurációs adatait a WebRTC szolgáltatástól. A haver webböngészője ugyanezt teszi.

A streaming kapcsolat zökkenőmentes működése érdekében jó minőségű, három motor működik a böngészőben. Közülük kettő optimalizálja és tömöríti az audio- és videoadatokat, a harmadik pedig ezek szállításáért felel. Az adatokat az SRTP (Secure Real-time Transport Protocol) segítségével küldi, amely lehetővé teszi a titkosított valós idejű adatfolyamot.

Ha a közvetlen kapcsolat meghiúsul, a WebRTC másik elérési utat keres. Ez például akkor történik, amikor hálózati beállítások megakadályozza, hogy a STUN szerver jelenteni tudja az IP-címet. A WebRTC szabvány előírja, hogy ebben az esetben a beszélgetés megtörténik, de közben a TURN szerver (Traversal Using Relays around NAT) bevonásával. Tehát a netscan.co webhelyen ellenőrizheti, hogy a WebRTC implementálva van-e az Ön számítógépén és a web-hozzáféréssel.

Hogyan jön létre a kapcsolat

Először regisztrálnia kell egy beszélgetést (1). A WebRTC szolgáltatás egy hivatkozást biztosít, amelyet el kell küldeni a beszélgetőpartnernek. A böngésző a STUN-szerver segítségével megkeresi saját IP-címét (2), elküldi a szolgáltatásnak, és megkapja a partner IP-jét a közvetlen kapcsolat létrehozásához (3). Ha a STUN sikertelen, a beszélgetést a TURN szerver (4) segítségével irányítja át.

A WebRTC technológiát használó kommunikáció a böngészőben JavaScript kóddal indul. Ezt követően három motor felel a kommunikációért: a hang- és videómotorok a webkamerából és a mikrofonból gyűjtik a multimédiás adatokat, a szállítómotor pedig egyesíti az információkat, és a Secure Real-time Protocol (SRTP) segítségével titkosított formában küldi el a streamet.

Mely böngészők működnek a WebRTC-vel

A Chrome és a Firefox WebRTC motorral van felszerelve, amely olyan szolgáltatásokat használ, mint a talky.io. A Mozilla böngésző közvetlenül képes együttműködni saját kliensével.

A Google és a Mozilla tovább fejleszti a valós idejű kommunikáció ötletét: a Chrome több résztvevős WebRTC-konferenciát tud rendezni, a Firefox új Hello-kliensét pedig a Telefonica távközlési óriáscég leányvállalata fejleszti. Az Apple egyelőre a pálya szélén marad, a WebRTC-re még nem kell számítani a Safariban. A Safarihoz azonban rengeteg alternatív iOS-alkalmazás és -bővítmény létezik.

A Microsoft egy kicsit más irányt követ. A versenyképes Skype szolgáltatás tulajdonosaként ez a cég nem fog ilyen könnyen megadni magát a WebRTC előtt. Ehelyett a Microsoft az ORTC (Object Real-Time Communications) nevű technológiát fejleszti internet böngésző.

A WebRTC-től való eltérések, mint például a szerverrel való kapcsolatfelvételhez szükséges különböző kodekek és protokollok, csekélyek, és idővel valószínűleg kiegészítik a WebRTC szabványt, amely magában foglalja ezeket a különbségeket. Így – szokás szerint – csak az Apple marad le.

Fotó: gyártó cégek; goodluz/Photolia.com

Napjainkban a WebRTC a "forró" technológia az audio- és videostreamelésre a böngészőkben. A konzervatív technológiák, mint pl HTTP Streamingés a Flash alkalmasabb a rögzített tartalom (video on demand) terjesztésére, és lényegesen alulmúlja a WebRTC-t valós idejű és online adások tekintetében, i. ahol minimális videó késleltetés szükséges, így a nézők „élőben” láthatják, mi történik.

A kiváló minőségű valós idejű kommunikáció lehetősége magából a WebRTC architektúrából adódik, ahol az UDP protokollt használják a videó folyamok továbbítására, amely a minimális késleltetésű videó továbbítás standard alapja, és széles körben használatos a valós idejű kommunikációs rendszerekben.

A kommunikációs késleltetés fontos az élő streaming rendszerekben, webináriumokban és más alkalmazásokban, ahol interaktív kommunikációra van szükség a videó forrásával, a végfelhasználókkal és a megoldással.

Egy másik jó ok a WebRTC kipróbálására határozottan trend. Ma minden Android Chrome böngésző támogatja ezt a technológiát, amely biztosítja, hogy több millió eszköz álljon készen az adás megtekintésére további szoftverek és konfigurációk telepítése nélkül.

A WebRTC technológia működésének tesztelésére és egy egyszerű online adás indítására a Flashphoner WebRTC Media & Broadcasting Server szerver szoftvert használtuk. A funkciók deklarálják a WebRTC adatfolyamok egy-a többhez módban történő sugárzásának lehetőségét, valamint az IP-kamerák és a videó megfigyelőrendszerek támogatását az RTSP protokollon keresztül; Ebben az áttekintésben a web-web adásokra és azok funkcióira fogunk összpontosítani.

WebRTC Media & Broadcasting Server telepítése

Mert azért Windows rendszerek nem volt szerververzió, és nem akartam olyan virtuális gépet telepíteni, mint a VMWare + Linux, tesztelni az online adásokat otthon Windows számítógép Nem sikerült. Az időmegtakarítás érdekében úgy döntöttünk, hogy példát veszünk a felhőalapú tárhelyszolgáltatásról, például:

Ez egy Centos x86_64 6.5-ös verzió volt, minden előre telepített szoftver nélkül egy amszterdami adatközpontban. Így csak egy szerver és ssh hozzáférés áll rendelkezésünkre. Azoknak, akik ismerik konzolparancsok Linux, WebRTC beállítása szerver egyszerűnek és fájdalommentesnek ígérkezik. Szóval mit csináltunk:

1. Archívum letöltése:

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

2. Kicsomagolás:

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

3. Telepítés:

$cd FlashphonerWebCallServer

A telepítés során adja meg a szerver IP-címét: XXX.XXX.XXX.XXX

4. Aktiválja a licencet:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. Indítsa el a WCS-kiszolgálót:

$service webcallserver start

6. Ellenőrizze a naplót:

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

7. Ellenőrizze, hogy két folyamat működik-e:

$ps aux | grep Flashphoner

A telepítési folyamat befejeződött.

WebRTC élő közvetítések tesztelése

A közvetítések tesztelése egyszerű dolognak bizonyult. A szerveren kívül van egy webes kliens is, amely tucatnyi Javascript, HTML és CSS fájlból áll, és a telepítés során mi telepítettük a /var/www/html mappába. Csak annyit kellett tenni, hogy a flashphoner.xml konfigurációba be kellett írni a szerver IP-címét, hogy a webkliens HTML5 Websocketeken keresztül tudjon kapcsolatot létesíteni a szerverrel. Ismertesse a tesztelési folyamatot.

1. Nyissa meg a tesztkliens index.html oldalát a Chrome böngészőben:

2. A sugárzás elindításához kattintson a képernyő közepén található "Start" gombra.
Mielőtt ezt megtenné, meg kell győződnie arról, hogy a webkamera csatlakoztatva van, és használatra kész. A webkamerával szemben nincs különösebb követelmény, például szabványos beépített laptop kamerát használtunk 1280 × 800 felbontással.

A Chrome böngésző minden bizonnyal hozzáférést fog kérni a kamerához és a mikrofonhoz, hogy a felhasználó megértse, hogy videója elküldésre kerül az internetes szerverre, és lehetővé teszi számára ezt.

3. Az interfész a videofolyam sikeres fordítása a kameráról a WebRTC szerverre. A jobb felső sarokban a jelző jelzi, hogy a stream a szerverre megy, az alsó sarokban pedig egy "Stop" gomb található a videó küldésének leállításához.

Vessen egy pillantást az alábbi linkre. Egyedi azonosítót tartalmaz ehhez az adatfolyamhoz, így bárki csatlakozhat a nézethez. Csak nyissa meg ezt a hivatkozást egy böngészőben. A vágólapra másoláshoz kattintson a "Másolás" gombra.

Az olyan valós alkalmazásokban, mint a webináriumok, előadások, online videoközvetítések vagy interaktív tévéadások, a fejlesztőknek meg kell valósítaniuk ennek az azonosítónak a szétosztását a nézők bizonyos csoportjai számára, hogy csatlakozhassanak a kívánt streamekhez, de ez az alkalmazás logikája. A WebRTC Media & Broadcasting Server nincs hatással rá, csak videót terjeszt.

5. A kapcsolat létrejön, és a néző látja az adatfolyamot a képernyőn. Mostantól elküldheti a linket valaki másnak, leállíthatja a stream lejátszást vagy engedélyezheti a teljes képernyős módot a jobb alsó sarokban található vezérlők segítségével.

WebRTC szerver tesztelési eredmények online adásokhoz

A tesztek során a várakozási idő tökéletesnek tűnt. Az adatközpontba érkező ping körülbelül 100 ezredmásodperc volt, és a késés nem volt látható a szemnek. Innentől kezdve feltételezhetjük, hogy a valódi késleltetés ugyanaz, mint 100 plusz-mínusz néhány tíz milliszekundum a pufferelési időre. A Flash videóhoz képest ezekben a tesztekben a Flash nem teljesít olyan jól, mint a WebRTC. Tehát, ha egy hasonló hálózaton mozgatja a kezét, akkor a mozgás a képernyőn csak egy/két másodperc múlva látható.

A minőséggel kapcsolatban megjegyezzük, hogy néha meg lehet különböztetni a kockákat a mozgásokon. Ez összhangban van a VP8 kodek természetével, és fő célja a valós idejű videokommunikáció biztosítása elfogadható minőségben és kommunikációs késések nélkül.

A szerver telepítése és konfigurálása meglehetősen egyszerű, nem igényel komolyabb készségeket a futtatásához, kivéve a Linux ismerete haladó szinten, aki képes parancsokat végrehajtani a konzolról ssh-n keresztül és használni szöveg szerkesztő. Ennek eredményeként sikerült beállítani egy-a-többhöz online adást a böngészők között. További nézők csatlakoztatása sem okozott problémát.

A webináriumok és online adások közvetítésének minősége meglehetősen elfogadhatónak bizonyult. Csak a videó felbontása okozott néhány kérdést. A kamera támogatja az 1280x800-as felbontást, de a tesztképen a felbontás nagyon hasonló a 640x480-hoz. Úgy tűnik, ezt a kérdést tisztázni kell a fejlesztőkkel.

Videó a webkameráról történő tesztelésről
WebRTC szerveren keresztül

A WebRTC-n található anyagok nagy része a kódolás alkalmazási rétegére összpontosít, és nem járul hozzá a technológia megértéséhez. Próbáljunk meg mélyebbre menni, és megtudjuk, hogyan jön létre a kapcsolat, mi a munkamenet-leíró és a jelöltek, mire valók a STUN és TURN szerverek.

WebRTC Bevezetés

A WebRTC egy böngésző alapú technológia, amely lehetővé teszi két kliens összekapcsolását videó adatátvitelhez. A fő jellemzők a belső böngésző támogatása (nincs szükség harmadik féltől származó beágyazott technológiákra, mint pl Adobe Flash) és a kliensek összekapcsolásának képessége további szerverek használata nélkül - peer-to-peer kapcsolat (a továbbiakban: p2p).

A p2p kapcsolat létrehozása meglehetősen nehéz feladat, mivel a számítógépek nem mindig rendelkeznek nyilvános IP-címekkel, azaz az interneten található címekkel. Az IPv4-címek kis száma miatt (és biztonsági okokból) kifejlesztették a NAT-mechanizmust, amely lehetővé teszi például otthoni használatra privát hálózatok létrehozását. Sok otthoni útválasztó már támogatja a NAT-ot, és ennek köszönhetően minden otthoni eszköz hozzáfér az internethez, bár az internetszolgáltatók általában egy IP-címet biztosítanak. A nyilvános IP-címek egyediek az interneten, de a privátok nem. Ezért nehéz a p2p csatlakoztatása.

Ennek jobb megértéséhez vegyünk három helyzetet: mindkét csomópont ugyanazon a hálózaton van (1. ábra), mindkét csomópont különböző hálózaton (az egyik privát, a másik nyilvános) (2. ábra), és mindkét csomópont különböző magánhálózaton van. azonos IP-című hálózatok (3. ábra) .

1. ábra: Mindkét csomópont ugyanazon a hálózaton

2. ábra: Csomópontok különböző hálózatokon (egy privát, egy nyilvános)

3. ábra: Csomópontok különböző magánhálózatokban, de számszerűen azonos címekkel

A fenti ábrákon a kétkarakteres jelölés első betűje a csomópont típusát jelöli (p = peer , r = router ). Az első ábrán a helyzet kedvező: hálózatuk csomópontjait meglehetősen azonosítják a hálózati IP-címek, így közvetlenül tudnak kapcsolódni egymáshoz. A második ábrán két különböző hálózatunk van, amelyeknek hasonló csomópontszámai vannak. Itt megjelennek az útválasztók (routerek), amelyeknek kettő van hálózati felület- a hálózaton belül és a hálózaton kívül. Ezért két IP-címük van. A normál csomópontoknak csak egy interfészük van, amelyen keresztül csak a saját hálózatukon tudnak kommunikálni. Ha a hálózatukon kívül valakinek továbbítanak adatokat, akkor csak a routeren (routeren) belüli NAT-ot használva, így mások számára láthatóak a router IP-címe alatt – ez az ő külső IP-cím. Így a p1 csomópont rendelkezik belső IP= 192.168.0.200 És külső IP= 10.50.200.5 , amelynek utolsó címe a hálózatán lévő összes többi gazdagépen kívül is van. Hasonló a helyzet a p2 csomópont esetében is. Ezért kommunikációjuk lehetetlen, ha csak belső (saját) IP-címeiket használják. Használhat külső címeket, azaz útválasztók címeit, de mivel ugyanabban a magánhálózatban minden csomópontnak ugyanaz a külső címe, ez meglehetősen nehéz. Ezt a problémát a NAT mechanizmussal oldják meg.

Mi történik, ha mégis úgy döntünk, hogy a csomópontokat belső címükön keresztül csatlakoztatjuk? Az adatok nem hagyják el a hálózatot. A hatás fokozása érdekében elképzelheti az utolsó ábrán látható helyzetet - mindkét csomópontnak ugyanaz a belső címe. Ha ezeket használják kommunikációra, akkor minden csomópont önmagával kommunikál.

A WebRTC sikeresen kezeli az ilyen problémákat az ICE protokoll használatával, amely azonban további szerverek használatát igényli (STUN , TURN ). Mindezt alább.

A WebRTC két fázisa

Ahhoz, hogy két csomópontot összekapcsolhassunk a WebRTC protokollon keresztül (vagy egyszerűen RTC, ha két iPhone van csatlakoztatva), el kell végezni néhány előzetes akciók kapcsolatot létesíteni. Ez az első fázis – a kapcsolat létrehozása. A második fázis a videó adatok továbbítása.

Azonnal el kell mondani, hogy bár a WebRTC technológia sokat használ különböző módokon kommunikáció (TCP és UDP), és rugalmas váltást biztosít közöttük, ez a technológia nem rendelkezik protokollal a kapcsolati adatok átadására. Nem meglepő, mert két p2p csomópont összekapcsolása nem olyan egyszerű. Ezért szükséges, hogy legyen néhány további adatátviteli módszer, amelynek semmi köze a WebRTC-hez. Lehet socket átvitel, HTTP protokoll, akár SMTP protokoll vagy orosz posta is. Ez az átviteli mechanizmus elsődleges adatot hívják jel. Nem kell sok információt átadni. Az összes adatot szövegként továbbítják, és két típusra oszthatók: SDP és Ice Candidate. Az első típus logikai, a második pedig fizikai kapcsolat létrehozására szolgál. Minderről később, de egyelőre csak azt kell megjegyeznünk, hogy a WebRTC olyan információkat ad nekünk, amelyeket egy másik csomóponthoz kell továbbítani. Amint minden szükséges információt átadunk, a csomópontok képesek lesznek kapcsolódni, és a segítségünkre már nincs szükség. Tehát a jelzőmechanizmust meg kell valósítanunk külön, használva lesz csak csatlakoztatva, és nem használják videoadatok átviteléhez.

Nézzük tehát az első fázist, a kapcsolat beállítási fázisát. Több elemből áll. Tekintsük ezt a fázist először a kapcsolatot kezdeményező csomópontnál, majd a várakozónál.

• Kezdeményező (hívó - hívó):
• Ajánlat a videó adatátvitel elindítására (createOffer)
• SDP SDP beszerzése)
• Jégjelölt megszerzése Ice jelölt)
• Hívásvárakoztatás (hívó):
• Helyi (saját) médiafolyam beszerzése és átvitelre való beállítása (getUserMediaStream)
• Ajánlat fogadása videó adatátvitel megkezdésére és válasz létrehozására (createAnswer)
• Az SDP objektum lekérése és átadása a jelzőmechanizmuson (SDP)
• Jégjelölt objektumok fogadása és átadása a jelzőmechanizmuson (Jégjelölt )
• Távoli (idegen) médiafolyam fogadása és megjelenítése a képernyőn (onAddStream)

Az egyetlen különbség a második bekezdésben van.

A lépések látszólagos bonyolultsága ellenére valójában három van belőlük: saját médiafolyam küldése (1. o.), kapcsolati paraméterek beállítása (2-4. oldal), valaki más médiafolyamának fogadása (5. oldal). A legnehezebb a második lépés, mert ez két részből áll: az alapításból fizikaiÉs logikus kapcsolatokat. Az első jelzi pálya, amelyen a csomagoknak haladniuk kell ahhoz, hogy az egyik hálózati csomópontból a másikba kerüljenek. A második jelzi videó/audio paraméterek- milyen minőséget, milyen kodeket használjunk.

Mentálisan a createOffer vagy a createAnswer szakasznak kapcsolódnia kell az SDP és az Ice jelölt objektumok átadásának szakaszaihoz.

Alapvető entitások Médiafolyamok (MediaStream)

A fő entitás a médiafolyam, vagyis a video- és hangadatok, kép és hang folyama. Kétféle médiafolyam létezik – helyi és távoli. A helyi a bemeneti eszközöktől (kamera, mikrofon), a távoli pedig a hálózaton keresztül fogad adatokat. Így minden csomópontnak van helyi és távoli szála is. A WebRTC-ben van MediaStream felület a streamekhez, és van egy LocalMediaStream alinterfész is, amely kifejezetten a helyi szál. JavaScriptben csak az elsővel találkozhatunk, ha pedig libjingle -t használunk, akkor a másodikkal is.

A WebRTC-ben meglehetősen zavaros hierarchia van egy adatfolyamon belül. Minden adatfolyam több médiasávból állhat (MediaTrack ), amelyek viszont több médiacsatornát is tartalmazhatnak (MediaChannel ). És lehet több médiafolyam is.

Vegyünk mindent sorjában. Ehhez tartsunk szem előtt néhány példát. Tegyük fel, hogy nem csak egy videót szeretnénk közvetíteni magunkról, hanem az asztalunkról is, amelyen egy papírlap hever, amire írunk valamit. Szükségünk lesz két videóra (mi + asztal) és egy hangra (mi). Nyilvánvaló, hogy minket és a táblázatot különböző szálakba kell osztani, mert ezek az adatok valószínűleg gyengén függenek egymástól. Ezért lesz két MediaStream 'a - egy nekünk és egy az asztalnak. Az első video- és hangadatokat is tartalmaz, a második pedig csak videót (4. ábra).

4. ábra: Két különböző médiafolyam. Egyet nekünk, egyet az asztalunknak

Azonnal világos, hogy a médiafolyamnak tartalmaznia kell legalább az adattartalmat különböző típusok- videó és hang. Ezt figyelembe veszi a technológia, ezért minden adattípus a MediaTrack médiasávon keresztül valósul meg. A médiasávnak van egy speciális tulajdonsága, amely meghatározza, hogy van-e előttünk videó vagy hang (5. ábra)

5. ábra: A médiafolyamok médiasávokból állnak

Hogyan zajlik majd minden a programban? Két médiafolyamot fogunk létrehozni. Ezután létrehozunk két videosávot és egy hangsávot. Hozzáférjünk a kamerákhoz és a mikrofonhoz. Mondjuk el minden sávnak, hogy melyik eszközt használja. Adjunk hozzá egy videó- ​​és hangsávot az első médiafolyamhoz, és egy videosávot egy másik kamerától a második médiafolyamhoz.

De hogyan különböztetjük meg a médiafolyamokat a kapcsolat másik végén? Ehhez minden médiafolyamnak van egy címke tulajdonsága - az adatfolyam címkéje, neve (6. ábra). A médiasávok ugyanazzal a tulajdonsággal rendelkeznek. Bár első pillantásra úgy tűnik, hogy a videót más módon is meg lehet különböztetni a hangtól.

6. ábra: A médiafolyamokat és -sávokat címkék azonosítják

Tehát, és ha a médiasávok azonosíthatók egy címkén keresztül, akkor miért kell két médiafolyamot használnunk a példánkban egy helyett? Végül is átvihet egy médiafolyamot, és különböző sávokat használhat benne. elértük fontos tulajdon médiafolyamok – ők szinkronizálni médiasávok. A különböző médiafolyamok nincsenek szinkronizálva egymással, hanem az egyes médiafolyamokon belül az összes sáv egyszerre játszott.

Így ha azt akarjuk, hogy szavaink, érzelmeink az arcon és a papírdarabunk egyszerre szólaljanak meg, akkor érdemes egy médiafolyamot használni. Ha ez nem annyira fontos, akkor jövedelmezőbb a különböző folyamok használata - a kép simább lesz.

Ha valamelyik műsorszámot le kell tiltani az átvitel során, akkor használhatja a médiasáv engedélyezett tulajdonságát.

A végén érdemes a sztereó hangzásra gondolni. Mint tudod, a sztereó hang két különböző hangzás. És külön is kell őket küldeni. Ehhez a MediaChannels-t használják. Egy audio médiasávnak sok csatornája lehet (például 6, ha 5+1 hangra van szüksége). A médiapályán belül természetesen a csatornákon is szinkronizálva. Videóhoz általában csak egy csatornát használnak, de több is használható például hirdetési fedvényekhez.

Összefoglalni: médiafolyamot használunk video- és hangadatok továbbítására. Az egyes médiafolyamokon belül az adatok szinkronizálva vannak. Több médiafolyamot is használhatunk, ha nincs szükségünk szinkronizálásra. Minden médiafolyamon belül kétféle médiasáv található – videóhoz és hanghoz. Általában nem több, mint két szám, de több is lehet, ha több különböző videót kell átvinnie (a beszélgetőpartnerről és az asztaláról). Minden sáv több csatornából állhat, amelyeket általában csak sztereó hangzásra használnak.

A legegyszerűbb videocsevegési helyzetben egy helyi médiafolyamunk lesz, amely két sávból áll - egy videosávból és egy hangsávból, amelyek mindegyike egy fő csatornából áll. A videosáv a kameráért, a hangsáv a mikrofonért, a médiafolyam pedig mindkettő tárolója.

Munkamenet-leíró (SDP)

Nál nél különböző számítógépek mindig lesznek különböző kamerák, mikrofonok, videokártyák és egyéb felszerelések. Sok lehetőségük van. Mindezt össze kell hangolni két hálózati csomópont közötti médiaadatátvitelhez. A WebRTC ezt automatikusan megteszi, és létrehoz egy speciális objektumot - az SDP-munkamenet leíróját. Adja át ezt az objektumot egy másik csomópontnak, és küldhet médiaadatokat. Csak egy másik csomóponttal még nincs kapcsolat.

Ehhez bármilyen jelzőmechanizmust használnak. Az SDP-t akár socketeken keresztül is továbbíthatja, akár ember (telefonon mondd el egy másik csomópontnak), akár az Orosz Posta is. Minden nagyon egyszerű - kap egy kész SDP-t, és el kell küldenie. A másik oldalon lévő kézhezvétel után pedig vigye át a WebRTC osztálynak. A munkamenet leírója szövegként van tárolva, és módosíthatja az alkalmazásokban, de általában nincs rá szükség. Például az asztali↔telefon csatlakoztatásakor néha kényszerítenie kell a kívánt audiokodek kiválasztását.

Általában a kapcsolat létesítésekor meg kell adni valamilyen címet, például egy URL-t. Itt erre nincs szükség, hiszen Ön a jelzőmechanizmuson keresztül küldi el az adatokat a célállomásra. Ahhoz, hogy közöljük a WebRTC-vel, hogy p2p kapcsolatot szeretnénk létesíteni, meg kell hívnunk a createOffer függvényt. A függvény meghívása és egy speciális visszahívás 'a megadása után létrejön egy SDP-objektum, amelyet ugyanannak a visszahívásnak adunk át. Mindössze annyit kell tennie, hogy ezt az objektumot a hálózaton keresztül egy másik csomóponthoz (beszélgetőpartnerhez) vigye át. Ezt követően a másik végén az adatok a jelzőmechanizmuson keresztül érkeznek, mégpedig ezen az SDP objektumon. Ennek a csomópontnak ez a munkamenetleírója idegen, ezért hordoz hasznos információ. Ennek az objektumnak a fogadása a kapcsolat indításának jele. Ezért el kell fogadnia ezt, és meg kell hívnia a createAnswer függvényt. Ez a createOffer teljes analógja. Ismét egy helyi munkamenet-leíró lesz átadva a visszahívásnak, és vissza kell jelezni.

Érdemes megjegyezni, hogy a createAnswer függvény csak akkor hívható meg, ha valaki más SDP objektumát megkapta. Miért? Mivel a createAnswer meghívásakor előállított helyi SDP-objektumnak a távoli SDP-objektumra kell támaszkodnia. Csak ebben az esetben lehetséges a videóbeállítások összehangolása a beszélgetőpartner beállításaival. Ezenkívül ne hívja meg a createAnswer és a createOffer parancsot a helyi médiafolyam beszerzése előtt – nem lesz mit írniuk az SDP-objektumnak.

Mivel a WebRTC képes szerkeszteni egy SDP-objektumot, a helyi leíró kézhezvétele után telepíteni kell. Kicsit furcsának tűnhet, hogy a WebRTC-nek azt kell továbbítania, amit maga adott nekünk, de ez a protokoll. Amikor kap egy távirányítót, azt is be kell állítania. Ezért két leírót kell telepítenie egy csomópontra - a saját és valaki másé (azaz helyi és távoli).

Ilyenek után kézfogások a csomópontok tudnak egymás kívánságairól. Például, ha az 1. csomópont támogatja az A és B kodeket, a 2. csomópont pedig a B és C kodeket, akkor mivel mindegyik csomópont ismeri a saját és a másik leíróját, mindkét csomópont a B kodeket választja (7. ábra). A kapcsolódási logika most már létrejött, és a médiafolyamok továbbíthatók, de van egy másik probléma - a csomópontok továbbra is csak jelzőmechanizmussal vannak összekötve.

7. ábra: Codec egyeztetés

Jelöltek (Jég jelölt)

A WebRTC technológia megpróbál minket összezavarni új módszertanával. A kapcsolat létrehozásakor nincs megadva annak a csomópontnak a címe, amelyhez csatlakozni kíván. Először telepítve logikus kapcsolat, nem fizikai, bár mindig ennek az ellenkezője történt. De ez nem tűnik furcsának, ha nem felejtjük el, hogy harmadik féltől származó jelzőmechanizmust használunk.

Tehát a kapcsolat már létrejött (logikai kapcsolat), de még nincs mód a hálózati csomópontok adatátvitelére. Ez nem ilyen egyszerű, de kezdjük egyszerűen. Legyenek a csomópontok ugyanabban a magánhálózatban. Amint azt már tudjuk, könnyen csatlakozhatnak egymáshoz belső IP-címeik használatával (vagy esetleg másokkal, ha nem TCP/IP-t használnak).

Néhány visszahíváson keresztül és a WebRTC megmondja nekünk az Ice jelölt objektumokat. Szöveges formában is jönnek, és csakúgy, mint a munkamenet-leírókat, csak a jelzőmechanizmuson keresztül kell elküldeni őket. Ha a munkamenetleíró kamera és mikrofon szintű beállításainkról tartalmazott információkat, akkor a jelöltek a hálózaton belüli elhelyezkedésünkről tartalmaznak információkat. Adja át őket egy másik csomópontnak, és ő fizikailag tud csatlakozni hozzánk, és mivel már rendelkezik munkamenet-leíróval, logikusan tud csatlakozni, és az adatok „folyni fognak”. Ha nem felejti el elküldeni nekünk a jelölt objektumát, vagyis információt arról, hogy hol van a hálózaton, akkor tudunk vele kapcsolatba lépni. Megjegyezzük itt még egy különbséget a klasszikus kliens-szerver interakcióhoz képest. Kommunikáció a HTTP szerver kérés-válasz séma szerint történik, a kliens adatokat küld a szervernek, amely feldolgozza és elküldi a kéréscsomagban megadott cím. A WebRTC-ben tudnia kell két címetés kösse össze őket mindkét oldalon.

A különbség a munkamenet-leíróktól az, hogy csak távoli jelölteket kell beállítani. A szerkesztés itt tilos, és nem hozhat semmilyen hasznot. Egyes WebRTC-megvalósításokban a jelölteket csak a munkamenet-leírók beállítása után kell beállítani.

És miért csak egy ülésleíró volt, de sok jelölt lehet? Ugyanis a hálózaton belüli elhelyezkedés nemcsak a belső IP-címe alapján határozható meg, hanem a router külső címe alapján is, és nem feltétlenül egy, valamint a TURN szerverek címei alapján. A bekezdés további részét a jelöltek és a különböző magánhálózatokból származó csomópontok összekapcsolásának részletes megvitatásának szenteljük.

Tehát két csomópont ugyanabban a hálózatban van (8. ábra). Hogyan lehet azonosítani őket? IP-címek használata. Nincs más mód. Igaz, továbbra is különböző szállításokat (TCP és UDP) és különböző portokat használhat. Ez az információ, amelyet a jelölt objektum tartalmaz - IP , PORT , TRANSPORT és néhány más. Használjuk például az UDP szállítást és az 531-es portot.

8. ábra: Két csomópont van ugyanazon a hálózaton

Ekkor, ha a p1 csomóponton vagyunk, akkor a WebRTC átad nekünk egy ilyen jelölt objektumot - . Ez nem pontos formátum, csak egy diagram. Ha a p2 csomóponton vagyunk, akkor a jelölt - . A jelzőmechanizmuson keresztül p1 megkapja a p2 jelöltet (vagyis a p2 csomópont helyét, nevezetesen annak IP-jét és PORT-ját). Ezután a p1 közvetlenül csatlakozhat a p2-höz. Helyesebben, a p1 adatokat küld a 10.50.150.3:531 címre, abban a reményben, hogy eléri a p2-t. Nem számít, hogy ez a cím a p2 csomóponthoz vagy valamilyen közvetítőhöz tartozik. Az egyetlen fontos dolog az, hogy az adatok ezen a címen keresztül kerülnek elküldésre, és elérhetik a p2-t.

Mindaddig, amíg a csomópontok ugyanabban a hálózatban vannak - minden egyszerű és könnyű - minden csomópontnak csak egy jelölt objektuma van (mindig a sajátját, vagyis a hálózatban elfoglalt helyét). De sokkal több jelölt lesz, amikor a csomópontok beépülnek különböző hálózatok.

Térjünk át egy bonyolultabb esetre. Az egyik csomópont az útválasztó mögött lesz (pontosabban a NAT mögött), a második pedig ugyanabban a hálózatban lesz ezzel az útválasztóval (például az interneten) (9. ábra).

9. ábra: Egy gazdagép a NAT mögött, egy másik nem

Ez az eset sajátos megoldást kínál a problémára, amelyet most megvizsgálunk. Az otthoni útválasztó általában tartalmaz egy NAT táblát. Ez egy speciális mechanizmus, amely lehetővé teszi, hogy az útválasztó magánhálózatán belüli csomópontok hozzáférjenek például webhelyekhez.

Tegyük fel, hogy a webszerver közvetlenül kapcsolódik az internethez, azaz nyilvános IP * címmel rendelkezik. Legyen ez a p2 csomópont. A p1 csomópont (webkliens) kérést küld a 10.50.200.10 címre. Először is, az adatok az r1 útválasztóhoz, vagy inkább hozzá jutnak belső interfész 192.168.0.1 . Ezt követően a router megjegyzi a forráscímet (p1 cím), és beírja egy speciális NAT táblába, majd megváltoztatja a forráscímet a sajátjára (p1 → r1). Továbbá szerint külső interfészen keresztül a router közvetlenül a p2 webszervernek küldi az adatokat. A webszerver feldolgozza az adatokat, választ generál, majd visszaküldi. R1-et küld az útválasztónak, mivel ő van a visszatérési címben (a router megváltoztatta a címet a sajátjára). Az útválasztó fogadja az adatokat, megnézi a NAT táblát, és továbbítja az adatokat a p1-nek. A router itt közvetítőként működik.

De mi van akkor, ha a belső hálózatból egyszerre több csomópont is hozzáfér a külső hálózathoz? Hogyan fogja megérteni a router, hogy kinek küldje vissza a választ? Ez a probléma megoldva a portok. Amikor az útválasztó lecseréli a gazdagép címét a sajátjára, a portot is lecseréli. Ha két csomópont hozzáfér az Internethez, akkor az útválasztó lecseréli a forrásportjaikat a következőre különböző. Ezután, amikor a webszervertől érkező csomag visszajön az útválasztóhoz, az útválasztó megérti azt a portot, amelyhez ez a csomag hozzá van rendelve. Egy példa alább látható.

Térjünk vissza a WebRTC technológiához, vagy inkább annak ICE protokollt használó részéhez (ezért az Ice jelöltek). A p2 csomópontnak egy jelöltje van (helye a hálózaton: 10.50.200.10 ), és a p1 csomópontnak, amely egy NAT útválasztó mögött van, két jelölt lesz - egy helyi (192.168.0.200 ) és egy útválasztó jelölt (10.50.200.5 ). . Az első nem hasznos, de mégis létrejön, mivel a WebRTC még nem tud semmit a távoli gazdagépről - lehet, hogy ugyanazon a hálózaton van, de lehet, hogy nem. A második jelölt jól fog jönni, és mint már tudjuk, a portnak fontos szerepe lesz (a NAT-on való átjutáshoz).

A NAT táblában csak akkor jön létre bejegyzés, ha az adatok kilépnek a belső hálózatból. Ezért a p1 csomópontnak kell először adatot továbbítania, és csak ezután érheti el a p2 csomópont adatai a p1 csomópontot.

A gyakorlatról mindkét csomópont NAT mögött lesz. Az egyes útválasztók NAT-táblájában bejegyzés létrehozásához a gazdagépeknek küldeniük kell valamit a távoli gazdagépnek, de ezúttal sem az előbbi nem tudja elérni az utóbbit, sem fordítva. Ennek az az oka, hogy a csomópontok nem ismerik a külső IP-címeiket, és értelmetlen az adatokat belső címekre küldeni.

Ha azonban a külső címek ismertek, akkor a kapcsolat könnyen létrejön. Ha az első csomópont adatokat küld a második csomópont útválasztójának, akkor a router figyelmen kívül hagyja azokat, mivel a NAT táblája még üres. Az első csomópont útválasztójában azonban megjelent egy bejegyzés a NAT táblában. Ha most a második csomópont adatokat küld az első csomópont útválasztójának, akkor a router sikeresen továbbítja azokat az első csomópontnak. Most a második útválasztó NAT táblája rendelkezik a szükséges adatokkal.

A probléma az, hogy ahhoz, hogy megtudja a külső IP-címét, egy állomáson kell lennie közös hálózat. A probléma megoldására további szervereket használnak, amelyek közvetlenül csatlakoznak az internethez. Segítségükkel létrejönnek a NAT tábla kincses bejegyzései is.

STUN és TURN szerverek

A WebRTC inicializálása során meg kell adni az elérhető STUN és TURN szervereket, amelyeket a jövőben ICE szervereknek nevezünk. Ha a kiszolgálók nincsenek megadva, akkor csak ugyanazon a hálózaton (a NAT nélkül csatlakozva) lévő csomópontok tudnak csatlakozni. Rögtön meg kell jegyezni, hogy a 3g hálózatoknál a TURN szerverek használata kötelező.

KÁBÍTÁS szerver csak egy szerver az interneten, amely visszatér visszaszállítási cím, amely a küldő gazdagép címe. Az útválasztó mögötti gazdagép felveszi a kapcsolatot a STUN szerverrel, hogy átmenjen a NAT-on. A STUN szerverhez érkezett csomag tartalmazza a forráscímet - az útválasztó címét, vagyis a csomópontunk külső címét. A STUN szerver visszaküldi ezt a címet. Így a csomópont megkapja a külső IP-címét és azt a portot, amelyen keresztül elérhető a hálózatról. Ezután a WebRTC ezt a címet használja egy további jelölt létrehozásához (az útválasztó külső címe és portja). Most az útválasztó NAT táblájában van egy bejegyzés, amely a routernek a kívánt porton küldött csomagokat továbbítja a gazdagépünknek.

Nézzük meg ezt a folyamatot egy példán keresztül.

Példa (STUN szerver működése)

A STUN szervert s1 jelöli. A router, mint korábban, az r1 -en keresztül, a csomópont pedig a p1 -en keresztül. Szükség lesz a NAT tábla figyelésére is - r1_nat-ként fogjuk jelölni. Ezenkívül ez a táblázat általában sok bejegyzést tartalmaz különböző alhálózati csomópontokból – ezeket nem adjuk meg.

Tehát az elején van egy üres r1_nat tábla.

2. táblázat: Csomag fejléc

A p1 csomópont elküldi ezt a csomagot az r1 útválasztónak (nem számít, hogyan, a különböző alhálózatokban különböző technológiák használhatók). A routernek meg kell változtatnia az Src IP forráscímet, mivel a csomagban megadott cím nyilvánvalóan nem alkalmas a külső alhálózatra, ráadásul az ebből a tartományból származó címek le vannak foglalva, és az interneten egyetlen címnek sincs ilyen címe. Az útválasztó helyettesíti a csomagot, és létrehozza új rekord a táblázatodban r1_nat . Ehhez ki kell találnia egy portszámot. Ne feledje, hogy mivel egy alhálózaton belül több gazdagép is elérheti a külső hálózatot, a NAT táblát tárolni kell további információígy az útválasztó meg tudja határozni, hogy a kiszolgálótól érkező visszatérő csomag melyik állomás közül melyikre szánja. Hagyja, hogy az útválasztó találja meg a 888-as portot.

Módosított csomag fejléc:

4. táblázat: A NAT-tábla új bejegyzéssel frissítve

Itt az alhálózat IP-címe és portja pontosan megegyezik az eredeti csomagéval. Valójában a visszaküldéskor módunkban áll teljesen visszaállítani őket. A külső hálózat IP-címe a router címe, a port pedig a router által kitaláltra változott.

A valódi port, amelyen a p1 fogadja a kapcsolatot természetesen a 35777, de a szerver adatokat küld kitalált a 888-as portot, amelyet az útválasztó a valódi 35777-re cserél.

Tehát az útválasztó megváltoztatta a forráscímet és a portot a csomag fejlécében, és hozzáadott egy bejegyzést a NAT táblához. Most a csomag elküldésre kerül a hálózaton keresztül a szerverhez, azaz az s1 csomóponthoz. A bemeneten az s1 a következő csomaggal rendelkezik:

Src IP Src PORT Cél IP Cél PORT

10.50.200.5	888	12.62.100.200	6000

5. táblázat: A STUN szerver csomagot kapott

Összességében a STUN szerver tudja, hogy a 10.50.200.5:888 címről kapott egy csomagot. Most a szerver visszaküldi ezt a címet. Itt érdemes megállni, és újra átgondolni, amit az imént gondoltunk. A fenti táblázatok részét képezik fejléc csomagot, egyáltalán nem belőle tartalom. A tartalomról nem beszéltünk, mivel nem annyira fontos – valahogy le van írva a STUN protokollban. Most a címen kívül a tartalmat is figyelembe vesszük. Egyszerű lesz, és tartalmazza az útválasztó címét - 10.50.200.5:888, bár mi innen vettük fejléc csomag. Ezt nem szokták megtenni, általában a protokollok nem törődnek a csomópontok címére vonatkozó információkkal, csak az a fontos, hogy a csomagok célba kerüljenek. Itt egy olyan protokollt tekintünk, amely útvonalat hoz létre két csomópont között.

Tehát most van egy második tétel, ami az ellenkező irányba megy:

7. táblázat: A STUN szerver ilyen tartalmú csomagot küld

Ezután a csomag áthalad a hálózaton, amíg el nem éri az r1 útválasztó külső interfészét. Az útválasztó megérti, hogy a csomag nem neki való. Ő hogy érti? Ezt csak a kikötő találja meg. A 888-as portot nem személyes célokra használja, hanem a NAT-mechanizmushoz használja. Ezért a router belenéz ebbe a táblázatba. Megnézi a Külső PORT oszlopot, és keres egy sort, amely megegyezik a bejövő csomagból származó célporttal, azaz a 888-assal.

Belső IP Belső PORT Külső IP Külső PORT

192.168.0.200	35777	10.50.200.5	888

8. táblázat: NAT táblázat

Szerencsések vagyunk, hogy létezik ilyen vonal. Ha nem lenne szerencsés, akkor a csomagot egyszerűen eldobnák. Most meg kell értenie, hogy az alhálózati csomópontok közül melyik küldje el ezt a csomagot. Ne kapkodjunk, foglaljuk össze a portok fontosságát ebben a mechanizmusban. Ugyanakkor az alhálózat két csomópontja kéréseket küldhet a külső hálózatnak. Aztán, ha az első csomópontnál a router a 888-as porttal állt elő, akkor a másodiknál ​​a 889-es porttal. Tegyük fel, hogy ez történt, vagyis az r1_nat tábla így néz ki:

10. táblázat: A router hamis vevő címe

Src IP Src PORT Cél IP Cél PORT

12.62.100.200	6000	192.168.0.200	35777

11. táblázat: Az útválasztó megváltoztatta a vevő címét

A csomag sikeresen megérkezik a p1 csomóponthoz, és a csomag tartalmának megtekintése után a csomópont tudomást szerez a külső IP-címéről, vagyis a külső hálózatban lévő router címéről. Ismeri azt a portot is, amelyen a router átmegy a NAT-on.

Mi a következő lépés? Mi haszna ennek az egésznek? Az előny egy bejegyzés az r1_nat táblában. Ha most valaki csomagot küld a 888-as porttal rendelkező r1 útválasztónak, akkor a router továbbítja ezt a csomagot a p1 csomópontnak. Így egy kis keskeny átjáró jött létre a rejtett p1 csomóponthoz.

A fenti példából képet kaphat a NAT működéséről és a STUN szerver lényegéről. Általában az ICE mechanizmus és a szerver STUN / TURN funkciója csak a NAT korlátainak leküzdésére irányul.

A csomópont és a szerver között több útválasztó is lehet, de több is. Ebben az esetben a csomópont megkapja annak az útválasztónak a címét, amelyik elsőként lép be ugyanabba a hálózatba, mint a szerver. Más szóval, megkapjuk a STUN szerverhez csatlakoztatott útválasztó címét. A p2p kommunikációhoz pont erre van szükségünk, ha nem feledkezünk meg arról a tényről, hogy minden routerben az a vonal, amelyre szükségünk van, bekerül a NAT táblába. Így a visszaút ismét ugyanolyan sima lesz.

A TURN szerver egy továbbfejlesztett STUN szerver. Innen azonnal ki kell bontani, hogy bármelyik TURN szerver STUN szerverként is működhet. Vannak azonban előnyei is. Ha a p2p kommunikáció nem lehetséges (mint például a 3g hálózatokban), akkor a szerver közvetítő módba (relay) kapcsol, azaz közvetítőként működik. Természetesen akkor nem p2p-ről beszélünk, de az ICE mechanizmuson kívül a csomópontok azt hiszik, hogy közvetlenül kommunikálnak.

Mikor van szükség TURN szerverre? Miért hiányzik a STUN szerver? A tény az, hogy a NAT-nak több fajtája létezik. Ugyanúgy cserélik ki az IP-címet és a portot, azonban némelyikük beépített kiegészítő védelem"hamisítástól". Például be szimmetrikus A NAT táblában további 2 paraméter tárolódik - a távoli gazdagép IP és portja. A külső hálózatról érkező csomag csak akkor jut el a NAT-on keresztül a belső hálózatba, ha a forráscím és a port megegyezik a táblázatban rögzítettekkel. Ezért a STUN szerverrel végzett trükk meghiúsul - a NAT tábla tárolja a STUN szerver címét és portját, és amikor az útválasztó csomagot kap a WebRTC beszélgetőpartnertől, eldobja, mivel „hamisított”. Nem STUN szerverről jött.

Így egy TURN szerverre akkor van szükség, ha mindkét beszélgetőpartner mögötte van szimmetrikus NAT (mindegyik a sajátját).

Rövid összefoglaló

Íme néhány kijelentés a WebRTC entitásokról, amelyeket mindig szem előtt kell tartania. Ezeket fentebb részletesen ismertetjük. Ha valamelyik állítás nem tűnik teljesen egyértelműnek, olvassa el újra a vonatkozó bekezdéseket.

• médiafolyam
  • A video- és hangadatok médiafolyamokba vannak csomagolva
  • A médiafolyamok szinkronizálják az alkotó médiasávokat
  • A különböző médiafolyamok nincsenek szinkronban
  • A médiafolyamok lehetnek helyiek és távoliak, a lokálishoz általában kamera és mikrofon csatlakozik, a távoliak titkosított formában fogadják az adatokat a hálózatról
  • Kétféle médiasáv létezik – videóhoz és hanghoz.
  • A médiasávok be- és kikapcsolhatók
  • A médiasávok médiacsatornákból állnak
  • A médiasávok szinkronizálják az alkotó médiacsatornákat
  • A médiafolyamokon és médiasávokon címkék vannak, amelyek alapján megkülönböztethetők
• Session fogantyú
  • A munkamenet-leíró két hálózati csomópont logikai összekapcsolására szolgál
  • A munkamenet-leíró információkat tárol arról elérhető módokon videó és audio adatok kódolása
  • A WebRTC külső jelzőmechanizmust használ – a munkamenet-leírók (sdp) továbbítása az alkalmazásra hárul
  • A logikai kapcsolódási mechanizmus két szakaszból áll - egy ajánlatból (ajánlat) és egy válaszból (válasz)
  • A munkamenetleíró létrehozása nem lehetséges helyi médiafolyam használata nélkül ajánlat esetén (ajánlat ), és válasz esetén nem lehetséges távoli munkamenetleíró használata nélkül (válasz )
  • A kapott leírót meg kell adni a WebRTC implementációnak, és nem számít, hogy ez a leíró távolról vagy helyileg érkezik ugyanattól a WebRTC implementációtól
  • A munkamenet-leíró kis mértékben módosítható
• Jelöltek
  • A jelölt (Jégjelölt) a hálózat csomópontjának címe
  • A csomópont címe lehet a saját, vagy egy útválasztó vagy egy TURN szerver címe
  • Mindig sok jelölt van
  • A jelölt IP-címből, portból és szállítási típusból áll (TCP vagy UDP)
  • A jelöltek fizikai kapcsolat létrehozására szolgálnak a hálózat két csomópontja között
  • A jelölteket a jelzőmechanizmuson keresztül is el kell küldeni
  • A pályázóknak át kell adniuk a WebRTC implementációkat is, de csak távolról
  • Egyes WebRTC-megvalósításokban a jelöltek csak a munkamenet-leíró beállítása után adhatók át.
• STUN/TURN/ICE/NAT
  • NAT - egy külső hálózathoz való hozzáférést biztosító mechanizmus
  • Az otthoni útválasztók egy speciális NAT-táblát támogatnak
  • A router lecseréli a csomagokban lévő címeket - a forráscímet a sajátjával, ha a csomag a külső hálózatba kerül, és a vevő címét a belső hálózatban lévő gazdagép címére, ha a csomag külső hálózatról érkezett.
  • A külső hálózatok többcsatornás hozzáférésének biztosításához a NAT portokat használ
  • Az ICE egy NAT bejárási mechanizmus
  • A STUN és TURN szerverek segédkiszolgálók a NAT megkerüléséhez
  • A STUN szerver lehetővé teszi a szükséges bejegyzések létrehozását a NAT táblában, és visszaadja a gazdagép külső címét is
  • A TURN szerver általánosítja a STUN mechanizmust, és mindig működőképessé teszi
  • A legrosszabb esetben a TURN szervert közvetítőként (továbbítóként) használják, vagyis a p2p kliens-szerver-kliens kapcsolattá alakul.

Ennek a cikknek az a célja, hogy megismerkedjen annak felépítésével és működési elvével egy peer-to-peer videocsevegés (p2p videocsevegés) demómintáján. Erre a célra a többfelhasználós peer-to-peer videocsevegés demót használjuk a webrtc.io-demo. Letölthető a következő linkről: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

Meg kell jegyezni, hogy a GitHub egy webprojektek közös fejlesztésére szolgáló webhely vagy webszolgáltatás. Ezen a fejlesztők közzétehetik fejlesztéseik kódjait, megvitathatják azokat és kommunikálhatnak egymással. Ezenkívül néhány nagy IT-cég ezen az oldalon tárolja hivatalos adattárait. A szolgáltatás ingyenes a nyílt forráskódú projektek számára. A GitHub nyílt forráskódú könyvtárak tárháza.

Tehát a GitHubról letöltött egy peer-to-peer videocsevegés demómintáját a C lemezre helyezzük. személyi számítógép a "webrtc_demo" alkalmazásunkhoz létrehozott könyvtárban.

Rizs. 1

Amint a szerkezetből (1. ábra) következik, a peer-to-peer videocsevegés a JavaScript programozási nyelven implementált kliens script.js és szerver server.js szkriptekből áll. Szkript (könyvtár) webrtc.io.js (CLIENT) - biztosítja a böngészők közötti valós idejű kommunikáció megszervezését egy peer-to-peer séma szerint: "kliens-ügyfél", valamint webrtc.io.js (CLIENT) és webrtc .io.js (SERVER), a WebSocket protokoll használatával duplex kommunikációt biztosítanak a böngésző és a webszerver között a "kliens-szerver" architektúra használatával.

A webrtc.io.js (SERVER) parancsfájl a webrtc.io könyvtárban található, és a node_modules\webrtc.io\lib könyvtárban található. Az index.html videocsevegési felület HTML5-ben és CSS3-ban van megvalósítva. A webrtc_demo alkalmazásfájlok tartalma megtekinthető valamelyik html szerkesztővel, például "Notepad++".

Ellenőrizzük a videocsevegés elvét a számítógépes fájlrendszerben. A szerver (server.js) PC-n történő futtatásához telepítenie kell a node.js futási környezetet. A Node.js lehetővé teszi JavaScript kód futtatását a böngészőn kívül. A node.js fájl letölthető a következő linkről: http://nodejs.org/ (verzió 0.10.13, 2013. 07. 15.). Tovább Főoldal node.org webhelyen kattintson a letöltés gombra, és lépjen a http://nodejs.org/download/ oldalra. Mert Windows felhasználók először töltse le a win.installer (.msi) fájlt, majd futtassa a win.installer (.msi) programot a számítógépen, és telepítse a nodejs-t és az „npm csomagkezelőt” a Program Files könyvtárba.

Rizs. 2

Így a node.js egy JavaScript fejlesztői és végrehajtási környezetből, valamint egy sor belső modulból áll, amelyek az npm csomagkezelővel vagy csomagkezelővel telepíthetők.

A modulok telepítéséhez szükséges parancs sor az alkalmazáskönyvtárból (például "webrtc_demo") futtassa a következő parancsot: npm install modul_name . A modulok telepítése során az npm manager létrehoz egy node_modules mappát abban a könyvtárban, ahonnan a telepítés történt. Futás közben a nodejs automatikusan tartalmazza a modulokat a node_modules könyvtárból.

Tehát a node.js telepítése után nyissa meg a parancssort, és frissítse az expressz modult a webrtc_demo könyvtár node_modules mappájában az npm csomagkezelő segítségével:

C:\webrtc_demo>npm install express

Az expressz modul a node.js vagy webalkalmazás-fejlesztő platform webes keretrendszere. Az expressz globális eléréséhez a következőképpen telepítheti: npm install -g express .

Ezután frissítjük a webrtc.io modult:

C:\webrtc_demo>npm telepítse a webrtc.io-t

Ezután a parancssorban elindítjuk a szervert: server.js:

C:\webrtc_demo>nodeserver.js

Rizs. 3

Minden, a szerver sikeresen működik (3. ábra). Most egy webböngészővel kapcsolatba léphet a szerverrel ip-címen, és letöltheti az index.html weboldalt, amelyről a webböngésző kibontja a kliens szkript kódját - script.js és webrtc.io.js szkriptkód, és kivégezni őket. Ahhoz, hogy a peer-to-peer videocsevegés működjön (a kapcsolat létrehozásához két böngésző között), két webrtc-t támogató böngészőnek fel kell vennie a kapcsolatot a node.js-n futó jelkiszolgálóval ip-címen.

Ezzel megnyílik az ügyféloldali felület. kommunikációs alkalmazás(videocsevegés) a kamerához és a mikrofonhoz való hozzáférési engedélykéréssel (4. ábra).

Rizs. 4

Az "Engedélyezés" gombra kattintás után a kamera és a mikrofon csatlakoztatva van a multimédiás kommunikációhoz. Emellett a videocsevegési felületen keresztül szöveges adatokkal is kommunikálhatunk (5. ábra).

Rizs. 5

Meg kell említeni, hogy . A szerver jelzés, és főként arra szolgál, hogy kapcsolatot létesítsen a felhasználók böngészői között. A WebRTC jelzést biztosító server.js szkript Node.js-t használ a futtatáshoz.