WebRTC негізіндегі тең-теңімен бейне чат. WebRTC Webrtc орнатуына негізделген P2P бейне чаты

Еуропалық интернет пайдаланушылар екі бөлікке бөлінеді: Алленбахтағы (Германия) қоғамдық пікірді талдау институтының сауалнамасы бойынша Skype, чат және лезде хабар алмасу жүйелері Интернеттің ажырамас бөлігіне айналды. Күнделікті өмір 16,5 миллион ересектер мен балалардың 9 миллионы бұл қызметтерді анда-санда пайдаланады, ал 28 миллионы оларға қол тигізбейді.

Бұл Firefox енді біріктірілгендіктен өзгеруі мүмкін нақты уақыттағы байланыс технологиясы (WebRTC), сондай-ақ клиенттің өзі. Аудио және бейне чатты бастау енді веб-сайтты ашудан қиын емес. Facebook және Skype сияқты қызметтер, керісінше, бөлек клиентті пайдаланып және тіркелгі жасау арқылы шешімдерге сүйенеді.

WebRTC қолданудың қарапайымдылығымен ғана ерекшеленеді. Бұл әдіс тіпті орнатуға мүмкіндік береді екі браузер арасындағы тікелей байланыс. Осылайша, аудио және бейне деректері шамадан тыс жүктелуі мүмкін немесе әкімші құпиялылыққа немесе деректерді қорғауға аса сезімтал емес сервер арқылы өтпейді. Тікелей қосылымның арқасында WebRTC тіркеуді де, тіркеуді де қажет етпейді тіркеу жазбасыкез келген қызметте.

Әңгімелесуді бастау үшін тек сілтеме бойынша өту керек. Байланыс құпия болып қалады, өйткені деректер ағыны шифрланған. Google 2011 жылы WebRTC іске асырудың бастапқы кодын жариялаған кезде браузер арқылы нақты уақыттағы байланысқа белсенді түрде кірісті.

Осыдан кейін көп ұзамай Chrome және Firefox өздерінің WebRTC қозғалтқыштарын алды. Қазіргі уақытта олардың мобильді нұсқалары осы технологиямен де, қолданбалар пайдаланатын Android 5.0 орнатылған WebView 3.6 қозғалтқышымен де жабдықталған.

Нақты уақыттағы байланыс үшін веб-қарау құралында сәйкес JavaScript интерфейстері енгізілуі керек. GetUserMedia пайдалану бағдарламалық қамтамасыз етуаудио және бейне көздерінен, яғни веб-камера мен микрофоннан түсіруді белсендіреді. RTCPeerConnection қосылымды орнатуға, сондай-ақ байланыстың өзі үшін жауап береді.

Браузерге біріктірумен қатар Консорциумның жұмыс тобы Дүниежүзілік өрмек(W3C) WebRTC стандарттау процесін жылдамдатты. Ол 2015 жылы аяқталуы тиіс.

WebRTC мазмұны аз

WebRTC қызметін пайдалану көп ресурстарды қажет етпейді, өйткені сервер тек сұхбаттасушыларды қосады. Байланысты орнату да қиын емес. Біріншіден, браузер WebRTC серверіне қоңырауды бастауды жоспарлап отырғаны туралы сигнал береді. Ол серверден HTTPS сілтемесін алады - байланыс шифрланған. Пайдаланушы бұл сілтемені сұхбаттасушысына жібереді. Содан кейін браузер пайдаланушыдан веб-камера мен микрофонға кіруге рұқсат сұрайды.

Әңгімелесушімен тікелей ағынды қосылымды орнату үшін браузер өзінің IP мекенжайын және конфигурация деректерін WebRTC қызметінен алады. Басқа адамның веб-қараушысы да солай істейді.

Ағынды қосылым бірқалыпты және сапалы жұмыс істеуі үшін браузерде үш қозғалтқыш жұмыс істейді. Олардың екеуі аудио және бейне деректерді оңтайландырады және қысады, үшіншісі оларды тасымалдауға жауап береді. Ол арқылы деректерді жібереді SRTP протоколы(Secure Real-time Transport Protocol), ол шифрланған нақты уақыттағы ағынға мүмкіндік береді.

Тікелей қосылымды орнату мүмкін болмаса, WebRTC басқа жолды іздейді. Мысалы, бұл кезде болады желі параметрлері STUN серверінің IP мекенжайын хабарлауын болдырмайды. WebRTC стандарты бұл жағдайда әңгіме TURN серверінің аралық белсендірілуімен (NAT айналасындағы релелерді пайдалану арқылы өту) болатынын қарастырады. Сонымен, netscan.co веб-сайтында WebRTC компьютеріңізде іске асырылғанын және сіздің желіге кіру мүмкіндігіңіз бар-жоғын тексеруге болады.

Байланыс қалай жасалады

Алдымен сөйлесуді тіркеу керек (1). WebRTC қызметі сұхбаттасушыға жіберілетін сілтемені ұсынады. Браузер STUN серверін пайдалана отырып, өзінің IP мекенжайын (2) табады, оны қызметке жібереді және тікелей байланыс орнату үшін серіктестің IP-ді алады (3). STUN орындалмаса, сөйлесу TURN сервері арқылы қайта бағытталады (4).

Браузердегі WebRTC технологиясын пайдаланатын байланыс JavaScript коды арқылы іске қосылады. Осыдан кейін байланыс үшін үш қозғалтқыш жауап береді: дауыс және бейне қозғалтқыштары веб-камера мен микрофоннан мультимедиялық деректерді жинайды, ал көлік қозғалтқышы ақпаратты біріктіреді және SRTP (Secure Real-time Protocol) көмегімен шифрланған түрде ағынды жібереді.

WebRTC-пен қандай браузерлер жұмыс істейді

Chrome және Firefox-та talky.io сияқты қызметтерді пайдаланатын WebRTC қозғалтқышы бар. Mozilla браузері өз клиентімен тікелей жұмыс істей алады.

Google және Mozilla нақты уақыттағы байланыс идеясын дамытуды жалғастыруда: Chrome бірнеше қатысушылармен WebRTC конференциясын өткізе алады және Firefox-тағы жаңа Hello клиенті Telefonica телекоммуникациялық алпауытының еншілес компаниясымен бірлесіп әзірленген. Apple әзірше шетте тұр, сіз әлі Safari-де WebRTC күтпеуіңіз керек. Дегенмен, көп балама қолданбалар iOS үшін және Safari үшін плагиндер.

Майкрософт сәл басқаша курс алады. Бәсекелестік иесі ретінде Skype қызметібұл компания WebRTC-ке оңайлықпен берілмейді. Оның орнына, Microsoft корпорациясы ORTC (Нақты уақыттағы объекті байланысы) технологиясын әзірлеуде. Internet Explorer.

WebRTC-тен әртүрлі кодектер мен сервермен байланыс орнату протоколдары сияқты айырмашылықтар шамалы және уақыт өте келе WebRTC стандартына осы айырмашылықтарды қамтитын қосымшаға айналуы мүмкін. Осылайша, тек Apple ғана қалды - әдеттегідей.

Фото:өндірістік компаниялар; goodluz/Fotolia.com

Материалдың көп бөлігі WebRTCкодтаудың қолданбалы деңгейіне назар аударады және технологияны түсінуге ықпал етпейді. Тереңірек барып, байланыс қалай пайда болатынын, сеанс дескрипторы мен кандидаттар деген не, олар не үшін қажет екенін білуге ​​тырысайық. ТАҢДАУЖәне БҰРУсервер.

WebRTC

Кіріспе

WebRTC — бейне деректерін тасымалдау үшін екі клиентті қосуға мүмкіндік беретін шолғышқа бағытталған технология. Негізгі мүмкіндіктер: браузердің ішкі қолдауы (үшінші тарап енгізген технологиялар қажет емес Adobe Flash ) және қосымша серверлерді қолданбай-ақ клиенттерді қосу мүмкіндігі - қосылу пиринг жүйесі(Әрі қарай, p2p).

Байланыс орнату p2p- өте қиын тапсырма, өйткені компьютерлер әрқашан ашық бола бермейді IPмекенжайлар, яғни Интернеттегі мекенжайлар. Саны аз болғандықтан IPv4мекенжайлары (және қауіпсіздік мақсатында) механизмі әзірленді NAT, бұл сізге жеке желілерді жасауға мүмкіндік береді, мысалы, үйде пайдалану үшін. Көптеген үй маршрутизаторлары қазір қолдайды NATжәне осының арқасында барлық үй құрылғылары Интернетке қол жеткізе алады, дегенмен Интернет-провайдерлер әдетте оны қамтамасыз етеді IPмекенжайы. Қоғамдық IPмекенжайлар Интернетте бірегей, бірақ жеке мекенжайлар жоқ. Сондықтан қосылыңыз p2p- қиын.

Мұны жақсырақ түсіну үшін үш жағдайды қарастырыңыз: екі түйін де бір желіде (1-сурет), екі түйін де әртүрлі желілерде (біреуі жеке, екіншісі жалпыға ортақ) (2-сурет)және екі түйін де бірдей әртүрлі жеке желілерде IPмекенжайлар (3-сурет).

1-сурет: Бір желідегі екі түйін

2-сурет: Әр түрлі желілердегі түйіндер (біреуі жеке, біреуі жалпыға ортақ)

3-сурет: Әртүрлі жеке желілердегі түйіндер, бірақ сандық жағынан бірдей мекенжайлар

Жоғарыдағы суреттерде екі таңбалы белгілердің бірінші әрпі түйіннің түрін көрсетеді (p = құрдас, r = маршрутизатор). Бірінші суретте жағдай қолайлы: олардың желісіндегі түйіндер желі арқылы толығымен анықталған IPмекенжайлары бар, сондықтан бір-бірімен тікелей қосыла алады. Екінші суретте бізде түйін нөмірлері ұқсас екі түрлі желі бар. Бұл жерде маршрутизаторлар (маршрутизаторлар) пайда болады, олардың екеуі бар желі интерфейсі– желіңіздің ішінде және желіңізден тыс. Сондықтан олардың екеуі бар IPмекенжайлар. Тұрақты түйіндердің бір ғана интерфейсі бар, ол арқылы олар тек желі ішінде ғана байланыса алады. Егер олар деректерді желіден тыс біреуге жіберсе, тек пайдаланады NATмаршрутизатордың (маршрутизатордың) ішінде, сондықтан оның астындағы басқаларға көрінеді IPмаршрутизатордың мекенжайы олардыкі сыртқы IPмекенжайы. Осылайша, түйінде p1Сонда бар интерьер IP = 192.168.0.200 Және сыртқы IP = 10.50.200.5 , және соңғы мекенжай оның желісіндегі барлық басқа түйіндерге де сыртқы болады. Түйін үшін ұқсас жағдай p2. Сондықтан, егер сіз тек ішкі (меншік) қолдансаңыз, олардың қосылуы мүмкін емес. IPмекенжайлар. Сіз сыртқы мекенжайларды, яғни маршрутизатор мекенжайларын пайдалана аласыз, бірақ бір жеке желідегі барлық түйіндердің сыртқы мекенжайы бірдей болғандықтан, бұл өте қиын. Бұл мәселе механизмнің көмегімен шешіледі NAT

Түйіндерді олардың ішкі мекенжайлары арқылы қосуды шешсек не болады? Деректер желіден шықпайды. Эффектіні күшейту үшін сіз соңғы суретте көрсетілген жағдайды елестете аласыз - екі түйіннің де ішкі мекенжайлары бірдей. Егер олар оларды байланысу үшін пайдаланса, онда әрбір түйін өзімен байланысады.

WebRTCхаттаманы пайдалана отырып, осындай мәселелермен сәтті күреседі ICE, бірақ бұл қосымша серверлерді пайдалануды талап етеді ( ТАҢДАУ, БҰРУ). Мұның бәрі төменде толығырақ.

WebRTC екі фазасы

Екі түйінді протокол арқылы қосу үшін WebRTC(немесе жай RTC, егер екеуі байланысса iPhone‘a) байланыс орнату үшін кейбір алдын ала қадамдар жасалуы керек. Бұл бірінші кезең – байланыс орнату. Екінші кезең – бейне мәліметтерді жіберу.

Технология болса да, бірден айту керек WebRTCөз жұмысында көп пайдаланады түрлі жолдарменбайланыс ( TCPЖәне UDP) және олардың арасында икемді ауысу бар, бұл технология қосылым деректерін жіберу протоколы жоқ. Таңқаларлық емес, өйткені екі түйінді қосыңыз p2pоңай емес. Сондықтан біраз болуы керек қосымшаешқандай қатысы жоқ деректерді беру әдісі WebRTC. Бұл розетка тасымалдауы, хаттама болуы мүмкін HTTP, ол тіпті протокол болуы мүмкін SMTPнемесе орыс поштасы. Бұл тасымалдау механизмі бастапқыдеректер деп аталады сигнал. Көп ақпаратты жеткізудің қажеті жоқ. Барлық деректер мәтін түрінде беріледі және екі түрге бөлінеді - SDPЖәне Мұз кандидаты. Бірінші түрі логикалық байланыс орнату үшін, ал екіншісі физикалық байланыс үшін қолданылады. Мұның бәрі туралы кейінірек, бірақ әзірге мұны есте сақтау маңызды WebRTCбізге басқа түйінге жіберуді қажет ететін кейбір ақпаратты береді. Біз барлық қажетті ақпаратты жібергеннен кейін түйіндер қосыла алады және біздің көмегіміз қажет болмайды. Сонымен, біз іске асыруымыз керек сигнал беру механизмі болып табылады бөлек, пайдаланылады қосылған кезде ғана, бірақ бейне деректерін жіберу кезінде пайдаланылмайды.

Сонымен, бірінші кезеңді қарастырайық - байланыс орнату кезеңі. Ол бірнеше нүктелерден тұрады. Бұл фазаны алдымен қосылымды бастайтын түйін үшін, содан кейін күтіп тұрған түйін үшін қарастырайық.

• Бастамашы (қоңырау шалушы - қоңырау шалушы):
  1. Бейне деректерін тасымалдауды бастау ұсынысы (createOffer)
  2. Өзіңдікі SDP SDP)
  3. Өзіңдікі Мұз кандидаты Мұз кандидаты)
• Қоңырау күту ( қоңырау шалушы):
  1. Жергілікті (сіздің) медиа ағынын қабылдау және оны жіберуге орнату (getUserMediaStream)
  2. Бейне деректерін тасымалдауды бастау ұсынысын алу және жауап жасау (createAnswer)
  3. Өзіңдікі SDPобъект және оны сигналдық механизм арқылы беру ( SDP)
  4. Өзіңдікі Мұз кандидатыобъектілер және олардың сигналдық механизм арқылы берілуі ( Мұз кандидаты)
  5. Қашықтағы (шетелдік) медиа ағынын қабылдау және оны экранда көрсету (onAddStream)

Жалғыз айырмашылық екінші тармақта.

Қадамдардың көрінетін күрделілігіне қарамастан, олардың үшеуі бар: өз медиа ағынын жіберу (1-тармақ), қосылым параметрлерін орнату (2-4-тармақтар), басқа біреудің медиа ағынын қабылдау (5-тармақ). Ең қиын қадам - ​​екінші қадам, өйткені ол екі бөліктен тұрады: орнату физикалықЖәне логикалықбайланыстар. Біріншісі көрсетеді жол, ол бойынша пакеттер бір желі түйінінен екіншісіне өту үшін жүруі керек. Екіншісі көрсетеді бейне/аудио параметрлері– қандай сапаны пайдалану керек, қандай кодектерді пайдалану керек.

Психикалық кезең ұсыныс жасаунемесе Жауап жасауберу сатыларына қосылуы керек SDPЖәне Мұз кандидатынысандар.

Негізгі нысандар

Медиа ағындары (MediaStream)

Негізгі мәні – медиа ағыны, яғни бейне және дыбыс деректерінің, сурет пен дыбыстың ағыны. Медиа ағынының екі түрі бар - жергілікті және қашықтағы. Жергілікті құрылғы деректерді енгізу құрылғыларынан (камера, микрофон), ал қашықтағы құрылғы желі арқылы алады. Осылайша, әрбір түйінде жергілікті және қашықтағы ағын бар. IN WebRTCжіптерге арналған интерфейс бар MediaStreamсонымен қатар ішкі интерфейс бар LocalMediaStreamарнайы жергілікті жіп үшін. IN JavaScriptсіз тек біріншісін кездестіре аласыз және егер сіз пайдалансаңыз ренжіту, содан кейін сіз екіншісіне тап болуыңыз мүмкін.

IN WebRTCЖіп ішінде өте шатастыратын иерархия бар. Әрбір ағын бірнеше медиа тректерден тұруы мүмкін ( MediaTrack), ол өз кезегінде бірнеше медиа арналардан тұруы мүмкін ( MediaChannel). Сондай-ақ бірнеше медиа ағындары болуы мүмкін.

Барлығын ретімен қарастырайық. Ол үшін бірнеше мысалды есте сақтайық. Біз өзіміздің бейнемізді ғана емес, бірдеңе жазатын қағаз жатқан үстеліміздің видеосын да жібергіміз келеді делік. Бізге екі бейне (біз + кесте) және бір аудио (біз) қажет болады. Біз және кестені әртүрлі ағындарға бөлу керек екені анық, өйткені бұл деректер бір-біріне әлсіз тәуелді болуы мүмкін. Сондықтан бізде екі болады MediaStream‘a – біреуі бізге, бірі дастарханға. Біріншісінде бейне және аудио деректер де болады, ал екіншісінде тек бейне болады (4-сурет).

4-сурет: Екі түрлі медиа ағыны. Біреуі бізге, бірі дастарханымызға

Медиа ағыны кем дегенде деректерді қамту мүмкіндігін қамтуы керек екені бірден түсінікті әртүрлі түрлері- бейне және аудио. Бұл технологияда ескеріледі, сондықтан деректердің әрбір түрі медиа трек арқылы жүзеге асырылады MediaTrack. Медиа тректің ерекше қасиеті бар мейірімді, бұл біздің алдымызда не бар екенін анықтайды - бейне немесе аудио (5-сурет)

5-сурет: Медиа ағындары медиа тректерден тұрады

Бағдарламада бәрі қалай болады? Біз екі медиа ағынын жасаймыз. Содан кейін біз екі бейне трек және бір аудио трек жасаймыз. Камералар мен микрофонға қол жеткізейік. Әр трекке қандай құрылғыны пайдалану керектігін айтайық. Бірінші медиа ағынына бейне және аудио жолды және екінші медиа ағынына басқа камерадан бейне жолды қосамыз.

Бірақ қосылымның екінші жағындағы медиа ағындарын қалай ажыратамыз? Ол үшін әрбір медиа ағынының қасиеті болады заттаңба– ағын белгісі, оның атауы (6-сурет). Медиа тректер бірдей сипатқа ие. Бір қарағанда, бейнені дыбыстан басқа жолдармен ажыратуға болатын сияқты.

6-сурет: Медиа ағындары мен тректер белгілер арқылы анықталады

Сонымен, егер медиа тректерді тег арқылы анықтауға болатын болса, онда неге бізге мысал үшін біреудің орнына екі медиа ағынын пайдалану керек? Өйткені, сіз бір медиа ағынын жібере аласыз, бірақ ондағы әртүрлі тректерді пайдалана аласыз. Біз медиа ағындардың маңызды қасиетіне жеттік – олар синхрондаумедиа тректер. Әртүрлі медиа ағындары бір-бірімен синхрондалмайды, бірақ әрбір медиа ағынының ішінде барлық тректер бір уақытта ойналады.

Осылайша, егер біз сөзімізді, бет-әлпетімізді және қағаз парағын бір уақытта ойнатқымыз келсе, онда бір медиа ағынын қолданған жөн. Егер бұл соншалықты маңызды болмаса, онда әртүрлі ағындарды пайдалану тиімдірек - сурет тегіс болады.

Тасымалдау кезінде кейбір жолдарды өшіру қажет болса, сипатты пайдалануға болады қосылғанмедиа тректер.

Ақырында, стерео дыбыс туралы ойлануға тұрарлық. Өздеріңіз білетіндей, стерео дыбыс екі әртүрлі дыбыстар. Және олар да бөлек ауыстырылуы керек. Ол үшін арналар қолданылады MediaChannel. Мультимедиа аудио трегінде көптеген арналар болуы мүмкін (мысалы, 5+1 аудио қажет болса, 6). Әрине, медиа тректердің ішінде арналар да бар. синхрондалған. Бейне үшін әдетте бір ғана арна пайдаланылады, бірақ бірнеше, мысалы, жарнаманы қабаттастыру үшін пайдалануға болады.

Қорытындылай келе: Бейне және аудио деректерді беру үшін біз медиа ағынын қолданамыз. Әрбір медиа ағынында деректер синхрондалады. Синхрондау қажет болмаса, біз бірнеше медиа ағындарын пайдалана аламыз. Әрбір медиа ағынының ішінде медиа тректердің екі түрі бар - бейне және аудио үшін. Әдетте екі тректен аспайды, бірақ бірнеше түрлі бейнелерді (әңгімелесушінің және оның кестесінің) жіберу қажет болса, одан да көп болуы мүмкін. Әрбір трек әдетте тек стерео дыбыс үшін қолданылатын бірнеше арнадан тұруы мүмкін.

Ең қарапайым бейне чат жағдайында бізде екі тректен тұратын бір жергілікті медиа ағыны болады - бейне трек және аудио трек, олардың әрқайсысы бір негізгі арнадан тұрады. Бейне трек камераға жауап береді, аудио трек микрофонға арналған, ал медиа ағыны екеуіне арналған контейнер болып табылады.

Сеанс дескрипторы (SDP)

Әртүрлі компьютерлерде әрқашан әртүрлі камералар, микрофондар, видеокарталар және басқа жабдықтар болады. Олардың көптеген нұсқалары бар. Мұның барлығы екі желі түйіні арасында деректерді медиа тасымалдау үшін үйлестірілуі керек. WebRTCавтоматты түрде жасайды және жасайды арнайы объект– сеанс дескрипторы SDP. Бұл нысанды басқа түйінге жіберіңіз және медиа деректерін тасымалдауға болады. Тек басқа түйінмен байланыс әлі жоқ.

Ол үшін кез келген сигналдық механизм қолданылады. SDPрозеткалар арқылы да, адам арқылы да (басқа түйінге телефон арқылы айтыңыз), немесе орыс поштасы арқылы берілуі мүмкін. Бұл өте қарапайым - олар сізге дайын нәрсені береді SDPжәне оны жіберу керек. Ал екінші жағынан алған соң – бөлімге ауысады WebRTC. Сеанс дескрипторы мәтін ретінде сақталады және оны қолданбаларыңызда өзгертуге болады, бірақ бұл әдетте қажет емес. Мысал ретінде, жұмыс үстелі ↔ телефонды қосқанда, кейде қажетті аудио кодектерді таңдауға мәжбүрлеу керек.

Әдетте, қосылымды орнату кезінде, мысалы, мекенжайдың қандай да бір түрін көрсету керек URL. Мұнда мұның қажеті жоқ, өйткені сигнал беру механизмі арқылы сіз деректерді тағайындалған жерге өзіңіз жібересіз. Белгілеу үшін WebRTCне орнатқымыз келеді p2pқосылым үшін createOffer функциясын шақыру керек. Бұл функцияны шақырғаннан кейін және оған арнайы қайта телефон соғу'а құрылады SDPобъектісіне ауыстырылады қайта телефон соғу. Сізден талап етілетін нәрсе - бұл нысанды желі арқылы басқа түйінге (әңгімелесушіге) беру. Осыдан кейін деректер сигнал беру механизмі арқылы екінші жағынан келеді, атап айтқанда бұл SDPобъект. Бұл сеанс дескрипторы осы түйінге бөтен болып табылады, сондықтан пайдалы ақпаратты тасымалдайды. Бұл нысанды қабылдау қосылымды бастау сигналы болып табылады. Сондықтан сіз бұған келісіп, createAnswer функциясын шақыруыңыз керек. Бұл createOffer толық аналогы. Өзіңізге оралу қайта телефон соғужергілікті сеанс дескрипторын жібереді және оны сигнал беру механизмі арқылы кері жіберу қажет болады.

Айта кету керек, createAnswer функциясын басқа біреудің функциясын алғаннан кейін ғана шақыруға болады SDPобъект. Неліктен? Өйткені жергілікті SDP createAnswer шақырылған кезде жасалатын нысан қашықтан басқару құралына сенуі керек SDPобъект. Тек осы жағдайда ғана сіздің бейне параметрлеріңізді әңгімелесушіңіздің параметрлерімен үйлестіруге болады. Сондай-ақ, жергілікті медиа ағынын алмас бұрын createAnswer және createOffer деп атауға болмайды - оларда жазатын ештеңе болмайды. SDPобъект.

бастап WebRTCөңдеуге болады SDPнысан, содан кейін жергілікті тұтқаны алғаннан кейін оны орнату керек. Бұл жеткізу үшін сәл оғаш көрінуі мүмкін WebRTCол бізге не берді, бірақ бұл протокол. Қашықтағы тұтқаны алған кезде оны орнату керек. Сондықтан бір түйінге екі дескрипторды орнату керек - сіздікі және басқа біреудікі (яғни, жергілікті және қашықтағы).

Осыдан кейін қол алысутүйіндер бір-бірінің тілектері туралы біледі. Мысалы, егер түйін 1 кодектерді қолдайды АЖәне Б, және түйін 2 кодектерді қолдайды БЖәне C, содан кейін әрбір түйін өзінің және басқалардың дескрипторларын білетіндіктен, екі түйін де кодекті таңдайды Б(7-сурет). Қосылу логикасы енді орнатылды және медиа ағындарын жіберуге болады, бірақ тағы бір мәселе бар - түйіндер әлі де сигнал беру механизмі арқылы қосылады.

7-сурет: Codec келіссөздері

Мұз кандидаты

Технология WebRTCбізді өзінің жаңа әдістемесімен шатастырғысы келеді. Қосылымды орнату кезінде қосылғыңыз келетін түйіннің мекенжайы көрсетілмейді. Алдымен орнатылды логикалықбайланыс, жоқ физикалық, дегенмен керісінше әрқашан жасалды. Бірақ егер біз үшінші тараптың сигнал беру механизмін қолданып жатқанымызды есте сақтасақ, бұл таңқаларлық болып көрінбейді.

Сонымен, байланыс орнатылды (логикалық байланыс), бірақ желі түйіндері деректерді жібере алатын жол әлі жоқ. Мұның бәрі қарапайым емес, бірақ қарапайым бастайық. Түйіндер бір жеке желіде болсын. Біз білетіндей, олар өздерінің ішкі ерекшеліктеріне сәйкес бір-бірімен оңай байланыса алады IPмекенжайлары (немесе пайдаланылмаса басқа біреуге болуы мүмкін TCP/IP).

Біраздан кейін қайта телефон соғу'Және WebRTCбізге айтады Мұз кандидатынысандар. Олар сондай-ақ мәтіндік пішінде келеді және сеанс дескрипторлары сияқты оларды сигнал беру механизмі арқылы жіберу керек. Сеанс дескрипторында камера мен микрофон деңгейіндегі параметрлеріміз туралы ақпарат болса, үміткерлер желідегі орнымыз туралы ақпаратты қамтиды. Оларды басқа түйінге жіберіңіз, сонда ол бізге физикалық түрде қосыла алады және оның сеанс дескрипторы бар болғандықтан, ол логикалық түрде қосыла алады және деректер «ағынды». Егер ол бізге өзінің кандидаттық нысанын, яғни өзінің желіде қай жерде екендігі туралы ақпаратты жіберуді ұмытпаса, біз онымен байланыса аламыз. Классикалық клиент пен сервер әрекетінен тағы бір айырмашылықты атап өтейік. HTTP серверімен байланыс сұрау-жауап схемасына сәйкес жүзеге асады, клиент деректерді өңдейтін серверге жібереді және оны келесі арқылы жібереді. сұрау пакетінде көрсетілген мекенжай. IN WebRTCбілу керек екі мекенжайжәне оларды екі жағынан қосыңыз.

Сеанс дескрипторларынан айырмашылығы тек қашықтағы кандидаттарды орнату қажет. Мұнда өңдеуге тыйым салынады және ешқандай пайда әкелмейді. Кейбір іске асыруларда WebRTCкандидаттар сеанс дескрипторлары орнатылғаннан кейін ғана орнатылуы керек.

Неліктен бір ғана сеанс дескрипторы болды, бірақ көптеген үміткерлер болуы мүмкін? Өйткені желідегі орынды оның ішкі жағынан ғана анықтауға болмайды IPмекенжайы, сонымен қатар маршрутизатордың сыртқы мекенжайы және міндетті түрде біреуі ғана емес, сонымен қатар мекенжайлар БҰРУсерверлер. Параграфтың қалған бөлігі үміткерлерді егжей-тегжейлі талқылауға және әртүрлі жеке желілерден түйіндерді қосу әдісіне арналады.

Сонымен, екі түйін бір желіде (8-сурет). Оларды қалай анықтауға болады? Көмегімен IPмекенжайлар. Басқа жол жоқ. Рас, сіз әлі де әртүрлі көліктерді пайдалана аласыз ( TCPЖәне UDP) және әртүрлі порттар. Бұл кандидат нысанындағы ақпарат - IP, ПОРТ, КӨЛІКжәне басқасы. Мысалы, қолданайық UDPкөлік және 531 порт.

8-сурет: Екі түйін бір желіде

Сонда біз түйінде болсақ p1, Бұл WebRTCбізге осындай үміткер объектіні береді - . Бұл нақты формат емес, жай диаграмма. Егер біз түйінде болсақ p2, онда кандидат – . Сигнал беру механизмі арқылы p1кандидатты қабылдайды p2(яғни түйіннің орналасуы p2, атап айтқанда оның IPЖәне ПОРТ). Содан кейін p1-мен қосыла алады p2тікелей. Дұрысырақ, p1мекенжайына деректерді жібереді 10.50.150.3:531 жетеді деген үмітпен p2. Мекенжай түйінге тиесілі ме, маңызды емес p2немесе кейбір делдал. Жалғыз маңызды нәрсе - деректер осы мекенжай арқылы жіберіледі және қол жеткізуге болады p2.

Түйіндер бір желіде болғанша, бәрі қарапайым және оңай - әрбір түйінде тек бір ғана үміткер объекті болады (әрқашан өзінің, яғни желідегі орнын білдіреді). Бірақ түйіндер кірген кезде көп үміткерлер болады әртүрліжелілер.

Күрделі іске көшейік. Бір түйін маршрутизатордың артында (дәлірек айтқанда, NAT артында), ал екінші түйін осы маршрутизатормен бір желіде (мысалы, Интернетте) орналасады (9-сурет).

9-сурет: Бір түйін NAT артында, екіншісі жоқ

Бұл жағдайда мәселенің нақты шешімі бар, оны біз қазір қарастырамыз. Үй маршрутизаторыәдетте кестені қамтиды NAT. Бұл маршрутизатордың жеке желісіндегі түйіндерге, мысалы, веб-сайттарға кіруге мүмкіндік беретін арнайы механизм.

Веб-сервер Интернетке тікелей қосылған, яғни жалпыға ортақ деп есептейік IP* мекен-жайы. Бұл түйін болсын p2. Түйін p1(веб-клиент) мекенжайға сұраныс жібереді 10.50.200.10 . Алдымен деректер маршрутизаторға түседі r1, дәлірек айтқанда, оның интерьеринтерфейс 192.168.0.1 . Осыдан кейін маршрутизатор бастапқы мекенжайды (адрес p1) және оны арнайы кестеге енгізеді NAT, содан кейін бастапқы мекенжайды өзіңіздікіне өзгертеді( p1 → r1). Әрі қарай, өз жолыммен сыртқыинтерфейс, маршрутизатор деректерді тікелей веб-серверге жібереді p2. Веб-сервер деректерді өңдейді, жауапты жасайды және оны кері жібереді. Маршрутизаторға жібереді r1, өйткені ол қайтару мекенжайында (маршрутизатор мекенжайды өзінің мекен-жайына ауыстырды). Маршрутизатор деректерді қабылдайды және кестеге қарайды NATжәне деректерді түйінге жібереді p1. Бұл жерде маршрутизатор делдал ретінде әрекет етеді.

Ішкі желідегі бірнеше түйіндер бір уақытта сыртқы желіге кірсе ше? Маршрутизатор жауапты кімге қайтару керектігін қалай түсінеді? Бұл мәселе көмегімен шешіледі порттар. Маршрутизатор хост мекенжайын өзінің мекен-жайымен ауыстырғанда, ол портты да ауыстырады. Егер екі түйін Интернетке кірсе, маршрутизатор өздерінің бастапқы порттарын ауыстырады әртүрлі. Содан кейін веб-серверден пакет маршрутизаторға қайтып келгенде, маршрутизатор пакеттің кімге тағайындалғанын порт арқылы түсінеді. Төмендегі мысал.

Технологияға оралайық WebRTC, дәлірек айтқанда, оның пайдаланатын бөлігіне ICEхаттама (демек Мұзкандидаттар). Түйін p2бір үміткер бар (оның желідегі орны – 10.50.200.10 ) және түйін p1, NAT бар маршрутизатордың артында орналасқан, екі үміткер болады - жергілікті ( 192.168.0.200 ) және маршрутизатор кандидаты ( 10.50.200.5 ). Біріншісі пайдалы емес, бірақ ол соған қарамастан жасалады, өйткені WebRTCқашықтағы түйін туралы әлі ештеңе білмейді - ол бір желіде болуы немесе болмауы мүмкін. Екінші үміткер пайдалы болады және біз білетініміздей, порт маңызды рөл атқарады (өту үшін NAT).

Кестені енгізу NATдеректер ішкі желіден шыққанда ғана жасалады. Сондықтан түйін p1алдымен деректерді және одан кейін ғана түйін деректерін жіберуі керек p2түйініне жете алады p1.

Іс жүзінде екі түйінартта болады NAT. Кестеде жазба жасау үшін NATәрбір маршрутизатордың түйіндері қашықтағы түйінге бірдеңе жіберуі керек, бірақ бұл жолы біріншісі де екіншісіне жете алмайды, не керісінше. Бұл түйіндердің сыртқы жағын білмеуіне байланысты IPмекенжайлар және деректерді ішкі мекенжайларға жіберу мағынасыз.

Дегенмен, егер сыртқы мекенжайлар белгілі болса, байланыс оңай орнатылады. Егер бірінші түйін деректерді екінші түйіннің маршрутизаторына жіберсе, маршрутизатор оны елемейді, өйткені оның кестесі NATәзірге бос. Дегенмен, кестедегі бірінші түйіннің маршрутизаторында NATМаған жазба керек. Егер қазір екінші түйін деректерді бірінші түйіннің маршрутизаторына жіберсе, онда маршрутизатор оны бірінші түйінге сәтті тасымалдайды. Енді үстел NATекінші маршрутизаторға деректер қажет.

Мәселе мынада: сыртқы тану үшін IPмекенжайы үшін сізге орналасқан түйін қажет ортақ желі. Бұл мәселені шешу үшін Интернетке тікелей қосылған қосымша серверлер пайдаланылады. Олардың көмегімен кестедегі құнды жазбалар да жасалады NAT.

STUN және TURN серверлері

Баптандыру кезінде WebRTCбарын көрсету керек ТАҢДАУЖәне БҰРУсерверлер, біз оларды әрі қарай шақырамыз ICEсерверлер. Егер серверлер көрсетілмесе, онда бір желідегі түйіндер ғана (оған NAT). үшін бірден атап өткен жөн 3г- желілерді пайдалану керек БҰРУсерверлер.

ТАҢДАУ сервербұл жай ғана қайтару мекенжайын, яғни жіберушінің түйінінің мекенжайын қайтаратын Интернеттегі сервер. Маршрутизатордың артында орналасқан түйін қол жеткізеді ТАҢДАУөту үшін сервер NAT. Келген пакет ТАҢДАУсерверде бастапқы адрес – маршрутизатор адресі, яғни біздің түйіннің сыртқы мекенжайы бар. Бұл мекенжай ТАҢДАУсерверге жібереді және оны кері жібереді. Осылайша, түйін өзінің сыртқы түрін алады IPжеліден қол жеткізуге болатын мекенжай мен порт. Әрі қарай, WebRTCосы мекенжайды пайдалану қосымша үміткерді жасайды (сыртқы маршрутизатор мекенжайы және порт). Енді кестеде NATМаршрутизаторда қажетті порттағы маршрутизаторға жіберілген пакеттердің біздің түйінге өтуіне мүмкіндік беретін жазба бар.

Бұл процесті мысалмен қарастырайық.

Мысал (STUN серверінің жұмысы)

ТАҢДАУсерверді арқылы белгілейміз s1. Маршрутизатор, бұрынғыдай, арқылы r1, ал түйін – арқылы p1. Сіз сондай-ақ кестені орындауыңыз керек NAT– деп белгілейік r1_nat. Сонымен қатар, бұл кестеде әдетте әртүрлі ішкі желі түйіндерінен көптеген жазбалар бар - олар берілмейді.

Сонымен, басында бізде бос үстел бар r1_nat.

2-кесте: Пакет тақырыбы

Түйін p1бұл пакетті маршрутизаторға жібереді r1(қалай болса да, оларды әртүрлі ішкі желілерде пайдалануға болады әртүрлі технологиялар). Маршрутизатор бастапқы мекенжайды өзгертуі керек Src IP, пакетте көрсетілген мекенжай сыртқы ішкі желіге сәйкес келмейтіндіктен, мұндай ауқымдағы мекенжайлар сақталған және Интернеттегі бірде-бір мекенжайда мұндай мекенжай жоқ; Маршрутизатор пакетте ауыстыруды жасайды және жасайды жаңа жазбасіздің үстеліңізде r1_nat. Ол үшін порт нөмірін ойлап табу керек. Еске салайық, ішкі желідегі бірнеше түйіндер сыртқы желіге, содан кейін кестеге кіре алады NATсақталуы керек қосымша ақпарат, осылайша маршрутизатор осы бірнеше түйіндердің қайсысы серверден қайтару пакеті үшін тағайындалғанын анықтай алады. Маршрутизатор портты ойлап тапсын 888 .

Өзгертілген пакет тақырыбы:

4-кесте: NAT кестесі жаңа жазбамен жаңартылды

Мұнда IPішкі желі мекенжайы мен порты бастапқы пакетпен бірдей. Шын мәнінде, постбэкинг кезінде бізде оларды толығымен қалпына келтірудің жолы болуы керек. IPсыртқы желінің мекенжайы маршрутизатордың мекенжайы болып табылады, ал порт маршрутизатор ойлап тапқанға өзгерді.

Түйін баратын нақты порт p1байланысты қабылдайды - бұл, әрине, 35777 , бірақ сервер деректерді жібереді ойдан шығарылғанпорт 888 , оны маршрутизатор нақтыға өзгертеді 35777 .

Осылайша, маршрутизатор пакет тақырыбындағы бастапқы мекенжай мен портты ауыстырып, кестеге жазба қосты NAT. Енді пакет желі арқылы серверге, яғни түйінге жіберіледі s1. Кіре берісте, s1мына пакет бар:

Src IP	Src PORT	Мақсатты IP	Тағайындалған порт
10.50.200.5	888	12.62.100.200	6000

5-кесте: STUN сервер пакетін қабылдады

Барлығы ТАҢДАУсервер адрестен пакетті алғанын біледі 10.50.200.5:888 . Енді сервер бұл мекенжайды кері жібереді. Осы жерде тоқтап, жаңа ғана қарастырғанымызға тағы бір көз жүгірткен жөн. Жоғарыдағы кестелер үзінді тақырыбыпакет, одан мүлде емес мазмұны. Біз оның мазмұны туралы айтқан жоқпыз, өйткені ол соншалықты маңызды емес - ол қандай да бір түрде хаттамада сипатталған ТАҢДАУ. Енді біз тақырыпқа қосымша мазмұнды қарастырамыз. Бұл қарапайым болады және маршрутизатордың мекенжайын қамтиды - 10.50.200.5:888 , дегенмен біз оны алдық тақырыбыпакет. Бұл жиі жасалмайды, хаттамалар, әдетте, түйін мекенжайлары туралы ақпаратқа мән бермейді; Мұнда біз екі түйін арасындағы жолды белгілейтін хаттаманы қарастырамыз.

Енді бізде қарама-қарсы бағытта жүретін екінші пакет бар:

7-кесте: STUN сервері осы мазмұнмен пакетті жібереді

Содан кейін пакет маршрутизатордың сыртқы интерфейсіне жеткенше желі бойынша жүреді r1. Маршрутизатор пакеттің оған арналмағанын түсінеді. Ол мұны қалай түсінеді? Мұны тек порт арқылы анықтауға болады. Порт 888 ол оны өзінің жеке мақсатына емес, механизмге пайдаланады NAT. Сондықтан маршрутизатор осы кестеге қарайды. Бағанға қарайды Сыртқы портжәне сәйкес келетін жолды іздейді Тағайындалған порткіріс пакетінен, яғни 888 .

Ішкі IP	Ішкі порт	Сыртқы IP	Сыртқы порт
192.168.0.200	35777	10.50.200.5	888

8-кесте: NAT кестесі

Біз бақыттымыз, мұндай сызық бар. Егер сәтіміз болмаса, пакет жай ғана жойылар еді. Енді осы пакетті ішкі желідегі қай түйін жіберу керектігін түсінуіңіз керек. Асықпаудың қажеті жоқ, осы механизмдегі порттардың маңыздылығын тағы да еске түсірейік. Бұл ретте ішкі желідегі екі түйін сыртқы желіге сұраныс жібере алады. Содан кейін, егер бірінші түйін үшін маршрутизатор портты ойлап тапса 888 , содан кейін ол екінші портты ойлап тапты 889 . Бұл болды деп есептейік, яғни кесте r1_natбылай көрінеді:

10-кесте: Маршрутизатор ресивер мекенжайын ауыстырады

Src IP	Src PORT	Мақсатты IP	Тағайындалған порт
12.62.100.200	6000	192.168.0.200	35777

11-кесте: Маршрутизатор ресивер мекенжайын өзгертті

Пакет түйінге сәтті келді p1және пакеттің мазмұнын қарау арқылы түйін оның сыртқы туралы біледі IPадресі, яғни сыртқы желідегі маршрутизатордың мекенжайы. Ол сонымен қатар маршрутизатор өтетін портты біледі NAT.

Келесі не? Мұның бәрінен не пайда? Пайда - кестедегі жазба r1_nat. Егер қазір біреу маршрутизаторға жіберсе r1порты бар пакет 888 , содан кейін маршрутизатор бұл пакетті түйінге жібереді p1. Осылайша, жасырын түйінге шағын тар жол құрылды p1.

Жоғарыдағы мысалдан сіз оның қалай жұмыс істейтіні туралы түсінік ала аласыз NATжәне мәні ТАҢДАУсервер. Жалпы, механизм ICEЖәне ТАҢДАУ/БҰРЫЛУсерверлер дәл шектеулерді еңсеруге бағытталған NAT.

Түйін мен сервер арасында бір маршрутизатор емес, бірнеше болуы мүмкін. Бұл жағдайда түйін сервермен бір желіге бірінші болып кіретін маршрутизатордың мекенжайын алады. Басқаша айтқанда, біз қосылған маршрутизатордың мекенжайын аламыз ТАҢДАУсервер. Үшін p2pбайланыс - бұл бізге қажет нәрсе, егер әрбір маршрутизатор кестеге қажетті жолды қосатынын ұмытпасақ NAT. Сондықтан кері қайтар жолы да дәл солай тегіс болады.

БҰРУсервер жетілдірілді ТАҢДАУсервер. Осы жерден кез келген екенін бірден білу керек БҰРУсервер жұмыс істей алады және қалай ТАҢДАУсервер. Дегенмен, артықшылықтары да бар. Егер p2pбайланыс мүмкін емес (мысалы 3гжелілер), содан кейін сервер қайталағыш режиміне ауысады ( реле), яғни делдал ретінде жұмыс істейді. Әрине, ештеңе туралы p2pонда мәселе жоқ, бірақ механизм шеңберінен тыс ICEтүйіндер тікелей байланысады деп ойлайды.

Қандай жағдайларда қажет БҰРУсервер? Неге жетпейді ТАҢДАУсерверлер? Өйткені, оның бірнеше сорттары бар NAT. Олар бірдей ауыстырады IPмекен-жайы мен порты, бірақ олардың кейбіреулерінде «жалған жасаудан» қосымша қорғаныс бар. Мысалы, в симметриялыкесте NATТағы 2 параметр сақталады - IPжәне қашықтағы түйіннің порты. Сыртқы желіден пакет өтеді NATбастапқы мекенжай мен порт кестеде жазылғандарға сәйкес келсе ғана ішкі желіге. Сондықтан, назар ТАҢДАУсервер сәтсіз аяқталды - кесте NATмекенжай мен портты сақтайды ТАҢДАУсервер және маршрутизатор пакетті қашан қабылдайды WebRTCәңгімелесуші, ол оны «жалған» болғандықтан тастайды. Ол келген жоқ ТАҢДАУсервер.

Осылайша БҰРУекі сұхбаттасушы да орналасқан кезде сервер қажет симметриялы NAT(әрқайсысы өзінше).

Қысқаша қорытынды

Мұнда нысандар туралы кейбір мәлімдемелер берілген WebRTCәрқашан есте ұстау керек. Олар жоғарыда егжей-тегжейлі сипатталған. Егер мәлімдемелердің кез келгені сізге толық түсініксіз болып көрінсе, тиісті абзацтарды қайта оқып шығыңыз.

• Медиа ағыны
  • Бейне және аудио деректері медиа ағындарына бумаланады
  • Мультимедиа ағындары құрайтын медиа тректерді синхрондайды
  • Әртүрлі медиа ағындары бір-бірімен синхрондалмаған
  • Медиа ағындары жергілікті және қашықтағы болуы мүмкін, жергілікті әдетте камера мен микрофонға қосылады, қашықтағылар желіден деректерді шифрланған түрде алады.
  • Медиа тректердің екі түрі бар - бейне және аудио үшін.
  • Медиа тректердің қосу/өшіру мүмкіндігі бар
  • Медиа тректер медиа арналардан тұрады
  • Медиа тректер құрайтын медиа арналарды синхрондайды
  • Медиа ағындары мен медиа тректерінде оларды ажыратуға болатын белгілер бар
• Сеанс дескрипторы
  • Сеанс дескрипторы екі желі түйінін логикалық қосу үшін қолданылады
  • Сеанс дескрипторы туралы ақпаратты сақтайды қолжетімді жолдарбейне және аудио деректерді кодтау
  • WebRTCсыртқы сигнал беру механизмін пайдаланады - сеанс дескрипторларын жіберу тапсырмасы ( sdp) қолданбаға түседі
  • Логикалық байланыс механизмі екі кезеңнен – сөйлемдерден ( ұсыныс) және жауап беру ( жауап)
  • Ұсыныс болған жағдайда жергілікті медиа ағынын қолданбай сеанс дескрипторын құру мүмкін емес ( ұсыныс) және жауап болған жағдайда қашықтағы сеанс дескрипторын қолданбай мүмкін емес ( жауап)
  • Алынған дескриптор іске асыруға берілуі керек WebRTC, және бұл дескриптордың қашықтан немесе бірдей іске асырудан жергілікті түрде алынғаны маңызды емес WebRTC
  • Сеанс дескрипторын аздап өңдеуге болады
• Үміткерлер
  • кандидат ( Мұз кандидаты) – желідегі түйіннің адресі
  • Түйін мекенжайы сіздің жеке болуы мүмкін немесе ол маршрутизатордың немесе мекенжайы болуы мүмкін БҰРУсерверлер
  • Үміткерлер әрқашан көп
  • Кандидат мыналардан тұрады IPмекенжайы, порты және көлік түрі ( TCPнемесе UDP)
  • Үміткерлер желідегі екі түйін арасында физикалық байланыс орнату үшін пайдаланылады
  • Үміткерлерді сигнал беру механизмі арқылы жіберу керек
  • Үміткерлерді іске асыруға да ауыстыру қажет WebRTC, дегенмен тек қашықтан
  • Кейбір іске асыруларда WebRTCкандидаттарды сеанс дескрипторы орнатылғаннан кейін ғана жіберуге болады
• ТАҢ/БҰРЫЛУ/МҰЗ/НАТ
  • NAT– сыртқы желіге кіруді қамтамасыз ету механизмі
  • Үй маршрутизаторлары арнайы кестені қолдайды NAT
  • Маршрутизатор пакеттердегі адрестерді ауыстырады - бастапқы мекенжайды, егер пакет сыртқы желіге өтсе, және тағайындалған мекенжайды ішкі желідегі хост мекенжайымен, егер пакет сыртқы желіден келсе
  • Сыртқы желіге көп арналы қатынасты қамтамасыз ету NATпорттарды пайдаланады
  • ICE– айналып өту механизмі NAT
  • ТАҢДАУЖәне БҰРУсерверлер – айналып өтуге арналған көмекші серверлер NAT
  • ТАҢДАУсервер кестеде қажетті жазбаларды жасауға мүмкіндік береді NAT, сонымен қатар түйіннің сыртқы мекенжайын қайтарады
  • БҰРУсервер жалпылайды ТАҢДАУмеханизмі және оны үнемі жұмыс істеуге мүмкіндік береді
  • Ең нашар жағдайларда БҰРУсервер делдал ретінде пайдаланылады ( реле), яғни p2pклиент-сервер-клиент байланысына айналады.

WebRTC (Web Real Time Communications) – плагиндерді немесе басқа кеңейтімдерді орнатусыз нақты уақыт режимінде ағындық аудио деректерін, бейне деректерін және мазмұнды шолғыштан және браузерге жіберуді сипаттайтын стандарт. Стандарт браузерді бейнеконференцбайланыс терминалына айналдыруға мүмкіндік береді, тек байланыс орнату үшін веб-бетті ашу керек;

WebRTC дегеніміз не?

Бұл мақалада біз WebRTC технологиясы туралы білуіңіз керек барлық нәрсені қарастырамыз тұрақты қолданушы. Жобаның артықшылықтары мен кемшіліктерін қарастырайық, кейбір құпияларды ашайық, оның қалай жұмыс істейтінін, WebRTC қайда және не үшін қолданылатынын айтайық.

WebRTC туралы не білуіңіз керек?

Бейне байланыс стандарттары мен технологияларының эволюциясы

Сергей Ютсайтис, Cisco, Бейне+конференция 2016

WebRTC қалай жұмыс істейді

Клиент жағы

• Пайдаланушы HTML5 тегін қамтитын бетті ашады
• Браузер пайдаланушының веб-камерасына және микрофонына кіруді сұрайды.
• Пайдаланушы бетіндегі JavaScript коды NAT және желіаралық қалқанды айналып өту үшін қосылым параметрлерін (IP мекенжайлары мен WebRTC серверінің порттары немесе басқа WebRTC клиенттері) басқарады.
• Серверде араласқан конференциядан сұхбаттасушы туралы немесе ағын туралы ақпаратты алған кезде браузер пайдаланылатын аудио және бейне кодектерімен келіссөздер жүргізе бастайды.
• Кодтау процесі басталады және WebRTC клиенттері арасында (біздің жағдайда, браузер мен сервер арасында) ағындық деректерді тасымалдау басталады.

WebRTC сервер жағында

Екі қатысушы арасында деректер алмасу үшін бейне сервер қажет емес, бірақ бір конференцияда бірнеше қатысушыны біріктіру қажет болса, сервер қажет.

Бейне сервер әртүрлі көздерден медиа трафигін қабылдайды, оны түрлендіреді және оны WebRTC терминал ретінде пайдаланатын пайдаланушыларға жібереді.

Сондай-ақ, WebRTC сервері WebRTC әріптестерінен медиа трафигін алады және оны қолданбаларды пайдаланатын конференция қатысушыларына жібереді. жұмыс үстелі компьютерлерінемесе мобильді құрылғылар, бар болса.

Стандарттың артықшылықтары

• Бағдарламалық құралды орнату қажет емес.
• Байланыстың өте жоғары сапасы, соның арқасында:
  • Қазіргі бейнені (VP8, H.264) және аудио кодектерді (Opus) пайдалану.
  • Ағын сапасын қосылу жағдайларына автоматты түрде реттеу.
  • Кірістірілген жаңғырық пен шуды азайту жүйесі.
  • Қатысушы микрофондарының (AGC) сезімталдық деңгейін автоматты түрде реттеу.
• Қауіпсіздіктің жоғары деңгейі: барлық қосылымдар TLS және SRTP хаттамалары арқылы қорғалған және шифрланған.
• Мазмұнды түсірудің кірістірілген механизмі бар, мысалы, жұмыс үстелі.
• HTML5 және JavaScript негізіндегі кез келген басқару интерфейсін енгізу мүмкіндігі.
• WebSockets көмегімен интерфейсті кез келген серверлік жүйелермен біріктіру мүмкіндігі.
• Ашық жоба бастапқы код— өніміңізге немесе қызметіңізге енгізуге болады.
• Шынайы кросс-платформа: бірдей WebRTC қолданбасы кез келгенінде бірдей жақсы жұмыс істейді операциялық жүйе, жұмыс үстелі немесе мобильді, браузер WebRTC қолдайтын жағдайда. Бұл бағдарламалық жасақтаманы әзірлеуде ресурстарды айтарлықтай үнемдейді.

Стандарттың кемшіліктері

• Топтық аудио және бейне конференцияларды ұйымдастыру үшін қатысушылардың бейнелері мен дыбыстарын араластыратын бейнеконференция сервері қажет, өйткені Браузер бірнеше кіріс ағындарын бір-бірімен синхрондауды білмейді.
• Барлық WebRTC шешімдері бір-бірімен үйлеспейді, себебі... стандарт тек бейне және дыбысты беру әдістерін сипаттайды, жазылушыларға жүгіну әдістерін іске асыруды, олардың қолжетімділігін қадағалауды, хабарламалар мен файлдармен алмасуды, жоспарлауды және басқаларды жеткізушіге қалдырады.
• Басқаша айтқанда, бір әзірлеушінің WebRTC қолданбасынан басқа әзірлеушінің WebRTC қолданбасына қоңырау шала алмайсыз.
• Топтық конференцияларды араластыру үлкен есептеу ресурстарын қажет етеді, сондықтан бейнебайланыстың бұл түрі ақылы жазылымды сатып алуды немесе әр конференцияға заманауи процессордың 1 физикалық ядросын қажет ететін инфрақұрылымға инвестиция салуды талап етеді.

WebRTC құпиялары: Жеткізушілер жаңа веб-технологиядан қалай пайда көреді

Цачи Левент-Леви, Bloggeek.me, Бейне+конференция 2015

Бейнеконференция нарығына арналған WebRTC

Бейнеконференция терминалдарының санын көбейту

WebRTC технологиясы бейнеконференциялар нарығының дамуына қатты әсер етті. 2013 жылы WebRTC қолдауы бар алғашқы браузерлер шыққаннан кейін бүкіл әлем бойынша бейнеконференция терминалдарының әлеуетті саны бірден 1 миллиард құрылғыға өсті. Шын мәнінде, әрбір браузер байланыс сапасы бойынша аппараттық аналогтарынан кем түспейтін бейнеконференцбайланыс терминалына айналды.

Арнайы шешімдерде қолданыңыз

WebRTC қолдауымен әртүрлі JavaScript кітапханаларын және бұлттық қызмет API интерфейстерін пайдалану кез келген веб-жобаларға бейне байланыс қолдауын қосуды жеңілдетеді. Бұрын нақты уақыт режимінде деректерді беру үшін әзірлеушілерге хаттаманың жұмыс істеу принциптерін зерделеу және басқа компаниялардың әзірлемелерін пайдалану қажет болды, бұл көбінесе қосымша лицензиялауды талап етеді, бұл шығындарды арттырады. WebRTC қазірдің өзінде «Сайттан қоңырау шалу», «Онлайн чатты қолдау» және т.б. қызметтерде белсенді түрде қолданылады.

Linux үшін Skype бағдарламасының бұрынғы пайдаланушылары

2014 жылы Microsoft корпорациясы IT мамандарының үлкен тітіркенуін тудырған Skype for Linux жобасын қолдауды аяқтайтынын хабарлады. WebRTC технологиясы операциялық жүйеге байланысты емес, бірақ браузер деңгейінде жүзеге асырылады, яғни. Linux пайдаланушылары Skype үшін толыққанды ауыстыру ретінде WebRTC негізіндегі өнімдер мен қызметтерді көре алады.

Flash бағдарламасымен жарыс

WebRTC және HTML5 ең нашар жылдарын бастан өткеріп жатқан Flash технологиясына ауыр соққы болды. 2017 жылдан бастап жетекші браузерлер Flash-ті қолдауды ресми түрде тоқтатты және технология нарықтан мүлдем жоғалып кетті. Бірақ біз Flash-қа өз құқығын беруіміз керек, өйткені ол веб-конференция нарығын құрып, ұсынған техникалық мүмкіндіктербраузерлерде тікелей байланыс үшін.

WebRTC бейне презентациялары

Дмитрий Одинцов, TrueConf, Бейне+конференция қазан 2017 ж

WebRTC жүйесіндегі кодектер

Аудио кодектер

WebRTC аудио трафигін қысу үшін Opus және G.711 кодектерін пайдаланады.

G.711- дәстүрлі телефония жүйелерінде жиі қолданылатын жоғары бит жылдамдығы (64 кбит) бар ең көне дауыстық кодек. Негізгі артықшылығы - жеңіл қысу алгоритмдерін қолдану есебінен ең аз есептеу жүктемесі. Кодек дауыстық сигналдарды қысудың төмен деңгейіне ие және пайдаланушылар арасындағы байланыс кезінде қосымша аудио кідірістерін енгізбейді.

G.711 көптеген құрылғылармен қолдау көрсетеді. Басқа аудио кодектерге (G.723, G.726, G.728, т.б.) негізделген жүйелерге қарағанда, осы кодекті пайдаланатын жүйелерді пайдалану оңайырақ. Сапа бойынша G.711 MOS тестілеуінде 4,2 балл алды (4-5 арасындағы балл ең жоғары және білдіреді жақсы сапа, ISDN ішіндегі дауыстық трафикті беру сапасына ұқсас және одан да жоғары).

Опускодтау кідірісі төмен (2,5 мс-тен 60 мс-ге дейін), айнымалы бит жылдамдығын қолдауы және жоғары сығу деңгейлері бар кодек, ол айнымалы мәндері бар желілерде ағындық аудио сигналдарды беру үшін өте қолайлы. өткізу қабілеті. Opus — SILK (дауысты қысу, адам сөйлеуінің бұрмалануын жою) және CELT (аудио деректерін кодтау) кодектерінің ең жақсы сипаттамаларын біріктіретін гибридті шешім. Кодек еркін қол жетімді, оны пайдаланатын әзірлеушілер авторлық құқық иелеріне роялти төлеудің қажеті жоқ. Басқа аудио кодектермен салыстырғанда, Opus сөзсіз көп жағынан жеңеді. Ол MP3, Vorbis, AAC LC сияқты өте танымал төмен жылдамдықты кодектерді басып озды. Opus дыбыс «суретін» AMR-WB және Speex-ке қарағанда түпнұсқаға жақынырақ қалпына келтіреді. Бұл кодек болашақ болып табылады, сондықтан WebRTC технологиясын жасаушылар оны қолдау көрсетілетін аудио стандарттарының міндетті ауқымына енгізді.

Бейне кодектер

WebRTC үшін бейне кодектерді таңдау мәселелері әзірлеушілерге бірнеше жыл қажет болды және соңында олар H.264 және VP8 пайдалануды шешті. Барлық дерлік заманауи браузерлер екі кодектерді де қолдайды. WebRTC-пен жұмыс істеу үшін бейнеконференция серверлері тек біреуін қолдауы керек.

VP8- ашық лицензиясы бар тегін бейне кодек, жоғары бейне ағынының декодтау жылдамдығымен және кадрдың жоғалуына төзімділіктің жоғарылауымен сипатталады. Кодек әмбебап және аппараттық платформаларға енгізу оңай, сондықтан бейнеконференция жүйелерін әзірлеушілер оны өз өнімдерінде жиі пайдаланады.

Ақылы бейне кодек H.264ағасынан әлдеқайда ерте танымал болды. Бұл сақтау кезінде бейне ағынын сығудың жоғары дәрежесі бар кодек Жоғары сапабейне. Аппараттық бейнеконференцбайланыс жүйелері арасында бұл кодектің жоғары таралуы оны WebRTC стандартында пайдалануды болжайды.

Google және Mozilla VP8 кодегін белсенді түрде алға жылжытуда, ал Microsoft, Apple және Cisco H.264 (дәстүрлі бейнеконференция жүйелерімен үйлесімділікті қамтамасыз ету үшін) белсенді түрде алға жылжытуда. Бұл жерде WebRTC бұлтты шешімдерін әзірлеушілер үшін өте үлкен мәселе туындайды, өйткені конференцияға қатысушылардың барлығы бірдей браузерді пайдаланса, конференцияны бір кодекпен бір рет араластыру жеткілікті, ал браузерлер әртүрлі болса және Safari/Edge олардың арасында, содан кейін конференция екі еселенген әртүрлі кодектерді кодтауға тура келеді жүйелік талаптармедиа серверге және соның нәтижесінде WebRTC қызметтеріне жазылу құны.

WebRTC API

WebRTC технологиясы үш негізгі API интерфейсіне негізделген:

• (камералардан немесе пайдаланушының жұмыс үстелінен аудио және бейне сигналдарын алатын веб-шолғышқа жауап береді).
• RTCPeerConnection(камерадан, микрофоннан және жұмыс үстелінен алынған медиа деректерін «алмасу» үшін браузерлер арасындағы байланысқа жауап береді. Сондай-ақ, осы API «міндеттеріне» сигналды өңдеу (оны бөгде шудан тазалау, микрофонның дыбыс деңгейін реттеу) және бақылау кіреді. пайдаланылатын аудио және бейне кодектер).
• RTCData арнасы(белгіленген қосылым арқылы екі жақты деректерді беруді қамтамасыз етеді).

Пайдаланушының микрофоны мен камерасына қол жеткізбес бұрын браузер рұқсат сұрайды. IN Google Chrome Opera және Firefox-тың «Параметрлер» бөлімінде қол жеткізуді алдын ала конфигурациялауға болады, құрылғылар қол жеткізу кезінде ашылмалы тізімнен таңдалады; Рұқсат сұрауы HTTP протоколын пайдаланған кезде әрқашан және HTTPS пайдаланылған кезде бір рет пайда болады:

RTCPeerConnection. WebRTC конференциясына қатысатын әрбір браузерде рұқсат болуы керек бұл нысан. RTCPeerConnection пайдаланудың арқасында бір браузерден екіншісіне медиа деректері тіпті NAT және брандмауэрлер. Медиа ағындарын сәтті жіберу үшін қатысушылар веб-розеткалар сияқты тасымалдау арқылы келесі деректерді алмасуы керек:

• бастамашы қатысушы екінші қатысушыға Offer-SDP (ол жіберетін медиа ағынының сипаттамалары бар деректер құрылымы) жібереді;
• екінші қатысушы «жауапты» жасайды - Answer-SDP және оны бастамашыға жібереді;
• содан кейін қатысушылар арасында ICE кандидаттарымен алмасу ұйымдастырылады, егер олар анықталса (қатысушылар NAT немесе желіаралық қалқандардың артында болса).

Осы алмасу сәтті аяқталғаннан кейін қатысушылар арасында медиа ағындарын (аудио және бейне) тікелей тасымалдау ұйымдастырылады.

RTCData арнасы. Data Channel протоколын қолдау браузерлерде салыстырмалы түрде жақында пайда болды, сондықтан бұл API браузерлерде WebRTC пайдаланылған жағдайда ғана қарастырылуы мүмкін. Mozilla Firefox 22+ және Google Chrome 26+. Оның көмегімен қатысушылар алмаса алады мәтіндік хабарларбраузерде.

WebRTC арқылы қосылу

Қолдау көрсетілетін жұмыс үстелі браузерлері

• Google Chrome (17+) және Chromium қозғалтқышына негізделген барлық браузерлер;
• Mozilla FireFox (18+);
• Опера (12+);
• Safari (11+);

Android үшін қолдау көрсетілетін мобильді браузерлер

• Google Chrome (28+);
• Mozilla Firefox (24+);
• Opera Mobile (12+);
• Сафари (11+).

WebRTC, Microsoft және Internet Explorer

Microsoft өте ұзақ уақыт бойы Internet Explorer шолғышындағы WebRTC қолдауы және оның жаңа Edge браузері туралы үнсіз қалды. Редмондтық жігіттер өздері басқармайтын технологияларды пайдаланушылардың қолына беруді ұнатпайды, бұл саясат. Бірақ бірте-бірте мәселе өлі нүктеден қозғалды, өйткені... Енді WebRTC-ті елемеу мүмкін болмады және WebRTC стандартының туындысы болып табылатын ORTC жобасы жарияланды.

Әзірлеушілердің пікірінше, ORTC - JavaScript және HTML5 негізіндегі API интерфейстерінің жетілдірілген жиынтығы бар WebRTC стандартының кеңейтімі, ол кәдімгі тілге аударғанда бәрі бұрынғыдай болады, стандартты Google емес, Microsoft ғана басқарады. және оның дамуы. Кодектер жиынтығы H.264 және телефония және аппараттық бейнеконференция жүйелерінде қолданылатын G.7ХХ сериясының кейбір аудио кодектерін қолдау арқылы кеңейтілді. RDP (мазмұнды тасымалдау үшін) және хабар алмасу үшін кірістірілген қолдау болуы мүмкін. Айтпақшы, Internet Explorer пайдаланушыларының жолы болмады; ORTC қолдауы тек Edge-де қолжетімді болады. Және, әрине, хаттамалар мен кодектер жиынтығы Skype for Business бағдарламасымен оңай интерфейске түседі, бұл WebRTC үшін одан да көп іскери қолданбаларды ашады.

Бұл мақаланың мақсаты – құрылымымен және жұмыс принципімен танысу үшін тең дәрежелі бейне чаттың (p2p бейне чат) демо үлгісін пайдалану. Осы мақсатта біз webrtc.io-demo демо-пайдаланушылы бейне чатты қолданамыз. Оны мына сілтемеден жүктеп алуға болады: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

Айта кету керек, GitHub - бұл веб-жобаларды бірлесіп әзірлеуге арналған сайт немесе веб-сервис. Онда әзірлеушілер өз әзірлемелерінің кодтарын орналастыра алады, оларды талқылап, бір-бірімен байланыса алады. Сонымен қатар, кейбір ірі IT-компаниялар өздерінің ресми репозиторийлерін осы сайтта орналастырады. Ашық бастапқы жобалар үшін қызмет тегін. GitHub – ашық, тегін бастапқы кітапханаларға арналған репозиторий.

Сонымен, біз C дискісінде GitHub-тен жүктеп алынған тең-теңімен бейне чаттың демонстрациялық үлгісін орналастырамыз. Дербес компьютер"webrtc_demo" қолданбасы үшін жасалған каталогта.

Күріш. 1

Құрылымнан (1-сурет) көрінетіндей, тең дәрежелі бейне сұхбат JavaScript бағдарламалау тілінде жүзеге асырылған клиент script.js және server server.js сценарийлерінен тұрады. Сценарий (кітапхана) webrtc.io.js (КЛИЕНТ) – тең дәрежелі схеманы пайдалана отырып, браузерлер арасында нақты уақыттағы байланысты ұйымдастыруды қамтамасыз етеді: «клиент-клиент», және webrtc.io.js (CLIENT) және webrtc. io.js (СЕРВЕР), WebSocket протоколын пайдалана отырып, олар клиент-сервер архитектурасын пайдаланып браузер мен веб-сервер арасында дуплексті байланысты қамтамасыз етеді.

webrtc.io.js (SERVER) сценарийі webrtc.io кітапханасына кіреді және node_modules\webrtc.io\lib каталогында орналасқан. Бейне сұхбат интерфейсі index.html HTML5 және CSS3-те жүзеге асырылады. webrtc_demo қолданбасының файлдарының мазмұнын html редакторларының бірі арқылы көруге болады, мысалы, "Блокнот++".

Біз бейне чаттың жұмыс принципін тексереміз файлдық жүйеДК. Компьютерде серверді (server.js) іске қосу үшін node.js орындалу ортасын орнату қажет. Node.js браузерден тыс JavaScript кодын іске қосуға мүмкіндік береді. Сіз node.js файлын мына сілтемеден жүктей аласыз: http://nodejs.org/ (07/15/13 жағдайындағы v0.10.13 нұсқасы). node.org веб-сайтының басты бетінде жүктеу түймесін басып, http://nodejs.org/download/ сайтына өтіңіз. Windows пайдаланушылары үшін алдымен win.installer (.msi) жүктеп алыңыз, содан кейін компьютерде win.installer (.msi) бағдарламасын іске қосыңыз және Бағдарлама файлдары каталогында nodejs және "npm бума менеджерін" орнатыңыз.

Күріш. 2

Осылайша, node.js JavaScript кодын әзірлеуге және іске қосуға арналған ортадан, сондай-ақ менеджер немесе npm пакет менеджері арқылы орнатуға болатын ішкі модульдер жинағынан тұрады.

Модульдерді орнату үшін сізге қажет пәрмен жолыҚолданбалар каталогынан (мысалы, «webrtc_demo») пәрменді іске қосыңыз: npm орнату module_name. Модульдерді орнату кезінде npm менеджері орнату орындалған каталогта node_modules қалтасын жасайды. Жұмыс барысында nodejs модульдерді node_modules каталогынан автоматты түрде қосады.

Сонымен, node.js орнатқаннан кейін пәрмен жолын ашыңыз және npm бума менеджерін пайдаланып webrtc_demo каталогының node_modules қалтасындағы экспресс модульді жаңартыңыз:

C:\webrtc_demo>npm орнату экспресс

Экспресс модулі node.js үшін веб-рамка немесе қолданбаларды әзірлеуге арналған веб-платформа болып табылады. Экспресске жаһандық қол жеткізу үшін оны келесідей орнатуға болады: npm орнату -g экспресс.

Содан кейін webrtc.io модулін жаңартыңыз:

C:\webrtc_demo>npm webrtc.io орнатыңыз

Содан кейін пәрмен жолында серверді іске қосамыз: server.js:

C:\webrtc_demo>түйін server.js

Күріш. 3

Міне, сервер сәтті жұмыс істеуде (3-сурет). Енді веб-шолғышты пайдаланып серверге IP мекенжайы бойынша хабарласып, index.html веб-бетін жүктей аласыз, одан веб-шолғыш клиенттің сценарий кодын - script.js және webrtc.io.js сценарий кодын шығарып алады және оларды орындаңыз. Тең-теңімен бейне чатты басқару үшін (екі браузер арасында байланыс орнату үшін) webrtc қолдайтын екі шолғыштың node.js жүйесінде жұмыс істейтін сигнал серверіне хабарласу керек.

Нәтижесінде байланыс қосымшасының клиент бөлігінің интерфейсі (бейне чат) камера мен микрофонға кіруге рұқсат сұрауымен ашылады (4-сурет).

Күріш. 4

«Рұқсат ету» түймесін басқаннан кейін мультимедиялық байланыс үшін камера мен микрофон қосылады. Сонымен қатар, мәтіндік деректер арқылы бейне чат интерфейсі арқылы байланысуға болады (Cурет 5).

Күріш. 5

Айта кету керек. Сервер сигналдық сервер болып табылады және негізінен пайдаланушы браузерлері арасында байланыс орнатуға арналған. Node.js WebRTC сигналын қамтамасыз ететін server.js сервер сценарийін басқару үшін пайдаланылады.