TURN Server: bu nima, qanday ishlaydi va qayerda qo'llaniladi

TURN Server nima

TURN Server (Traversal Using Relays around NAT) — bu RFC 5766 da belgilangan va RFC 8656 da yangilangan tarmoq xizmati bo'lib, NAT yoki firewall cheklovlari tufayli to'g'ridan-to'g'ri P2P ulanishi imkonsiz bo'lganda ikki mijoz o'rtasida UDP va TCP trafigini qayta uzatadi. WebRTC arxitekturasida TURN serveri har qanday tarmoq sharoitida ulanishni kafolatlovchi yakuniy zaxira mexanizmi sifatida ishlaydi.

STUN dan farqli o'laroq, u faqat mijozga uning tashqi manzilini bildiradi, TURN serveri ma'lumotlarni uzatishda faol ishtirok etadi. Har bir peer TURN serveri bilan ulanish o'rnatadi va unga o'z media ma'lumotlarini yuboradi. TURN serveri o'z navbatida bu ma'lumotlarni boshqa peerga yo'naltiradi. Natijada, peerlar o'rtasida to'g'ridan-to'g'ri ulanish mavjud emas — barcha trafik rele serveri orqali o'tadi, bu esa eng qattiq NAT cheklovlarida ham yetkazib berishni kafolatlaydi.

TURN protokoli

TURN STUN protokolining kengaytmasidir. TURN xabarlari bir xil 20 baytlik sarlavha va atributlar mexanizmidan foydalanadi. Asosiy farq shundaki, TURN rele alokatsiyalarini boshqarish uchun yangi xabar turlari (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) va atributlarni belgilaydi. Mijoz Allocate xabari orqali TURN serverida alokatsiya yaratadi, rele transport manzilini (relayed transport address) oladi va undan server orqali ma'lumot yuborish va qabul qilish uchun foydalanadi.

TURN serveri qanday ishlaydi

TURN serveri quyidagi qadamlar ketma-ketligi bo'yicha ishlaydi. Mijoz autentifikatsiya bilan (username, credential) Allocate Request yuboradi. Server hisob ma'lumotlarini tekshiradi va alokatsiya — rele manzilining (TURN serveridagi IP:port) mijozga vaqtincha bog'lanishini yaratadi. Server relayed transport address bilan Allocate Response qaytaradi — boshqa peerlar ushbu mijozga TURN serveri orqali ma'lumot yuborish uchun foydalanadigan manzil.

Alokatsiya yaratilgandan so'ng, mijoz Send Indication xabarlari yoki kanallar (ChannelBind) orqali TURN serveri orqali ma'lumot yuborishi mumkin. Mijozdan ma'lumot olinganda, TURN serveri ruxsatlarni (permissions) tekshiradi va ma'lumotlarni maqsadli peerga qayta uzatadi. Kiruvchi ma'lumotlarni qabul qilish uchun mijoz avval ma'lumot kutayotgan peer uchun ruxsat yaratishi kerak, aks holda TURN serveri kiruvchi paketni rad etadi. Ruxsat peerning IP manzilini ko'rsatuvchi CreatePermission xabari orqali yaratiladi.

Alokatsiya va amal qilish muddati

TURN serveridagi alokatsiya cheklangan amal qilish muddatiga ega — standart 10 daqiqa. Mijoz alokatsiyani uzaytirish uchun davriy ravishda Refresh Request yuborishi kerak. Amal qilish muddati LIFETIME atributida soniyalarda ko'rsatiladi. Refresh bo'lmaganda server alokatsiyani o'chiradi va rele manzilini bo'shatadi. Tavsiya etiladigan yangilash intervali Refresh paketlarini yo'qotishdan himoyalanish uchun 5 daqiqa (300 soniya).

TURN serverini WebRTC da sozlash

WebRTC da TURN serveri RTCPeerConnection sozlamalarida iceServers massivida sozlanadi. TURN serverlari ham UDP, ham TCP yoki TLS transportidan foydalanishi mumkin. Autentifikatsiya uchun odatda ilova serverida yaratilgan va vaqt chekloviga ega vaqtinchalik hisob ma'lumotlari (TURN credentials) ishlatiladi.

JavaScript da HMAC-SHA1 tokeni bilan TURN serverini sozlash misolini ko'rib chiqamiz.

async function createPeerConnection(turnServerUrl) {
    const credentials = await fetchTurnCredentials();

    const config = {
        iceServers: [
            {
                urls: "stun:stun.l.google.com:19302"
            },
            {
                urls: turnServerUrl,
                username: credentials.username,
                credential: credentials.credential
            }
        ],
        iceTransportPolicy: "all"
    };

    return new RTCPeerConnection(config);
}

async function fetchTurnCredentials() {
    const response = await fetch("/api/turn-credentials");
    return response.json();
}

const turnUrl = "turn:turn.example.com:3478";
const pc = await createPeerConnection(turnUrl);

Ushbu misolda TURN serveri STUN serveri bilan birgalikda yagona ICE sozlamasida ko'rsatilgan. ICE jarayoni avval host nomzodlari va STUN dan olingan srflx nomzodlaridan foydalanishga harakat qiladi. To'g'ridan-to'g'ri ulanish muvaffaqiyatsiz bo'lsa, ICE avtomatik ravishda TURN serveridan olingan rele nomzodiga o'tadi. iceTransportPolicy: "all" parametri rele nomzodlariga ruxsat beradi — muqobil "relay" qiymati TURN dan boshqa barcha nomzodlarni taqiqlaydi, bu test qilish uchun foydali.

TURN serveri autentifikatsiyasi

Ruxsatsiz foydalanishni oldini olish uchun TURN serveri autentifikatsiyani talab qiladi. Standart yondashuv — ilova serverida HMAC-SHA1 yordamida yaratiladigan vaqtinchalik hisob ma'lumotlari (time-limited credentials). Ilova serveri foydalanuvchi nomini TURN serverining maxfiy kaliti bilan shifrlaydi va mijozga foydalanuvchi nomi va ishonchnoma qaytaradi. Mijoz ularni RTCPeerConnection sozlamasiga uzatadi, brauzer esa ulardan TURN serverida alokatsiya yaratishda foydalanadi. Hisob ma'lumotlarining muddati tugagach, mijoz ilova serveridan yangilarini oladi.

TURN vs STUN: taqqoslash

TURN va STUN NAT dan o'tish bilan bog'liq o'xshash vazifalarni hal qiladi, ammo mexanizm va narx jihatidan tubdan farqlanadi. TURN trafikni qayta uzatib, vositechi rolini o'ynaydi, STUN esa faqat to'g'ridan-to'g'ri P2P ulanishi uchun tashqi manzilni aniqlashga yordam beradi. Ularning o'rtasida tanlov peerlarning NAT turi va ishlash talablari bilan belgilanadi.

Amalda TURN serveri faqat P2P imkonsiz bo'lgan ulanishlar uchun ishlatiladi. Google ma'lumotlariga ko'ra (WebRTC statistikasi, 2023), barcha WebRTC ulanishlarining taxminan 15–20% TURN qayta uzatishni talab qiladi. Qolgan 80–85% STUN yoki mahalliy host nomzodlari orqali o'rnatiladi. Ilovani loyihalashda, agar auditoriya korporativ tarmoqlar va qattiq NAT cheklovlari bo'lgan mintaqalardan foydalanuvchilarni o'z ichiga olsa, umumiy media ma'lumotlari hajmining 15–20% miqdorida TURN trafigi uchun byudjet ajratilishi kerak.

TURN serverining narxi va ishlashi

TURN serveri sezilarli resurslarni iste'mol qiladi, chunki barcha media trafigi undan o'tadi. TURN qayta uzatishi bo'lgan har bir faol qo'ng'iroq media trafigining umumiy o'tkazish qobiliyatiga teng server tarmoq kengligidan foydalanadi (kiruvchi + chiquvchi oqim). HD sifatli (720p) video qo'ng'iroq uchun bu har bir yo'nalishda ulanish uchun 1,5–2,5 Mb/s, ya'ni TURN serveri orqali umumiy 3–5 Mb/s trafik bo'lishi mumkin.

TURN infratuzilmasini joylashtirishning bir nechta variantlari mavjud. Bepul umumiy TURN serverlari sifat va xavfsizlik kafolatlari yo'qligi sababli ishlab chiqarish muhiti uchun tavsiya etilmaydi. Tijorat provayderlari (Twilio Network Traversal Service, Xirsys, Metered) TURN ni gigabayt trafik uchun to'lanadigan xizmat sifatida taklif qiladi — odatdagi narx gigabayt uchun $0,005–0,02. coturn (ochiq manbali TURN serveri) asosida o'z joylashtirishingiz yetarli o'tkazish qobiliyatiga ega server va monitoring sozlamasini talab qiladi.

• coturn — eng mashhur ochiq manbali TURN serveri, ko'pchilik ishlab chiqarish tizimlarida qo'llaniladi, UDP, TCP, TLS va DTLS transportini qo'llab-quvvatlaydi.
• Twilio — trafik uchun to'lov va vaqtinchalik tokenlar bilan autentifikatsiya orqali TURN + STUN taklif qiluvchi tijorat xizmati.
• Xirsys — global server tarmog'i va batafsil foydalanish analitikasi bilan ixtisoslashgan TURN provayderi.
• Metered.ca — oyiga 50 GB gacha bepul limiti va limitdan yuqori to'lovi bo'lgan TURN xizmati.
• Self-hosted coturn — sozlash ustidan to'liq nazorat, ammo serverni boshqarish va mavjudlik monitoringini o'rnatish talab qilinadi.

TURN serveri uchun yechim tanlashda foydalanuvchilar geografiyasi, trafik narxi va xavfsizlik talablarini hisobga olish kerak. Minglab bir vaqtda qo'ng'iroqlari bo'lgan ilovalar uchun keng kanalli (1+ Gb/s) serverlarda self-hosted coturn tijorat provayderlaridan tejamkorroq bo'lishi mumkin. O'nlab foydalanuvchilari bo'lgan kichik loyihalar uchun tijorat TURN xizmatlari boshqaruv va monitoring xarajatlarining yo'qligi sababli afzalroqdir.