Материалдың көп бөлігі 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)

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

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

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

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

Медиа ағыны кем дегенде деректерді қамту мүмкіндігін қамтуы керек екені бірден түсінікті әртүрлі түрлері- бейне және аудио. Бұл технологияда ескеріледі, сондықтан деректердің әрбір түрі медиа трек арқылы жүзеге асырылады. медиа трек. Медиа тректің ерекше қасиеті бар мейірімді, ол біздің алдымызда не екенін анықтайды - бейне немесе аудио (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 серверімен байланыс сұрау-жауап схемасына сәйкес жүзеге асады, клиент деректерді өңдейтін серверге жібереді және оны келесі арқылы жібереді. сұрау пакетінде көрсетілген мекенжай. AT 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мына пакет бар:

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

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

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

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

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

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

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

10-кесте: Маршрутизатордың спуфинг қабылдағышының мекенжайы

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клиент-сервер-клиент байланысына айналады.

Сәлем достар, сіздер білетіндей, біз сіздерді жаңа технологиялармен үнемі жаңартып отырамыз, бүгін мен Google әзірлеген WebRTC технологиясын таныстырамын, ол пайдаланушыларға плагиндерді- Веб-сайттарды немесе қолданбаларды пайдалануды қажет етпестен, шолғышта бейне және аудио арқылы тікелей сөйлесуге мүмкіндік береді. . Пайдаланушылар арасындағы бейне және аудио тікелей байланыс браузерде тікелей орын алады.
WebRTC технологиясына қолдау көрсетіледі Mozilla Firefox Google браузерлері Chrome және кез келген операциялық жүйе, Opera жақында қосылады.
WebRTC дегеніміз не және не?
WebRTC — Web Real Time Communication деген сөздің қысқартылған нұсқасы, бұл технология бұл үшін Интернеттегі басқа плагиндерді, қолданбаларды немесе қызметтерді қажет етпестен аудио және бейне чаттарды тікелей шолғышта ашуға мүмкіндік береді. Қосылым браузерден браузерге тікелей жасалады.
Белгілі қызметтер (Skype, Yahoo Messenger, Apple FaceTime, Google Hago және т.б.) трафикті бастау және басқару үшін пайдаланушыларды байланыстыратын серверді қажет ететін жерлерде. Осы қызметтерді пайдалана отырып, біз тіркеліп, клиенттер мен контактілердің тізімін орнатуымыз керек.
WebRTC көмегімен бізге серверлер, қолданбалар немесе арашалауға қосылатын серверлер қажет емес.
WebRTC артықшылықтары:
1. Ресурс пен батареяны тұтынатын қолданбалар енді болмайды.
2. Чаттар жеке (салыстырмалы түрде).
3. Жергілікті қосылымдар үшін Flos АҚШ серверлері емес, жергілікті жерде байланысуға болады.
4. Қарапайымдылық, қолданудың қарапайымдылығы.
5. Әрі қарай даму мүмкіндігі және басқа бағыттар бойынша.
6. Байланыс тұрақты және сыртқы байланыстарға тәуелді емес, олар кейде өте тұрақсыз.
Оқулықта мен Google-дағы адамдар әзірлеген демонстрацияны қолдандым, бұл демонстрация өте қарапайым, жетілдірілген мүмкіндіктер және жылдам қосылымдар WebRTC қолдайтын қолданбалардың бірін пайдалана алады, оларды пайдалану оңайырақ. Жақында біз WebRTC қолданбалары туралы оқу құралын дайындайтын боламыз.
WebRTC демонстрациясын қалай пайдалануға болады?
Төмендегі сілтемені нұқыңыз, ол автоматты түрде чатты жасайды. осы бөлмені байланыстыру үшін сіз хабарласқыңыз келетін досыңызды / қызыңызды жіберуіңіз керек.
Досыңыз / қызыңыз және сіздікі, бірақ сіз тек ең көп пайдалануыңыз керек соңғы нұсқалары Mozilla Firefox немесе Google Chrome.

Demo WebRTC(Кіріспе чат аудио - бейне)

Назар аударыңыз:
Демонстрация өте тұрақты емес, ол тек көрсету мақсатында жасалған. Ол шағын қосылым қателері орын алуы мүмкін шектеулі уақыт кезеңі үшін пайдаланылуы мүмкін.
Байланыс мәселесі туындаса, басқа чат жасап көріңіз.

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

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

Үйлесімділік

WebRTC енгізулері жасалып жатқандықтан және әрбір браузерде WebRTC функционалдығы болғандықтан, кодпен жұмыс істеуді бастамас бұрын Google ұсынған Adapter.js политолтыру кітапханасын пайдалану ұсынылады.

Adapter.js оны қолдайтын мәтінмәндер арасындағы WebRTC енгізулеріндегі айырмашылықтарды біркелкі жою үшін сыналар мен политолтырларды пайдаланады. Adapter.js сонымен қатар жеткізуші префикстерін және басқа сипат атауларының айырмашылықтарын өңдейді, бұл WebRTC әзірлеу процесін ең дәйекті нәтижемен жеңілдетеді. Кітапхана NPM бумасы ретінде де қол жетімді.

Adapter.js кітапханасын қосымша зерттеу үшін қараңыз.

WebRTC түсінігі және қолданылуы

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

Екі түйін арасындағы байланыс RTCPeerConnection интерфейсінің нысаны ретінде ұсынылған. RTCPeerConnection нысанын пайдаланып қосылым орнатылған және ашылғаннан кейін қосылымға медиа ағындарын ( MediaStream ) және/немесе деректер арналарын ( RTCDataChannel s ) қосуға болады.

Медиа ағындары мультимедиа ақпаратының кез келген санынан (тректерден) тұруы мүмкін. MediaStreamTrack интерфейсінің нысандарымен ұсынылған бұл тректер аудио, бейне, мәтінді (субтитрлер немесе тарау тақырыптары сияқты) қоса алғанда, бір немесе бірнеше медиа түрлерін қамтуы мүмкін. Көптеген ағындар кем дегенде бір аудио жолдан (бір аудио трек) немесе бейне жолдан тұрады және оларды ағындар (нақты уақыттағы медиа) ретінде жіберуге және қабылдауға немесе файлға сақтауға болады.

Сондай-ақ, тасымалдау үшін пайдалануға болатын RTCDataChannel интерфейс нысанын пайдаланып ерікті деректермен алмасу үшін екі түйін арасындағы байланысты пайдалануға болады. қызмет туралы ақпарат, қор деректері, ойын күйі пакеттері, файлдарды тасымалдау немесе жеке деректер арналары.

қосымша мәліметтер мен тиісті нұсқаулықтар мен оқулықтарға сілтемелер қажет

WebRTC интерфейстері

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

Қосылымды орнату және басқару

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

Гидтер

WebRTC қазіргі уақытта ыстық технология болып табылады аудио ағыныжәне браузерлердегі бейне. HTTP Streaming және Flash сияқты консервативті технологиялар жазылған мазмұнды (сұраныс бойынша бейне) тарату үшін қолайлы және нақты уақыттағы және онлайн-хабарламалар бойынша WebRTC-тен айтарлықтай төмен, яғни. Көрермендерге не болып жатқанын «тікелей» көруге мүмкіндік беретін ең аз бейне кідірісі қажет.

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

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

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

WebRTC технологиясын іс жүзінде сынау және оған қарапайым онлайн хабар таратуды іске қосу үшін біз Flashphoner WebRTC Media & Broadcasting Server сервер бағдарламалық құралын қолдандық. Мүмкіндіктер WebRTC ағындарын бір-көп режимінде тарату мүмкіндігін, сондай-ақ RTSP хаттамасы арқылы IP камералары мен бейнебақылау жүйелерін қолдауды жариялайды; осы шолуда біз веб-веб-таратуларға және олардың мүмкіндіктеріне тоқталамыз.

WebRTC Media & Broadcasting Server орнату

Өйткені, үшін Windows жүйелерісервер нұсқасы болған жоқ, мен VMWare + Linux сияқты виртуалды машинаны орнатқым келмеді, желідегі таратылымдарды тексергім келмеді. Windows үйікомпьютер сәтсіз аяқталды. Уақытты үнемдеу үшін біз бұлтты хостингтің мысалын алуды шештік:

Бұл Амстердам деректер орталығында алдын ала орнатылған бағдарламалық құралсыз Centos x86_64 6.5 нұсқасы болды. Осылайша, біздің қолымызда тек сервер және оған ssh қолжетімділігі бар. Консольмен таныстар үшін Linux командалары, WebRTC серверін орнату қарапайым және ауыртпалықсыз болуға уәде береді. Сонымен, біз не істедік:

1. Мұрағатты жүктеп алу:

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

2. Қаптаманы ашу:

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

3. Орнату:

$cd FlashphonerWebCallServer

Орнату кезінде сервердің IP мекенжайын енгізіңіз: XXX.XXX.XXX.XXX

4. Лицензияны белсендіру:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. WCS серверін іске қосыңыз:

$service webcallserver іске қосылады

6. Журналды тексеру:

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

7. Екі процестің бар-жоғын тексеріңіз:

$ps aux | grep Flashphoneer

Орнату процесі аяқталды.

WebRTC тікелей ағындарын сынау

Трансляцияларды тестілеу қарапайым мәселе болып шықты. Серверден басқа, ондаған Javascript, HTML және одан тұратын веб-клиент бар CSS файлдарыжәне біз орнату кезеңінде /var/www/html қалтасына орналастырдық. Веб-клиент HTML5 Websockets арқылы серверге қосылым орнатуы үшін сервердің IP мекенжайын flashphoner.xml конфигурациясына енгізу керек болды. Тестілеу процесін сипаттайық.

1. Chrome браузерінде сынақ клиентінің index.html бетін ашыңыз:

2. Трансляцияны бастау үшін экранның ортасындағы «Бастау» түймесін басу керек.
Мұны жасамас бұрын, веб-камера қосылғанына және пайдалануға дайын екеніне көз жеткізу керек. Веб-камера үшін арнайы талаптар жоқ, мысалы, біз 1280 × 800 рұқсаты бар стандартты кірістірілген ноутбук камерасын қолдандық.

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

3. Интерфейс бейне ағынының камерадан WebRTC серверіне сәтті таратылуын білдіреді. Жоғарғы оң жақ бұрышта индикатор ағынның серверге өтіп жатқанын көрсетеді, төменгі бұрышта бейнені жіберуді тоқтату үшін «Тоқтату» түймесі бар.

Төмендегі сілтемені қараңыз. Онда осы ағын үшін бірегей идентификатор бар, сондықтан кез келген адам көрініске қосыла алады. Бұл сілтемені браузерде ашыңыз. Оны алмасу буферіне көшіру үшін «Көшіру» түймесін басу керек.

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

5. Байланыс орнатылып, көрермен экрандағы ағынды көреді. Енді ол төменгі оң жақ бұрыштағы басқару элементтері арқылы сілтемені басқа біреуге жібере алады, ағынмен ойнатуды тоқтата алады немесе толық экран режимін қоса алады.

Онлайн таратылымдар үшін WebRTC серверінің сынақ нәтижелері

Сынақтар кезінде кідіріс мінсіз болып көрінді. Деректер орталығына пинг шамамен 100 миллисекунд болды және кідіріс көзге көрінбеді. Осы жерден біз нақты кідіріс буферлеу уақыты үшін бірдей 100 плюс немесе минус бірнеше ондаған миллисекундтар деп болжауға болады. Flash бейнесімен салыстырғанда, Flash бұл сынақтарда WebRTC сияқты жақсы жұмыс істемейді. Сонымен, егер сіз қолыңызды ұқсас желіде жылжытсаңыз, экрандағы қозғалысты тек бір/екі секундтан кейін ғана көруге болады.

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

Серверді орнату және конфигурациялау өте оңай, оны іске қосу үшін ешқандай күрделі дағдылар қажет емес, тек ssh арқылы консольден пәрмендерді орындай алатын және қолдана алатын озық пайдаланушы деңгейіндегі Linux білімін қоспағанда мәтіндік редактор. Нәтижесінде біз браузерлер арасында бір-көп онлайн-трансляциясын орната алдық. Қосымша көрушілерді ағынға қосу да қиындық тудырмады.

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

Веб-камерадан тестілеу туралы бейне
WebRTC сервері арқылы

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

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

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

Күріш. бір

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

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

Біз бейне чаттың жұмыс істеу принципін тексереміз файлдық жүйеДК. Компьютерде серверді (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) бағдарламасын іске қосыңыз және Program Files каталогында 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>nodeserver.js

Күріш. 3

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

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

Күріш. төрт

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

Күріш. 5

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