ICE Candidate: bu nima, nomzod turlari va qanday ishlaydi

ICE Candidate nima?

ICE Candidate (Interactive Connectivity Establishment Candidate) — WebRTC protokoli orqali P2P ulanishini o“rnatish jarayonida asosiy birlikdir. U ikki peer o“rtasida ma“lumotlarni uzatish uchun ishlatilishi mumkin bo“lgan IP manzil + port juftligini ifodalaydi. Har bir nomzod transport protokoli (UDP, TCP), ulanish turi va ustuvorlik haqida ma“lumotni o“z ichiga oladi.

ICE Candidate har bir qurilmada alohida shakllanadi. Qurilma barcha mavjud tarmoq interfeyslarini yig“adi, STUN serveri orqali tashqi manzilni so“raydi va TURN serveridan rele manzilini qo“shadi. Olingan nomzodlar ro“yxati SDP (Session Description Protocol) formatida signal kanali orqali uzoq peerga yuboriladi.

RFC 8445 (IETF, 2018) spetsifikatsiyasiga ko“ra, ICE nominated pairs mexanizmidan foydalanadi: barcha nomzodlar yig“ilgandan so“ng ularning STUN so“rovlari orqali juft-juft sinovdan o“tkazilishi amalga oshiriladi. Sinovdan birinchi o“tgan juft nominated (tayinlangan) deb e“lon qilinadi va multimedia uzatish uchun ishlatiladi. Qolgan juftlar ulanish uzilishi holatida zahirada qoladi.

ICE ning WebRTC stekidagi roli

WebRTC — P2P kommunikatsiyalari uchun ochiq standart, ammo qurilmalar o“rtasida to“g“ridan-to“g“ri ulanish ko“pincha NAT (Network Address Translation) va xavfsizlik devorlari tufayli imkonsizdir. ICE Candidate bir nechta muqobil ulanish yo“llarini taklif qilib, bu muammoni hal qiladi. ICE (Interactive Connectivity Establishment) protokoli WebRTC ning majburiy komponentidir va W3C WebRTC (2025) spetsifikatsiyasida tasvirlangan.

Ko“plab mobil ilova dasturchilari Google WebRTC (Android uchun) va iOS uchun native qobiqlar kabi WebRTC kutubxonalaridan foydalanadilar. Ularning har birida ICE jarayoni avtomatik boshqariladi, ammo nomzod turlarini tushunish dasturchiga server infratuzilmasini sozlash va ulanish sifatini optimallashtirish imkonini beradi.

ICE nomzodlari bilan SDP formati

ICE Candidate SDP xabari tarkibida a=candidate atributlari shaklida uzatiladi. Har bir satr foundation, component ID, transport protokoli, ustuvorlik, IP manzil, port va nomzod turini o“z ichiga oladi. Quyida turli xil turdagi uch nomzodga ega SDP fragmentining namunasi keltirilgan:

// ICE nomzodlari bilan namunaviy SDP
a=candidate:1 1 UDP 2130706431 192.168.1.10 54321 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.5 54322 typ srflx
a=candidate:3 1 TCP 1019212287 198.51.100.7 54323 typ relay raddr 203.0.113.5 rport 3478

priority maydoni nomzodlarni sinovdan o“tkazish tartibini belgilaydi. Ustuvorlik qanchalik yuqori bo“lsa, nomzod shunchalik tez tekshiriladi. Host nomzodlari har doim eng yuqori ustuvorlikka, relay esa eng past ustuvorlikka ega.

ICE nomzodlarining turlari

RFC 8445 spetsifikatsiyasi to“rttur ICE nomzodini belgilaydi, ularning har biri uzoq peerga erishishning ma“lum bir usuliga mos keladi. Nomzod turi uning ustuvorligiga, ulanishni o“rnatish vaqtiga va server infratuzilmasiga bo“lgan talablarga ta“sir qiladi.

Host nomzodlari

Host nomzod qurilmaning mahalliy tarmoq interfeysining IP manzilidan shakllanadi. Agar qurilma peer bilan bir xil mahalliy tarmoqda bo“lsa, host nomzod minimal kechikish bilan to“g“ridan-to“g“ri ulanishni ta“minlaydi. Mobil qurilmalar uchun host nomzodlari WiFi interfeysi, mobil LTE/5G ulanishi va kerak bo“lganda VPN tunnellari uchun yaratiladi.

Host nomzodlari eng yuqori ustuvorlikka (UDP uchun 2130706431) ega va birinchi bo“lib sinovdan o“tkaziladi. Agar ikkala peer ham NAT orqasida bo“lsa, ularning host nomzodlari xususiy manzillar (192.168.x.x, 10.x.x.x) bo“ladi va ular orqali to“g“ridan-to“g“ri ulanish imkonsizdir. ICE srflx va relay nomzodlarini sinovdan o“tkazishga o“tadi.

SRFLX va PRFLX nomzodlari

SRFLX (Server Reflexive) nomzod — STUN serveridan olingan tashqi IP manzil va portdir. Qurilma STUN so“rovini yuborganda, server uning NAT dan keyingi umumiy manzilini ko“radi va uni qaytaradi. Bu nomzod turli NAT lar orqasidagi peerlar o“rtasida to“g“ridan-to“g“ri ulanish o“rnatishga imkon beradi, agar ularning NAT qurilmalari Hairpinning ni qo“llab-quvvatlasa.

PRFLX (Peer Reflexive) nomzod bir peerdan STUN so“rovi kutilmagan manzilga kelganda dinamik ravishda aniqlanadi. Bu tur ikkala peer bir vaqtning o“zida so“rov yuborganda va NAT vaqtinchalik bog“lanish yaratganda paydo bo“ladi. PRFLX nomzodi srflx dan yuqori, ammo host dan past ustuvorlikka ega.

Mobil ilovalarda srflx nomzodlari WiFi va mobil tarmoq o“rtasida o“tishda ayniqsa muhimdir. Qurilma tarmoqni o“zgartirganda, IP manzil o“zgaradi va ICE nomzodlarni qayta yig“ishi kerak. Bu jarayon ICE restart deb ataladi va yangi SDP ni qayta yuborishni talab qiladi.

TURN orqali Relay nomzodlari

Relay nomzod — trafik bir peerdan ikkinchisiga uzatiladigan TURN serveridagi manzildir. Bu tur to“g“ridan-to“g“ri P2P ulanishi imkonsiz bo“lganda (simmetrik NAT, korporativ xavfsizlik devori) zaxira varianti sifatida ishlatiladi. Rele kanali kechikish qo“shadi va server yukini oshiradi, shuning uchun optimal sozlamalarda TURN serveri barcha sessiyalarning faqat 10–15% i uchun ishlatiladi.

Mashhur TURN server tatbiqlari: coturn (ochiq kod), Twilio Network Traversal, Metered TURN. TURN provayderini tanlash mobil ilovalardagi media ulanish sifatiga ta“sir qiladi — server qo“shimcha kechikishni minimallashtirish uchun geografik jihatdan foydalanuvchilarga yaqin joylashgan bo“lishi kerak.

ICE jarayoni qanday ishlaydi

ICE jarayoni — tarmoq topologiyasining noaniqligi sharoitida ishonchli P2P ulanishini ta“minlovchi ko“p bosqichli protokoldir. Algoritm RFC 8445 da tavsiflangan va to“rtta majburiy bosqichni o“z ichiga oladi: nomzodlarni yig“ish, saralash, sinovdan o“tkazish va nominatsiya.

1-bosqich: nomzodlarni yig“ish

Har bir qurilma barcha mavjud tarmoq manzillarini yig“adi. Buning uchun WebRTC dvigateli mahalliy interfeyslarni (host) sanab o“tadi, STUN serveriga so“rov yuboradi (srflx) va TURN serveridan rele manzilini so“raydi (relay). Shu bilan birga, qurilma peerdan kiruvchi STUN so“rovini olgan bo“lsa, prflx nomzodini aniqlashi mumkin.

Mobil ishlanmada bu bosqich ulanishni o“rnatish vaqti uchun muhimdir. iOS va Android da nomzodlarni yig“ish tarmoq tezligiga, STUN/TURN serverlarining mavjudligiga va faol tarmoq interfeyslari soniga qarab 200 ms dan 2 soniyagacha davom etishi mumkin.

2-bosqich: juftlarni shakllantirish va saralash

Signal kanali orqali uzoq peerdan nomzodlar ro“yxati olingandan so“ng, mahalliy ICE dvigateli barcha mumkin bo“lgan nomzod juftlarini (mahalliy + uzoq) shakllantiradi. Har bir juft RFC 8445 dan formula bo“yicha ustuvorlik oladi, bu ikkala nomzodning ustuvorliklarini va yo“nalishni (incoming/outgoing) hisobga oladi.

Juftlar ustuvorlik bo“yicha kamayish tartibida saralanadi. Eng yaxshi juftlar birinchi bo“ib sinovdan o“tkaziladi. Algoritm host-host jufti host-srflx, host-relay yoki relay-relay dan oldin tekshirilishini ta“minlaydi, oddiy tarmoq konfiguratsiyalarida ulanish kechikishini minimallashtiradi.

3-bosqich: sinovdan o“tkazish va nominatsiya

ICE har bir nomzod jufti uchun STUN-binding so“rovlarini yuboradi. Agar STUN javobi olinsa — juft haqiqiydir. Birinchi haqiqiy juft asosiy sifatida nominated (tayinlangan) bo“ladi. WebRTC dvigateli ushbu juft orqali media uzatishni boshlaydi, qolgan juftlar asosiy ishdan chiqqan taqdirda tekshirishda davom etadi.

Sinov jarayoni ko“p sonli nomzodlar bilan bir necha soniyagacha davom etishi mumkin. WebRTC taymerlardan foydalanadi: host juftlari uchun agressiv taymer (20 ms), relay uchun konservativroq (200 ms). Mobil ilova dasturchilari ICE serverlari sonini cheklash yoki iceTransportPolicy ni sozlash orqali ulanishni tezlashtirishlari mumkin.

ICE Restart

ICE restart — butun RTCPeerConnection ni qayta yaratmasdan ICE jarayonini qayta ishga tushirishdir. Tarmoq o“zgarishi, ulanish yo“qolishi yoki WiFi va mobil tarmoq o“rtasida o“tishda zarurdir. Restart vaqtida barcha joriy nomzodlar qayta o“rnatiladi va jarayon yangi ufrag va pwd yaratish bilan qaytadan boshlanadi.

iOS ishlanmasida ICE restart RTCPeerConnection da restartIce() metodi bilan chaqiriladi. Android da Google WebRTC dan PeerConnection sinfida analogik metod ishlatiladi. ICE restart ni to“g“ri qayta ishlash — beqaror tarmoq ulanishiga ega mobil qurilmalarda ishlaydigan ilovalar uchun muhim talabdir.

ICE da STUN va TURN serverlari

STUN (Session Traversal Utilities for NAT) va TURN (Traversal Using Relays around NAT) — real internet sharoitida ICE Candidate muvaffaqiyatli ulanishni kafolatlay olmaydigan asosiy server komponentlaridir. Ularning to“g“ri sozlanishi mobil ilovalardagi qo“ng“iroq sifatiga bevosita ta“sir qiladi.

STUN: tashqi manzilni aniqlash

STUN serveri qurilmaga o“zining umumiy IP manzili va NAT chiqish ulanishi uchun ajratgan portni bilish imkonini beradi. STUN protokoli RFC 8489 da belgilangan va UDP orqali 3478 portida ishlaydi, shuningdek TCP ni qo“llab-quvvatlaydi. Google bepul ishlatilishi mumkin bo“lgan umumiy STUN serverlarini taqdim etadi (stun.l.google.com:19302).

Mobil ishlanmada STUN so“rovi — 50–200 ms davom etadigan yengil operatsiyadir. Biroq, ba“zi korporativ va mobil tarmoqlar UDP trafigini bloklaydi, ICE ni STUN aloqasi uchun TCP dan foydalanishga yoki to“g“ridan-to“g“ri TURN ga o“tishga majbur qiladi.

TURN: trafikni retranslyatsiya qilish

TURN serveri — media trafigining retranslyatoridir. To“g“ridan-to“g“ri P2P ulanishi imkonsiz bo“lganda (simmetrik NAT, xavfsizlik devori), qurilma ma“lumotlarni TURN ga yuboradi, u ularni boshqa peerga uzatadi. TURN — ishonchli, ammo qimmat mexanizm: kechikish qo“shadi (30–100 ms) va barcha media sessiyalarining yig“indisiga teng o“tkazish qobiliyatini talab qiladi.

WebRTC Stats Report (2025) ma“lumotlariga ko“ra, mobil tarmoqlardagi WebRTC sessiyalarining taxminan 8–15% i TURN ni talab qiladi. TURN trafigi xarajatlarini optimallashtirish uchun dasturchilar ulanishni dastlabki sinovdan o“tkazishdan foydalanadilar va faqat P2P muvaffaqiyatsiz bo“lganda TURN kanalini faollashtiradilar.

Mobil ilova uchun STUN/TURN tanlash

Mobil loyihada ICE uchun infratuzilmani tanlashda hisobga olinadi: kechikishni minimallashtirish uchun serverlarning geografik joylashuvi, UDP va TCP qo“llab-quvvatlashi, TURN trafigi narxi va SLA. Mashhur yechimlar: mustaqil o“rnatish uchun coturn, bulutli foydalanish uchun Twilio, Agora va LiveKit.

Mobil ishlanmada ICE Candidate

Mobil dasturchilar uchun ICE Candidate ni tushunish nazariyadan tashqariga chiqadi — bu ovozli va video qo“ng“iroqlari bo“lgan ilovalarni yaratishda amaliy zaruratdir. iOS va Android platformalari WebRTC uchun native API larni taqdim etadi, ular ICE bilan ishlashni avtomatlashtiradi, ammo dasturchi ICE serverlarini sozlash va tarmoq o“zgarish hodisalarini qayta ishlash uchun javobgardir.

iOS da ICE sozlamalari

iOS da WebRTC WebRTC.framework ramkasi yoki CocoaPods orqali GoogleWebRTC kutubxonasi orqali mavjud. ICE serverlari RTCConfiguration da RTCIceServer massivi orqali sozlanadi:

let config = RTCConfiguration()
let stunServer = RTCIceServer(urlStrings: ["stun:stun.l.google.com:19302"])
let turnServer = RTCIceServer(urlStrings: ["turn:turn.example.com:3478"],
                                    username: "user",
                                    credential: "pass")
config.iceServers = [stunServer, turnServer]
let pc = RTCPeerConnection(configuration: config)

RTCPeerConnection yaratilgandan va offer() yoki answer() chaqirilgandan so“ng, dvigatel avtomatik ravishda ICE nomzodlarini yig“adi. iceGatheringStateChange hodisasi yig“ish holatining o“zgarishi haqida, iceConnectionState esa ulanish holati haqida xabar beradi.

Android da ICE sozlamalari

Android bir xil Google WebRTC kutubxonasidan foydalanadi. ICE serverlari PeerConnection.RTCConfiguration orqali o“rnatiladi. Dasturchi ICE siyosatini iceTransportsType orqali boshqarishi mumkin — relay rejimi faqat TURN dan foydalanishga majbur qiladi, bu ishonchlilikni oshiradi, ammo kechikishni ham oshiradi:

val iceServers = listOf(
    PeerConnection.IceServer.builder("stun:stun.l.google.com:19302").createIceServer(),
    PeerConnection.IceServer.builder("turn:turn.example.com:3478")
        .setUsername("user")
        .setPassword("pass")
        .createIceServer()
)
val config = PeerConnection.RTCConfiguration(iceServers)
config.iceTransportsType = PeerConnection.IceTransportsType.ALL
config.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE

bundlePolicy parametri ICE nomzodlari soniga ta“sir qiladi — MAXBUNDLE rejimi barcha media oqimlarini bitta transportda birlashtiradi, nomzodlarning umumiy sonini kamaytiradi va ulanishni tezlashtiradi.

Mobil ilovada ICE hodisalarini qayta ishlash

Dasturchi ishlashi kerak bo“lgan asosiy ICE hodisalari: ICE ulanish holati (ICE connection state), yig“ish holatining o“zgarishi (ICE gathering state) va yangi nomzodni aniqlash. ICE yig“ish va sinovdan o“tkazishni tugatgandan so“ng, uning holati connected yoki completed ga o“tadi.

Mobil tarmoqlarda tez-tez WiFi va mobil aloqa o“rtasida o“tishlar sodir bo“ladi. Tarmoq o“zgarganda ICE restart qilishi kerak, aks holda media oqimi uziladi. Dasturchilar restartIce() ni avtomatik chaqirish uchun NetworkManager (iOS) yoki ConnectivityManager (Android) monitoringini amalga oshiradilar.

Mobil ilovada ICE ni muvaffaqiyatli tatbiq etish o“z ichiga oladi: ishonchli STUN/TURN serverlarini tanlash, tarmoq o“zgarishida ICE restart ni to“g“ri qayta ishlash, UI da ulanish holatini ko“rsatish uchun iceConnectionState ni sozlash va RTCStatsReport orqali statistika monitoringi.