WebRTC में STUN/TURN/TURNS/SFU का विस्तृत विवरण और अभ्यास

12 अप्रैल, 2025

विषयसूची

वेबआरटीसी क्या है?

वेबआरटीसी (वेब रीयल-टाइम कम्युनिकेशन) एक खुली तकनीक है जो ब्राउज़रों के बीच रीयल-टाइम ऑडियो, वीडियो और डेटा संचार को सक्षम बनाती है। गूगल सहित कई कंपनियाँ इसे एक ऐसे तंत्र के रूप में मानकीकृत कर रही हैं जो बिना किसी अतिरिक्त प्लग-इन या सॉफ़्टवेयर की आवश्यकता के, केवल एक जावास्क्रिप्ट एपीआई का उपयोग करके पी2पी संचार को सक्षम बनाता है।

WebRTC में तीन मुख्य घटक होते हैं:

getUserMedia: कैमरा और माइक्रोफ़ोन जैसे उपकरणों से ऑडियो और वीडियो प्राप्त करने के लिए एक एपीआई।
RTCPeerConnection: साथियों के बीच संचार स्थापित करने और मीडिया और डेटा का आदान-प्रदान करने के लिए कोर एपीआई।
आरटीसीडेटाचैनल: एक डेटा चैनल जिसका उपयोग फ़ाइलें भेजने, चैटिंग आदि के लिए किया जा सकता है।

ये API कई वास्तविक समय अनुप्रयोगों जैसे वीडियो कॉल, ऑडियो कॉन्फ्रेंसिंग, फ़ाइल साझाकरण आदि के विकास को सक्षम करते हैं। हालाँकि, वास्तविक संचार में, NAT ट्रैवर्सल और फ़ायरवॉल के साथ समस्याएँ होती हैं, इसलिए STUN/TURN/TURNS जैसी NAT ट्रैवर्सल तकनीकों को समझना और कार्यान्वित करना आवश्यक है।

स्टन, टर्न और टर्न्स के अंतर और भूमिकाएँ

WebRTC के साथ स्थिर पीयर-टू-पीयर कनेक्शन प्राप्त करने के लिए एक NAT ट्रैवर्सल तंत्र आवश्यक है। यह लेख तीन प्रमुख तकनीकों, STUN, TURN और TURNS, का विस्तृत विवरण प्रदान करता है, जिसमें उनके तकनीकी अंतर, उपयोग परिदृश्य और लाभ-हानि शामिल हैं।

STUN एक प्रोटोकॉल है जिसका इस्तेमाल मुख्यतः NAT वातावरण में अपना बाहरी पता ढूँढ़ने के लिए किया जाता है, जबकि TURN एक ऐसा प्रोटोकॉल है जो सीधा कनेक्शन संभव न होने पर रिले सर्वर के रूप में काम करता है। दूसरी ओर, TURNS, TURN संचार को TLS के साथ एन्क्रिप्ट करता है और HTTPS की तरह ही पोर्ट 443 का इस्तेमाल करता है, जिससे कॉर्पोरेट नेटवर्क जैसे सख्त फ़ायरवॉल के पीछे संचार संभव हो जाता है।

प्रत्येक की विशेषताओं को समझकर और उनका उचित उपयोग करके, आप WebRTC संचार की सफलता दर और गुणवत्ता बढ़ा सकते हैं।

STUN (UDP) की भूमिका और विशेषताएं

STUN (NAT के लिए सत्र ट्रैवर्सल यूटिलिटीज) एक प्रोटोकॉल है जो क्लाइंट को अनुमति देता हैबाहरी IP पता और पोर्टउदाहरण के लिए, यदि आपका पीसी NAT के पीछे है, तो उसे अपना वैश्विक IP पता नहीं पता है, लेकिन वह STUN सर्वर से पूछताछ करके अपना "IP:port as seen from the external world" प्राप्त कर सकता है।

STUN सर्वर एक मिरर की तरह काम करता है और प्राप्त अनुरोध की स्रोत जानकारी को ठीक उसी रूप में लौटाता है जैसी वह है। परिणामस्वरूप, क्लाइंट अपना वैश्विक IP पता और NAT (सर्वर रिफ्लेक्सिव कैंडिडेट) द्वारा निर्दिष्ट पोर्ट नंबर पता कर सकता है।

STUN संचार आमतौर पर UDP पर किया जाता है, जिसका डिफ़ॉल्ट पोर्ट 3478 (UDP/3478) होता है। चूँकि इसके लिए UDP पर केवल हल्के, सिंगल-शॉट संचार की आवश्यकता होती है, इसलिए इसका ओवरहेड कम होता है, विलंबता कम होती है, और सर्वर पर लगभग कोई भार नहीं पड़ता। इसलिए, ऐसे वातावरण में जहाँ UDP संचार की अनुमति है, STUN का उपयोग करके NAT ट्रैवर्सल पहले किया जाता है।

STUN उपयोग परिदृश्य

यह उन वातावरणों में प्रभावी है जहाँ NAT ट्रैवर्सल की आवश्यकता होती है लेकिन UDP संचार स्वयं अवरुद्ध नहीं होता, जैसे घरेलू नेटवर्क या मोबाइल नेटवर्क। यदि STUN एक-दूसरे के बाहरी IP और पोर्ट प्राप्त कर सकता है, तो क्लाइंट सीधा (पीयर-टू-पीयर) संचार स्थापित कर सकते हैं। चूँकि संचार पथ सीधा है, विलंबता कम है और गुणवत्ता उच्च स्तर पर बनी रहती है। इसके अलावा, चूँकि सर्वर केवल IP सूचनाओं के आदान-प्रदान की सुविधा प्रदान करता है, इसलिए लागत बेहद कम रहती है। उदाहरण के लिए, ऑनलाइन गेम या वीडियो कॉल में, यदि दोनों डिवाइस अपेक्षाकृत खुले NAT के पीछे हैं, तो STUN पीयर-टू-पीयर कनेक्शन सक्षम करने के लिए पर्याप्त है।

STUN की सीमाएँ और नुकसान

STUN केवल "अपना बाहरी पता ढूँढ़ने" का एक साधन है, और NAT के प्रकार और फ़ायरवॉल प्रतिबंधों के आधार पर, केवल इसी के माध्यम से कनेक्ट करना संभव नहीं हो सकता है। विशेष रूप से, सममित NAT या सख्त फ़ायरवॉल वातावरण में, दूसरे पक्ष के पैकेट STUN द्वारा प्राप्त पते तक नहीं पहुँच सकते हैं, जिससे संचार असंभव हो जाता है।

इसके अतिरिक्त, कॉर्पोरेट नेटवर्क पर UDP संचार स्वयं अवरुद्ध हो सकता है, ऐसी स्थिति में STUN अनुरोध स्वयं प्राप्त नहीं हो सकते हैं। संक्षेप में, STUN यह निर्धारित करने का एक तंत्र है कि क्या प्रत्यक्ष संचार संभव है, और यह उन वातावरणों में काम नहीं करेगा जहाँ प्रत्यक्ष संचार भौतिक रूप से असंभव है। इसी कारण से, STUN का उपयोग ICE (नीचे वर्णित) में प्रथम-चरण के उम्मीदवारों को प्राप्त करने के लिए किया जाता है, और यदि STUN पर्याप्त नहीं है, तो इसे नीचे वर्णित TURN पर वापस लौटने के लिए डिज़ाइन किया गया है।

टर्न (यूडीपी) की भूमिका और विशेषताएं

TURN (ट्रैवर्सल यूजिंग रिलेज़ अराउंड NAT) एक प्रोटोकॉल है जो STUN के माध्यम से सीधा संचार संभव न होने पर मध्यस्थ रिले के रूप में कार्य करता है। TURN सर्वर एक वैश्विक रूप से सुलभ रिले बिंदु के रूप में कार्य करता है, जो संचार भागीदार और दूसरे पक्ष के बीच पैकेट अग्रेषित करने के लिए मध्यस्थ का काम करता है। क्लाइंट TURN सर्वर से जुड़ता है और एक रिले IP पता और पोर्ट प्राप्त करता है, जिसे रिले कैंडिडेट कहा जाता है। इसके बाद, दूसरे पक्ष के साथ मीडिया और डेटा का आदान-प्रदान उस TURN सर्वर के माध्यम से होता है।

TURN भी सामान्यतः UDP पर संचार करता है, इसलिए जब तक UDP का उपयोग होता है, यह मीडिया पैकेट्स को सीधे संचार के समान तरीके से रिले कर सकता है। डिफ़ॉल्ट रूप से, TURN प्रोटोकॉल पोर्ट 3478 (UDP) पर स्वीकार किया जाता है, STUN की तरह। भले ही आपकी फ़ायरवॉल नीति UDP पोर्ट संख्याओं को प्रतिबंधित करती हो, आप TURN को UDP/443 जैसे अनुमत पोर्ट पर भी चला सकते हैं। जब तक UDP उपलब्ध है, TCP की तुलना में बेहतर रीयल-टाइम प्रदर्शन के साथ रिले करना संभव है।

TURN उपयोग परिदृश्य

जब सीधा कनेक्शन स्थापित नहीं हो पाता, तो TURN ज़रूरी होता है। उदाहरण के लिए,यह तब होता है जब एक या दोनों पक्ष सख्त कॉर्पोरेट फ़ायरवॉल के पीछे होते हैं, या जब दोनों पक्षों के पास सममित NAT होते हैं, जिसके कारण UDP होल पंचिंग विफल हो सकती है।ऐसे वातावरण में, TURN सर्वर के माध्यम से रिले किए बिना संचार असंभव है, इसलिए TURN एक प्रकार से अंतिम उपाय के रूप में कार्य करता है।

WebRTC का लक्ष्य सभी पीयर्स को सीधे संवाद करने में सक्षम बनाना है, लेकिन अगर यह संभव न भी हो, तो TURN पर वापस जाकर संचार जारी रखा जा सकता है। वास्तविक संचालन में, सामान्य रणनीति यह है कि पहले STUN का उपयोग करके सीधा कनेक्शन बनाने का प्रयास किया जाए, और उसके विफल होने पर ही TURN रिले पर स्विच किया जाए। उदाहरण के लिए, किसी आंतरिक नेटवर्क पर वीडियो कॉन्फ्रेंस में, यदि दो पीयर्स एक-दूसरे से सीधे संवाद नहीं कर सकते, तो सिस्टम स्वचालित रूप से TURN सर्वर के माध्यम से संचार पर स्विच कर देता है, जिससे उपयोगकर्ता को पता भी न चले और बातचीत जारी रहे।

टर्न के लाभ

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

टर्न के नुकसान

इसकी सबसे बड़ी कमियाँ संसाधनों की खपत और विलंबता हैं। TURN के साथ, सभी ऑडियो और वीडियो डेटा सर्वर से होकर गुजरता है, जिसके लिए सर्वर की ओर से भारी मात्रा में बैंडविड्थ और प्रोसेसिंग पावर की आवश्यकता होती है। उदाहरण के लिए, यदि हम मान लें कि एक-से-एक वीडियो कॉल एक दिशा में 1Mbps बैंडविड्थ की खपत करती है, तो सरल गणना के अनुसार, एक साथ 1,000 उपयोगकर्ताओं के लिए 1Gbps की रिले बैंडविड्थ की आवश्यकता होगी। इससे TURN सर्वर की परिचालन लागत बढ़ जाती है, और बड़े पैमाने की सेवाओं के लिए कई TURN रिले सर्वरों की आवश्यकता होती है।

इसके अतिरिक्त, लंबा संचार पथ विलंबता को बढ़ाता है, जिसके परिणामस्वरूप वीडियो और ऑडियो समय में देरी होती है और गुणवत्ता कम हो जाती है। इसके अलावा, STUN के माध्यम से पीयर-टू-पीयर संचार की तुलना में, TURN पूरी तरह से पीयर-टू-पीयर नहीं है, इसलिए गोपनीयता के मामले में यह थोड़ा कम सुरक्षित है (हालाँकि TURN सर्वर आमतौर पर केवल अनएन्क्रिप्टेड RTP/डेटाग्राम ही रिले करते हैं और सामग्री की व्याख्या नहीं करते हैं)।

कुल मिलाकर, TURN का इस्तेमाल केवल तभी किया जाना चाहिए जब ज़रूरी हो। दरअसल, ज़्यादातर WebRTC संचार STUN का इस्तेमाल करके सीधे जोड़े जा सकते हैं, और Google के आँकड़े बताते हैं कि लगभग 861 TP3T कॉल बिना रिले (पीयर-टू-पीयर) के स्थापित होते हैं। केवल शेष लगभग 141 TP3T को ही TURN की ज़रूरत होती है, लेकिन उन 141 TP3T के लिए एक TURN इंफ्रास्ट्रक्चर का होना ज़रूरी है।

TURNS की भूमिका और विशेषताएं (TLS over TCP/443)

TURNS, "TURN over TLS" का संक्षिप्त रूप है, जिसका अर्थ है कि TURN प्रोटोकॉल के माध्यम से रिले संचार को TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) के साथ एन्क्रिप्ट किया जाता है।TURN संचार TLS (HTTPS) द्वारा सुरक्षितइसे प्रायः TCP पोर्ट 443 पर परोसा जाता है।पोर्ट 443, HTTPS के समान ही पोर्ट संख्या है, इसलिए यह आसानी से कॉर्पोरेट फायरवॉल से गुजर सकता है तथा प्रॉक्सी और सेंसरशिप को बायपास कर सकता है।.

उदाहरण के लिए, एक आंतरिक कंपनी नेटवर्क केवल पोर्ट 80 और 443 के माध्यम से बाहरी संचार की अनुमति दे सकता है, लेकिन इस स्थिति में भी, यदि TURN सर्वर पोर्ट 443 के माध्यम से TLS संचार का उपयोग करता है, तो इस बात की प्रबल संभावना है कि संचार हो पाएगा। इसके अलावा, चूँकि संचार TLS एन्क्रिप्टेड होते हैं, इसलिए वे सुरक्षित होते हैं और तीसरे पक्ष के लिए उन्हें रोकना मुश्किल होता है।

WebRTC में, सेटिंग्स"urls": "turns:turnsserver:443"यूआरआई योजना में,मोड़:आप इस TLS-एन्क्रिप्टेड TURN सर्वर का उपयोग निर्दिष्ट करके कर सकते हैं

TURNS उपयोग परिदृश्य

कॉर्पोरेट नेटवर्क जैसे सख्त प्रतिबंधित वातावरणों में, जहाँ अन्य सभी माध्यम अवरुद्ध होते हैं, TURNS WebRTC संचार के लिए उपयोगी है। यहाँ तक कि ऐसे वातावरणों में भी जहाँ सभी UDP और सामान्य TCP पोर्ट अवरुद्ध हैं, कई नीतियाँ संचार की अनुमति देती हैं, बशर्ते इसे HTTPS संचार के समान ही माना जाए, इसलिए TLS पोर्ट 443 पर TURN प्रभावी रूप से अंतिम उपाय है।

इसका उपयोग उन स्थितियों में भी किया जाता है जहां सार्वजनिक वायरलेस LAN पर कुछ पोर्ट बंद होते हैं, या जब क्लाइंट साइड पर केवल TLS संचार संभव होता है।पहले UDP, यदि वह काम न करे तो TCP, यदि वह काम न करे तो TLS से 443इसे क्रमिक वापसी के अंतिम चरण के रूप में देखा जा रहा है।

टर्न्स के लाभ

इसका सबसे बड़ा फ़ायदा इसकी उच्च फ़ायरवॉल प्रतिरोधकता है। TLS एन्क्रिप्टेड संचार को मानक HTTPS से अलग करना मुश्किल है, इसलिए इसके सख्त फ़िल्टरों से भी गुज़रने की संभावना ज़्यादा होती है। ख़ास तौर पर, किसी कंपनी में वेब कॉन्फ़्रेंसिंग सिस्टम शुरू करते समय, आंतरिक नेटवर्क से बाहरी कनेक्शन की अनुमति ज़रूरी होती है, और TCP/443 पर TLS संचार को सुरक्षा नीतियों के तहत स्वीकार किए जाने की संभावना ज़्यादा होती है। इसके अलावा, एन्क्रिप्टेड होने की वजह से, रिले सर्वर के साथ संचार की गोपनीयता सुनिश्चित की जा सकती है (ध्यान दें कि वीडियो जैसी सामग्री अक्सर WebRTC परत पर पहले से ही एन्क्रिप्टेड होती है)।

टर्न्स के नुकसान

सबसे बड़ी कमी प्रदर्शन में कमी है। TURN की विलंबता और लोड के अलावा, TLS और TCP का अतिरिक्त ओवरहेड भी है। TCP विश्वसनीय परिवहन प्रदान करता है और पैकेट हानि की स्थिति में पुनः प्रेषण तंत्र मौजूद है, लेकिन यह रीयल-टाइम मीडिया के लिए उपयुक्त नहीं है, और हानि के कारण वीडियो और ऑडियो सुचारू रूप से नहीं चल सकते हैं।

इसके अलावा, पैकेट ऑर्डरिंग के कारण टीसीपी हेड-ऑफ-लाइन ब्लॉकिंग के लिए प्रवण है,यूडीपी की तुलना में जिटर (उतार-चढ़ाव) भी बढ़ जाता हैइसके अलावा, TLS एन्क्रिप्शन और डिक्रिप्शन प्रोसेसिंग CPU पर अतिरिक्त भार डालती है। परिणामस्वरूप, यह बताया गया है कि 50 मिलीसेकंड या उससे अधिक की अतिरिक्त देरी होती है, जिससे उपयोगकर्ताओं को एक अंतराल महसूस हो सकता है। विशेष रूप से, वीडियो कॉन्फ्रेंसिंग में, यह बढ़ा हुआ विलंब बातचीत की गति को धीमा कर सकता है और समय में उल्लेखनीय विसंगतियाँ पैदा कर सकता है।

इस तरह, गुणवत्ता के संदर्भ में TURNS को "अंतिम उपाय" माना जा सकता है, लेकिन यह उन परिस्थितियों में एक विश्वसनीय जीवन रेखा भी है जहां संचार सुनिश्चित करने के अलावा कोई अन्य विकल्प नहीं है।

हाल के वर्षों में, एक नए दृष्टिकोण (TURN over QUIC) पर विचार किया गया है, जो UDP पोर्ट 443 पर संचालित होता है और TLS के स्थान पर DTLS/QUIC का उपयोग करता है, लेकिन यह अभी भी मानकीकृत होने की प्रक्रिया में है और इसका व्यापक रूप से उपयोग नहीं किया जाता है।

जब UDP STUN का उपयोग नहीं किया जा सकता, तो संचार प्रवाह

हम चरण-दर-चरण समझाएँगे कि UDP पर STUN उपलब्ध न होने पर WebRTC ICE प्रोसेसिंग कैसे आगे बढ़ती है। आइए एक ऐसी स्थिति मान लें जहाँ UDP पूरी तरह से अवरुद्ध हो, जैसे कि किसी कॉर्पोरेट नेटवर्क पर, और देखें कि ICE बातचीत कैसे वापस आती है।

क्लाइंट STUN सर्वर को बाह्य IP क्वेरी (UDP/3478) भेजता है:
WebRTC क्लाइंट (ब्राउज़र)आइस सर्वरएक बाइंडिंग अनुरोध (बाह्य पते को सत्यापित करने का अनुरोध) UDP पोर्ट 3478 के माध्यम से निर्दिष्ट STUN सर्वर को भेजा जाता है। यह ICE उम्मीदवारों को एकत्रित करने में पहला कदम है, और यदि सफल होता है, तो सर्वर अपना स्वयं का वैश्विक IP पता और पोर्ट नंबर लौटाएगा, और इसे सर्वर रिफ्लेक्सिव उम्मीदवार (srflx उम्मीदवार) के रूप में उम्मीदवार सूची में जोड़ देगा।
फ़ायरवॉल द्वारा UDP पैकेट अवरुद्ध और कोई प्रतिक्रिया नहीं:
इस स्थिति में, नेटवर्क फ़ायरवॉल सेटिंग्स UDP संचार को बाहरी नेटवर्क तक पहुँचने से रोकती हैं। इसलिए, STUN सर्वर को भेजे गए अनुरोध सर्वर तक नहीं पहुँच पाते, या प्रतिक्रिया क्लाइंट तक नहीं पहुँच पाती। परिणामस्वरूप, क्लाइंटकोई STUN प्रतिक्रिया प्राप्त नहीं हुई, बाहरी IP पता ज्ञात नहीं हो सकता। ICE एजेंट एक निश्चित अवधि तक प्रतिक्रिया की प्रतीक्षा करता है, लेकिन एक समय-सीमा समाप्त हो जाती है। उपयोगकर्ता के दृष्टिकोण से, कनेक्शन अभी भी जारी है और कोई त्रुटि संदेश प्रदर्शित नहीं होता है, लेकिन वास्तव में,उम्मीदवारों को इकट्ठा करने में विफलयह वर्तमान में हो रहा है।
ICE प्रत्यक्ष कनेक्शन जांच विफल हो जाती है क्योंकि कोई सर्वर रिफ्लेक्सिव उम्मीदवार उपलब्ध नहीं है:
सामान्यतः, यदि STUN सफल होता है, तो क्लाइंट के पास एक होस्ट कैंडिडेट (उसका स्थानीय IP) और एक सर्वर रिफ्लेक्सिव कैंडिडेट (उसका वैश्विक IP) होगा, और वह उन्हें दूरस्थ पीयर के समान कैंडिडेट के साथ संयोजित करके कनेक्शन की जाँच करेगा। हालाँकि, यदि STUN विफल हो जाता है और कोई वैश्विक IP कैंडिडेट नहीं है,प्रत्यक्ष सहकर्मी संपर्क के लिए अत्यंत सीमित उम्मीदवारउदाहरण के लिए, यदि दोनों पक्षों के पास केवल निजी IP पते हैं, तो वे कनेक्ट करने का प्रयास करने पर भी एक-दूसरे तक नहीं पहुँच पाएँगे। परिणामस्वरूप, ICE यह निर्धारित करेगा कि "प्रत्यक्ष संचार संभव नहीं है।" यदि ICE सर्वर (TURN) कॉन्फ़िगर नहीं किया गया है, तो इस स्तर पर संपूर्ण ICE को विफल माना जाएगा, और WebRTC कनेक्शन स्थापित नहीं होगा (डेवलपर कंसोल दिखाएगा)ICE विफल रहायाICE कनेक्शन स्थिति: विफलया अन्य त्रुटि प्रदर्शित होगी).
TURN रिले उम्मीदवारों को प्राप्त करने का प्रयास (TCP/TLS/443 पर):
भले ही STUN के माध्यम से प्रत्यक्ष उम्मीदवार अधिग्रहण विफल हो जाए,आइस सर्वरयदि TURN सर्वर निर्दिष्ट हैअगले कदमइस परिदृश्य में, UDP समर्थित नहीं है, इसलिए क्लाइंट TCP या TLS (उदाहरण के लिए,turns:turn.example.com:443(यदि कॉन्फ़िगर किया गया है, तो TLS हैंडशेक शुरू हो जाएगा।) सौभाग्य से, फ़ायरवॉल TCP 443 पर HTTPS संचार की अनुमति देता है, इसलिए TLS के माध्यम से TURN कनेक्शन सफल होता है। क्लाइंट TURN सर्वर पर एक रिले पता सुरक्षित करता है,रिले उम्मीदवारदूसरा पक्ष रिले कैंडिडेट्स (उम्मीदवार) प्राप्त करेगा। ये "TURN सर्वर के माध्यम से संचार के लिए वर्चुअल कैंडिडेट्स" हैं। इस बीच, दूसरा पक्ष (दूरस्थ पक्ष) भी रिले कैंडिडेट्स प्राप्त करेगा, या यदि नेटवर्क समस्या-मुक्त है, तो उसके पास डायरेक्ट कैंडिडेट्स या STUN कैंडिडेट्स होंगे। किसी भी स्थिति में, यदि कम से कम एक पक्ष के पास रिले कैंडिडेट्स हैं, तो दूसरा पक्ष उस TURN सर्वर से जुड़ने का प्रयास कर सकता है।
रिले के माध्यम से ICE कनेक्शन स्थापना (या अंततः विफलता):
एक बार जब दोनों पीयर उपलब्ध कैंडिडेट (इस उदाहरण में एक या दोनों रिले कैंडिडेट) प्राप्त कर लेते हैं, तो ICE उनका उपयोग कनेक्शन की जाँच के लिए करता है। TURN सर्वर के माध्यम से संचार, सर्वर के साथ स्थापित होने के बाद, रिले किया जा सकता है, इसलिए एक मीडिया चैनल खुला रहता है, भले ही UDP सीधे पीयर के बीच न पहुँचे। इससे उपयोगकर्ताओं के बीच वीडियो और ऑडियो संचार शुरू हो सकता है। एक बार कनेक्शन स्थापित हो जाने पर, TLS पर TCP का ओवरहेड होता है, लेकिन बातचीत स्वयं संभव है। इसके विपरीत, यदि यहाँ भी कोई विफलता होती है (उदाहरण के लिए, कोई कॉर्पोरेट प्रॉक्सी गैर-HTTP TLS संचार का पता लगाकर उसे ब्लॉक कर देता है, या TURN सर्वर प्रमाणीकरण विफल हो जाता है), तो दुर्भाग्य से, ICE विफल हो जाएगा और कनेक्शन छोड़ दिया जाएगा। एप्लिकेशन को इस स्थिति का पता लगाना होगा और उपयोगकर्ता को "कनेक्शन विफल" जैसी सूचना देनी होगी।

यह एक कठोर वातावरण में ICE बातचीत का प्रवाह है जहाँ UDP का उपयोग नहीं किया जा सकता। संक्षेप में, उम्मीदवारों को "host → STUN → TURN" क्रम में आज़माया जाता है, और यदि वह काम नहीं करता है, तो कनेक्शन विफल हो जाएगा। डेवलपर्स के लिए इस व्यवहार को समझना और कम से कम ICE सर्वर सूची में TURN/TURNS सर्वर को शामिल करना महत्वपूर्ण है, ताकि सबसे खराब स्थिति में भी संचार स्थापित किया जा सके। इसके अलावा, उपयोगकर्ताओं से पूछताछ प्राप्त करते समय, समस्या निवारण की आवश्यकता होती है, जैसे कि "ICE विफल" जैसी जानकारी से नेटवर्क वातावरण (जैसे UDP अवरोधन) में किसी समस्या का अनुमान लगाना और यह जांचना कि क्या TURN सर्वर ठीक से कॉन्फ़िगर किया गया है।

कोटर्न का उपयोग करके STUN/TURN/TURNS सर्वर का निर्माण और कॉन्फ़िगरेशन

यदि आप अपना स्वयं का STUN/TURN सर्वर स्थापित करना चाहते हैं, तो ओपन सोर्स कार्यान्वयन का उपयोग करें। कोटर्नकोटर्न का उपयोग आम है। कोटर्न एक सर्वर कार्यान्वयन है जो STUN और TURN दोनों का समर्थन करता है, और कॉन्फ़िगरेशन के आधार पर, यह TURNS (TLS) का भी समर्थन कर सकता है। यह लेख बताता है कि लिनक्स सर्वर पर कोटर्न कैसे स्थापित करें और STUN/TURN/TURNS प्रदान करने वाला सर्वर कैसे बनाएँ, साथ ही कॉन्फ़िगरेशन पॉइंट भी। इसके अलावा, हम विशिष्ट कॉन्फ़िगरेशन फ़ाइल () के बारे में भी बताएँगे।टर्नसर्वर.conf) भी दिखाया गया है.

स्थापना और बुनियादी कॉन्फ़िगरेशन

स्थापित करना

उबंटू या डेबियन के लिए,अपार्टआप कमांड लाइन से कोटर्न पैकेज इंस्टॉल कर सकते हैं। उदाहरण के लिए, इसे इंस्टॉल करने और इसे स्वचालित रूप से शुरू करने के लिए निम्न कमांड का उपयोग करें।

# Ubuntu/Debianの場合
sudo apt-get install coturn
sudo sed -i 's/#TURNSERVER_ENABLED=1/TURNSERVER_ENABLED=1/' /etc/default/coturn
sudo systemctl enable --now coturn

इससे कोटर्न सर्वर एक डेमॉन के रूप में शुरू हो जाएगा। डिफ़ॉल्ट रूप से, यह कॉन्फ़िगरेशन फ़ाइल का उपयोग करेगा /etc/turnserver.conf इससे फ़ाइल लोड हो जाएगी, और फिर आप इसे संपादित कर सकते हैं (सुरक्षा के लिए संपादन से पहले बैकअप बना लें)।

मूल सेटिंग्स

टर्नसर्वर.confअब, निम्नलिखित आइटम सेट करें:

क्षेत्र और सर्वर-नाम: यह TURN सर्वर का डोमेन नाम या पहचानकर्ता है। इसका उपयोग WebRTC क्लाइंट को प्रमाणित करते समय किया जा सकता है, लेकिन मूल रूप से यह कोई भी स्ट्रिंग हो सकती है। उदाहरण: realm=example.com,सर्वर-नाम=example.com.
श्रवण-पोर्ट: TURN और STUN के लिए सुनने हेतु UDP पोर्ट संख्या। डिफ़ॉल्ट 3478 है।सुनने-आईपीआप किसी विशिष्ट NIC से भी जुड़ सकते हैं0.0.0.0हम उन सभी को स्वीकार करते हैं।
tls-लिसनिंग-पोर्ट: यह TLS (TURNS) सुनने के लिए TCP पोर्ट नंबर है। आमतौर पर, आप 443 या 5349 निर्दिष्ट करेंगे। उदाहरण: tls-लिसनिंग-पोर्ट=443.
बाहरी-आईपी: यदि सर्वर स्वयं NAT के पीछे है, तो उसका अपना वैश्विक IP निर्दिष्ट करें (इससे सर्वर आंतरिक IP और बाहरी IP के बीच मैपिंग को पहचान सकता है)। यदि सर्वर का कोई प्रत्यक्ष वैश्विक IP है, तो यह आवश्यक नहीं है।
प्रमाणीकरण विधि: चूंकि WebRTC TURN दीर्घकालिक क्रेडेंशियल्स का उपयोग करता है,lt-cred-mech(दीर्घकालिक क्रेडेंशियल तंत्र) सक्षम है।उपयोगकर्ता=उपयोगकर्ता नाम:पासवर्डउपयोगकर्ता नाम और पासवर्ड को इस प्रारूप में सेट करेंउपयोग-प्राधिकरण-गुप्त(उत्तरार्द्ध टोकन-आधारित प्रमाणीकरण है, जो सुरक्षा में सुधार के लिए प्रभावी है, लेकिन यहां हम उदाहरण के रूप में सरल स्थैतिक उपयोगकर्ता प्रमाणीकरण दिखाएंगे।)
लॉग सेटिंग्स: समस्या निवारण के लिएबोटा दस्तावेजलॉग फ़ाइल पथ निर्दिष्ट करेंवाचालआप वर्बोज़ लॉगिंग को सक्षम करना चाह सकते हैं।

फ़ायरवॉल सेटिंग्स

सर्वर साइड पर, STUN/TURN के लिएयूडीपी पोर्ट 3478, और TURN/TLS के लिएटीसीपी पोर्ट 443(या 5349) खुला होना चाहिए। इसके अतिरिक्त, TURN रिले डिफ़ॉल्ट रूप से UDP 10000-20000 रेंज का उपयोग करता है, इसलिए सर्वर पर भी इस पोर्ट रेंज को खोलें (यदि आवश्यक हो)।मिन-पोर्टऔरअधिकतम-पोर्ट(रेंज को बदला जा सकता है

नीचे सेटिंग्स की सूची दी गई है जो उपरोक्त मूल सेटिंग्स को दर्शाती हैं।/etc/turnserver.confयहाँ एक उदाहरण है:

# TURNサーバの名称とレルム（ドメイン）
realm=example.com
server-name=example.com

# ネットワーク設定
listening-ip=0.0.0.0           # すべてのIPアドレスで待受
external-ip=203.0.113.10       # サーバのグローバルIP（必要な場合）

# ポート設定
listening-port=3478            # STUN/TURN用 UDPポート
tls-listening-port=443         # TLS用 TCPポート (443番)
min-port=10000                 # 中継に使用するポート範囲（下限）
max-port=20000                 # 中継に使用するポート範囲（上限）

# ログ設定
log-file=/var/log/turnserver.log
verbose                        # 詳細ログを有効化
fingerprint                    # パケットにfingerprint属性を付与

# 認証設定（長期認証方式）
lt-cred-mech                   # 長期認証を有効化
user=webrtcuser:secretpass123  # ユーザ名:パスワード を設定

# TLS/SSL証明書の指定
cert=/etc/letsencrypt/live/example.com/fullchain.pem   # サーバ証明書
pkey=/etc/letsencrypt/live/example.com/privkey.pem     # 秘密鍵

उपरोक्त में, डोमेनexample.comहम Let's Encrypt प्रमाणपत्र प्राप्त करते हैं और इसका उपयोग TLS कॉन्फ़िगरेशन के लिए करते हैं।lt-cred-mechदीर्घकालिक प्रमाणीकरण सक्षम करेंउपयोगकर्तासरल उपयोगकर्ता नाम और पासवर्ड प्रमाणीकरण द्वारा सेट किया गया हैउपयोग-प्राधिकरण-गुप्तऔरस्थैतिक-प्रमाणीकरण-गुप्तअनुशंसित विधि अस्थायी क्रेडेंशियल जारी करने के लिए टोकन-आधारित विधि का उपयोग करना है, लेकिन हम यहां उस पर चर्चा नहीं करेंगे।

TLS का उपयोग करते समय सावधानियां

पोर्ट 443 पर कोटर्न चलाते समय, आपको लिनक्स वातावरण में पोर्ट अनुमतियों के बारे में सावधान रहना होगा। 1024 से कम पोर्ट को विशेषाधिकार प्राप्त पोर्ट कहा जाता है और आमतौर पर रूट विशेषाधिकारों के बिना इन्हें खोला नहीं जा सकता। उबंटू कोटर्न पैकेज डिफ़ॉल्ट रूप सेटर्नसर्वरचूंकि यह उपयोगकर्ता द्वारा निष्पादित किया जाता है, इसलिए पोर्ट 443 को उसी रूप में बाउंड नहीं किया जा सकता।/etc/default/coturnचल रहे उपयोगकर्ता को रूट में बदलें, यासेटकैपआदेश के साथटर्नसर्वरनिष्पादन योग्य फ़ाइल मेंकैप_नेट_बाइंड_सर्विसअनुमतियाँ देने के कई तरीके हैं। उदाहरण के लिए, बाद वाले मामले में,सुडो सेटकैप cap_net_bind_service=+ep /usr/bin/turnserverइस कमांड को निष्पादित करके, आप रूट न होने पर भी कम संख्या वाले पोर्ट को बाइंड कर पाएँगे। साथ ही, कृपया प्रमाणपत्र फ़ाइल (cert/pkey) का सही पथ निर्दिष्ट करें और फ़ाइल अनुमतियाँ सेट करें ताकि कोटर्न उपयोगकर्ता उसे पढ़ सके। सेटिंग्स बदलने के बाद,sudo systemctl पुनरारंभ coturnसेवा को पुनः आरंभ करें और किसी भी त्रुटि के लिए लॉग की जाँच करें।

संचालन जांच

कोटर्न सर्वर शुरू करने के बाद, हम इसके संचालन की जांच करने के लिए STUN क्लाइंट का उपयोग करके इसका परीक्षण करेंगे, और फिर ब्राउज़र में WebRTC ऐप से ICE से कनेक्ट करने का प्रयास करेंगे।स्टनक्लाइंटआज्ञा(apt-get इंस्टॉल स्टन-क्लाइंट(स्थापित किया जा सकता हैstunclient <सर्वर IP> 3478आप निम्नलिखित चलाकर अपना बाहरी IP पता प्राप्त करने का प्रयास कर सकते हैं। साथ ही, आपके ब्राउज़र में, ICE उम्मीदवार डेवलपर टूल लॉग में सूचीबद्ध होंगे, इसलिएएसआरएफएलएक्स(सर्वर रिफ्लेक्सिव) उम्मीदवार औररिलेकृपया जाँच लें कि आपको कोई उम्मीदवार मिला है या नहीं। यदि नहीं, तो निम्नलिखित समस्या निवारण चरणों का प्रयास करें:

क्या सर्वर की फ़ायरवॉल सेटिंग्स (iptables और क्लाउड सुरक्षा समूह) में आवश्यक पोर्ट खुले हैं?
क्या क्लाइंट-साइड ICE सर्वर सेटिंग्स (नीचे वर्णित) में सही URI, पोर्ट और प्रमाणीकरण जानकारी सेट की गई है?
टर्नसर्वर.confकाक्षेत्रजांचें कि क्या सेटिंग्स क्लाइंट प्रमाणीकरण से मेल खाती हैं (यह आमतौर पर WebRTC के ब्राउज़र संस्करण में कोई समस्या नहीं है, क्योंकि यह स्वचालित रूप से दायरे को निर्दिष्ट करता है, लेकिन यदि आपके पास कस्टम कार्यान्वयन है तो सावधान रहें)।
कोटर्न लॉग (/var/log/turnserver.log) और जाँच करें कि क्या कोई प्रमाणीकरण त्रुटि है (गलत उपयोगकर्तायदि उपरोक्त जैसी कोई त्रुटि है, तो उपयोगकर्ता नाम/पासवर्ड मेल नहीं खाता है।

उपरोक्त सेटिंग्स के साथ, आपके पास अपना स्वयं का STUN/TURN/TURNS सर्वर चालू होगा और विभिन्न नेटवर्क वातावरणों में WebRTC कनेक्शन का समर्थन करने में सक्षम होगा।

WebRTC क्लाइंट के लिए ICE सर्वर कॉन्फ़िगरेशन उदाहरण (जावास्क्रिप्ट)

वास्तव में STUN/TURN सर्वर का उपयोग करने के लिए, जिसे हमने अभी WebRTC एप्लिकेशन (ब्राउज़र) पर बनाया है,ICE सर्वर सेटिंग्सजावास्क्रिप्ट के WebRTC API में,RTCPeerConnectionआप STUN/TURN सर्वर बनाते समय उनकी सूची निर्दिष्ट कर सकते हैं। नीचे हम एक ठोस कोड उदाहरण दिखाएंगे जो सभी STUN/TURN/TURNS को निर्दिष्ट करता है और समझाता है कि इसका क्या अर्थ है।

सबसे पहले, ICE सर्वर के लिए एक कॉन्फ़िगरेशन ऑब्जेक्ट बनाएं।turn.example.com(उपयुक्त के अनुसार प्रतिस्थापित करें) STUN के लिए प्रमाणीकरण की आवश्यकता नहीं है, इसलिए केवल URI निर्दिष्ट करें, लेकिन TURN/TURNS के लिए प्रमाणीकरण की आवश्यकता है, इसलिए उपयोगकर्ता नाम और पासवर्ड भी निर्दिष्ट करें।

const iceConfig = {
  iceServers: [
    // 1. STUNサーバ（UDP/3478）
    { urls: 'stun:turn.example.com:3478' },
    // 2. TURNサーバ（UDP/443経由）
    { urls: 'turn:turn.example.com:443?transport=udp', username: 'webrtcuser', credential: 'secretpass123' },
    // 3. TURNサーバ（TCP/443 + TLS = TURNS）
    { urls: 'turns:turn.example.com:443', username: 'webrtcuser', credential: 'secretpass123' }
  ]
};
const pc = new RTCPeerConnection(iceConfig);

उपरोक्तआइस सर्वरसारणी में तीन प्रविष्टियाँ हैं।

अचेत: स्टन:turn.example.com:3478
आपके अपने STUN सर्वर का पता निर्दिष्ट करता है (यदि पोर्ट संख्या छोड़ दी जाती है, तो 3478 का उपयोग किया जाएगा)। STUN का उपयोग NAT ट्रैवर्सल निर्धारित करने और कैंडिडेट्स प्राप्त करने के लिए किया जाता है। सर्वर रिफ्लेक्सिव कैंडिडेट्स प्राप्त करने के लिए ब्राउज़र पहले UDP के माध्यम से इस सर्वर को क्वेरी करेगा।
टर्न (यूडीपी): turn:turn.example.com:443?transport=udp
आपका अपना TURN सर्वरयूडीपी पोर्ट 443यह वह सेटिंग है जिसका उपयोग किया जाना है। प्रमाणीकरण जानकारी के रूप में पहले से सेट किया गया उपयोगकर्ता नामवेबआरटीक्यूसरऔर पासवर्डसीक्रेटपास123क्वेरी पैरामीटर निर्दिष्ट किया गया है.?परिवहन=यूडीपीइसे जोड़ने पर, UDP पर एक TURN कनेक्शन का प्रयास किया जाएगा (यदि निर्दिष्ट नहीं किया गया है, तो ब्राउज़र पहले UDP का प्रयास करेगा, और यदि वह विफल रहता है, तो TCP का प्रयास करेगा)। इस सेटिंग के साथ, यदि सामान्य STUN के माध्यम से सीधा कनेक्शन विफल भी हो जाता है, तो आपके पास UDP पोर्ट 443 पर TURN रिले के लिए एक उम्मीदवार होगा।
टर्न (TLS/TCP): turns:turn.example.com:443
TLS के साथ टर्न करें, यानी TURNS सर्वर सेटिंग्स। यहाँ एक उपयोगकर्ता नाम और पासवर्ड भी निर्दिष्ट किया गया है। ब्राउज़र TURN रिले कैंडिडेट प्राप्त करने के लिए TCP पोर्ट 443 पर इस प्रविष्टि से एक TLS कनेक्शन बनाएगा। यह अंतिम उपाय का रिले कैंडिडेट है, और यदि UDP के माध्यम से संचार बिल्कुल भी संभव नहीं है, तो भी यदि यह कैंडिडेट उपलब्ध है, तो संचार स्थापित करने की संभावना है।

RTCPeerConnectionएक बार जब ICE एजेंट srflx उत्पन्न कर लेता है, तो वह कैंडिडेट्स एकत्रित करने के लिए निर्दिष्ट ICE सर्वर से जुड़ने का प्रयास करता है। ICE एजेंट पहले STUN कैंडिडेट्स (srflx) प्राप्त करता है, फिर समानांतर रूप से TURN कैंडिडेट्स (रिले) प्राप्त करता है। फिर ICE एल्गोरिथम इन कैंडिडेट्स को संयोजित करता है, कनेक्शन जाँच करता है, और इष्टतम रूट का चयन करता है। डेवलपर्स को आगे की किसी भी प्रक्रिया के बारे में विशेष रूप से जागरूक होने की आवश्यकता नहीं है।

बिंदु: जैसा ऊपर उल्लिखित हैकई उम्मीदवार तैयार करेंमहत्वपूर्ण है। उदाहरण के लिए,अचेत:यदि आप केवल TURN (UDP) निर्दिष्ट करते हैं, तो उस वातावरण में कोई भी कैंडिडेट नहीं मिलेगा जहाँ UDP अवरुद्ध है, और कनेक्शन विफल हो जाएगा। इसी प्रकार, यदि आप केवल TURN (UDP) निर्दिष्ट करते हैं, तो यह उस वातावरण में विफल हो जाएगा जहाँ केवल TCP की अनुमति है। इसलिए, यदि संभव हो,मोड़:औरमोड़:ICE सर्वर में दोनों को शामिल करके, अतिरेक प्राप्त किया जाता है ताकि किसी भी वातावरण में कम से कम एक मान्य उम्मीदवार मिल सके (बेशक, TURN सर्वर को UDP और TCP/TLS दोनों का समर्थन भी करना होगा)। क्लाइंट (ब्राउज़र) स्वचालित रूप से एक उपलब्ध पथ का चयन करेगा, इसलिए सूची का क्रम कोई बड़ी समस्या नहीं है। अगर मुझे कहना होता,बर्फ परिवहन नीतिकारिलेजब तक आप यह निर्दिष्ट नहीं करते, ब्राउज़र सीधे कनेक्शन को प्राथमिकता देगा, इसलिए यदि आप STUN प्रविष्टि दर्ज करते हैं, तो आप TURN सर्वर का अनावश्यक उपयोग करने से बचेंगे। इसके अलावा, यदि आप ICE सर्वर सूची में अप्रासंगिक सर्वर (जैसे गैर-मौजूद पते) दर्ज करते हैं, तो समय समाप्त होने की प्रतीक्षा के कारण देरी होने की संभावना है, इसलिए केवल उन्हीं सर्वरों को दर्ज करना सबसे अच्छा है जिनके उपलब्ध होने के बारे में आपको यकीन हो।

अंत में, इस सेटिंग को लागू करके WebRTC एप्लिकेशन चलाएँ और कनेक्शन स्थिति सत्यापित करें।पीयरकनेक्शन.getStats()याchrome://webrtc-internalsआप क्रोम में ICE कैंडिडेट और कनेक्शन स्थिति की जाँच कर सकते हैं। अगर यह अपेक्षानुसार काम करता है, तो यह उन परिवेशों में जहाँ UDP उपलब्ध है, सीधे (P2P) कनेक्शन पर और उन परिवेशों में जहाँ यह मुश्किल है, TURN/TLS के माध्यम से कनेक्शन पर स्वतः वापस आ जाएगा।

एसएफयू और टर्न के बीच अंतर

WebRTC रिले को मोटे तौर पर "TURN" और "SFU" में विभाजित किया जा सकता है, लेकिन उनकी भूमिकाएँ, कॉन्फ़िगरेशन और उपयोग काफ़ी अलग हैं। यहाँ हम तकनीकी अंतरों को स्पष्ट करेंगे।

टर्न: पीयर-टू-पीयर के विकल्प के रूप में रिले

TURN (ट्रैवर्सल यूजिंग रिलेज़ अराउंड NAT) एक सहायक रिले सर्वर है जिसका उपयोग ऐसे वातावरण में किया जाता है जहाँ WebRTC P2P संचार संभव नहीं है। TURN सर्वर पीयर्स के बीच एक रिले के रूप में कार्य करता है, और पैकेट्स को मुख्यतः तब रिले करता है जब STUN NAT या फ़ायरवॉल के कारण काम नहीं करता। चूँकि प्रत्येक पीयर अपने संबंधित संचार पार्टनर को अलग-अलग स्ट्रीम भेजता है, इसलिए कॉन्फ़िगरेशन अनिवार्य रूप से एक मेश होता है, और TURN को "पिंच हिटर" के रूप में तैनात किया जाता है।

संघटन: प्रत्येक उपयोगकर्ता एक रिले (प्रभावी रूप से एक जाल) के माध्यम से एक दूसरे को भेजता है
अनुमापकता: कम (जितने अधिक लोग होंगे, भार उतना अधिक होगा)
प्रसारण सामग्रीकेवल सरल पैकेट स्थानांतरण, कोई मीडिया विश्लेषण या अनुकूलन नहीं

एसएफयू: बहु-पक्षीय कॉल के लिए कुशल रिले

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

संघटन: स्टार प्रकार जहां प्रत्येक क्लाइंट एक SFU से जुड़ा होता है
अनुमापकता: महँगा (लोगों की संख्या बढ़ने पर भी केवल एक प्रसारण)
प्रसारण सामग्री: स्थानांतरण गंतव्य का नियंत्रण और मीडिया अनुकूलन संभव है

TURN बनाम SFU तुलना चार्ट

विशेषताएँ	मोड़	एसएफयू
उद्देश्य	जब NAT ट्रैवर्सल संभव न हो तो विकल्प	बहु-व्यक्ति वास्तविक समय संचार
संचार कॉन्फ़िगरेशन	जाल (एक दूसरे को प्रेषित)	स्टार प्रकार (एकल संचरण)
रिले फ़ंक्शन	सरल रिले (पारदर्शी)	चयनात्मक अग्रेषण और अनुकूलन उपलब्ध
अनुमापकता	कम	महँगा
मीडिया नियंत्रण	कोई नहीं	हाँ (जैसे स्पीकर पहचान, रिज़ॉल्यूशन समायोजन)

टर्न केवल एक "अंतिम उपाय है जब पी2पी संचार संभव नहीं होता है," और यह एक रिले है जो पी2पी मेश का पूरक है।एसएफयू एक रिले आर्किटेक्चर है जिसे बहु-पक्षीय कॉल के लिए शुरू से ही कुशल बनाने के लिए डिज़ाइन किया गया है।चूंकि दोनों की भूमिकाएं मौलिक रूप से भिन्न हैं, इसलिए उन्हें भ्रमित किए बिना डिजाइन करना महत्वपूर्ण है।

सारांश

यह आलेख मध्यम से उन्नत WebRTC उपयोगकर्ताओं के लिए STUN, TURN और TURNS के बीच तकनीकी अंतर के बारे में विस्तृत व्याख्या प्रदान करता है, साथ ही coturn का उपयोग करके सर्वर बनाने के तरीके और कठोर नेटवर्क वातावरण में ICE कैसे व्यवहार करता है, इसके उदाहरण भी प्रदान करता है।

अचेतहल्का है और NAT वातावरण में सीधा संचार सक्षम करता है,मोड़कठिन परिस्थितियों में संचार के लिए जीवन रेखा प्रदान करता है, औरमोड़ोंइनके संयोजन से, यह WebRTC के लिए विशेष वातावरणों में, जैसे कि किसी कंपनी के भीतर, उपयोग का रास्ता खोलता है।

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

WebRTC एक जटिल क्षेत्र है जो ब्राउज़र API और नेटवर्क प्रौद्योगिकियों को जोड़ता है, लेकिन विश्वसनीय अनुप्रयोग बनाने के लिए STUN/TURN और ICE कैसे काम करते हैं, यह समझना आवश्यक है।

हमें उम्मीद है कि आप इस लेख में दी गई जानकारी को ध्यान में रखेंगे और अपने उत्पाद में NAT ट्रैवर्सल चुनौती का समाधान करने का प्रयास करेंगे। ऐसा करने से, उपयोगकर्ता सहज संचार का आनंद ले पाएँगे, क्योंकि यह बुद्धिमान कनेक्शन प्रोसेसिंग, जो पर्दे के पीछे, बिना उन्हें पता चले, की जाती है।

URLをコピーしました！