मिलियन वीडियो कॉल प्रति दिन या "कॉल माँ!"

उपयोगकर्ता के दृष्टिकोण से, कॉल सेवाएँ बहुत सरल लगती हैं: आप किसी अन्य उपयोगकर्ता के पेज पर जाते हैं, आप कॉल करते हैं, वह फोन उठाता है, आप उससे बात करते हैं। बाहर ऐसा लगता है कि सब कुछ सरल है, लेकिन कम ही जानते हैं कि इस तरह की सेवा कैसे करें। लेकिन अलेक्जेंडर टोबोल ( एलाटोबोल ) न केवल जानता है, बल्कि स्वेच्छा से अपने अनुभव भी साझा करता है।



रिपोर्ट के आगे के संस्करण का संस्करण HighLoad ++ साइबेरिया पर है, जहाँ से आप सीखेंगे:

• हूड के तहत वीडियो कॉल सेवाएं कैसे काम करती हैं;
• NAT के माध्यम से तोड़ना कितना सुंदर है - यह खेल विशेषज्ञों के लिए दिलचस्प होगा जिन्हें सहकर्मी से सहकर्मी कनेक्शन की आवश्यकता है;
• WebRTC कैसे काम करता है, इसमें क्या प्रोटोकॉल शामिल हैं;
• मैं BigData के माध्यम से WebRTC को कैसे धुन सकता हूं।

स्पीकर के बारे में: अलेक्जेंडर टोबोल वीडियो और टेप प्लेटफार्मों के विकास को ok.ru पर ले जाता है।

वीडियो कॉल इतिहास

पहला वीडियो कॉल डिवाइस 1960 में दिखाई दिया, इसे एक पिचरफ़ोन कहा जाता था, समर्पित नेटवर्क का उपयोग किया जाता था और यह बहुत महंगा था। 2006 में, Skype ने अपने एप्लिकेशन में वीडियो कॉल जोड़े। 2010 में, फ्लैश ने RTMFP प्रोटोकॉल का समर्थन किया, और हमने Odnoklassniki में फ्लैश वीडियो कॉल लॉन्च किया। 2016 में, क्रोम ने फ्लैश का समर्थन करना बंद कर दिया, और अगस्त 2017 में हमने नई तकनीक के साथ कॉल को फिर से शुरू किया, जिसके बारे में मैं आज बात करूंगा। सेवा को अंतिम रूप देने के बाद, अगले छह महीनों के लिए हमें सफलतापूर्वक पूर्ण कॉलों में महत्वपूर्ण वृद्धि मिली। हाल ही में, हमारे पास कॉल में मास्क भी हैं।

वास्तुकला और टीके

चूंकि हम एक सामाजिक नेटवर्क में काम करते हैं, इसलिए हमारे पास तकनीकी कार्य नहीं हैं, और हमें पता नहीं है कि टीके क्या है। आमतौर पर पूरा विचार एक पृष्ठ पर फिट बैठता है और कुछ इस तरह दिखता है।


उपयोगकर्ता वेब या iOS / Android एप्लिकेशन का उपयोग करके अन्य उपयोगकर्ताओं को कॉल करना चाहता है। एक अन्य उपयोगकर्ता के पास कई उपकरण हो सकते हैं। सभी उपकरणों के लिए कॉल आता है, उपयोगकर्ता उनमें से एक पर फोन उठाता है, वे बात करते हैं। सब कुछ सरल है।

तकनीकी विनिर्देश

गुणवत्ता कॉल सेवा बनाने के लिए, हमें यह समझने की आवश्यकता है कि हम किन विशेषताओं को ट्रैक करना चाहते हैं। हमने इस बात की तलाश करने का निर्णय लिया कि उपयोगकर्ता को सबसे अधिक क्या परेशान करता है।

यदि वह फोन उठाता है और कनेक्शन स्थापित होने तक प्रतीक्षा करने के लिए मजबूर होता है, तो उपयोगकर्ता निश्चित रूप से नाराज होता है।


कॉल की गुणवत्ता खराब होने पर उपयोगकर्ता नाराज हो जाता है - कुछ बाधित होता है, वीडियो बिखरा हुआ होता है, ध्वनि बुदबुदाती है।


लेकिन ज्यादातर उपयोगकर्ता कॉल में देरी से परेशान हैं। विलंबता कॉल की महत्वपूर्ण विशेषताओं में से एक है। 5 सेकंड के आदेश की बातचीत में विलंबता के साथ, एक संवाद का संचालन करना बिल्कुल असंभव है।


हम अपने लिए स्वीकार्य विशेषताओं को निर्धारित करते हैं:

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

पॉलीकॉम हमारे कार्यालयों में स्थापित एक कॉन्फ्रेंसिंग प्रणाली है। हमारे पास 1.3 सेकंड के आदेश के औसत पॉलीकॉम विलंब हैं। इस तरह की देरी के साथ, आप हमेशा एक दूसरे को नहीं समझते हैं। यदि विलंब 2 सेकंड तक बढ़ जाता है, तो संवाद संभव नहीं होगा।


चूंकि हमने पहले ही प्लेटफ़ॉर्म लॉन्च कर दिया था, इसलिए हमें उम्मीद थी कि हमारे पास प्रति दिन एक मिलियन कॉल आएंगे। यह समानांतर में एक हजार कॉल है। यदि सभी कॉल सर्वर के माध्यम से लॉन्च किए जाते हैं, तो प्रति कॉल एक हजार मेगाबिट कॉल होगी। यह केवल 1 गीगाबिट / सेकंड है एक लोहे का सर्वर पर्याप्त होगा।

इंटरनेट बनाम टीटीएक्स

ऐसी शांत विशेषताओं को प्राप्त करने से आप क्या रोक सकते हैं? इंटरनेट!


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

पहले, हमने अपने उपयोगकर्ताओं के नेटवर्क में संचरण की गति को मापा।


हमने इसे कनेक्शन के प्रकार से तोड़ दिया, औसत आरटीटी, पैकेट नुकसान, गति को देखा और फैसला किया कि हम इनमें से प्रत्येक नेटवर्क के औसत मूल्यों पर कॉल का परीक्षण करेंगे।


इंटरनेट पर अन्य समस्याएं हैं:

• पैकेट नुकसान - हमने 0.6% यादृच्छिक पैकेट हानि को मापा (हम पैकेट के अत्यधिक संख्या के साथ कंजेशन पैकेट के नुकसान को ध्यान में नहीं रखते हैं)।
• रीऑर्डरिंग - आप एक ही क्रम में पैकेट भेजते हैं, और नेटवर्क उन्हें फिर से सॉर्ट करता है।
• जिटर - एक निश्चित अंतराल पर एक वीडियो या ऑडियो स्ट्रीम भेजें, और बंडल में क्लाइंट साइड पर पैकेट एक साथ आते हैं, उदाहरण के लिए, नेटवर्क उपकरणों पर बफरिंग के कारण।
• NAT - यह पता चला कि 97% से अधिक उपयोगकर्ता NAT के पीछे हैं। हम क्यों, क्या और कैसे के बारे में बात करेंगे।

एक सरल उदाहरण के साथ ऊपर सूचीबद्ध नेटवर्क सेटिंग्स पर विचार करें।

मैंने नोवोसिबिर्स्क स्टेट यूनिवर्सिटी की वेबसाइट को अपने कार्यालय से पृष्ठांकित किया और इस तरह के एक अजीब पिंग को प्राप्त किया।


इस उदाहरण में औसत घबराना 30 एमएस है, अर्थात आसन्न पिंग समय के बीच औसत अंतराल लगभग 30 एमएस है, और औसत पिंग 105 एमएस है।

कॉल में क्या महत्वपूर्ण है, हम पी 2 पी के लिए क्यों लड़ेंगे?


जाहिर है, अगर हम अपने उपयोगकर्ताओं के बीच पी 2 पी कनेक्शन स्थापित करने में कामयाब रहे, जो सेंट पीटर्सबर्ग में एक-दूसरे से बात करने की कोशिश कर रहे हैं, और नोवोसिबिर्स्क में स्थित सर्वर के माध्यम से नहीं, तो हम इस सेवा के बारे में 100 एमएस राउंड-ट्रिप और ट्रैफ़िक को बचाएंगे।

इसलिए, अधिकांश लेख अच्छा पी 2 पी बनाने के लिए समर्पित है।

इतिहास या विरासत

जैसा कि मैंने कहा, हमारे पास 2010 से कॉल सेवा है, और अब हमने इसे फिर से शुरू कर दिया है।


2006 में, जब Skype शुरू हुआ, तो फ्लैश ने एमिसिमा को खरीदा, जिसने RTMFP बनाया। फ्लैश में पहले से ही RTMP था, जिसे सिद्धांत रूप में कॉल के लिए इस्तेमाल किया जा सकता है, और इसका उपयोग अक्सर स्ट्रीमिंग के लिए किया जाता है। फ्लैश ने बाद में RTMP विनिर्देश को खोला। मुझे आश्चर्य है कि उन्हें RTMFP की आवश्यकता क्यों थी? 2010 में, हमने RTMFP का उपयोग किया।

कॉल प्रोटोकॉल और वास्तविक स्ट्रीमिंग प्रोटोकॉल के लिए आवश्यकताओं की तुलना करें और देखें कि यह सीमा कहां है।


RTMP एक वीडियो स्ट्रीमिंग प्रोटोकॉल का अधिक है। यह टीसीपी का उपयोग करता है, इसमें संचयी देरी है। यदि आपके पास एक अच्छा इंटरनेट कनेक्शन है, तो RTMP पर कॉल काम करेगी।

RTMFP प्रोटोकॉल , सिर्फ एक अक्षर में अंतर के बावजूद, UDP प्रोटोकॉल है। यह बफ़रिंग समस्याओं से मुक्त है - जो टीसीपी पर हैं; यह हेड-ऑफ-लाइन ब्लॉकिंग से वंचित है - यह तब है जब आपने एक पैकेट खो दिया है, और टीसीपी निम्नलिखित पैकेटों को वापस नहीं करता है जब तक कि यह एक बार फिर से खोए हुए को भेजने का समय नहीं है। RTMFP NAT को संभालने में सक्षम था और ग्राहकों के आईपी पते में बदलाव का अनुभव कर रहा था। इसलिए, हमने 2010 में RTMFP पर वेब लॉन्च किया।


फिर 2011 में केवल प्रारंभिक मसौदा WebRTC प्रकट हुआ, जो अभी तक पूरी तरह से चालू नहीं था। 2012 में, हमने iOS / Android पर कॉल का समर्थन करना शुरू किया, फिर कुछ और हुआ और 2016 में क्रोम ने फ्लैश का समर्थन करना बंद कर दिया। हमें कुछ करना था।


हमने सभी वीओआईपी प्रोटोकॉल को देखा: हमेशा की तरह, कुछ करने के लिए, हम प्रतियोगियों को देखकर शुरू करते हैं।

प्रतियोगी या कहाँ से शुरू करें

हमने सबसे लोकप्रिय प्रतियोगियों को चुना: स्काइप, व्हाट्सएप, गूगल डुओ (हैंगआउट के समान) और आईसीक्यू।

शुरू करने के लिए, हमने देरी को मापा।


यह करना आसान है। ऊपर एक तस्वीर है जिसमें:

• स्टॉपवॉच (ऊपर बाईं ओर फोन देखें), जो समय दिखाता है (03:08)।
• पास का टेलीफोन कॉल करता है और वीडियो के रूप में पहला टेलीफोन लेता है। जिस क्षण से छवि फोन के कैमरे में आ गई, और आपने इसे देखा, इसमें लगभग 100 एमएस लगे।
• एक और फोन (सफेद) और एक बार के लिए एक कॉल। यहां देरी Google डुओ के साथ लगभग 310 एमएस की है।

मैंने अभी तक सभी कार्ड प्रकट नहीं किए हैं, लेकिन हमने यह सुनिश्चित किया है कि ये डिवाइस पी 2 पी कनेक्शन स्थापित नहीं कर सकते हैं। बेशक, माप विभिन्न नेटवर्क में किए गए थे, और यह केवल एक उदाहरण है।


स्काइप अभी भी थोड़ा बाधित करता है। यह पता चला कि Skype के साथ, यदि यह P2p को जोड़ने में विफल रहता है, तो देरी 1.1 s है।

हमारे परीक्षण का माहौल जटिल था। हमने विभिन्न स्थितियों (EDGE, 3G, LTE, WiFi) में परीक्षण किया, इस बात को ध्यान में रखा कि चैनल असममित हैं, और मैं सभी मापों का औसत मान देता हूं।


बैटरी की खपत, प्रोसेसर लोड और बाकी सभी चीजों का अनुमान लगाने के लिए, हमने फैसला किया कि आप बस फोन के तापमान को पाइरोमीटर से माप सकते हैं और मान सकते हैं कि यह फोन के GPU प्रति प्रोसेसर, बैटरी पर कुछ औसत भार है। सिद्धांत रूप में, अपने कान के लिए एक गर्म फोन लाने के लिए यह बहुत अप्रिय है, और यहां तक ​​कि इसे अपने हाथों में पकड़ लें। यह उपयोगकर्ता को लगता है कि अब एप्लिकेशन अपनी पूरी बैटरी का उपयोग करेगा।


परिणाम है:

• देरी में सबसे धीमी आईसीक्यू और स्काइप थे, और सबसे तेज - टेलीग्राम। यह पूरी तरह से सही तुलना नहीं है, क्योंकि टेलीग्राम में वीडियो कॉल नहीं है, लेकिन उनके पास ऑडियो में न्यूनतम विलंबता है। WhatsApp (लगभग 200 एमएस) और हैंगआउट - 390 एमएस महान काम करते हैं।
• तापमान से, टेलीग्राम बिना वीडियो के कम से कम खाता है, और स्काइप सबसे ज्यादा।
• प्रतिक्रिया समय के संदर्भ में, टेलीग्राम सबसे लंबे समय के लिए कनेक्शन स्थापित करता है, और सबसे तेज़ व्हाट्सएप और Google डुओ।

बहुत बढ़िया, हमें कुछ मेट्रिक्स मिले!


हमने अलग-अलग नेटवर्कों पर वीडियो और वॉयस की गुणवत्ता का परीक्षण किया, अलग-अलग बूंदों और बाकी चीजों के साथ। नतीजतन, हम इस निष्कर्ष पर पहुंचे कि उच्चतम गुणवत्ता वाला वीडियो Google डुओ पर है, और आवाज स्काइप पर है , लेकिन यह "खराब" नेटवर्क में है जब पहले से ही विकृति है। सामान्य तौर पर, हर कोई लगभग औसत दर्जे का काम करता है। WhatsApp में सबसे धुंधली तस्वीर है।

आइए देखें कि यह सब किस पर लागू किया गया है।


Skype का अपना स्वामित्व प्रोटोकॉल है, और बाकी सभी लोग या तो WebRTC के संशोधन का उपयोग करते हैं, या आमतौर पर सीधे WebRTC का। हैंगआउट, Google डुओ, व्हाट्सएप, फेसबुक मैसेंजर वेब के साथ काम कर सकते हैं, और वे सभी हुड के तहत WebRTC हैं। वे सभी बहुत अलग हैं, अलग-अलग विशेषताओं के साथ, और उन सभी में एक वेबआरटीसी है! तो, आपको इसे सही ढंग से पकाने में सक्षम होने की आवश्यकता है। प्लस के टेलीग्राम, जिसके लिए वेबआरटीसी के कुछ हिस्से ऑडियो भाग के लिए जिम्मेदार हैं, आईसीक्यू है, जिसने लंबे समय तक वेबआरटीसी को फोर्क किया और अपने तरीके से विकसित किया।

WebRTC। आर्किटेक्चर

WebRTC का तात्पर्य है एक सिग्नलिंग सर्वर की उपस्थिति, ग्राहकों के बीच एक मध्यस्थ, जो कि उनके बीच पी 2 पी कनेक्शन की स्थापना के दौरान संदेशों का आदान-प्रदान करने के लिए उपयोग किया जाता है। एक सीधा संबंध स्थापित करने के बाद, ग्राहक एक दूसरे के साथ मीडिया डेटा का आदान-प्रदान करना शुरू करते हैं।

WebRTC। डेमो

एक सरल डेमो के साथ शुरू करते हैं। WebRTC कनेक्शन स्थापित करने के लिए 5 सरल चरण हैं।


यह निम्नलिखित कहता है:

1. एक वीडियो लें और एक सहकर्मी कनेक्शन स्थापित करें, कुछ प्रकार के आइसवर्कर्स को स्थानांतरित करें (यह तुरंत स्पष्ट नहीं है कि यह क्या है)।
   
2. एक एसडीपी प्रस्ताव बनाएं और इसे सिग्नलिंग पर भेजें, और सिग्नलिंग वेबआरटीसी आपके लिए किसी भी तरह से लागू नहीं होगा।
   
3. फिर आपको सिग्नलिंग से आने वाले के लिए एक आवरण बनाने की जरूरत है, और यह भी WebRTC का हिस्सा नहीं है।
   
4. आगे कुछ उम्मीदवारों का आदान-प्रदान।
   
5. अंत में रिमोट वीडियो स्ट्रीम प्राप्त करें।
   

आइए जानें कि वहां क्या हो रहा है और हमें खुद को लागू करने की क्या आवश्यकता है।


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

लेख में आगे हम नेटवर्क पर चर्चा करेंगे, फिर वीडियो / ऑडियो, और अंत में हम अपना सिग्नलिंग लिखेंगे।

WebRTC नेटवर्क या पी 2 पी (वास्तव में c2s2c)

एक p2p कनेक्शन की स्थापना के लिए बहुत आसान हो रहा है।


हमारे पास ऐलिस और बॉब हैं जो पी 2 पी कनेक्शन स्थापित करना चाहते हैं। वे अपने आईपी पते लेते हैं, उनके पास एक सिग्नलिंग सर्वर है जिससे वे दोनों जुड़े हुए हैं, और जिसके माध्यम से वे इन पते का आदान-प्रदान कर सकते हैं। वे पते का आदान-प्रदान करते हैं, और ओह! उनके पते समान हैं, कुछ गलत हो गया है!


वास्तव में, दोनों उपयोगकर्ता वाई-फाई राउटर के पीछे सबसे अधिक संभावना है और ये उनके स्थानीय ग्रे आईपी पते हैं। राउटर उन्हें नेटवर्क एड्रेस ट्रांसलेशन (NAT) जैसी सुविधा प्रदान करता है। वह कैसे काम करती है?


आपके पास एक ग्रे सबनेट और एक बाहरी आईपी पता है। आप अपने ग्रे पते से इंटरनेट पर एक पैकेट भेजते हैं, NAT आपके ग्रे पते को सफेद के साथ बदल देता है और मैपिंग को याद करता है: यह किस पोर्ट से भेजा गया है, किस उपयोगकर्ता और किस पोर्ट से मेल खाता है। जब रिटर्न पैकेट आता है, तो वह इस मैपिंग द्वारा हल करता है और प्रेषक को भेजता है। सब कुछ सरल है।

नीचे एक उदाहरण है कि यह मेरी जगह पर कैसा दिखता है।


यह मेरा आंतरिक आईपी पता और राउटर का पता है (वैसे, ग्रे भी)। यदि आप ट्रेस करते हैं और मार्ग देखते हैं, तो हम मेरा वाई-फाई राउटर देखेंगे: ग्रे प्रदाता पते का एक पैकेट और एक बाहरी सफेद आईपी। इस प्रकार, वास्तव में, मेरे पास दो NAT होंगे: एक जिस पर मैं वाई-फाई पर हूं, और प्रदाता से दूसरा एक, जब तक कि निश्चित रूप से, मैंने खुद को एक समर्पित बाहरी आईपी पता खरीदा।

NAT इतना लोकप्रिय है क्योंकि:

• कई IPv4s अभी भी गायब हैं, और पर्याप्त पते नहीं हैं;
• नेट नेटवर्क की रक्षा के लिए लगता है;
• यह राउटर का एक मानक कार्य है: वाई-फाई से कनेक्ट करें, वहां एनएटी है, यह काम करता है।

इसलिए, केवल 3% उपयोगकर्ता बाहरी आईपी के साथ बैठते हैं, जबकि बाकी सभी NAT से गुजरते हैं।

NAT आपको किसी भी सफेद पते पर सुरक्षित रूप से जाने की अनुमति देता है। लेकिन अगर आप कहीं नहीं गए, तो कोई भी आपके पास नहीं आ सकता है।


पी 2 पी कनेक्शन स्थापित करने के लिए एक समस्या है। वास्तव में, एलिस और बॉब एक ​​दूसरे को पैकेट नहीं भेज सकते हैं यदि वे दोनों नेट के पीछे हैं।

WebRTC के पास इस समस्या को हल करने के लिए एक STUN प्रोटोकॉल है। यह एक STUN सर्वर को तैनात करने का प्रस्ताव है। फिर ऐलिस STUN सर्वर से जुड़ जाता है, अपना आईपी पता प्राप्त करता है, इसे सिग्नलिंग के माध्यम से बॉब को भेजता है। बॉब ने अपना आईपी पता भी प्राप्त किया और इसे ऐलिस को भेज दिया। वे एक-दूसरे की ओर पैकेट भेजते हैं और इस तरह एनएटी से गुजरते हैं।


प्रश्न : एलिस का एक विशिष्ट पोर्ट खुला है, इस पोर्ट के माध्यम से NAT / फ़ायरवॉल पहले ही टूट चुका है, और बॉब खुला है। वे एक-दूसरे के पते जानते हैं। ऐलिस पैकेट को बॉब को भेजने की कोशिश करता है, वह पैकेट ऐलिस को भेजता है। क्या आपको लगता है कि वे बात कर सकते हैं या नहीं?

वास्तव में, आप किसी भी मामले में सही हैं, परिणाम NAT जोड़ी के प्रकार पर निर्भर करता है जो उपयोगकर्ताओं के पास है।

नेटवर्क एड्रेस ट्रांसलेशन

NAT के 4 प्रकार हैं:

1. पूर्ण शंकु NAT;
   
2. प्रतिबंधित शंकु NAT;
   
3. पोर्ट प्रतिबंधित शंकु NAT;
   
4. सममित एनएटी
   

मूल संस्करण में, ऐलिस STUN सर्वर को एक पैकेट भेजता है, वह कुछ पोर्ट खोलता है। बॉब किसी तरह अपने पोर्ट के बारे में पता करता है और एक रिटर्न पैकेट भेजता है। यदि यह पूर्ण शंकु NAT है - सबसे आसान है जो सिर्फ बाहरी पोर्ट को आंतरिक पोर्ट पर मैप करता है, तो बॉब तुरंत ऐलिस को एक पैकेट भेजने में सक्षम होगा, एक कनेक्शन स्थापित करेगा, और वे बात करेंगे।


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


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


इस समस्या को कैसे हल किया जाता है? एक साधारण योजना में (नीचे चित्रण देखें) इस तरह: ऐलिस STUN को एक पैकेट भेजता है, वह उसे अपने आईपी के साथ जवाब देता है। जब तक यह प्रतिबंधित शंकु NAT है STUN किसी भी बंदरगाह से इसका जवाब दे सकता है। बॉब ऐलिस को जवाब नहीं दे सकता क्योंकि उसका एक अलग पता है। ऐलिस एक पैकेट के साथ प्रतिक्रिया करता है, बॉब के आईपी पते को जानता है। वह नैट को बॉब को खोलता है, बॉब उसे जवाब देता है। हुर्रे, उन्होंने बात की।


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

सबसे हानिकारक चीज सममितीय NAT है ।


सबसे पहले, सब कुछ ठीक उसी तरह से काम करता है - ऐलिस पैकेट को STUN सर्वर को भेजता है, यह उसी पोर्ट से प्रतिक्रिया करता है। बॉब ऐलिस को जवाब नहीं दे सकता है, लेकिन वह पैकेट को बॉब को भेजता है। और यहाँ, इस तथ्य के बावजूद कि ऐलिस 4444 पोर्ट के लिए एक पैकेट भेजता है, मैपिंग उसके लिए एक नया पोर्ट आवंटित करती है। सममित एनएआर उस में भिन्न होता है जब प्रत्येक नया कनेक्शन स्थापित होता है, हर बार यह राउटर पर एक नया पोर्ट जारी करता है। तदनुसार, बॉब उस बंदरगाह में पिटाई कर रहा है जिसमें से एलिस STUN गया था, और वे कनेक्ट नहीं कर सकते हैं।

विपरीत दिशा में, यदि बॉब के पास एक खुला आईपी पता है, तो ऐलिस बस उसके पास आ सकता है और वे एक कनेक्शन स्थापित करेंगे।

सभी विकल्प नीचे एक तालिका में एकत्र किए गए हैं।


यह दर्शाता है कि जब हम पोर्ट प्रतिबंधित शंकु NAT या दूसरे छोर पर Symmetric NAT के साथ Symmetric NAT के माध्यम से कनेक्शन स्थापित करने का प्रयास करते हैं, तब लगभग सब कुछ संभव है।


जैसा कि हमने पाया, पी 2 पी विलंबता के संदर्भ में हमारे लिए अनमोल है, लेकिन अगर इसे स्थापित करना संभव नहीं था, तो WebRTC हमें एक TURN सर्वर प्रदान करता है। जब हमने महसूस किया कि पी 2 पी स्थापित नहीं होगा, तो हम बस टर्न से जुड़ सकते हैं, जो सभी ट्रैफ़िक को प्रॉक्सी करेगा। हालाँकि, उसी समय आप ट्रैफ़िक के लिए भुगतान करेंगे, और उपयोगकर्ताओं के लिए कुछ अतिरिक्त देरी हो सकती है।

अभ्यास

Google के पास STUN सर्वर मुफ्त हैं। आप उन्हें पुस्तकालय में रख सकते हैं, यह काम करेगा।

TURN सर्वर में क्रेडेंशियल (लॉगिन और पासवर्ड) होता है। सबसे अधिक संभावना है, आपको अपना खुद का उठाना होगा, मुफ्त में खोजना मुश्किल है।

Google से मुक्त STUN सर्वर के उदाहरण:

• stun: stun.l.google.com: 19302
• stun: stun1.l.google.com: 19302
• stun: stun2.l.google.com: 19302
• stun: stun3.l.google.com: 19302

और पासवर्ड के साथ एक मुफ्त TURN सर्वर: url: 'turn: 192.158.29.39: 34;

हम खाट का उपयोग करते हैं ।


नतीजतन, 34% ट्रैफ़िक पी 2 पी कनेक्शन से गुजरता है, बाकी सब TURN सर्वर के माध्यम से अनुमानित है।

STUN प्रोटोकॉल में और क्या दिलचस्प है?

STUN आपको NAT का प्रकार निर्धारित करने की अनुमति देता है।


स्लाइड लिंक

पैकेट भेजते समय, आप यह संकेत दे सकते हैं कि आप एक ही पोर्ट से प्रतिक्रिया प्राप्त करना चाहते हैं या STUN को किसी भिन्न पोर्ट से, किसी भिन्न IP से, या यहाँ तक कि किसी भिन्न IP और पोर्ट से भी उत्तर देना चाहते हैं। इस प्रकार, STUN सर्वर के 4 प्रश्नों के लिए, आप NAT के प्रकार को निर्धारित कर सकते हैं ।


हमने NAT के प्रकार गिनाए और हमने पाया कि लगभग सभी उपयोगकर्ताओं के पास या तो Symmetric NAT या Port प्रतिबंधित शंकु NAT है। इसलिए, यह पता चला है कि केवल एक तिहाई उपयोगकर्ता पी 2 पी कनेक्शन स्थापित कर सकते हैं।

आप पूछ सकते हैं कि मैं आपको यह सब क्यों बता रहा हूं यदि आप Google से सिर्फ STUN ले सकते हैं, इसे WebRTC में डाल सकते हैं, और ऐसा लगता है कि सब कुछ काम करेगा।

क्योंकि आप वास्तव में स्वयं NAT का प्रकार निर्धारित कर सकते हैं।


यह जावा एप्लिकेशन का एक लिंक है जो कुछ भी मुश्किल नहीं करता है: यह सिर्फ अलग-अलग पोर्ट और अलग-अलग STUN सर्वरों को पिंग करता है, और अंत में यह देखता है कि किस पोर्ट को देखता है। अगर आपके पास Open Full cone NAT है, तो STUN सर्वर में एक ही पोर्ट होगा। प्रतिबंधित शंकु NAT के साथ, आपके पास प्रत्येक STUN अनुरोध के लिए अलग-अलग पोर्ट होंगे।


सिमिट्रिक एनएटी के साथ, यह मेरे कार्यालय में इस तरह से निकला। पूरी तरह से अलग बंदरगाह हैं।

लेकिन कभी-कभी एक दिलचस्प पैटर्न होता है कि प्रत्येक कनेक्शन के लिए, पोर्ट संख्या एक से बढ़ जाती है।


यही है, कई NAT को कॉन्फ़िगर किया जाता है ताकि वे पोर्ट को स्थिर करके बढ़ाएं या घटाएं। यह स्थिरांक पाया जा सकता है और इस प्रकार सममितीय NAT के माध्यम से टूट सकता है।


इस प्रकार हम NAT के माध्यम से टूट जाते हैं - हम एक STUN सर्वर पर जाते हैं, दूसरे से, अंतर को देखते हैं, तुलना करते हैं और इस वृद्धि या गिरावट के साथ पहले से ही हमारे पोर्ट देने के लिए फिर से प्रयास करते हैं। यही है, ऐलिस बॉब को अपना बंदरगाह देने की कोशिश कर रहा है, पहले से ही एक स्थिर के लिए समायोजित, यह जानकर कि अगली बार बस यही होगा।


इसलिए हम एक और 12% पीयर-टू-पीयर वेल्ड करने में कामयाब रहे।

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

CDN रिले या क्या करें यदि आप एक P2P कनेक्शन स्थापित नहीं कर सके

यदि हम अभी भी TURN सर्वर का उपयोग करते हैं और पी 2 पी में काम नहीं करते हैं, लेकिन वास्तविक मोड में, सर्वर के माध्यम से सभी ट्रैफ़िक को पास करते हुए, हम अभी भी एक सीडीएन जोड़ सकते हैं। जब तक, ज़ाहिर है, आपके पास एक खेल का मैदान है। हमारी अपनी सीडीएन साइटें हैं, इसलिए हमारे लिए यह काफी सरल था। लेकिन यह निर्धारित करना आवश्यक था कि किसी व्यक्ति को कहां भेजना बेहतर है: सीडीएन साइट पर या कहें, मॉस्को के एक चैनल को। यह बहुत तुच्छ कार्य नहीं है, इसलिए हमने ऐसा किया:

1. गलती से मास्को साइट के कुछ उपयोगकर्ताओं को जारी किया गया, कुछ - दूरस्थ।
   
2. हमने उपयोगकर्ता के आईपी पर, सर्वर पर और नेटवर्क की विशेषताओं पर आंकड़े एकत्र किए।
   
3. MaxMind द्वारा, हमने सबनेट्स को समूहीकृत किया, आँकड़ों को देखा और आईपी द्वारा यह समझने में सक्षम थे कि किस उपयोगकर्ता के पास कनेक्शन के लिए निकटतम TURN सर्वर था।
   

नोवोसिबिर्स्क में एक सीडीएन है। यदि मास्को के माध्यम से सब कुछ आपके लिए काम करता है, तो आरटीटी का 99 वां प्रतिशत 1.3 सेकंड है। सीडीएन के माध्यम से, सब कुछ बहुत तेज़ी से काम करता है (0.4 सेकंड)।

क्या हमेशा पी 2 पी कनेक्शन का उपयोग करना बेहतर है और सर्वर का उपयोग नहीं करना चाहिए? एक दिलचस्प उदाहरण दो क्रास्नोयार्स्क प्रदाता ऑप्टिबाइट और मोब्रा (नाम बदल सकते हैं) हैं। किसी कारण से, पी 2 पी पर उनके बीच का संबंध एमएसके के मुकाबले बहुत खराब है। संभवतः वे एक-दूसरे के मित्र नहीं हैं।


हमने ऐसे सभी मामलों का विश्लेषण किया, उपयोगकर्ताओं को यादृच्छिक रूप से पी 2 पी या एमएसके के माध्यम से, एकत्रित आंकड़े और निर्मित भविष्यवाणियों का विश्लेषण किया। हम जानते हैं कि आंकड़ों को अपडेट करने की आवश्यकता है, इसलिए कुछ उपयोगकर्ताओं के लिए हम विशेष रूप से यह जांचने के लिए विभिन्न कनेक्शन स्थापित करते हैं कि क्या नेटवर्क में कुछ बदल गया है।

हमने इस तरह की सरल विशेषताओं को गोल समय, पैकेट नुकसान, बैंडविड्थ के रूप में मापा - यह जानने के लिए रहता है कि उनकी सही तरीके से तुलना कैसे करें।


कैसे समझें कि कौन सा बेहतर है: 2 Mbit / s इंटरनेट, 400 ms RTT और 5% पैकेट नुकसान या 100 Kbit / s, 100 ms देरी और झुलसा पैकेट नुकसान?

कोई सटीक उत्तर नहीं है, वीडियो कॉल की गुणवत्ता का आकलन बहुत व्यक्तिपरक है। इसलिए, कॉल समाप्त होने के बाद, हमने उपयोगकर्ताओं को परिणामों के अनुसार तारांकन में गुणवत्ता का मूल्यांकन करने और स्थिरांक निर्धारित करने के लिए कहा। यह पता चला है कि, उदाहरण के लिए, आरटीटी 300 एमएस से कम है - इससे कोई फर्क नहीं पड़ता, बिटरेट अधिक महत्वपूर्ण है।

Android और iOS पर उच्च उपयोगकर्ता रेटिंग। यह देखा जाता है कि आईओएस उपयोगकर्ता एक यूनिट लगाने की अधिक संभावना रखते हैं और अधिक बार पांच। मुझे पता नहीं है, शायद, मंच की बारीकियों को क्यों। लेकिन हमने स्थिरांक को अपने साथ खींच लिया, ताकि हमारे पास, जैसा कि हमें लगता है, अच्छा है।

लेख के लिए हमारी रूपरेखा पर वापस, हम अभी भी नेटवर्क पर चर्चा कर रहे हैं।

कनेक्शन सेटअप कैसा दिखता है?


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


कनेक्शन की स्थापना के 5 चरणों में, जिस पर हमने पहले चर्चा की थी, हमने सर्वरों का पता लगाया, यह पता लगाया कि उन्हें कहाँ प्राप्त करना है, और यह कि आईसीई उम्मीदवार बाहरी आईपी पते हैं जो हम सिग्नलिंग के माध्यम से विनिमय करते हैं। ग्राहकों के आंतरिक आईपी पते, यदि वे एक वाई-फाई की सीमा के भीतर हैं, तो उन्हें भी तोड़ने की कोशिश की जा सकती है।

आइए वीडियो के भाग पर चलते हैं।

वीडियो और ऑडियो

WebRTC वीडियो और ऑडियो कोडेक्स के एक निश्चित सेट का समर्थन करता है, लेकिन आप वहां अपना खुद का कोडेक जोड़ सकते हैं। मूल रूप से वीडियो के लिए H.264 और VP8 द्वारा समर्थित है। VP8 एक सॉफ्टवेयर कोडेक है, इसलिए यह बहुत अधिक बैटरी की खपत करता है। H.264 सभी उपकरणों पर उपलब्ध नहीं है (यह आमतौर पर मूल है), इसलिए डिफ़ॉल्ट प्राथमिकता VP8 पर है।

एसडीपी (सत्र विवरण प्रोटोकॉल) के अंदर, कोडेक वार्ता होती है: जब एक क्लाइंट अपने कोडेक्स की एक सूची भेजता है, तो दूसरा अपने स्वयं के प्राथमिकता के साथ भेजता है, और वे इस बात पर सहमत होते हैं कि कौन सा कोडक संचार के लिए उपयोग करेगा। यदि वांछित है, तो आप VP8 और H.264 कोडेक की प्राथमिकता को बदल सकते हैं, और इसके कारण, आप कुछ उपकरणों पर बैटरी बचा सकते हैं, जहां 264 मूल है। यहाँ एक उदाहरण है कि यह कैसे किया जा सकता है। हमने ऐसा किया, यह हमें लग रहा था कि उपयोगकर्ताओं ने गुणवत्ता के बारे में शिकायत नहीं की थी, लेकिन साथ ही बैटरी चार्ज की खपत बहुत कम थी।

ऑडियो के लिए, WebRTC में OPUS या G711 हैं , आमतौर पर सभी OPUS हमेशा काम करते हैं, इसके साथ कुछ भी करने की आवश्यकता नहीं है।

10 मिनट के उपयोग के बाद तापमान माप नीचे दिए गए हैं।


यह स्पष्ट है कि हमने विभिन्न उपकरणों का परीक्षण किया। यह एक iPhone का एक उदाहरण है, और उस पर, ओके एप्लिकेशन बैटरी का कम से कम उपयोग करता है, क्योंकि डिवाइस का तापमान सबसे कम है।

दूसरी चीज जो आप सक्षम कर सकते हैं यदि आप वेबआरटीसी का उपयोग करते हैं तो कनेक्शन बहुत खराब होने पर वीडियो को स्वचालित रूप से बंद करना है ।


यदि आपके पास 40 Kbps से कम है, तो वीडियो बंद हो जाएगा। आपको कनेक्शन बनाते समय केवल बॉक्स को जांचना होगा, थ्रेशोल्ड मान को इंटरफ़ेस के माध्यम से कॉन्फ़िगर किया जा सकता है। आप न्यूनतम और अधिकतम आरंभिक बिटरेट भी सेट कर सकते हैं।


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

व्हाट्सएप बहुत साबुन वीडियो के साथ काम करता है, लेकिन छोटे विलंब के साथ, क्योंकि यह आक्रामक रूप से ऊपर से बिटरेट को संपीड़ित करता है।

हमने MaxMind का उपयोग करके आंकड़े एकत्र किए और इसे मैप किया।


यह एक अनुमानित शुरुआती गुणवत्ता है जिसका उपयोग हम रूस के विभिन्न क्षेत्रों में कॉल के लिए करते हैं।

सिग्नलिंग

यदि आप कॉल करना चाहते हैं तो आपको इस भाग को लिखना होगा। सभी तरह के नुकसान हैं। यह कैसे दिखता है याद करें।


सिग्नलिंग के साथ एक एप्लिकेशन है जो एसडीपी के साथ कनेक्ट और एक्सचेंज करता है, और नीचे एसडीपी वेबआरटीसी के लिए इंटरफ़ेस है।

यह साधारण सिग्नलिंग जैसा दिखता है:


एलिस बॉब को बुलाती है। यह जोड़ता है, उदाहरण के लिए, वेब-सॉकेट कनेक्शन के माध्यम से। बॉब को अपने मोबाइल फोन या ब्राउज़र पर एक धक्का मिलता है, या किसी तरह के खुले कनेक्शन में, वेब-सॉकेट के माध्यम से जुड़ता है और उसके बाद उसकी जेब में फोन बजने लगता है। बॉब फोन उठाता है, ऐलिस उसे अपने कोडेक्स और अन्य वेबआरटीसी फीचर्स भेजता है जो वह समर्थन करता है। बॉब ने उसी का जवाब दिया, और उसके बाद उन्होंने अपने उम्मीदवारों को देखा। हुर्रे, कॉल!

यह सब बहुत लंबा दिखता है। सबसे पहले, जब तक आप वेब-सॉकेट कनेक्शन स्थापित नहीं करते हैं, जब तक पुश नहीं आता है और बाकी सब कुछ, बॉब का फोन उसकी जेब में नहीं जाएगा। ऐलिस हर समय इंतजार करेगी, सोचें कि बॉब कहां है, वह फोन क्यों नहीं उठाता है। पुष्टि के बाद, यह सभी सेकंड लेता है, और अच्छे कनेक्शन पर भी यह 3-5 सेकंड हो सकता है, और सभी 10 पर खराब कनेक्शन हो सकता है।

हमें इसके बारे में कुछ करना चाहिए! आप मुझे बताएंगे कि सब कुछ बहुत सरलता से किया जा सकता है।



यदि आपके पास पहले से ही अपने आवेदन के लिए एक खुला कनेक्शन है, तो आप तुरंत कनेक्शन स्थापित करने के लिए एक पुश भेज सकते हैं, वांछित सिग्नलिंग सर्वर से कनेक्ट कर सकते हैं और तुरंत कॉल करना शुरू कर सकते हैं।

फिर एक और अनुकूलन। यहां तक ​​कि अगर फोन अभी भी आपकी जेब में बज रहा है और आपने फोन नहीं उठाया है, तो आप वास्तव में समर्थित कोडेक्स, बाहरी आईपी पते के बारे में जानकारी का आदान-प्रदान कर सकते हैं, खाली वीडियो पैकेट भेजना शुरू कर सकते हैं, और सामान्य तौर पर सब कुछ गर्म हो जाएगा। एक बार जब आप फोन उठाएंगे, तो सब कुछ बहुत अच्छा होगा।

हमने ऐसा किया, और ऐसा लगा कि सब कुछ अच्छा था। लेकिन नहीं।


पहली समस्या यह है कि उपयोगकर्ता अक्सर कॉल को रद्द कर देते हैं। वे "कॉल" पर क्लिक करते हैं और तुरंत रद्द कर देते हैं। तदनुसार, पुश कॉल पर जाता है, और उपयोगकर्ता गायब हो जाता है (उसने इंटरनेट या कुछ और खो दिया है)। इस बीच, किसी के फोन की घंटी बजती है, वह फोन उठाता है, और उसे वहां उम्मीद नहीं है। इसलिए, हमारे आदिम अनुकूलन के लिए जितनी जल्दी हो सके कॉल करना शुरू करना वास्तव में काम नहीं करता है।


त्वरित कॉल रद्द होने के साथ, एक दूसरी हानिकारक चीज है। यदि आप सर्वर पर अपनी बातचीत की आईडी जनरेट करते हैं, तो आपको प्रतिक्रिया की प्रतीक्षा करने की आवश्यकता है। यही है, आप एक कॉल बनाते हैं, एक आईडी प्राप्त करते हैं, और उसके बाद ही आप जो चाहें कर सकते हैं: कॉल रद्द करें सहित पैकेट, विनिमय भेजें। यह एक बहुत बुरी कहानी है, क्योंकि यह पता चलता है कि जब तक प्रतिक्रिया नहीं आई है, तब तक आप वास्तव में क्लाइंट से कुछ भी रद्द नहीं कर सकते। इसलिए, क्लाइंट पर GUID जैसे किसी प्रकार की ID जनरेट करना सबसे अच्छा है और कहें कि आपने कॉल शुरू कर दिया है। लोग अक्सर ऐसा करते हैं: उन्होंने फोन किया, रद्द किया और तुरंत फिर से फोन किया। इसे गड़बड़ाने से रोकने के लिए, एक GUID करें और इसे सबमिट करें।


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

क्या करें? आइए अपनी मूल सरल धीमी सिग्नलिंग योजना पर वापस जाएं और इसे अनुकूलित करें, पुश को थोड़ा पहले भेजें। उपयोगकर्ता तेजी से जुड़ना शुरू कर देगा, लेकिन इससे कुछ पैसे बचेंगे।


फोन उठाने और एक्सचेंज शुरू करने के बाद सबसे लंबे समय तक क्या करना है?


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

बॉब क्या कर सकता है? प्रस्ताव प्राप्त करने के बाद, वह देख सकता है कि कोडेक्स क्या थे, अपना खुद का उत्पादन करें, उसके पास क्या है, लिखें और इसे भी भेजें। लेकिन बॉब के पास दो फोन हैं, और उनकी अलग-अलग कोडेक बातचीत है, इसलिए सिग्नलिंग यह सब खुद के लिए रखेगा और जब तक वह यह पता नहीं कर लेता कि वह किस डिवाइस पर फोन उठाएगा। उम्मीदवार दोनों डिवाइस भी उत्पन्न करेंगे और उन्हें सिग्नलिंग के लिए भेजेंगे।

इस प्रकार, सिग्नलिंग में ऐलिस से एक संदेश कतार और बॉब से विभिन्न उपकरणों पर कई संदेश कतारें हैं। वह इस सब को संग्रहीत करता है, और जैसे ही वे इन उपकरणों में से एक पर फोन उठाते हैं, वह बस पहले से तैयार किए गए पैकेज के पूरे सेट को फेंक देता है।

यह बहुत तेजी से काम करता है। हम Google Duo और WhatsApp जैसी विशेषताओं तक पहुंचने के लिए इस तरह के एक एल्गोरिथ्म के साथ प्रबंधित हुए।


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

आपको किन अन्य समस्याओं का इंतजार है?


रिटर्न कॉल के रूप में ऐसी बात है: एक दूसरे को कॉल करता है, दूसरा रिंग करता है। यह अच्छा होगा यदि वे प्रतिस्पर्धा करने की कोशिश नहीं करते हैं - सिग्नलिंग स्तर पर एक कमांड जोड़ते हैं जो कहता है कि यदि कोई दूसरा आया, तो आपको कॉल स्वीकार करने और तुरंत फोन लेने पर मोड पर स्विच करने की आवश्यकता है।


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

तो यह सब हमारे साथ आंतरिक रूप से लागू किया जाता है, इस बात को ध्यान में रखते हुए कि हमारे पास 24/7 सेवा है, हम डेटा केंद्रों को खोना चाहते हैं, अपने सॉफ़्टवेयर के संस्करण को स्थानांतरित करना और अपडेट करना चाहते हैं।


लिंक स्लाइड पर वीडियो और के संदर्भ के लिए पाठ संस्करण

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

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

एल्गोरिथ्म इस तरह दिखता है:

• क्लाइंट कुछ संदेश भेजता है, आइए संकेत करने के लिए इसके बाहरी आईपी को कहते हैं
• सिग्नलिंग स्वीकार करता है, डेटाबेस को लिखता है।
• जब वह समझता है कि सब कुछ आ गया है, तो वह जवाब देता है कि उसे यह संदेश मिला है।
• ग्राहक इस संदेश को अपनी कतार से हटा देता है।

सभी पैकेज अद्वितीय संख्याओं के साथ प्रदान किए जाते हैं ताकि भ्रमित न हों।

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

तो, आपने सीखा है:

• हिमशैल क्या हैं और उन्हें कैसे स्थानांतरित किया जाए;
• सत्र विवरण प्रोटोकॉल क्या है;
• यह उत्पन्न होना चाहिए और दूसरी तरफ भेजा जाना चाहिए;
• यह सिग्नलिंग से लिया जाना चाहिए और दूसरी तरफ WebRTC को हस्तांतरित किया जाना चाहिए, बाहरी आईपी पते के साथ आदान-प्रदान किया जाना चाहिए;
• और वीडियो भेजना शुरू करें!

हमने प्राप्त किया है:

• बाजार के औसत से नीचे देरी के साथ कॉल;
• हमने फोन को बहुत गर्म नहीं किया;
• शीर्ष स्तर पर हमारे आवेदन में प्रतिक्रिया समय।

वाह!

सुरक्षा। WebRTC के लिए मध्य हमले में आदमी

वेबआरटीसी के लिए मध्य हमले में आदमी के बारे में बात करते हैं। वास्तव में, WebRTC एक बहुत ही कठिन प्रोटोकॉल है कि यह RTP पर आधारित है, जो अभी भी 1996 है, और SDP 1998 में SIP से आया था।


सबसे नीचे, एक विशाल सूची RFC और अन्य RTP एक्सटेंशन का एक समूह है जो RTP WebRTC बनाती है।

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

WebRTC का इतिहास जटिल था। पहला मसौदा रिलीज़ 2011 में जारी किया गया था, 2013 में फ़ायरफ़ॉक्स ने इस प्रोटोकॉल का समर्थन किया, फिर इसे 2014 ओपेरा में iOS / Android पर बनाया जाना शुरू हुआ। सामान्य तौर पर, यह कई, कई वर्षों तक विकसित हुआ, लेकिन फिर भी एक दिलचस्प समस्या का समाधान नहीं करता है।


जब ऐलिस और बॉब सिग्नलिंग से जुड़ते हैं, तो वे इस चैनल का उपयोग करते हैं, DTLS हैंडशेक और सुरक्षित कनेक्शन स्थापित करते हैं। सब कुछ बहुत अच्छा है, लेकिन अगर यह हमारे सिग्नलिंग के रूप में नहीं निकला, तो, सिद्धांत रूप में, बीच में व्यक्ति को ऐलिस और बॉब दोनों के साथ "पैसा बनाने" का अवसर मिलता है, जो कि वहां हो रहे सभी ट्रैफ़िक और ईगलड्रॉप को अवरुद्ध करता है।


यदि आपके पास उच्च विश्वास के साथ सेवा है, तो, निश्चित रूप से, आपको निश्चित रूप से HTTPS, WSS, आदि का उपयोग करने की आवश्यकता है। एक और दिलचस्प समाधान है - ZRTP, इसका उपयोग किया जाता है, उदाहरण के लिए, टेलीग्राम द्वारा।

कई लोगों ने एक कनेक्शन स्थापित होने पर टेलीग्राम पर इमोजी देखा है, लेकिन कुछ लोग इसका उपयोग करते हैं। वास्तव में, यदि आप किसी मित्र को बताते हैं कि आपके पास कौन सी इमोजी है, तो वह सत्यापित करेगा कि उसके पास बिल्कुल वैसा ही है, तो आपने बिल्कुल सुरक्षित पी 2 पी कनेक्शन की गारंटी दी है।

यह कैसे काम करता है?


इन सभी प्रोटोकॉल के अंदर, सामान्य रूप से डिफी-हेलमैन एल्गोरिथम का उपयोग किया जाता है। ऐलिस कुछ संख्या उत्पन्न करता है, उन सभी को भेजता है लेकिन एक बॉब को। बॉब एक ​​यादृच्छिक संख्या भी बनाता है और इसे ऐलिस को भेजता है। इस आदान-प्रदान के परिणामस्वरूप, ऐलिस और बॉब को एक बड़ी संख्या में K मिलता है, जिसके बारे में मध्य में जो व्यक्ति अपने पूरे चैनल को सुनता है वह कुछ भी नहीं जानता है और बिल्कुल भी अनुमान नहीं लगा सकता है।

जब डेव ऐलिस और बॉब के बीच दिखाई देता है, तो वे उसके साथ एक ही कुंजी का आदान-प्रदान करते हैं, और उन्हें क्रमशः के ₁ और के ₂ मिलते हैं। इस व्यक्ति की उपस्थिति को बीच में ट्रैक करने का कोई तरीका नहीं है। फिर ऐसी तरकीब लगाई जाती है। ये कुंजियाँ K ₁ और K _{2 हैं}डेव निश्चित रूप से अलग होगा, क्योंकि ऐलिस और बॉब अपनी चाबियाँ बेतरतीब ढंग से उत्पन्न करते हैं। हम बस K ₁ और K ₂ से कुछ हैश लेते हैं और इमोजी में प्रदर्शित करते हैं: एक सेब में, एक नाशपाती में - किसी भी चीज में, और लोग बस उन तस्वीरों को कहते हैं जिन्हें वे अपनी आवाज के साथ देखते हैं। चूंकि आप एक-दूसरे को आवाज़ देकर पहचान सकते हैं, और अगर ये तस्वीरें अलग हैं, तो आपके बीच कोई है और शायद वह आपकी बात सुन रहा है।

परिणाम

• हमने NAT प्रकार का "खनन" किया और सममित NAT के माध्यम से टूट गया।
• सांख्यिकीय रूप से मूल्यांकन किया गया, जो बेहतर है: पी 2 पी या रिले, गुणवत्ता, सीडीएन; और उपयोगकर्ताओं की दृष्टि से सितारों की गुणवत्ता में सुधार हुआ है।
• कोडेक्स की प्राथमिकताओं को बदला, थोड़ी बैटरी बचाई।
• सिग्नलिंग पर न्यूनतम देरी।

ग्राफ से पता चलता है कि पहले आरटीएमएमएफपी में पुरानी कॉल थीं, फिर जब हमने वेबआरटीसी को स्विच किया, तो थोड़ी विफलता होती है, और फिर शिखर बढ़ जाता है। नहीं सब कुछ सही बाहर काम किया! परिणामस्वरूप, अब आयोजित कॉल की संख्या 4 गुना बढ़ गई है।

सरल निर्देश

यदि आपको यह सब करने की आवश्यकता नहीं है, तो एक बहुत ही सरल निर्देश है:

• WebRTC ( https://webrtc.org/native-code/development/ ) से कोड डाउनलोड करें , इसे iOS / Android के तहत इकट्ठा करें, यह पहले से ही सभी ब्राउज़रों में मौजूद है;
• coturn ( https://github.com/coturn/coturn ) को तैनात करें ;
• संकेतन लिखें।

सब कुछ बज जाएगा, और बजना बहुत अच्छा है।

HighLoad++ 4-.

, . , 19 (10 9 -) , - . , , .