Először is meg kell értened, hogy a számítógéped/táblagéped/telefonod összes IP-címének WebRTC-n keresztüli megjelenítése nem probléma vagy a VPN/tor/socks hiányossága, hanem a használt böngésző problémája és hiányossága. .

A WebRTC projektet a Google hozta létre, hogy a streaming adatokat (hang és videó) főként közvetlenül a felhasználók böngészői között (p2p kapcsolatok), részvétel nélkül továbbítsa. harmadik féltől származó programok(pl. Skype) vagy bővítmények. Ez nem csupán a WebRTC-kompatibilis böngésző hozzáférését jelenti a hálózati környezethez (függetlenül a használt operációs rendszertől), hanem a nyilvános és helyi IP-cím meghatározásának képességét is a STUN protokoll segítségével, hogy minden típusú NAT-ot megkerülő p2p-kapcsolatot hozzon létre.

A Ebben a pillanatban Ismeretes, hogy a WebRTC alapértelmezés szerint engedélyezve van a Chrome (23-as verziótól), a Firefox (22-es verziótól) és az Opera (18-as verziótól) böngészőkben, ami általában érvényteleníti az összes anonimizálási módszert ezen böngészők felhasználói számára. Annak érdekében, hogy lehetetlenné tegye nyilvános és helyi IP-címének WebRTC-n keresztüli meghatározását, furcsa módon le kell tiltania a támogatást.

A WebRTC letiltása Firefoxban:

• NÁL NÉL címsorírja be az about:config parancsot, és nyomja meg az Enter billentyűt
• A Keresés sorba írja be a "media.peerconnection.enabled" kifejezést, és kattintson duplán a talált sorra, ezzel állítsa az Érték mezőt "false"-ra.

A WebRTC letiltása Chrome-ban és Operában:

• Jelenleg nem ismert mód a WebRTC letiltására maguk a böngészők használatával, és nem tudunk alternatív megoldásokat ajánlani bővítmények formájában (saját kockázatra és kockázatra keresse és telepítse őket), mivel hatékonyságuk sok kívánnivalót hagy maga után. . Ezért nyilvánvalóan csak azt tanácsolni kell, hogy ne használja ezeket a böngészőket, amíg a fejlesztők nem hajtják végre maguknak a böngészőknek a letiltásának lehetőségét (hasonlóan a Firefoxhoz).

A WebRTC letiltása Androidon a Chrome-ban:

• NÁL NÉL legújabb verziói Chrome böngésző Android esetén nem lehet letiltani a WebRTC-t, bár a beállításokban van ilyen lehetőség.
• Ha olyan böngészőt kell használnia, amelyben a WebRTC le van tiltva Androidon, javasoljuk, hogy használja Firefox Androidra. Ezen letilthatja a WebRTC-t ugyanazt a Firefoxhoz tartozó utasítást követve, amely fent található.

A böngészőből történő hívástechnológiák sok éve léteznek: Java, ActiveX, Adobe Flash... Az elmúlt néhány évben világossá vált, hogy a bővítmények és a bal oldalon virtuális gépek nem tündökölnek a kényelemtől (miért telepítsek egyáltalán semmit?), és ami a legfontosabb, a biztonságtól. Mit kell tenni? Van kijárat!

Egészen a közelmúltig számos protokollt használtak az IP-hálózatokon IP-telefonáláshoz vagy -videóhoz: a SIP, a legáltalánosabb protokoll, a H.323 és az MGCP, a Jabber/Jingle (a Gtalk-ban használatos), a félig nyitott Adobe RTMP* és persze a bezárt Skype. A Google által kezdeményezett WebRTC projekt úgy próbálja megfordítani az IP és webes telefonálás világát, hogy minden softphone-t, így a Skype-ot is elavulttá teszi. A WebRTC nemcsak mindent megvalósít kommunikációs képességek közvetlenül a böngészőn belül, amely ma már szinte minden eszközre telepítve van, ugyanakkor megpróbálja megoldani a böngészőhasználók közötti kommunikáció általánosabb feladatát (különböző adatok cseréje, képernyő casting, együttműködés a dokumentumokkal és még sok más).

WebRTC egy webfejlesztőtől

A webfejlesztők szempontjából a WebRTC két fő részből áll:

• a helyi forrásokból (kamera, mikrofon vagy képernyő) érkező médiafolyamok vezérlése helyi számítógép) a navigator.getUserMedia metódus valósítja meg, amely egy MediaStream objektumot ad vissza;
• peer-to-peer kommunikáció az eszközök között, amelyek médiafolyamokat generálnak, beleértve a kommunikációs módszerek meghatározását és azok közvetlen továbbítását - RTCPeerConnection objektumok (hang- és videofolyamok küldésére és fogadására) és RTCDataChannel (adatok küldésére és fogadására a böngészőből).

Mit csináljunk?

Meg fogjuk találni, hogyan szervezzük meg a legegyszerűbb többjátékos videocsevegést a böngészők között WebRTC alapján web socket használatával. Kezdjük a kísérletezést a Chrome / Chromiumban, mivel a legfejlettebb WebRTC böngészők, bár a június 24-én megjelent Firefox 22 majdnem utolérte őket. El kell mondanunk, hogy a szabványt még nem fogadták el, és az API verzióról verzióra változhat. Az összes példát Chromium 28-ban teszteltük. Az egyszerűség kedvéért nem fogjuk ellenőrizni a kód tisztaságát és a böngészők közötti kompatibilitást.

médiafolyam

Az első és legegyszerűbb WebRTC összetevő a MediaStream. A böngésző számára hozzáférést biztosít a helyi számítógép kamerájából és mikrofonjából származó médiafolyamokhoz. Chrome-ban ehhez meg kell hívni a navigator.webkitGetUserMedia() függvényt (mivel a szabvány még nincs véglegesítve, minden függvényhez előtag tartozik, Firefoxban pedig ugyanez a függvény neve navigator.mozGetUserMedia()). Amikor hívják, a felhasználó felkéri, hogy engedélyezze a hozzáférést a kamerához és a mikrofonhoz. A hívás folytatására csak a felhasználó hozzájárulása után van lehetőség. A kívánt médiafolyam és két visszahívási funkció paraméterei adódnak át ehhez a funkcióhoz: az elsőt a kamera/mikrofon sikeres elérése esetén hívja meg, a másodikat pedig hiba esetén. Először hozzunk létre egy rtctest1.html HTML fájlt egy gombbal és egy elemmel

getUserMedia

Microsoft CU-RTC-Web

A Microsoft nem lenne Microsoft, ha a Google kezdeményezésére válaszul nem adná ki azonnal saját, inkompatibilis egyéni változatát, a CU-RTC-Web nevet (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Bár az amúgy is csekély IE részesedése tovább csökken, a Skype-felhasználók száma reményt ad a Microsoftnak a Google nyomására, és feltételezhető, hogy a böngészőben ezt a szabványt fogják használni. Skype verziók. A Google szabvány elsősorban a böngészők közötti kommunikációra összpontosít; ugyanakkor a beszédforgalom nagy része továbbra is a hagyományos telefonhálózatban marad, és a közte és az IP-hálózatok közötti átjárókra nemcsak a könnyebb használat vagy a gyorsabb elosztás miatt van szükség, hanem a bevételszerzés eszközeként is, amely lehetővé teszi. több játékosok fejleszteni őket. Egy másik szabvány megjelenése nemcsak azt eredményezheti, hogy a fejlesztők kellemetlen igényt támasztanak, hogy egyszerre két inkompatibilis technológiát támogassanak, hanem a jövőben is szélesebb körű választási lehetőséget biztosít a felhasználó számára a lehetséges funkciók és elérhetőségek között. műszaki megoldások. Várj és láss.

Helyi szál engedélyezése

Belső címkék HTML-fájlunkban deklaráljunk egy globális változót a médiafolyam számára:

VarlocalStream = null;

A getUserMedia metódus első paramétere a kért médiafolyam paramétereinek megadása – például egyszerűen engedélyezze a hangot vagy a videót:

Var streamConstraints = ( "audio": igaz, "videó": igaz ); // Hozzáférés kérése hanghoz és videóhoz egyaránt

Vagy adjon meg további paramétereket:

Var streamConstraints = ( "audio": igaz, "videó": ( "kötelező": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5" ), "opcionális": ) );

A getUserMedia metódus második paramétere egy visszahívási függvény átadása, amely sikeresen meghívásra kerül:

Függvény getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Médiafolyam csatolása HTML elemhez

A harmadik paraméter egy visszahívási függvény, egy hibakezelő, amelyet hiba esetén hívunk meg.

Függvény getUserMedia_error(error) ( console.log("getUserMedia_error():", hiba); )

A getUserMedia metódus tényleges hívása – hozzáférés kérése a mikrofonhoz és a kamerához az első gomb megnyomásakor

Függvény getUserMedia_click() ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )

A helyileg megnyitott fájlból nem lehet elérni a médiafolyamot. Ha ezt próbáljuk megtenni, hibaüzenetet kapunk:

NavigatorUserMediaError (kód: 1, PERMISSION_DENIED: 1)"

Az így kapott fájlt töltsük fel a szerverre, nyissuk meg a böngészőben, és a megjelenő kérésre engedélyezzük a kamerához és a mikrofonhoz való hozzáférést.

Kiválaszthatja, hogy a Chrome mely eszközöket érje el a Beállítások, a Speciális beállítások link megjelenítése, az Adatvédelem részben és a Tartalom gombban. Firefox és Opera böngészőkben az eszközök közvetlenül a legördülő listából kerülnek kiválasztásra a hozzáférés megadásakor.

HTTP protokoll használata esetén a rendszer minden alkalommal engedélyt kér, amikor az oldal betöltése után egy médiafolyamhoz hozzáférnek. A HTTPS-re váltás lehetővé teszi a kérés egyszeri megjelenítését, csak a médiafolyamhoz való legelső hozzáféréskor.

Ügyeljen a lapon lévő ikonban pulzáló körre és a címsáv jobb oldalán lévő kamera ikonra:

RTCMediaConnection

RTCMediaConnection - egy objektum, amely médiafolyamok létrehozására és átvitelére szolgál a hálózaton keresztül a résztvevők között. Ezen túlmenően ez az objektum felelős a médiamunkamenet-leírás (SDP) létrehozásáért, a NAT-on vagy a tűzfalakon (helyi és STUN-t használó) való áthaladáshoz szükséges információk beszerzéséért, valamint a TURN szerverrel való interakcióért. Minden résztvevőnek kapcsolatonként egy RTCMediaConnection-nel kell rendelkeznie. A médiafolyamok továbbítása titkosított SRTP protokollon keresztül történik.

TURN szerverek

Háromféle ICE jelölt létezik: host, srflx és relay. A gazdagép helyileg szerzett információkat tartalmaz, az srflx azt jelenti, hogy a gazdagép hogyan néz ki egy külső kiszolgáló számára (STUN), a relay pedig a TURN szerveren keresztüli proxy forgalomra vonatkozó információ. Ha a csomópontunk NAT mögött van, akkor a host jelöltek helyi címeket tartalmaznak, és használhatatlanok, az srflx jelöltek csak bizonyos típusú NAT-ok esetén segítenek, és a továbbítás az utolsó remény, hogy a forgalmat egy köztes szerveren továbbítsák.

Példa egy host típusú ICE jelöltre 192.168.1.37 címmel és udp/34022 porttal:

A=jelölt:337499441 2 udp 2113937151 192.168.1.37 34022 typ host generáció 0

Általános formátum a STUN/TURN szerverek meghatározásához:

Var servers = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn: [e-mail védett]:port", "credential": "jelszó" ) ]);

Az interneten számos nyilvános STUN szerver található. Egy nagy lista például a . Sajnos túl kevés problémát oldanak meg. A STUN-nal ellentétben gyakorlatilag nincs nyilvános TURN szerver. Ez annak a ténynek köszönhető, hogy a TURN szerver átengedi magán a médiafolyamokat, ami jelentősen terhelheti mind a hálózati csatornát, mind magát a szervert. Ezért a TURN szerverekhez való csatlakozás legegyszerűbb módja, ha saját kezűleg telepíted (nyilván nyilvános IP-címre lesz szükséged). Véleményem szerint az összes szerver közül a legjobb az rfc5766-turn-server. Alatta van még kész kép az Amazon EC2 számára.

A TURN-nál nem minden olyan jó, mint szeretnénk, de aktív fejlesztés folyik, és remélem, hogy egy idő után a WebRTC, ha nem éri utol a Skype-ot a címfordítás minőségében ( NAT) és a tűzfalak, akkor legalább észrevehetően közelebb kerülnek.

Az RTCMediaConnection-nek egy további mechanizmusra van szüksége a vezérlő információk cseréjére a kapcsolat létrehozásához - bár előállítja ezeket az adatokat, nem továbbítja azokat, és a többi résztvevő általi továbbítást külön kell megvalósítani.

Az átviteli mód megválasztása a fejlesztő felelőssége – legalábbis manuálisan. Amint a szükséges adatok kicserélődnek, az RTCMediaConnection automatikusan beállítja a médiafolyamokat (természetesen ha lehetséges).

ajánlat-válasz modell

A médiafolyamok létrehozásához és módosításához az ajánlat / válasz modell (ajánlat / válasz; az RFC3264-ben leírtak szerint) és az SDP protokoll (Session Description Protocol) használatos. Ezeket a SIP protokoll is használja. Ebben a modellben két ügynököt különböztetnek meg: Ajánlattevő – aki SDP-munkamenetleírást generál egy új létrehozásához vagy egy meglévő módosításához (SDP-ajánlat), és Válaszadó – aki SDP-munkamenetleírást kap egy másik ügynöktől, és válaszol saját munkamenetleírásával (Answer SDP). Ugyanakkor a specifikáció több mint protokollt igényel magas szint(például SIP vagy saját webes socket, mint esetünkben), amely az SDP ügynökök közötti átviteléért felelős.

Milyen adatokat kell átadni két RTCMediaConnection között, hogy sikeresen létrehozhassák a médiafolyamokat:

• A csatlakozást kezdeményező első fél Ajánlatot készít, amelyben egy SDP adatstruktúrát továbbít (ugyanezt a protokollt használják ugyanarra a célra a SIP-ben), amely leírja annak a médiafolyamnak a lehetséges jellemzőit, amelyet továbbítás előtt áll. Ezt az adatblokkot át kell adni a második résztvevőnek. A második résztvevő választ generál az SDP-jével, és elküldi az elsőnek.
• Mind az első, mind a második résztvevő elvégzi a lehetséges ICE jelöltek meghatározására szolgáló eljárást, amelynek segítségével a második résztvevő át tudja juttatni nekik a médiafolyamot. A jelöltek azonosítása után a róluk szóló információkat át kell adni egy másik résztvevőnek.

Ajánlatképzés

Az ajánlat kialakításához két funkcióra van szükségünk. Az elsőt sikeres kialakítása esetén hívjuk meg. A createOffer() metódus második paramétere egy visszahívási függvény, amelyet a végrehajtás során fellépő hiba esetén hívunk meg (feltéve, hogy a helyi adatfolyam már elérhető).

Ezenkívül két eseménykezelőre van szükség: az onicecandidate-re az új ICE-jelölt meghatározásakor, az onaddstream pedig egy médiafolyam túloldalról történő csatlakoztatásakor. Térjünk vissza az aktánkhoz. Hozzáadás a HTML-hez az elemeket tartalmazó sorok után még egy:

CreateOffer

És az elemmel ellátott sor után

Ezenkívül a JavaScript kód elején deklarálunk egy globális változót az RTCPeerConnection számára:

varpc1;

Az RTCPeerConnection konstruktor meghívásakor meg kell adnia a STUN/TURN szervereket. További részletekért lásd az oldalsávot; mindaddig, amíg minden résztvevő ugyanazon a hálózaton van, nincs szükség rájuk.

var szerverek = null;

Az SDP kiépítési lehetőségei

var offerConstraints = ();

A createOffer() metódus első paramétere egy visszahívási függvény, amelyet egy ajánlat sikeres létrehozása esetén hívnak meg

pc1_createOffer_success(desc) függvény ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // A theConne által generált RTCPeerction beállítása SDP setLocalDescription metódus felajánlása. // Amikor a távoli oldal elküldi az Answer SDP-jét, akkor azt a setRemoteDescription metódussal kell beállítani // Amíg a második oldal nincs implementálva, ne csináljon semmit // pc2_receivedOffer(desc); )

A második paraméter egy visszahívási függvény, amelyet hiba esetén hívunk meg

pc1_createOffer_error(error)(console.log("pc1_createOffer_success_error(): error:", error); ) függvény

És deklarálunk egy visszahívási függvényt, amelyet az ICE jelöltek a definíció szerint továbbítanak:

Függvény pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Ne csináljon semmit a második oldal megvalósításáig // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Valamint egy visszahívási funkció a médiafolyam túloldalról történő hozzáadásához (a jövőre nézve, mivel eddig csak egy RTCPeerConnection-ünk van):

pc1_onaddstream(event) függvény ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )

Amikor a „createOffer” gombra kattint, hozzon létre egy RTCPeerConnection-t, állítsa be az onicecandidate és onaddstream metódusokat, és kérje Offer SDP létrehozását a createOffer() metódus meghívásával:

Függvény createOffer_click() ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // RTCPeerConnection létrehozása pc1.onicecandidate = pc1_onicecandidate; // Visszahívási függvény az ICE jelöltek feldolgozásához pc1.onaddonad =dstream / Visszahívási függvény akkor hívható meg, ha van médiafolyam a túloldalról, de még nem létezik pc1.addStream(localStream); // A helyi médiafolyam átadása (feltételezve, hogy már megkapta) pc1.createOffer(// És valójában kérje az Ajánlat létrehozását pc1_createOffer_success , pc1_createOffer_error, offerConstraints); )

Mentsük el a fájlt rtctest2.html néven, tegyük fel a szerverre, nyissuk meg böngészőben és nézzük meg a konzolban, milyen adatok keletkeznek a működése során. A második videó még nem jelenik meg, mivel csak egy résztvevő van. Emlékezzünk vissza, hogy az SDP a médiamunkamenet-paraméterek leírása, az elérhető kodekek, médiafolyamok és az ICE jelöltek lehetséges opciók a résztvevőhöz való csatlakozáshoz.

Válasz SDP megalakítása és az ICE jelöltek cseréje

Mind az Ajánlat SDP-t, mind az ICE jelölteket át kell adni a másik oldalra, és ott, miután megkapta őket az RTCPeerConnection-től, hívja meg a setRemoteDescription metódusokat az Ajánlat SDP-hez és addIceCandidate-et minden túloldalról kapott ICE jelölthez; hasonlóan fordítva az Answer SDP és a távoli ICE jelölteknél. Maga a Válasz SDP az Ajánlathoz hasonlóan alakul; a különbség az, hogy nem a createOffer metódus hívódik meg, hanem a createAnswer metódus, és ez előtt az RTCPeerConnection előtt a setRemoteDescription metódus átadja a hívótól kapott Offer SDP-t.

Adjunk hozzá még egy videóelemet a HTML-hez:

És a második RTCPeerConnection globális változója az első deklarációja alatt:

Varpc2;

Az ajánlat és az SDP válasz feldolgozása

A válasz kialakítása SDP nagyon hasonló az ajánlathoz. A válasz sikeres formálása esetén meghívott visszahívási funkcióban az Ajánlathoz hasonlóan helyi leírást adunk és a kapott Válasz SDP-t továbbítjuk az első résztvevőnek:

pc2_createAnswer_success(desc) függvény ( pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); )

A válasz generálása közben fellépő hiba esetén meghívott visszahívás teljesen hasonló az Ajánlathoz:

pc2_createAnswer_error(error) függvény ( console.log("pc2_createAnswer_error():", hiba); )

Paraméterek az Answer SDP generálásához:

Var answerConstraints = ( "kötelező": ( "OfferToReceiveAudio":true, "OfferToReceiveVideo":true ) );

Amikor a második résztvevő ajánlatot kap, hozzon létre egy RTCPeerConnection-t, és adjon meg egy választ az ajánlathoz hasonlóan:

pc2_receivedOffer(desc) függvény ( console.log("pc2_receiveOffer()", desc); // RTCPeerConnection objektum létrehozása a második résztvevő számára az elsőhöz hasonló pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2_onicecandidate = pc2_onicecandidate az eseménykezelő, amikor az ICE jelölt pc2.onaddstream = pc_onaddstream; // Amikor megjelenik egy adatfolyam, csatlakoztassa a HTML-hez

Annak érdekében, hogy az ajánlati SDP-t az első résztvevőtől a másodikhoz vigye, a példánk részeként törölje a megjegyzést a pc1 függvényben CreateOffer success() hívási karakterlánc:

Pc2_receivedOffer(desc);

Az ICE jelöltek feldolgozásának megvalósításához törölje a megjegyzéseket az első résztvevő pc1_onicecandidate() ICE jelölt készenléti eseménykezelőjében annak átvitele a másodiknak:

Pc2.addIceCandidate(new RTCIceCandidate(event.candidate));

A második résztvevő ICE jelölt készenléti eseménykezelője tükörszerű az elsőhöz:

pc2_onicecandidate(event) függvény ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Visszahívási funkció médiafolyam hozzáadásához az első résztvevőtől:

pc2_onaddstream(event) függvény ( console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); )

Kapcsolat megszakítása

Adjunk hozzá még egy gombot a HTML-hez

rakd le

És egy funkció a kapcsolat befejezésére

Függvény btnHangupClick() ( // Helyi videó letiltása HTML elemekből

Mentsük el rtctest3.html néven, tegyük fel a szerverre és nyissuk meg a böngészőben. Ez a példa kétirányú médiastreamelést valósít meg két RTCPeerConnection között ugyanazon a böngészőlapon. Az Ajánlat és Válasz SDP, az ICE jelöltek résztvevők közötti és egyéb információk hálózaton keresztüli cseréjének megszervezéséhez szükség lesz a résztvevők közötti csere megvalósítására valamilyen közlekedési eszközzel, esetünkben web socketekkel, a közvetlen hívás helyett. eljárások.

Screen Broadcast

A getUserMedia funkcióval a képernyőt és a streamet MediaStreamként is rögzítheti a következő paraméterek megadásával:

Var mediaStreamConstraints = ( hang: false, videó: ( kötelező: ( chromeMediaSource: "screen" ), opcionális: ) );

A képernyő sikeres eléréséhez több feltételnek kell teljesülnie:

• képernyőkép jelző engedélyezése a getUserMedia()-ban a chrome://flags/,chrome://flags/ helyen;
• a forrásfájlt HTTPS-en (SSL eredetű) keresztül kell letölteni;
• az audio streamet nem szabad kérni;
• több kérést nem szabad ugyanazon a böngészőlapon benyújtani.

Könyvtárak a WebRTC számára

A WebRTC ugyan még nem készült el, de már több erre épülő könyvtár is megjelent. A JsSIP-et olyan böngészőalapú szoftverek létrehozására tervezték, amelyek SIP-kapcsolókkal működnek, mint például az Asterisk és a Camalio. A PeerJS leegyszerűsíti az adatcseréhez szükséges P2P hálózatok létrehozását, a Holla pedig csökkenti a böngészőkből származó P2P kommunikációhoz szükséges fejlesztések mennyiségét.

Node.js és socket.io

Az SDP- és ICE-jelöltek cseréjének megszervezése két RTCPeerConnection között a hálózaton keresztül, a Node.js-t használjuk a socket.io modullal.

Leírja a Node.js legújabb stabil verziójának telepítését (Debian/Ubuntu számára).

$ sudo apt-get install python-software-properties python g++ make $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get update $ sudo apt-get install nodejs

Telepítés mások számára Operációs rendszer leírta

Nézzük meg:

$ echo "sys=require("util"); sys.puts("Tesztüzenet");" > nodetest1.js $ nodejs nodetest1.js

Az npm (Node Package Manager) segítségével telepítse a socket.io fájlt és a kiegészítő expressz modult:

$ npm telepítse a socket.io expresst

Ellenőrizzük úgy, hogy létrehozunk egy nodetest2.js fájlt a szerveroldalon:

$ nano nodetest2.js var app = igény("express")() , szerver = igény("http").createServer(app) , io = követelmény("socket.io").listen(server); server.listen(80); // Ha a 80-as port ingyenes app.get("/", függvény (req, res) ( // A gyökéroldal elérésekor res.sendfile(__dirname + "/nodetest2.html"); // adja meg a HTML fájlt ) ) ; io.sockets.on("kapcsolat", függvény (socket) ( // Csatlakozáskor socket.emit("szerver esemény", ( hello: "world" )); // üzenet küldése socket.on("kliens esemény", function (data) ( // és deklarál egy eseménykezelőt, amikor üzenet érkezik az ügyfélkonzolból.log(data); )); ));

És a nodetest2.html az ügyféloldalra:

$nano nodetest2.html

Indítsuk el a szervert:

$ sudo nodejs nodetest2.js

és nyissa meg a http://localhost:80 oldalt (ha helyileg a 80-as porton fut) egy böngészőben. Ha minden sikeres, akkor a böngésző JavaScript konzoljában látni fogjuk az eseménycserét a böngésző és a szerver között csatlakozáskor.

Információcsere az RTCPeerConnection között webes socketeken keresztül

Ügyfél oldal

Mentsük el a fő példánkat (rtcdemo3.html) új néven rtcdemo4.html. Szerelje be a socket.io könyvtárat az elembe:

És a JavaScript szkript elején - web socket kapcsolat:

var socket = io.connect("http://localhost");

Cseréljük ki a közvetlen hívást egy másik résztvevő funkcióira úgy, hogy üzenetet küldünk neki webaljzatokon keresztül:

függvény createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit("ajánlat", desc); ... ) függvény pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); socket .emit("answer", desc); ) function pc1_onicecandidate(event) ( ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); .. . ) function pc2_onicecandidate(event) ( ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... )

A hangup() függvényben ahelyett, hogy közvetlenül a második résztvevő függvényeit hívnánk meg, üzenetet küldünk webcsatornákon keresztül:

Függvény btnHangupClick() ( ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("hangup", ()); )

És adjon hozzá üzenetfogadó kezelőket:

Socket.on("ajánlat", függvény (adatok) ( console.log("socket.on("ajánlat"):", adat); pc2_receivedOffer(data); )); socket.on("válasz", függvény (adatok) (e console.log("socket.on("válasz"):", data); pc1.setRemoteDescription(new RTCSessionDescription(data)); )); socket.on("ice1", függvény (data) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("ice2", függvény (data) ( console.log("socket.on("ice2"):", data); pc1.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("hangup", függvény (data) ( console.log("socket.on("hangup")):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

Szerver rész

A szerver oldalon mentse el a nodetest2 fájlt új néven rtctest4.js, és az io.sockets.on("connection", function (socket) (... ) függvény belsejében adja hozzá a kliens üzenetek fogadását és küldését:

Socket.on("ajánlat", függvény (adatok) ( // "ajánlat" üzenet érkezésekor, // mivel az ügyfélkapcsolat ezt a példát csak egy, // üzenet visszaküldése ugyanazon a socketen keresztül socket.emit("ajánlat", adat); // Ha szükséges lenne az üzenet továbbítása minden kapcsolaton // kivéve a feladót: // socket.broadcast.emit("ajánlat", adat); )); socket.on("válasz", függvény (adatok) ( socket.emit("válasz", adat); )); socket.on("ice1", function (data) ( socket.emit("ice1", data); )); socket.on("ice2", függvény (adatok) ( socket.emit("ice2", data); )); socket.on("hangup", function (data) ( socket.emit("lefagy", adat); ));

Ezenkívül módosítsa a HTML-fájl nevét:

// res.sendfile(__dirname + "/nodetest2.html"); // A HTML-fájl elküldése res.sendfile(__dirname + "/rtctest4.html");

Szerver indítása:

$ sudo nodejs nodetest2.js

Annak ellenére, hogy mindkét kliens kódja ugyanazon a böngészőlapon fut, a példánkban szereplő résztvevők közötti minden interakció teljes mértékben a hálózaton keresztül zajlik, és már nem nehéz a résztvevőket „elteríteni”. Amit azonban tettünk, az is nagyon egyszerű volt – ezek a technológiák jók a könnyű használatukhoz. Bár néha megtévesztő. Különösképpen ne felejtsük el, hogy STUN/TURN szerverek nélkül példánk nem fog működni címfordítás és tűzfalak jelenlétében.

Következtetés

Az eredményül kapott példa nagyon feltételes, de ha kissé univerzalizáljuk az eseménykezelőket, hogy ne különbözzenek a hívó és a hívott fél között, akkor két objektum, a pc1 és a pc2 helyett, készítsünk egy RTCPeerConnection tömböt és implementáljuk dinamikus alkotásés az elemek eltávolítása

Feltételezhető, hogy a WebRTC-nek köszönhetően hamarosan forradalom fog bekövetkezni nemcsak a hang- és videokommunikáció megértésében, hanem abban is, hogy miként tekintjük az Internetet egészében. A WebRTC nem csak böngésző-böngésző hívástechnológia, hanem valós idejű kommunikációs technológia is. Az általunk elemzett videó link csak egy kis része ennek. lehetőségek a használatát. Már van példa képernyőmegosztásra (képernyőmegosztás), együttműködésre, sőt, az RTCDataChannel segítségével böngésző alapú P2P tartalomszolgáltató hálózatra is.

Törekedj a maximumra hatékony átvitel a böngészők közötti adatfolyamok egyre fejlettebb technológiák megjelenéséhez vezetnek, de új aggodalmak forrásává is válhatnak az interneten a magánélet védelmét és biztonságát értékelő felhasználók számára. Az egyik ilyen technológia az Valós idejű kommunikáció vagy halmazként rövidítve API-interfészek, amelyeket különösen a böngészőkben a hang- és videokommunikáció biztosítására használnak.

Jelenleg támogatja a legnépszerűbb webböngészőket, beleértve Google Chrome , Mozilla Firefox , Operaés Microsoft Edge . Ennek a sok szempontból hasznos technológiának viszont van egy jelentős hátulütője, hiszen valósággá válik IP-user akkor is, ha az utolsó használta VPN és egyéb adatvédelmi eszközöket globális hálózat. Azonban nem minden webhely használja , de nem minden böngésző teszi lehetővé a kikapcsolását, legalábbis a fő beállításokon keresztül. Az alábbiakban bemutatjuk, hogyan lehet letiltani népszerű böngészőkben, de most nézzük meg, hogyan állapítható meg, hogy egy webhely használja-e ezt a technológiát.

Ha van Google Chrome vagy más böngésző alapú Chromium (Opera, Yandex stb.), nyissa meg az elemzett webes erőforrást, majd lépjen a címre egy új lapon chrome://webrtc-internals . Ha a webhely megpróbálta telepíteni -kapcsolat, akkor egy olyan képet fog látni, mint a képernyőkép (a weboldal címe fent lesz).

Ellenkező esetben az oldal így fog kinézni:

Ha van, nyissa meg a webhelyet is, és lépjen a címre egy új lapon about:webrtc. segítségével részben megjelenik az oldal "Munkamenet statisztika", ellenkező esetben a szakasz üres lesz.

Sajnos a böngészőfejlesztők eddig süket fülekre találtak a felhasználók kéréseire alapértelmezés szerint le van tiltva, tehát egyedül kell cselekednie. A technológia kikapcsolásának legegyszerűbb módja az . Ehhez nyissa meg a szerviz oldalt, nyomja meg a gombot "Vállalom a kockázatot", keresse meg a paramétert, kattintson duplán az értékének megváltoztatásához igaz a hamis és indítsa újra a böngészőt.

Alternatív megoldásként használhatja a bővítményt, ha telepíti a webhelyről bolt Firefox kiegészítők . Még jobb, ha letölti a segédprogramot, futtassa, és jelölje be a lehetőséget az általa megjelenített paraméterek listájában. (Média, kamera, mikrofon alatt található) .

TÓL TŐL Google Chrome minden kicsit bonyolultabb. A rejtett beállításaiban nincs olyan lehetőség, amely lehetővé tenné a letiltást , de megpróbálhatja ezt megtenni egy harmadik féltől származó kiterjesztéssel ScriptSafe. A telepítés után a bővítmény letiltja a szkripteket, beleértve a , kár, hogy a módszernek van egy hátulütője, mert senki sem tudja garantálni, hogy ezek után az oldalak jól működnek. Ugyanaz a plugin használható a letiltásra ban ben Operaés (verziókat keress a kiegészítő boltokban) .

Sok felhasználó még azt sem tudja, mi az a WebRTC (elvileg semmi érdekes), és hogy ez a technológia el tudja adni, ha proxyt használ... és még Tort is! WebRCT ha egyszerű szavakkal, akkor ez egy olyan dolog, ami létrejött Google hogy biztosítsuk valamiféle streaming adatok átvitelét a böngészők vagy más, ezt a dolgot támogató programok között.

De nem tudom, hol használják, de a WebRTC-t le kéne tiltani, mert könnyen ki tudja adni az IP-címedet zsigerekkel ... és ami a legérdekesebb, az IPLeak.net weboldalon ellenőrizheted (készítsd el) jobb könyvjelzővel) – kapcsolja be a VPN-t , vagy állítson be egy proxyt, és nézze meg, mit nyújt ez a webhely

És nagyon-nagyon érdekes információkat fog adni - a tetején lesz egy proxy vagy VPN-cím, de az alsó sorban csak a tiéd, bár úgy változtatta meg:

Mi a legjobb tennivaló, hogyan lehet megszabadulni ettől a karámtól? Ezt a technológiát teljesen le kell tiltania a böngészőjében! Ma már ez mindenképpen lehetséges a Chrome-ban és a Mozillában, amelyek elvileg amúgy is a legnépszerűbb böngészők, főleg, ha figyelembe vesszük, hogy sok más is Chrome-ra épül.

Tehát letiltani WebRTC technológia a Google-tól, a Google hivatalos kiterjesztését kell használnod, hát ez vicces igaz, erről a linkről tudod letölteni az áruházból.

Folytassa, kattintson a TELEPÍTÉS gombra:

Most megerősítjük:

A bővítmény telepítve van, ellenőrizheti, lépjen újra az IPLeak.net oldalra, és ellenőrizze, hogy a WebRTC már nem zavarja-e az anonimitásunkat.

Nos, mi a helyzet a Mozillával? Itt sem nehéz, nyissa meg, és írja be a címsorba így - körülbelül: config, amely után egy speciális oldalra jutunk egy csomó paraméterrel.

Most be kell írnia a keresésbe (a felső sorban) ezt a paramétert - media.peerconnection.enabled, és módosítania kell az értéket igazról hamisra:

Ennyi, újraindíthatod a böngészőt és ellenőrizheted, most már nem lesz látható az IP-címed a hálózaton VPN vagy proxy használatakor. Ahogy már írtam, lehetséges, hogy más Chrome alapú böngészők is használhatják a fenti kiterjesztést, de erre nincs garancia, és főleg Opera böngésző(Úgy tűnik, ő is a Chrome motort használja). Eddig biztosan működik Chrome-ban és Mozillában!

02.02.2016

A következő képernyő azt jelzi, hogy a WebRTC funkció engedélyezve van a böngészőben. Ezen kívül az oldal egyéb érdekes információkat is tartalmaz.

Hogyan lehet letiltani a WebRTC-t?

A modern böngészők közül a Firefox a leginkább betanítható. És ebben a konkrét esetben a Firefox megmutatta a legjobb oldalát, lehetővé téve a felhasználó számára, hogy letiltja a WebRTC-t rejtett beállításokkal anélkül, hogy harmadik féltől származó kiegészítőket használna.

A WebRTC Firefox letiltása

A Firefox böngészőben történő letiltásához be kell írnia az about:config parancsot a címsorba, amely után ez az üzenet jelenik meg.

Kattintson az "Ígérem ..." gombra, és folytassa.

A beállítások ablakban a keresősávba (nem a címsorba!), az alábbi képernyőképen látható módon írja be a media.peerconnection.enabled parancsot. Megjelenik a szükséges sor. Kattintson rá a jobb egérgombbal, és válassza ki az első elemet a legördülő menüből " Váltás ".

Az "Érték" mezőre váltás után a "False" paraméternek kell megjelennie. Most zárja be ezt az ablakot, és indítsa újra a böngészőt.

Egy másik módszer a speciális Disable WebRTC bővítmény telepítése. De jobban szeretem és azt tanácsolom, hogy ezt a műveletet saját maga végezze el. Nem szeretek programokat telepíteni számítógépre, főleg böngészőbe.

Van egy még egyszerűbb módja - töltse le a ConfigFox segédprogramot, amely ezen a műveleten kívül jelentősen javíthatja a Firefox böngésző adatvédelmét és anonimitását. Erről a programról a "Firefox biztonsági beállításai" című cikkben írtunk. Nagyon ajánlom a használatát ezt a segédprogramot minden felhasználó számára Mozilla böngésző Firefox. A program nem telepíti magát a böngészőbe, hanem egyszerűen lehetővé teszi a beállításfájl módosítását.

A WebRTC Chrome letiltása

NÁL NÉL Google böngésző A Chrome egy kicsit bonyolultabb. A Chrome-ban nem lehet kikapcsolni. ezt a funkciót magában a böngészőben. Ehhez le kell töltened egy speciális WebRTC Block nevű kiegészítőt. Ezen a közvetlen hivatkozáson keresztül letöltheti és telepítheti a kiegészítőt. Nem teszteltük ezt a bővítményt, és nem tudunk garanciát vállalni.

Van egy ScriptSafe-kiegészítő is, amely szintén segíthet ezen a problémán. Véleményem szerint ezt A legjobb mód megoldja a WebRTC problémát a Chrome-ban.

Ezzel a kiterjesztéssel tapasztalatlan felhasználó nehezebb lesz, de ha haladó vagy, akkor erősen ajánlom, hogy ásd bele magad.

Ha ismer más módszereket a probléma megoldására a Chrome böngészőben, írja meg a megjegyzésekben.

A WebRTC Opera / Yandex böngésző letiltása

Számos bővítmény létezik az Opera böngészőhöz: WebRTC Leak Prevent és WebRTC Control. Személyesen nem teszteltem, próbáld ki és írd meg, hogy mi segített és mi nem.

Végezetül azt szeretném mondani, hogy jelenleg nincs megbízható, száz százalékos mód a WebRTC letiltására Chromium böngészők mint például: Chrome, Yandex, Opera stb. Ezért azt tanácsolom mindenkinek, aki VPN-t használ, és akinek fontos az anonimitás, átmenetileg hagyja abba ezeknek a böngészőknek a használatát. Azt hiszem, a közeljövőben ez a lyuk bezárul, és visszatérhetsz hozzájuk. Addig is ideiglenesen áttérhet a Firefoxra.

Ez minden. A következő cikkekben a VPN-ek és a nyilvános proxyk névtelenségéről és megbízhatóságáról fogunk beszélni. Jó móka lesz, megtörjük a sztereotípiákat. Szeretni fogod ;)!