TURN सर्वर: यह क्या है, कैसे काम करता है और कहाँ उपयोग होता है

TURN सर्वर क्या है

TURN सर्वर (Traversal Using Relays around NAT) RFC 5766 में परिभाषित और RFC 8656 में अद्यतन एक नेटवर्क सेवा है जो दो क्लाइंट के बीच UDP और TCP ट्रैफ़िक को रिले करती है जब NAT या फ़ायरवॉल प्रतिबंधों के कारण सीधा P2P कनेक्शन असंभव हो। WebRTC आर्किटेक्चर में, TURN सर्वर अंतिम फ़ॉलबैक तंत्र के रूप में कार्य करता है, जो किसी भी नेटवर्क स्थितियों में कनेक्टिविटी की गारंटी देता है।

STUN के विपरीत, जो केवल क्लाइंट को उसका बाहरी पता बताता है, TURN सर्वर डेटा ट्रांसमिशन में सक्रिय रूप से भाग लेता है। प्रत्येक पीयर TURN सर्वर से कनेक्शन स्थापित करता है और उसे अपना मीडिया डेटा भेजता है। TURN सर्वर, बदले में, इस डेटा को दूसरे पीयर को अग्रेषित करता है। परिणामस्वरूप, पीयर के बीच कोई सीधा कनेक्शन नहीं होता — सारा ट्रैफ़िक रिले सर्वर के माध्यम से गुज़रता है, जो सबसे सख्त NAT प्रतिबंधों के तहत भी डिलीवरी सुनिश्चित करता है।

TURN प्रोटोकॉल

TURN STUN प्रोटोकॉल का एक विस्तार है। TURN संदेश समान 20-बाइट हेडर और विशेषता तंत्र का उपयोग करते हैं। मुख्य अंतर यह है कि TURN नए संदेश प्रकार (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) और रिले आवंटन प्रबंधन के लिए आवश्यक विशेषताओं को परिभाषित करता है। क्लाइंट Allocate संदेश के माध्यम से TURN सर्वर पर एक आवंटन बनाता है, एक रिलेड ट्रांसपोर्ट पता प्राप्त करता है, और सर्वर के माध्यम से डेटा भेजने और प्राप्त करने के लिए इसका उपयोग करता है।

TURN सर्वर कैसे काम करता है

TURN सर्वर निम्नलिखित चरणों के अनुक्रम के अनुसार काम करता है। क्लाइंट प्रमाणीकरण (username, credential) के साथ Allocate Request भेजता है। सर्वर क्रेडेंशियल सत्यापित करता है और एक आवंटन बनाता है — क्लाइंट के लिए एक रिलेड पते (TURN सर्वर पर IP:पोर्ट) का अस्थायी बंधन। सर्वर रिलेड ट्रांसपोर्ट पते के साथ Allocate Response लौटाता है — वह पता जिसका उपयोग अन्य पीयर TURN सर्वर के माध्यम से इस क्लाइंट को डेटा भेजने के लिए करेंगे।

आवंटन बनने के बाद, क्लाइंट Send Indication संदेशों या चैनलों (ChannelBind) के माध्यम से TURN सर्वर के माध्यम से डेटा भेज सकता है। क्लाइंट से डेटा प्राप्त करने पर, TURN सर्वर अनुमतियाँ (विशिष्ट पीयर को डेटा भेजने का प्राधिकरण) जाँचता है और डेटा को लक्ष्य पीयर को रिले करता है। इनकमिंग डेटा प्राप्त करने के लिए, क्लाइंट को पहले उस पीयर के लिए अनुमति बनानी होगी जिससे वह डेटा की अपेक्षा करता है; अन्यथा TURN सर्वर इनकमिंग पैकेट को छोड़ देगा। अनुमति पीयर के IP पते को निर्दिष्ट करते हुए CreatePermission संदेश के माध्यम से बनाई जाती है।

आवंटन और जीवनकाल

TURN सर्वर पर आवंटन का सीमित जीवनकाल होता है — डिफ़ॉल्ट रूप से 10 मिनट। क्लाइंट को आवंटन बढ़ाने के लिए समय-समय पर Refresh Request भेजना होता है। जीवनकाल LIFETIME विशेषता में सेकंड में निर्दिष्ट किया जाता है। यदि कोई Refresh प्राप्त नहीं होता है, तो सर्वर आवंटन हटा देता है और रिलेड पता मुक्त कर देता है। अनुशंसित रिफ़्रेश अंतराल — 5 मिनट (300 सेकंड) Refresh पैकेट हानि से बचाव के लिए।

WebRTC में TURN सर्वर कॉन्फ़िगर करना

WebRTC में, TURN सर्वर iceServers ऐरे में RTCPeerConnection कॉन्फ़िगरेशन के माध्यम से कॉन्फ़िगर किया जाता है। TURN सर्वर UDP, TCP या TLS ट्रांसपोर्ट का उपयोग कर सकते हैं। प्रमाणीकरण आमतौर पर एप्लिकेशन सर्वर पर सीमित वैधता अवधि के साथ उत्पन्न समय-सीमित क्रेडेंशियल (TURN क्रेडेंशियल) का उपयोग करता है।

JavaScript में HMAC-SHA1 टोकन प्रमाणीकरण के साथ TURN सर्वर कॉन्फ़िगरेशन का एक उदाहरण देखें।

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);

इस उदाहरण में, TURN सर्वर को STUN सर्वर के साथ एकल ICE कॉन्फ़िगरेशन में निर्दिष्ट किया गया है। ICE प्रक्रिया पहले host उम्मीदवारों और STUN से प्राप्त srflx उम्मीदवारों का उपयोग करने का प्रयास करती है। यदि सीधा कनेक्शन विफल होता है, तो ICE स्वचालित रूप से TURN सर्वर से प्राप्त relay उम्मीदवार पर स्विच हो जाता है। पैरामीटर iceTransportPolicy: "all" relay उम्मीदवारों को सक्षम करता है — वैकल्पिक मान "relay" TURN को छोड़कर सभी उम्मीदवारों को अक्षम करता है, जो परीक्षण के लिए उपयोगी है।

TURN सर्वर प्रमाणीकरण

अनधिकृत उपयोग को रोकने के लिए, TURN सर्वर को प्रमाणीकरण की आवश्यकता होती है। मानक दृष्टिकोण HMAC-SHA1 का उपयोग करके एप्लिकेशन सर्वर पर उत्पन्न समय-सीमित क्रेडेंशियल है। एप्लिकेशन सर्वर TURN सर्वर की गुप्त कुंजी के साथ उपयोगकर्ता नाम को एन्क्रिप्ट करता है और क्लाइंट को username और credential लौटाता है। क्लाइंट उन्हें RTCPeerConnection कॉन्फ़िगरेशन में पास करता है, और ब्राउज़र TURN सर्वर पर आवंटन बनाते समय उनका उपयोग करता है। क्रेडेंशियल की समाप्ति पर, क्लाइंट एप्लिकेशन सर्वर से नए प्राप्त करता है।

TURN बनाम STUN: तुलना

TURN और STUN संबंधित NAT ट्रैवर्सल कार्यों को हल करते हैं लेकिन तंत्र और लागत में मौलिक रूप से भिन्न हैं। TURN ट्रैफ़िक को रिले करता है, मध्यस्थ के रूप में कार्य करता है, जबकि STUN केवल सीधे P2P कनेक्शन के लिए बाहरी पता निर्धारित करने में मदद करता है। उनके बीच चुनाव पीयर NAT प्रकार और प्रदर्शन आवश्यकताओं पर निर्भर करता है।

व्यवहार में, TURN सर्वर का उपयोग केवल उन कनेक्शनों के लिए किया जाता है जहाँ P2P असंभव है। Google के अनुसार (WebRTC आँकड़े, 2023), लगभग 15–20% सभी WebRTC कनेक्शनों को TURN रिले की आवश्यकता होती है। शेष 80–85% STUN या स्थानीय host उम्मीदवारों के माध्यम से कनेक्टिविटी स्थापित करते हैं। एप्लिकेशन डिज़ाइन करते समय, आपको कुल मीडिया वॉल्यूम के 15–20% पर TURN ट्रैफ़िक के लिए बजट बनाना चाहिए यदि आपके दर्शकों में कॉर्पोरेट नेटवर्क और सख्त NAT प्रतिबंधों वाले क्षेत्रों के उपयोगकर्ता शामिल हैं।

TURN सर्वर की लागत और प्रदर्शन

TURN सर्वर महत्वपूर्ण संसाधनों की खपत करता है क्योंकि सारा मीडिया ट्रैफ़िक इसके माध्यम से गुज़रता है। TURN रिले वाली प्रत्येक सक्रिय कॉल कुल मीडिया ट्रैफ़िक थ्रूपुट (इनकमिंग + आउटगोइंग स्ट्रीम) के बराबर सर्वर बैंडविड्थ का उपयोग करती है। HD वीडियो कॉल (720p) के लिए, यह प्रति कनेक्शन प्रत्येक दिशा में 1.5–2.5 Mbps हो सकता है, जो TURN सर्वर के माध्यमից कुल 3–5 Mbps ट्रैफ़िक होता है।

TURN इन्फ्रास्ट्रक्चर के लिए कई डिप्लॉयमेंट विकल्प हैं। गुणवत्ता और सुरक्षा गारंटी की कमी के कारण मुफ्त सार्वजनिक TURN सर्वर प्रोडक्शन के लिए अनुशंसित नहीं हैं। वाणिज्यिक प्रदाता (Twilio Network Traversal Service, Xirsys, Metered) प्रति गीगाबाइट मूल्य निर्धारण के साथ TURN को एक सेवा के रूप में प्रदान करते हैं — विशिष्ट लागत $0.005–0.02 प्रति गीगाबाइट है। coturn (ओपन-सोर्स TURN सर्वर) के साथ सेल्फ-होस्टिंग के लिए पर्याप्त बैंडविड्थ क्षमता और मॉनिटरिंग सेटअप वाले सर्वर की आवश्यकता होती है।

• coturn — सबसे लोकप्रिय ओपन-सोर्स TURN सर्वर, अधिकांश प्रोडक्शन सिस्टम में उपयोग किया जाता है, UDP, TCP, TLS और DTLS ट्रांसपोर्ट का समर्थन करता है।
• Twilio — एक वाणिज्यिक सेवा जो ट्रैफ़िक-आधारित मूल्य निर्धारण और समय-सीमित टोकन के माध्यम से प्रमाणीकरण के साथ TURN + STUN प्रदान करती है।
• Xirsys — वैश्विक सर्वर नेटवर्क और विस्तृत उपयोग विश्लेषण के साथ एक विशेष TURN प्रदाता।
• Metered.ca — प्रति माह 50 GB तक मुफ्त सीमा और उससे अधिक के लिए भुगतान-जैसे-आप-उपयोग के साथ TURN सेवा।
• सेल्फ़-होस्टेड coturn — कॉन्फ़िगरेशन पर पूर्ण नियंत्रण, लेकिन सर्वर प्रशासन और मॉनिटरिंग सेटअप की आवश्यकता होती है।

TURN सर्वर समाधान चुनते समय, उपयोगकर्ता भूगोल, ट्रैफ़िक लागत और सुरक्षा आवश्यकताओं पर विचार करें। हज़ारों समवर्ती कॉल वाले एप्लिकेशन के लिए, विस्तृत चैनल (1+ Gbps) वाले सर्वर पर सेल्फ़-होस्टेड coturn वाणिज्यिक प्रदाताओं की तुलना में अधिक लागत-प्रभावी हो सकता है। दर्जनों उपयोगकर्ताओं वाली छोटी परियोजनाओं के लिए, प्रशासन और मॉनिटरिंग ओवरहेड की कमी के कारण वाणिज्यिक TURN सेवाएँ बेहतर हैं।