2014-05-17 8 views
12

Webrtc के लिए STUN सर्वर के बारे में मेरी समझ यह है कि जब ग्राहक एनएटी के पीछे होते हैं (ज्यादातर मामलों में, यदि नहीं सभी), तो STUN सर्वर Webrtc क्लाइंट को उनके पते और बंदरगाहों की पहचान करने में मदद करेगा। और मैंने कुछ लेख भी पढ़ते हुए कहा कि Webrtc ग्राहकों के लिए एक सिग्नलिंग सर्वर की आवश्यकता है। सिग्नलिंग सर्वर एक वेब सर्वर, सॉकेट.ओओ, या यहां तक ​​कि एक यूआरएल ईमेल कर सकता है। मेरा पहला सवाल होगा: STUN सर्वर सिग्नलिंग सर्वर है?क्या मेरे पास socket.io आधारित सिग्नलिंग सर्वर है, तो STBR सर्वर webrtc के लिए बिल्कुल जरूरी है?

असल में अब मैंने एक बहुत ही सरल सॉकेट.io आधारित सेवा बनाई है जो क्लाइंट के सत्र विवरण को अन्य सभी ग्राहकों को प्रसारित करता है। तो मेरा मानना ​​है कि socket.io आधारित सर्वर के पास ग्राहकों के पते और बंदरगाहों के बारे में पर्याप्त जानकारी होनी चाहिए। यदि ऐसा है, तो हम एक और स्टन सर्वर क्यों परेशान करते हैं?

उत्तर

21

STUN सर्वर सिग्नलिंग सर्वर नहीं है।

सिग्नलिंग सर्वर का उद्देश्य सत्र की शुरुआत में सहकर्मियों के बीच जानकारी पास करना है (वे बिना किसी भेजने के प्रस्ताव को कैसे भेज सकते हैं?)। इस जानकारी में एसडीपी शामिल हैं जो प्रस्तावों और उत्तरों और किसी भी पार्टी द्वारा बनाए गए किसी भी बर्फ उम्मीदवारों पर बनाए जाते हैं।

स्टन सर्वर होने का कारण यह है कि दोनों सहकर्मी मीडिया को एक दूसरे को भेज सकते हैं। मीडिया स्ट्रीम आपके सिग्नलिंग सर्वर को नहीं दबाएगी बल्कि बदले में दूसरी पार्टी (पीयर-टू-पीयर कनेक्शन की परिभाषा) पर जायेगी, इसका अपवाद तब होगा जब टर्न सर्वर का उपयोग किया जाता है।

मीडिया जादुई रूप से एनएटी या फ़ायरवॉल से गुजर नहीं सकता क्योंकि दोनों पक्षों को एक दूसरे के लिए सीधे पहुंच नहीं है (जैसे वे एक ही लैन पर होंगे)।

कम STUN सर्वर में समय था जब दोनों पार्टियां एक ही नेटवर्क पर नहीं कर रहे हैं की बड़ी संख्या की जरूरत है (सहकर्मी से सहकर्मी मीडिया स्ट्रीमिंग के लिए मान्य कनेक्शन उम्मीदवारों प्राप्त करने के लिए) और एक संकेतन सर्वर हमेशा है जरूरत (चाहे वे अलग-अलग नेटवर्क पर हों या नहीं) ताकि वार्ता और कनेक्शन का निर्माण हो सके। Good explanation of the connection and streaming process

+0

बहुत स्पष्ट और सूचनात्मक उत्तर के लिए धन्यवाद @ bwtrent। तो STUN सर्वर कब खेलता है? केवल सहकर्मी कनेक्शन की शुरुआत में, या कनेक्शन के दौरान हर समय? अगर उत्तर केवल कनेक्शन की शुरुआत में है? सिग्नलिंग सर्वर को जो भी करना है, उसे सिग्नलिंग सर्वर को क्यों न दें? क्योंकि मुझे लगता है कि प्रत्येक सहकर्मी से बात करने के लिए सिग्नलिंग सर्वर को सहकर्मी की एनएटी जानकारी के बारे में पर्याप्त जानकारी होनी चाहिए। क्या मैंने STUN सर्वर की जटिलता को कम से कम समझ लिया? –

+1

@ElgsQianChen यह एक STUN सर्वर होना है। आपका सिग्नलिंग सर्वर और आपका STUN सर्वर एक ही भौतिक स्थान/एक ही भौतिक बॉक्स/एफक्यूडीएन में हो सकता है लेकिन एनएटी वार्ता एसटीयूएन के साथ की जानी चाहिए (या एक सममित एनएटी खेलने पर टर्न करें)। यह वेबआरटीसी स्पेक/आंदोलन/जो भी इसे अभी कहा जा रहा है के अनुसार है। –

+0

@BenjaminTrent के रूप में उल्लेख किया गया है, STUN और सिग्नलिंग सर्वर दोनों एक ही भौतिक मशीन IFF पर दोनों हो सकते हैं, यह दोनों सहकर्मियों के लिए सार्वजनिक है। जानकारी का आदान-प्रदान करने के लिए दोनों सहकर्मी कनेक्शन में संलग्न होने से ठीक पहले सिग्नलिंग सर्वर भाग खेल में आता है। दूसरी ओर, स्टन (या टर्न) की भूमिका पहले आती है, और यह प्रत्येक सहकर्मी को सूचित/अपडेट करना है कि यह कैसे पहुंचा जा सकता है। इस जानकारी का उपयोग सिग्नलिंग चरण में कनेक्शन स्थापित करने के लिए किया जाता है। यही कारण है कि स्टन दोनों सहकर्मियों के लिए सार्वजनिक होना चाहिए। – karimyafi

6

STUN का उपयोग आईसीई प्रोटोकॉल को लागू करने के लिए किया जाता है, जो दो ग्राहकों के बीच एक कार्य नेटवर्क पथ खोजने की कोशिश करता है। आईसीई उन मामलों के लिए टर्न रिले सर्वर (यदि आरटीसीपीयर कनेक्शन में कॉन्फ़िगर किया गया है) का भी उपयोग करेगा, जहां दो क्लाइंट (एनएटी/फ़ायरवॉल प्रतिबंधों के कारण) प्रत्यक्ष पीयर-टू-पीयर कनेक्शन नहीं बना सकते हैं।

STUN सर्वर इंटरनेट पर कंप्यूटर (बाहरी-एन-एनएटी पता) पर उपयोग किए गए बाहरी पते की पहचान करने के लिए उपयोग किए जाते हैं और सहकर्मी द्वारा उपयोग किए जाने वाले पोर्ट मैपिंग को सेट करने का प्रयास करने के लिए (यदि एनएटी नहीं है " सममित ") - STUN सर्वर से संपर्क करने से आपको आईसीई में उपयोग करने के लिए बाहरी आईपी और पोर्ट बताएगा। ये आईसीई उम्मीदवार एसडीपी में शामिल हैं या ट्रिकल-आईसीई संदेशों में शामिल हैं।

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

+0

धन्यवाद @ jesup। तो तकनीकी रूप से, क्या एसटीयूएन सर्वर को जो भी करना है, उसे करने के लिए सिग्नलिंग सर्वर का उपयोग करना संभव है? यदि STUN सर्वर का एकमात्र कार्य क्लाइंट को एनएटी के पीछे बता देना है कि उनके पास सार्वजनिक आईपी और पोर्ट क्या है, तो सिग्नलिंग सर्वर को ऐसा क्यों न करें? आप जानते हैं, मेरे लिए एसटीयूएन सर्वर से निर्भरता के रूप में बचने के लिए सबसे अच्छा है अगर मैं इसे अपने सॉकेट.io आधारित सिग्नलिंग सर्वर के साथ कर सकता हूं। –

+2

वही सर्वर (FQDN/IP) एक STUN सर्वर और सिग्नलिंग सर्वर दोनों हो सकता है - लेकिन वे अलग-अलग फ़ंक्शन हैं। आईसीई आपूर्ति की गई STUN/टर्न सर्वर की सूची को संसाधित करेगा। ध्यान दें कि आरटीपी/आरटीसीपी/डाटाचैनल के लिए उपयोग किए जाने वाले प्रत्येक चैनल को एक अलग पोर्ट मैपिंग मिलती है (हालांकि आरटीसीपी-मक्स आरटीपी और आरटीसीपी बंदरगाहों को जोड़ देगा, और बंडल (जब कार्यान्वित किया जाएगा) सभी धाराओं को एक बंदरगाह पर मक्स करेगा - लेकिन यह अभी भी सामान्य रूप से समान नहीं है बंदरगाह सिग्नलिंग के लिए उपयोग किया जाता है (और संकेत आमतौर पर टीसीपी होता है, यूडीपी वैसे भी नहीं, क्योंकि यह यूडीपी अला एसआईपी हो सकता है - लेकिन यादृच्छिक यूडीपी पोर्ट एक्सेस आमतौर पर ब्राउज़र में नहीं दी जाती है)। – jesup

1

एनएटी (नेटवर्क एड्रेस ट्रांसफॉर्मेशन) का उपयोग "निजी आईपी" का अनुवाद करने के लिए किया जाता है, जो केवल LAN में मान्य है "सार्वजनिक आईपी ​​"जो वैन में मान्य है। समस्या यह है कि" सार्वजनिक आईपी "केवल बाहर से दिखाई देता है, इसलिए हमें आपको" सार्वजनिक आईपी "भेजने के लिए STUN या TURN सर्वर की आवश्यकता है। यह प्रक्रिया एक वेबआरटीसी सहकर्मी को अपने लिए सार्वजनिक रूप से सुलभ पता लगाने में सक्षम बनाता है, और उसके बाद एक सिग्नलिंग तंत्र

एक बाहरी नेटवर्क पता प्राप्त करने के लिए एक STUN सर्वर का उपयोग किया जाता है। टर्न सर्वर का उपयोग ट्रैफिक को रिले करने के लिए किया जाता है यदि प्रत्यक्ष (सहकर्मी से सहकर्मी) कनेक्शन विफल हो जाता है। अधिक के लिए आप नीचे दिए गए लिंक से भी संदर्भित कर सकते हैं: https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/#what-is-signaling

संबंधित मुद्दे