Ихэнх материалууд дээр 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үйлчлүүлэгч-сервер-үйлчлүүлэгчийн холболт болж хувирдаг.

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

RTCPeerConnection интерфэйс нь хоёр хөтөч хоорондын үе тэнгийн холболт юм. Гурав ба түүнээс дээш хэрэглэгчийг холбохын тулд бид торон сүлжээг зохион байгуулах шаардлагатай болно (зангилаа бүр бусад бүх зангилаатай холбогдсон сүлжээ).
Бид дараахь схемийг ашиглана.

1. Хуудсыг нээхдээ бид өрөөний ID байгаа эсэхийг шалгадаг байршил.хэш
2. Хэрэв өрөөний ID-г заагаагүй бол шинээр үүсгэнэ үү
3. Бид дохионы сервер рүү "заасан өрөөнд нэгдэхийг хүсч буй мессежийг илгээдэг
4. Дохионы сервер нь энэ өрөөнд байгаа бусад үйлчлүүлэгчдэд шинэ хэрэглэгчийн мэдэгдлийг илгээдэг
5. Өрөөнд аль хэдийн орсон үйлчлүүлэгчид шинээр ирсэн хүнд SDP санал илгээдэг
6. Шинээр ирсэн хүн "s" гэсэн саналд хариулдаг

0. Дохионы сервер

Таны мэдэж байгаагаар WebRTC нь хөтчүүдийн хооронд P2P холболт хийх боломжийг олгодог боловч үйлчилгээний мессеж солилцоход нэмэлт тээвэрлэлт шаардлагатай хэвээр байна. Энэ жишээнд тээвэрлэлт нь socket.io ашиглан Node.JS дээр бичигдсэн WebSocket сервер юм:

var socket_io = шаардах("socket.io"); module.exports = функц (сервер) ( var хэрэглэгчид = (); var io = socket_io(сервер); io.on("холболт", функц(сокет) ( // Өрөөнд шинэ хэрэглэгч нэгдэхийг хүсэж байна socket.on( "room ", function(message) ( var json = JSON. parse(message); // Хэрэглэгчдийн жагсаалтад сокет нэмэх = сокет; if (socket.room !== тодорхойгүй) ( // Хэрэв залгуур нь аль хэдийн зарим өрөөнд байгаа бол үүнийг үлдээгээрэй socket.leave(socket.room); ) // Хүссэн өрөөг оруулна уу socket.room = json.room; socket.join(socket.room); socket.user_id = json.id; // Энэ өрөөнд шинэ оролцогч socket.broadcast.to(socket.room).emit("new", json.id); )); // WebRTC-тэй холбоотой мессеж (SDP санал, SDP хариулт) байгаа бусад үйлчлүүлэгчид рүү илгээх. эсвэл ICE нэр дэвшигч) socket.on("webrtc", function(message) ( var json = JSON.parse(message); if (json.to !== undefined && users !== undefined)) ( // Хэрэв мессеж байгаа бол хүлээн авагч болон серверт мэдэгдэж байгаа энэ хүлээн авагч, мессеж илгээнэ үү зөвхөн түүнд... хэрэглэгчид.emit("webrtc", мессеж); ) else ( // ...эсвэл мессежийг өргөн нэвтрүүлгийн залгуур гэж үзнэ.broadcast.to(socket.room).emit("webrtc", мессеж); ) )); // Хэн нэгэн socket.on("disconnect", function()-г салгасан байна ( // Үйлчлүүлэгч салгавал socket.broadcast.to(socket.room).emit("leave", socket.user_id); хэрэглэгчдийг устгах; ))) ))) );

1. индекс.html

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

2.main.js

2.0. Хуудасны элементүүд болон WebRTC интерфэйсүүдийн холбоосыг авч байна

var chatlog = document.getElementById("chatlog"); var message = document.getElementById("мессеж"); var connection_num = document.getElementById("холболтын_тоо"); var room_link = document.getElementById("өрөөний_холбоос");

Бид WebRTC интерфэйсүүдэд хандахын тулд хөтчийн угтварыг ашиглах шаардлагатай хэвээр байна.

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

2.1. Өрөөний ID-г тодорхойлох

Энд бидэнд өвөрмөц өрөө болон хэрэглэгчийн ID үүсгэх функц хэрэгтэй байна. Бид энэ зорилгоор UUID ашиглах болно.

Функц uuid () ( var s4 = function() ( буцаана Math.floor(Math.random() * 0x10000).toString(16); ); буцаана s4() + s4() + "-" + s4() + "-" + s4() + "-" + s4() + "-" + s4() + s4() + s4(); )

Одоо хаягаас өрөөний ID-г гаргаж авахыг оролдъё. Хэрэв үүнийг тохируулаагүй бол бид шинээр үүсгэх болно. Бид хуудсан дээрх одоогийн өрөөний холбоосыг харуулах бөгөөд үүний зэрэгцээ бид одоогийн хэрэглэгчийн танигчийг үүсгэх болно.

VarROOM = location.hash.substr(1); if (!ROOM) ( ROOM = uuid(); ) room_link.innerHTML = "Өрөөнд холбох"; varME = uuid();

2.2. вэб залгуур

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

// Мессеж хаагдсан үед бид серверт энэ тухай мэдэгдэл илгээх хэрэгтэйг зааж өгсөн var socket = io.connect("", ("буулгах үед синхрончлолыг таслах": үнэн)); socket.on("webrtc", socketReceived); socket.on("шинэ", socketNewPeer); // Өрөөнд орох хүсэлтийг нэн даруй илгээнэ үү socket.emit("өрөө", JSON.stringify((id: ME, өрөө: ROOM))); // WebRTC функцтэй холбоотой хаягийн мессежийг илгээх туслах функц sendViaSocket(төрөл, мессеж, to) ( socket.emit("webrtc", JSON.stringify((id: ME, to: to, type: type, data: message )) )))

2.3. Үе тэнгийн холболтын тохиргоо

Ихэнх ISP нь NAT-ээр дамжуулан интернетийн холболтыг хангадаг. Үүнээс болж шууд холболт тийм ч энгийн биш болдог. Холболт үүсгэх үед бид NAT-ыг тойрч гарахын тулд хөтөч ашиглахыг оролдох STUN болон TURN серверүүдийн жагсаалтыг зааж өгөх хэрэгтэй. Бид бас хосыг зааж өгдөг нэмэлт сонголтуудхолбохын тулд.

Var server = ( iceServers: [ (url: "stun:23.21.150.121"), (url: "stun.l.google.com:19302"), (url: "turn:numb.viagenie.ca", итгэмжлэл: "таны нууц үг энд байна", хэрэглэгчийн нэр: " [имэйлээр хамгаалагдсан]") ] ); var options = (заавал биш: [ (DtlsSrtpKeyAgreement: үнэн), // Chrome болон Firefox хооронд холбогдоход шаардлагатай (RtpDataChannels: үнэн) // DataChannels API ашиглахын тулд Firefox-д шаардлагатай ] )

2.4. Шинэ хэрэглэгчийг холбож байна

Өрөөнд шинэ үе тэнгийнхэн нэмэгдэхэд сервер бидэнд мессеж илгээдэг шинэ. Дээрх мессеж боловсруулагчийн дагуу функц дуудагдах болно socketNewPeer.

var peers = (); function socketNewPeer(өгөгдөл) ( peers = (candidateCache: ); // Шинэ холболт үүсгэх var pc = new PeerConnection(сервер, сонголтууд); // Үүнийг эхлүүлэх initConnection(pc, өгөгдөл, "санал"); // Peer-ийг хадгалах жагсаалтад peers peers.connection = pc; // Мэдээлэл солилцох DataChannel үүсгэх var channel = pc.createDataChannel("mychannel", ()); channel.owner = data; peers.channel = суваг; // Үйл явдал зохицуулагчийг суулгах bindEvents(channel); // SDP санал үүсгэх pc.createOffer(function(offer) ( pc.setLocalDescription(offer); )); ) function initConnection(pc, id, sdpType) ( pc.onicecandidate = функц ( event) ( if (event.candidate) ( // Шинэ ICE нэр дэвшигч олдвол peers.candidateCache.push(event.candidate); ) өөр ( // Нэр дэвшигчид илэрсэн үед түүнийг цааш илгээх жагсаалтад нэмнэ үү. дууссан бол зохицуулагч дахин дуудагдах боловч нэр дэвшигчгүй // Энэ тохиолдолд бид эхлээд SDP саналыг үе тэнгийнхэнд илгээнэ, эсвэл SDP-ийн хариулт (функцийн параметрээс хамаарч)... sendViaSocket(sdpType, pc.localDescription, id); // ... тэгээд өмнө нь олсон бүх ICE нэр дэвшигчид (var i = 0; i< peers.candidateCache.length; i++) { sendViaSocket("candidate", peers.candidateCache[i], id); } } } pc.oniceconnectionstatechange = function (event) { if (pc.iceConnectionState == "disconnected") { connection_num.innerText = parseInt(connection_num.innerText) - 1; delete peers; } } } function bindEvents (channel) { channel.onopen = function () { connection_num.innerText = parseInt(connection_num.innerText) + 1; }; channel.onmessage = function (e) { chatlog.innerHTML += "

"; }; }

2.5. SDP санал, SDP хариулт, ICE нэр дэвшигч

Эдгээр мессежүүдийн аль нэгийг хүлээн авах үед бид харгалзах мессеж боловсруулагчийг дууддаг.

Function socketReceived(data) ( var json = JSON.parse(data); switch (json.type) ( case "candidate": remoteCandidateReceived(json.id, json.data); завсарлага; case "offer": remoteOfferReceived(json. id, json.data); завсарлага; "хариулт" тохиолдол: remoteAnswerReceived(json.id, json.data); завсарлага; ) )

2.5.0 SDP санал

функц remoteOfferReceived(id, өгөгдөл) ( createConnection(id); var pc = peers.connection; pc.setRemoteDescription (шинэ SessionDescription(өгөгдөл)); pc.createAnswer(функц(хариулт) ( pc.setLocalDescription(хариу); )); ) функц createConnection(id) ( if (peers === тодорхойгүй) ( peers = (candidateCache: ); var pc = new PeerConnection(сервер, сонголтууд); initConnection(pc, id, "хариу"); peers.connection = pc ; pc.ondatachannel = функц(e) ( peers.channel = e.channel; peers.channel.owner = id; bindEvents(peers.channel); ) ) )

2.5.1 SDP хариултууд

remoteAnswerReceived(id, өгөгдөл) функц ( var pc = peers.connection; pc.setRemoteDescription(шинэ SessionDescription(өгөгдөл)); )

2.5.2 ICE нэр дэвшигч

функц remoteCandidateReceived(id, data) ( createConnection(id); var pc = peers.connection; pc.addIceCandidate(шинэ IceCandidate(өгөгдөл)); )

2.6. Мессеж илгээж байна

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

Европын интернет хэрэглэгчдийг хоёр хэсэгт хуваадаг: Алленбах (Герман) дахь Олон нийтийн санаа бодлыг шинжлэх хүрээлэнгийн судалгаагаар 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 (Вэб бодит цагийн харилцааны товчлол) нь хөтчүүд болон гар утасны програмуудын хооронд аудио болон видео дамжуулалтын өгөгдлийг дамжуулах боломжийг олгодог технологи юм.

Энэ технологийн хөгжил нь Skype-тай өрсөлдөж байна. WebRTC-ийг хөтөч дээр шууд видео хурал зохион байгуулахад ашиглаж болно. Төсөл нь нээлттэй эх сурвалж бөгөөд идэвхтэй сурталчилж байна Googleялангуяа хөтөч хөгжүүлэлтийн баг Гүүгл Кром.

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

WebRTC технологийг бүх алдартай хөтчүүд дэмждэг Mozilla Firefox, Opera, Google Chrome (мөн Google Chrome дээр суурилсан бүх хөтчүүд), мөн гар утасны програмууд Android дээр суурилсанболон iOS.

WebRTC-ийн аюул

WebRTC технологийн аюул нь таны жинхэнэ IP хаягийг тодорхойлоход оршдог. Учир нь холболт нь өөр хэрэглэгч, хөтөч, вэбсайт, эсвэл гар утасны програм, сүлжээний тохиргоог үл тоомсорлодог. Аудио болон видео холбоос үүсгэхийн тулд хөтчүүд гадаад болон дотоод IP хаягийг солилцох ёстой.

Нэргүй VPN үйлчилгээшийддэг энэ асуудалмөн жинхэнэ IP хаягийг нуудаг. Олж болох дээд хэмжээ нь хэрэглэгчдэд олгосон локал IP хаяг юм VPN сүлжээ. Энэ нь тийм ч аюултай биш, учир нь та интернетийг хуваалцахдаа чиглүүлэгч ашиглавал ижил локал IP хаягууд харагдах болно.

Хэрэв та прокси ашиглаж байгаа бол WebRTC нь прокси эсвэл IP хаягийн ард таны жинхэнэ IP хаягийг тодорхойлох боломжтой болно VPN серверүүдхэрэв та VPN + прокси сүлжээ ашиглаж байгаа бол.

WebRTC нь ашиглах үед таны жинхэнэ IP хаягийг мөн тодорхойлдог Tor сүлжээнүүд.

Ихэнх хамгийн сайн шийдэл– Хэрэв та үүнийг ашиглахгүй бол WebRTC технологийг идэвхгүй болго.

Хөтөч дээр WebRTC-г хэрхэн идэвхгүй болгох вэ

Энэ хуудсан дээр хурдан навигаци.

Mozilla Firefox дээр WebRTC-г хэрхэн идэвхгүй болгох вэ

Mozilla Firefox хөтөч нь нэмэлт залгаас суулгахгүйгээр WebRTC технологийг идэвхгүй болгох боломжийг олгодог цорын ганц хөтөч юм.

Гараар тохируулах

Хэрэв та WebRTC технологийг ашиглаагүй бол үүнийг бүрэн идэвхгүй болгож болно. WebRTC-ийг үе үе ашиглах шаардлагатай тохиолдолд ашиглахад илүү тохиромжтой.

Mozilla Firefox дээр WebRTC технологийг идэвхгүй болгохын тулд та үүнийг хийх хэрэгтэй хаягийн мөрхөтөч дээр дараах текстийг оруулаад Enter товчийг дарна уу.

Тухай: тохиргоо

"Би эрсдэлийг хүлээн зөвшөөрч байна" товчийг дарна уу.

Дараахыг хий.

1. Хайлтын талбарт текст оруулаад Enter дарна уу.
media.peerconnection.enabled
2. Нэг мөрөнд хулганы баруун товчийг дараад Toggle-г сонгоно уу. Эсвэл мөрөнд давхар товш.

Эдгээр алхмуудын дараа WebRTC идэвхгүй болно.

WebRTC Control залгаасаар дамжуулан тохиргоо

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

Нэмэлтүүдийг нээнэ үү.

Сонгох:

1. Хэсэг хайх
2. Хайлтын талбарт залгаасын нэрийг оруулна уу: WebRTC хяналт
3. Суулгах дээр дарна уу

Opera хөтөч дээр WebRTC-г хэрхэн идэвхгүй болгох вэ

WebRTC-г идэвхгүй болгохын тулд Opera хөтөчөргөтгөлүүдийн галлерей руу очно уу.

Дараахыг хий.

1. Нэвтрүүлгийн нэрийг оруулна уу хайлтын шугам: WebRTC хяналт
2. Plugin дээр дарна уу

Opera дээр нэмэх дээр дарна уу.

Plugin-ийг идэвхжүүлнэ үү. WebRTC-г хаахын тулд залгаасын дүрс цэнхэр өнгөтэй болно.

Google Chrome дээр WebRTC-г хэрхэн идэвхгүй болгох вэ

WebRTC-г идэвхгүй болгохын тулд Google хөтөч Chrome, Өргөтгөл хэсэг рүү очно уу.

Хуудсыг доош гүйлгээд Бусад өргөтгөлүүд дээр дарна уу.

Дараахыг хий.

1. Хайлтын талбарт залгаасын нэрийг оруулна уу: WebRTC хяналт
2. Суулгах товчийг дарна уу.

Plugin-ийг идэвхжүүлнэ үү. WebRTC-г хаахын тулд залгаасын дүрс цэнхэр өнгөтэй болно.

Yandex хөтөч дээр WebRTC-г хэрхэн идэвхгүй болгох вэ

Yandex Browser дээрх WebRTC-г идэвхгүй болгохын тулд Нэмэлтүүд хэсэгт очно уу.

Хуудсыг доош гүйлгээд Yandex хөтөчийн өргөтгөлүүдийн лавлах дээр дарна уу.

Эдгээр алхмуудыг дагана уу:

1. Хайлтын талбарт залгаасын нэрийг оруулна уу: WebRTC хяналт
2. Суулгахын тулд залгаас дээр дарна уу.

Yandex хөтөч дээр нэмэх дээр дарна уу.

Өргөтгөл суулгах дээр дарна уу.

Plugin-ийг идэвхжүүлнэ үү. WebRTC-г хаахын тулд залгаасын дүрс цэнхэр өнгөтэй болно.

SRWare Iron Browser дээрх WebRTC-г хэрхэн идэвхгүй болгох вэ

SRWare Iron хөтөч нь Google Chrome дээр суурилсан.

-ийн зааврын дагуу WebRTC Control залгаасыг суулгана уу.