Европын интернет хэрэглэгчдийг хоёр хэсэгт хуваадаг: Алленбах (Герман) дахь Олон нийтийн санаа бодлыг шинжлэх хүрээлэнгийн судалгаагаар Skype, чат, мессежийн систем нь 16.5 сая насанд хүрэгчид болон хүүхдүүдийн өдөр тутмын амьдралын салшгүй хэсэг болсон (9 сая). Эдгээр үйлчилгээг тухай бүр ашиглаж, 28 сая нь тэдэнд хүрдэггүй.

Firefox-г нэгтгэсэн тул нөхцөл байдал өөрчлөгдөж магадгүй юм бодит цагийн харилцаа холбооны технологи (WebRTC), түүнчлэн үйлчлүүлэгч өөрөө. Аудио болон видео чат эхлүүлэх нь вэбсайт нээхээс илүү хэцүү биш юм. Харин Facebook, Skype зэрэг үйлчилгээнүүд нь тусдаа үйлчлүүлэгч ашиглах, данс үүсгэх шийдэлд тулгуурладаг.

WebRTC нь зөвхөн ашиглахад хялбар биш юм. Энэ арга нь бүр тохируулах боломжийг олгодог хоёр хөтөч хооронд шууд холболт. Ийм байдлаар аудио болон видео өгөгдөл нь түгжрэл үүсч болзошгүй эсвэл администратор нь хувийн нууцлал, мэдээллийн хамгаалалтад онцгой мэдрэмжгүй серверээр дамжихгүй. Шууд холболтын ачаар WebRTC нь ямар ч бүртгэл шаарддаггүй Дансямар ч үйлчилгээнд.

Харилцааг эхлүүлэхийн тулд та зөвхөн холбоосыг дагахад л хангалттай. Харилцаа холбоо нууц хэвээр байнаУчир нь өгөгдлийн урсгал шифрлэгдсэн байдаг. Google нь 2011 онд WebRTC хэрэгжүүлэлтийн эх кодыг нийтлэхдээ хөтөчөөр дамжуулан бодит цагийн харилцаанд идэвхтэй оролцож эхэлсэн.

Үүний дараахан Chrome болон Firefox нь өөрсдийн WebRTC хөдөлгүүрийг хүлээн авав. Тэд одоогоор байна гар утасны сонголтуудЭнэ технологи болон WebView 3.6 хөдөлгүүрээр тоноглогдсон бөгөөд энэ нь Android 5.0 үйлдлийн системтэй бөгөөд программуудад ашиглагддаг.

Бодит цагийн харилцааны хувьд тохирох JavaScript интерфэйсийг вэб үзүүлэгч дээр хэрэгжүүлсэн байх ёстой. GetUserMedia-г ашиглах програм хангамжвэб камер, микрофон гэх мэт аудио болон видео эх сурвалжаас зураг авалтыг идэвхжүүлдэг. RTCPeerConnection нь холболтыг бий болгохоос гадна харилцаа холбоог өөрөө хариуцдаг.

Хөтөчийг нэгтгэхтэй зэрэгцээ ажлын хэсэг World Wide Web Consortium (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 үйлчилгээ нь ярилцагч руу илгээх шаардлагатай холбоосыг өгдөг. Хөтөч нь STUNserver ашиглан өөрийн IP хаягийг (2) олж, үйлчилгээ рүү илгээж, шууд холболт үүсгэхийн тулд түншийн IP-г хүлээн авдаг (3). Хэрэв STUN амжилтгүй болвол TURNсервер (4) ашиглан харилцан яриаг дахин чиглүүлнэ.

Харилцаа холбоо WebRTC технологихөтөч дээр JavaScript кодыг ашиглан эхлүүлсэн. Үүний дараа гурван хөдөлгүүр нь харилцаа холбоог хариуцдаг: дуут болон видео хөдөлгүүр нь вэб камер, микрофоноос мультимедиа өгөгдлийг цуглуулдаг бөгөөд тээврийн хөдөлгүүр нь мэдээллийг нэгтгэж, бодит цагийн аюулгүй байдлын протокол (SRTP) ашиглан дамжуулалтыг шифрлэсэн хэлбэрээр илгээдэг.

WebRTC-тэй ямар хөтчүүд ажилладаг

Chrome болон Firefox нь talky.io зэрэг үйлчилгээг ашигладаг WebRTC хөдөлгүүрээр тоноглогдсон. Mozilla хөтөч нь өөрийн үйлчлүүлэгчтэй шууд ажиллах боломжтой.

Google болон Mozilla нь бодит цагийн харилцааны санааг үргэлжлүүлэн хөгжүүлсээр байна: Chrome нь олон оролцогчтой WebRTC бага хурал зохион байгуулах боломжтой бөгөөд Firefox дахь шинэ Hello клиентийг харилцаа холбооны аварга Telefonica-ийн охин компанийн тусламжтайгаар боловсруулсан. Apple одоогоор хажуу тийшээ байгаа тул та Safari-д WebRTC-ийг хараахан хүлээх ёсгүй. Гэсэн хэдий ч Safari-д зориулсан өөр олон iOS програмууд болон залгаасууд байдаг.

Майкрософт арай өөр курс авч байна. Өрсөлдөх чадвартай Skype үйлчилгээний эзэмшигчийн хувьд энэ компани WebRTC-д тийм ч амархан бууж өгөхгүй. Үүний оронд Майкрософт ORTC (Object Real-Time Communications) хэмээх технологийг хөгжүүлж байна. Internet Explorer.

WebRTC-ийн ялгаа, тухайлбал сервертэй холбоо тогтоох өөр өөр кодлогч, протоколууд нь бага бөгөөд цаг хугацаа өнгөрөхөд WebRTC стандартаас гадна эдгээр ялгааг агуулсан байх магадлалтай. Тиймээс ердийнх шигээ зөвхөн Apple л үлдэж байна.

Зураг:үйлдвэрлэлийн компаниуд; goodluz/Photolia.com

Сайн байцгаана уу найзуудаа, та бүхний мэдэж байгаачлан бид та бүхэнд шинэ технологиудыг байнга шинэчилж байдгийг өнөөдөр би WebRTC технологийг танилцуулах болно. Google, энэ нь хэрэглэгчдэд нэмэлт өргөтгөл ашиглах шаардлагагүйгээр хөтөчийн видео болон аудио дээр шууд ярих боломжийг олгодог- Вэбсайт эсвэл програмууд. Хэрэглэгчдийн хоорондох видео болон аудио шууд холболт нь хөтөч дээр шууд явагддаг.
Mozilla дэмждэг WebRTC технологи Firefox хөтчүүд Гүүгл Кромболон аль ч хувьд үйлдлийн систем, 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.

Демо WebRTC(Танилцуулга чатын аудио - видео)

Анхаар:
Демо нь тийм ч тогтвортой биш, зөвхөн үзүүлэх зорилгоор хийгдсэн. Энэ нь холболтын жижиг алдаа гарч болзошгүй хязгаарлагдмал хугацаанд ашиглагдаж болно.
Хэрэв танд холболтын асуудал байгаа бол өөр чат үүсгэж үзнэ үү.

Өнөөдөр WebRTC нь хөтчөөр аудио болон видео дамжуулах "халуун" технологи юм. зэрэг консерватив технологиуд HTTP дамжуулалтболон Flash нь бичигдсэн контентыг түгээхэд илүү тохиромжтой (хүсэлтээр видео) бөгөөд бодит цагийн болон онлайн нэвтрүүлгүүдийн хувьд WebRTC-ээс хамаагүй доогуур байдаг, i.e. Видеоны хоцрогдол хамгийн бага байх ёстой бөгөөд үзэгчид юу болж байгааг "амьд" харах боломжийг олгодог.

Бодит цагийн өндөр чанарын харилцааны боломж нь 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 хандалт юм. Мэддэг хүмүүст зориулав консол командуудЛинукс, WebRTC серверийг суулгах нь хялбар бөгөөд өвдөлтгүй байх болно. Тэгэхээр бид юу хийв:

1. Архив татаж авах:

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

2. Баглаа задлах:

$tar -xzf татаж авах-wcs5-server.tar.gz

3. Суулгах:

$cd FlashphonerWebCallServer

Суулгах явцад серверийн IP хаягийг оруулна уу: XXX.XXX.XXX.XXX

4. Лицензийг идэвхжүүлэх:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. WCS серверийг эхлүүлэх:

$service вэб дуудлагын сервер эхлүүлнэ

6. Шалгах бүртгэл:

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

7. Хоёр процесс байгаа эсэхийг шалгана уу:

$ps aux | grep Flashphoner

Суулгах процесс дууссан.

WebRTC шууд дамжуулалтыг туршиж байна

Нэвтрүүлгийг турших нь энгийн зүйл болж хувирав. Серверээс гадна хэдэн арван Javascript, HTML, CSS файлуудаас бүрдэх вэб клиент байдаг бөгөөд үүнийг суулгах үе шатанд бид /var/www/html хавтсанд байршуулсан. Хийх ёстой цорын ганц зүйл бол серверийн IP хаягийг flashphoner.xml тохиргоонд оруулах бөгөөд ингэснээр вэб клиент HTML5 Websockets-ээр дамжуулан сервертэй холбогдох боломжтой болно. Туршилтын үйл явцыг тайлбарлая.

1. Chrome хөтөч дээр туршилтын үйлчлүүлэгчийн index.html хуудсыг нээнэ үү:

2. Өргөн нэвтрүүлгийг эхлүүлэхийн тулд та дэлгэцийн дунд байрлах "Эхлүүлэх" товчийг дарах хэрэгтэй.
Үүнийг хийхийн өмнө вэбкамер холбогдсон, ажиллахад бэлэн байгаа эсэхийг шалгах хэрэгтэй. Вэбкамерын хувьд тусгай шаардлага байхгүй, жишээлбэл, бид 1280 × 800 нягтралтай зөөврийн компьютерын стандарт камер ашигласан.

Chrome хөтөч нь камер, микрофон руу нэвтрэхийг хүсэх нь гарцаагүй бөгөөд ингэснээр хэрэглэгч өөрийн видеог интернет сервер рүү илгээх болно гэдгийг ойлгож, түүнд үүнийг хийхийг зөвшөөрдөг.

3. Интерфэйс нь камераас WebRTC сервер рүү видео дамжуулалтыг амжилттай дамжуулж байгааг харуулж байна. Баруун дээд буланд дамжуулалт сервер рүү явж байгааг харуулж байгаа бол доод буланд видео илгээхийг зогсоох "Зогс" товчлуур байна.

Доорх линкээр ороод үзээрэй. Энэ нь энэ дамжуулалтын өвөрмөц танигчийг агуулж байгаа тул дурын хүн үзвэрт нэгдэх боломжтой. Энэ холбоосыг хөтөч дээр нээнэ үү. Үүнийг санах ой руу хуулахын тулд та "Хуулбарлах" товчийг дарах хэрэгтэй.

Вебинар, лекц, онлайн видео нэвтрүүлэг эсвэл интерактив ТВ гэх мэт бодит програмуудад хөгжүүлэгчид энэ танигчийг тодорхой бүлэг үзэгчдэд түгээх шаардлагатай бөгөөд ингэснээр тэд хүссэн урсгалтай холбогдох боломжтой болно, гэхдээ энэ нь програмын логик юм. WebRTC Media & Broadcasting Server энэ нь нөлөөлөхгүй, гэхдээ зөвхөн видеог түгээхтэй холбоотой.

5. Холболт үүссэн бөгөөд үзэгч дэлгэцэн дээрх урсгалыг хардаг. Одоо тэр холбоосыг өөр хэн нэгэнд илгээх, дамжуулалтыг тоглуулахыг зогсоох эсвэл идэвхжүүлэх боломжтой бүтэн дэлгэцийн горимбаруун доод буланд байгаа удирдлагыг ашиглан.

Онлайн нэвтрүүлэгт зориулсан WebRTC серверийн туршилтын үр дүн

Туршилтын үеэр хоцролт нь төгс байсан юм шиг санагдав. Мэдээллийн төвийн ping нь 100 миллисекунд орчим байсан бөгөөд саатал нь нүдэнд харагдахгүй байв. Эндээс бид бодит саатал нь буферлэх хугацааны хувьд ижил 100 нэмэх эсвэл хасах хэдэн арван миллисекунд байна гэж үзэж болно. Flash видеотой харьцуулахад Flash нь эдгээр туршилтуудыг WebRTC шиг сайн гүйцэтгэдэггүй. Тиймээс, хэрэв та ижил төстэй сүлжээнд гараа хөдөлгөвөл дэлгэц дээрх хөдөлгөөнийг зөвхөн нэг / хоёр секундын дараа л харж болно.

Чанарын тухайд заримдаа та хөдөлгөөн дээр кубыг ялгаж чаддаг гэдгийг бид тэмдэглэж байна. Энэ нь VP8 кодлогчийн шинж чанартай нийцэж байгаа бөгөөд түүний гол зорилго нь хүлээн зөвшөөрөгдсөн чанартай, харилцааны сааталгүйгээр бодит цагийн видео холбоог хангах явдал юм.

Серверийг суулгах, тохируулахад маш хялбар бөгөөд үүнийг ажиллуулахын тулд ямар нэгэн ноцтой ур чадвар шаардагддаггүй, зөвхөн ssh-ээр дамжуулан консолоос командуудыг ажиллуулж, ашиглах боломжтой ахисан түвшний хэрэглэгчийн түвшний Linux-ийн мэдлэгийг эс тооцвол. текст засварлагч. Үүний үр дүнд бид хөтчүүдийн хооронд нэгээс олон онлайн дамжуулалтыг тохируулж чадсан. Нэмэлт үзэгчдийг дамжуулалтад холбох нь асуудал үүсгэсэнгүй.

Нэвтрүүлгийн чанар нь вебинар болон онлайн нэвтрүүлэгт нэлээд нийцэж байсан. Зарим асуултыг үүсгэсэн цорын ганц зүйл бол видеоны нягтрал байв. Камер нь 1280x800-г дэмждэг боловч туршилтын зураг дээрх нягтрал нь 640x480-тэй маш төстэй юм. Энэ асуудлыг хөгжүүлэгчидтэй хамт тодруулах хэрэгтэй бололтой.

Вэбкамераас нэвтрүүлсэн туршилтын тухай видео
WebRTC серверээр дамжуулан

Ихэнх материалууд дээр 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. Видео өгөгдөл дамжуулалтыг эхлүүлэх, хариулт үүсгэх саналыг хүлээн авах (хариулт үүсгэх)
  3. Таныг авч байна SDPобъект болон түүнийг дохионы механизмаар дамжуулах ( SDP)
  4. Таныг авч байна Мөсөн нэр дэвшигчобъектууд ба тэдгээрийн дохионы механизмаар дамжуулалт ( Мөсөн нэр дэвшигч)
  5. Алсын (гадаадын) медиа урсгалыг хүлээн авч, дэлгэцэн дээр харуулах (onAddStream)

Ганц ялгаа нь хоёр дахь догол мөрөнд байна.

Алхамууд нь илт нарийн төвөгтэй хэдий ч үнэндээ гурван зүйл байдаг: өөрийн медиа урсгалыг илгээх (х. 1), холболтын параметрүүдийг тохируулах (х. 2-4), өөр хэн нэгний медиа урсгалыг хүлээн авах (х. 5). Хамгийн хэцүү нь хоёр дахь алхам, учир нь энэ нь хоёр хэсгээс бүрддэг: байгуулах физикболон логикхолболтууд. Эхнийх нь харуулж байна зам, нэг сүлжээний зангилаанаас нөгөөд шилжихийн тулд пакетууд ямар дагуу явах ёстой. Хоёр дахь нь харуулж байна видео/аудио параметрүүд- ямар чанар, ямар кодлогч ашиглах вэ.

Сэтгэцийн үе шат санал үүсгэхэсвэл Хариулт үүсгэхдамжуулах үе шатуудтай холбогдсон байх ёстой SDPболон Мөсөн нэр дэвшигчобъектууд.

Үндсэн байгууллагууд

Медиа урсгал (MediaStream)

Гол объект нь медиа урсгал, өөрөөр хэлбэл видео болон аудио өгөгдөл, зураг, дууны урсгал юм. Орон нутгийн болон алсаас хоёр төрлийн медиа урсгал байдаг. Дотоод төхөөрөмж нь оролтын төхөөрөмжүүдээс (камер, микрофон), алсаас сүлжээгээр дамжуулан өгөгдлийг хүлээн авдаг. Тиймээс зангилаа бүр дотоод болон алсын утастай байдаг. AT WebRTCурсгалын интерфейс байдаг медиа урсгалмөн дэд интерфэйс бас байдаг LocalMediaStreamтусгайлан зориулсан орон нутгийн утас. AT JavaScriptта зөвхөн эхний нэгтэй тулгарах боломжтой бөгөөд хэрэв та ашигладаг бол lib jingle, дараа нь хоёр дахь нь бас учирч болно.

AT WebRTC thread дотор нэлээд будлиантай шатлал байдаг. Урсгал бүр хэд хэдэн медиа замаас бүрдэж болно ( медиа зам), энэ нь эргээд хэд хэдэн медиа сувгаас бүрдэж болно ( MediaChannel). Мөн хэд хэдэн хэвлэл мэдээллийн урсгал байж болно.

Бүгдийг дарааллаар нь авч үзье. Үүнийг хийхийн тулд зарим нэг жишээг санаарай. Бид зөвхөн өөрсдийнхөө видео бичлэгийг төдийгүй, дээр нь ямар нэгэн зүйл бичих гэж буй цаасан дээр хэвтэж буй ширээний видео бичлэгийг дамжуулахыг хүсч байна гэж бодъё. Бидэнд хоёр видео (бид + хүснэгт) болон нэг аудио (бид) хэрэгтэй болно. Бид болон хүснэгтийг өөр өөр хэлхээнд хуваах нь тодорхой байна, учир нь энэ өгөгдөл нь бие биенээсээ бага хамааралтай байж магадгүй юм. Тиймээс бид хоёртой болно медиа урсгал'a - нэг нь бидэнд, нөгөө нь ширээнд. Эхнийх нь видео болон аудио өгөгдлийг хоёуланг нь агуулна, хоёр дахь нь зөвхөн видеог агуулна (Зураг 4).

Зураг 4: Хоёр өөр медиа урсгал. Нэг нь бидэнд, нэг нь бидний ширээнд

Медиа урсгал нь ядаж өгөгдөл агуулсан байх ёстой гэдэг нь нэн даруй тодорхой байна янз бүрийн төрөл- видео болон аудио. Технологид үүнийг анхаарч үздэг тул төрөл бүрийг мэдээллийн хэрэгслээр дамжуулан хэрэгжүүлдэг. медиа зам. Хэвлэл мэдээллийн хэрэгсэл нь онцгой шинж чанартай байдаг төрлийн, бидний өмнө юу байгааг тодорхойлдог - видео эсвэл аудио (Зураг 5)

Зураг 5: Медиа урсгалууд нь медиа замуудаас бүрддэг

Хөтөлбөрт бүх зүйл хэрхэн өрнөх вэ? Бид хоёр медиа урсгал үүсгэх болно. Дараа нь бид хоёр видео бичлэг, нэг аудио зам үүсгэх болно. Камер болон микрофонд хандах эрх авцгаая. Аль төхөөрөмжийг ашиглахыг зам бүрт хэлж өгье. Эхний медиа урсгалд видео болон аудио бичлэг, хоёр дахь медиа урсгал руу өөр камераас видео бичлэг нэмье.

Гэхдээ бид холболтын нөгөө талд байгаа медиа урсгалыг хэрхэн ялгах вэ? Үүнийг хийхийн тулд медиа урсгал бүр өмчтэй байдаг шошго– урсгалын шошго, түүний нэр (Зураг 6). Медиа бичлэгүүд ижил өмчтэй байдаг. Хэдийгээр өнгөцхөн харахад видеог дуу чимээнээс өөр зүйлээр ялгах боломжтой юм шиг санагддаг.

Зураг 6: Медиа урсгал болон замуудыг шошгоор нь тодорхойлсон

Тэгэхээр, хэрэв медиа бичлэгийг шошгон дээр таних боломжтой бол бид яагаад нэг биш хоёр медиа урсгалыг жишээ болгон ашиглах хэрэгтэй байна вэ? Эцсийн эцэст та нэг медиа урсгалыг дамжуулж, өөр өөр замуудыг ашиглаж болно. Бид хүрсэн чухал өмчхэвлэл мэдээллийн урсгал - тэд синхрончлохмедиа замууд. Төрөл бүрийн медиа урсгалууд бие биетэйгээ синхрончлогддоггүй, гэхдээ медиа урсгал бүрийн дотор бүх замууд байдаг нэгэн зэрэг тоглосон.

Тиймээс, хэрэв бид үг хэллэг, нүүрэн дээрх сэтгэл хөдлөл, цаасан дээр нэгэн зэрэг тоглохыг хүсч байвал нэг медиа урсгалыг ашиглах нь зүйтэй. Хэрэв энэ нь тийм ч чухал биш бол өөр өөр урсгалыг ашиглах нь илүү ашигтай байдаг - зураг илүү зөөлөн болно.

Дамжуулах явцад замыг идэвхгүй болгох шаардлагатай бол та өмч хөрөнгийг ашиглаж болно идэвхжүүлсэнмедиа замууд.

Эцэст нь та стерео дууны талаар бодох хэрэгтэй. Та бүхний мэдэж байгаагаар стерео дуу нь хоёр юм өөр дуу чимээ. Мөн тэдгээрийг тусад нь илгээх шаардлагатай. Үүний тулд сувгуудыг ашигладаг. MediaChannel. Аудио медиа бичлэг нь олон сувагтай байж болно (жишээлбэл, танд 5+1 аудио хэрэгтэй бол 6). Медиа зам дотор суваг, мэдээжийн хэрэг синхрончлогдсон. Видеоны хувьд ихэвчлэн зөвхөн нэг суваг ашигладаг боловч хэд хэдэн сувгийг, жишээлбэл, сурталчилгааны давхаргыг ашиглаж болно.

Нэгтгэн дүгнэхэд: Бид видео болон аудио өгөгдлийг дамжуулахын тулд медиа урсгалыг ашигладаг. Медиа урсгал бүрт өгөгдөл синхрончлогддог. Синхрончлол хийх шаардлагагүй бол бид олон медиа урсгалыг ашиглаж болно. Медиа урсгал бүрт видео болон аудио гэсэн хоёр төрлийн медиа зам байдаг. Ихэвчлэн хоёроос илүүгүй зам байдаг, гэхдээ хэрэв та хэд хэдэн өөр видео (ярилцагч ба түүний хүснэгт) шилжүүлэх шаардлагатай бол илүү их байж болно. Зам бүр нь хэд хэдэн сувгаас бүрдэх боломжтой бөгөөд энэ нь ихэвчлэн стерео дуунд ашиглагддаг.

Хамгийн энгийн видео чатын нөхцөлд бид хоёр замаас бүрдэх нэг орон нутгийн медиа урсгалтай байх болно - видео бичлэг ба аудио зам тус бүр нь нэг үндсэн сувгаас бүрдэх болно. Видео бичлэг нь камер, аудио бичлэг нь микрофон, медиа урсгал нь хоёулангийнх нь сав юм.

Сешн тодорхойлогч (SDP)

At янз бүрийн компьютеруудүргэлж өөр өөр камер, микрофон, видео карт болон бусад тоног төхөөрөмж байх болно. Тэдэнд олон сонголт бий. Сүлжээний хоёр зангилааны хооронд медиа өгөгдөл дамжуулахад энэ бүгдийг зохицуулах ёстой. 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: Кодекийн хэлэлцээр

Нэр дэвшигчид (Мөсөн нэр дэвшигч)

Технологи 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энэ багц байна:

src IP	Src PORT	Зорилтот IP	DEST PORT
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. Тиймээс чиглүүлэгч энэ хүснэгтийг хардаг. Баганыг харж байна Гадаад портмөн тохирох мөрийг хайж байна DEST PORTирж буй багцаас, өөрөөр хэлбэл 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	DEST PORT
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хаяг, порт, гэхдээ тэдгээрийн зарим нь суулгагдсан байдаг нэмэлт хамгаалалт"хуурамчлах" -аас. Жишээлбэл, in тэгш хэмтэйширээ 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үйлчлүүлэгч-сервер-клиент холболт болж хувирдаг.