📱 🧔🏿 👩🏾‍💻 QUIC DataChannels: पहले चरण 🔷 🙇 💊

QUIC- आधारित डेटाचैनल्स को वर्तमान SCTP परिवहन का एक विकल्प माना जाता है। Google WebRTC कार्य समूह पहले से ही उनके साथ प्रयोग कर रहा है:

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

आरंभ करने से पहले, आइए DataChannel की मूल बातें याद करें।

संक्षेप में DataChannel के बारे में

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

 const dc = pc.createDataChannel("some label string"); // ,    – ,   – //    send dc.send("some string"); //    otherPc.addEventListener('datachannel', e => { const channel = e.channel; channel.onmessage = event => { console.log('received', event.data); }); });

आधिकारिक WebRTC नमूने पृष्ठ पर तार और बाइनरी डेटा भेजने के उदाहरण हैं।

DataChannel SCTP का उपयोग करता है। यह ऑडियो और वीडियो स्ट्रीम के लिए RTP ट्रांसपोर्ट के समानांतर काम करता है। यूडीपी के विपरीत, जो आमतौर पर ऑडियो और वीडियो स्ट्रीम द्वारा उपयोग किया जाता है, एससीटीपी कई अन्य सुविधाएँ प्रदान करता है, जैसे एकल कनेक्शन या विश्वसनीय पर मल्टीप्लेक्सिंग चैनल, आंशिक रूप से विश्वसनीय (यानी विश्वसनीय, लेकिन अव्यवस्थित) और अविश्वसनीय मोड।

Google ने 2012 में QUIC पेश किया (प्रोटोकॉल इतिहास के बारे में और इसकी बारीकियों को हमारी अन्य सामग्री - अनुवादक के नोट में पाया जा सकता है)। WebRTC की तरह, QUIC प्रोटोकॉल को IETF के विंग के तहत भी लिया गया है और अब HTTP / 3 है । QUIC में कई महान नवाचार हैं, जैसे: कम विलंबता, भीड़ नियंत्रण के आधार पर बैंडविड्थ गणना, प्रत्यक्ष देरी सुधार (FEC) और तेजी से रोलिंग के लिए उपयोगकर्ता अंतरिक्ष (कर्नेल के बजाय) में कार्यान्वयन।

QUIC WebRTC के लिए RTCP का विकल्प हो सकता है - जैसे DataChannel के लिए परिवहन। वर्तमान प्रयोग ICCP परिवहन के एक अलग संस्करण का उपयोग करके RTCPeerConnection API ( और SDP! ) का उपयोग करने से बचने की कोशिश कर रहा है। इसे एक आभासी कनेक्शन के रूप में सोचें जो थोड़ी सुरक्षा और बहुत से एनएटी ट्रैवर्सल जोड़ता है।

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

QUIC के साथ पहला कदम

सौभाग्य से, 2015 के लेख के अधिकांश कोड प्रासंगिक बने हुए हैं और आसानी से नए एपीआई के लिए अनुकूल हैं। चलिए इसका पता लगाते हैं।

यहाँ से कोड क्लोन करें या इसे यहाँ आज़माएँ। कृपया ध्यान दें कि प्रयोग को स्थानीय स्तर पर करने के लिए क्रोम (संस्करण 73+ अब कैनरी है) को विशेष झंडे के साथ चलाया जाना चाहिए:

 google-chrome-unstable --enable-blink-features=RTCQuicTransport,RTCIceTransportExtension

ICE परिवहन सेटअप

RTCIceTransport विनिर्देश ORTC पर आधारित है, इसलिए सेटअप पुराने कोड के समान है:

 const ice1 = new RTCIceTransport(); ice1.onstatechange = function() { console.log('ICE transport 1 state change', ice1.state); }; const ice2 = new RTCIceTransport(); ice2.onstatechange = function() { console.log('ICE transport 2 state change', ice2.state); }; //  ICE- ice1.onicecandidate = function(evt) { console.log('1 -> 2', evt.candidate); if (evt.candidate) { ice2.addRemoteCandidate(evt.candidate); } }; ice2.onicecandidate = function(evt) { console.log('2 -> 1', evt.candidate); if (evt.candidate) { ice1.addRemoteCandidate(evt.candidate); } }; //  ICE- ice1.start(ice2.getLocalParameters(), 'controlling'); ice2.start(ice1.getLocalParameters(), 'controlled'); ice1.gather(iceOptions); ice2.gather(iceOptions);

ध्यान दें कि इस API में ORTC के विपरीत RTCIceGatherer नहीं है। क्योंकि हमारे पास पहले से ही आईसीई परिवहन स्थापित करने के लिए आवश्यक सब कुछ है।

QUIC परिवहन को कॉन्फ़िगर करना

 const quic1 = new RTCQuicTransport(ice1); quic1.onstatechange = function() { console.log('QUIC transport 1 state change', quic1.state); }; const quic2 = new RTCQuicTransport(ice2); quic2.onstatechange = function() { console.log('QUIC transport 2 state change', quic2.state); }; //     QUIC quic2.addEventListener('quicstream', (e) => { console.log('QUIC transport 2 got a stream', e.stream); receiveStream = e.stream; });

यहां, प्रमाणपत्र विनिर्देश आधारित प्रमाणीकरण का उपयोग करने वाले विनिर्देश से प्रस्थान करता है। इसके बजाय, सार्वजनिक कुंजी का उपयोग किया जाता है, जैसा कि Google डेवलपर्स पोस्ट कहता है :

RTCQuicTransport कनेक्शन को API सार्वजनिक कुंजी से कॉन्फ़िगर किया गया है। मूल मान्यता को बदलने के लिए हम वर्तमान में इस एपीआई के लिए योजना नहीं बनाते हैं। इसे स्व-हस्ताक्षरित प्रमाणपत्रों को मान्य करने के लिए एक दूरस्थ प्रमाणपत्र संकेत द्वारा प्रतिस्थापित किया जाएगा - जब QUIC क्रोमियम में इसका समर्थन करना शुरू करता है।

अब तक, इतना अच्छा।

डेटा भेजने और प्राप्त करने के लिए QUICStream

QUICStream का उपयोग करना WebRTC DataChannel की तुलना में थोड़ा पेचीदा है। WHATWG वर्किंग ग्रुप द्वारा बनाई गई स्ट्रीम API ( MDN पर विवरण देखें ) को स्वीकार किया गया है लेकिन लागू नहीं किया गया है ।

QUIC परिवहन "कनेक्टेड" स्थिति में जाने के बाद ही हम sendStream बनाते हैं - एक अलग स्थिति में यह एक त्रुटि का कारण होगा:

 quic1.onstatechange = function() { console.log('QUIC transport 1 state change', quic1.state); if (quic1.state === 'connected' && !sendStream) { sendStream = quic1.createStream('webrtchacks'); //   createDataChannel. document.getElementById('sendButton').disabled = false; document.getElementById('dataChannelSend').disabled = false; } };

फिर हम हैंडलर को सबमिट बटन और इनपुट फ़ील्ड से जोड़ते हैं: बटन पर क्लिक करने के बाद, इनपुट फ़ील्ड से टेक्स्ट को Uint8Array में इनकोड किया जाता है और स्ट्रीम को लिखा जाता है:

 document.getElementById('sendButton').onclick = () => { const rawData = document.getElementById('dataChannelSend').value; document.getElementById('dataChannelSend').value = ''; //  Uint8Array. ,       TextEncoder. const data = encoder.encode(rawData); sendStream.write({ data, }); };

पहली प्रविष्टि दूरस्थ onquicstream ट्रांसपोर्ट पर onquicstream घटना को ट्रिगर करेगी:

 //     QUIC quic2.addEventListener('quicstream', (e) => { console.log('QUIC transport 2 got a stream', e.stream); receiveStream = e.stream; receiveStream.waitForReadable(1) .then(ondata); });

... और फिर हम डेटा के पठनीय होने की प्रतीक्षा करते हैं:

 function ondata() { const buffer = new Uint8Array(receiveStream.readBufferedAmount); const res = receiveStream.readInto(buffer); const data = decoder.decode(buffer); document.getElementById('dataChannelReceive').value = data; receiveStream.waitForReadable(1) .then(ondata); }

receiveStream सभी डेटा को receiveStream जाएगा, पाठ में डिकोड किया जाएगा और आउटपुट फ़ील्ड में रखा जाएगा। और इसलिए हर बार पठनीय डेटा दिखाई देता है।

निष्कर्ष और टिप्पणियाँ

मुझे उम्मीद है कि यह उदाहरण Google ब्लॉग पर समान की तुलना में समझने में आसान है। यह विधि पी 2 पी कनेक्शन के लिए शायद ही उपयुक्त है, एससीटीपी पर डेटाचैन उनके लिए पहले से ही ठीक कर रहा है। हालांकि, यह दूसरे छोर पर एक QUIC सर्वर के साथ वेब सॉकेट के लिए एक दिलचस्प विकल्प हो सकता है। ऐसा होने तक, आपको अविश्वसनीय और अव्यवस्थित चैनलों के साथ काम करने का एक अच्छा तरीका निर्धारित करना चाहिए। मेरी राय में, उपरोक्त पोस्ट के सुझाव फैसलों की तुलना में हैक की तरह अधिक दिखते हैं।

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

मैं क्रोमियम में SCTP को अतिरिक्त सुविधाएँ भी चाहूंगा। उदाहरण के लिए, DataChannel के बारे में यह क्वेरी - सबसे अधिक मूल्यांकित, तीन वर्षों तक लगभग अछूती रही है। यह पूरी तरह से स्पष्ट नहीं है कि क्यों SCIC कार्यों पर अभी भी QUIC पर ध्यान केंद्रित है; हालाँकि, यह किसी को भी QUIC और परिणामों पर प्रतिक्रिया का परीक्षण करने से नहीं रोकना चाहिए।

Voximplant द्वारा टिप्पणी

हमारे सामने की ओर लीड शब्द के लिए एक शब्द:

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

हमने हाल ही में DataChannel पर सिग्नलिंग प्रोटोकॉल का एक बंद बीटा परीक्षण शुरू किया है। यह प्रोटोकॉल भी इसके minuses के बिना नहीं है, लेकिन चूंकि यह खराब नेटवर्क में काम करता है और जब घूमते हैं, तो यह पहली नजर में जीत जाता है। क्या आपने नेटवर्क बदला है? कनेक्शन को फिर से बनाने की आवश्यकता नहीं है। ज्यादातर मामलों में ICE Restart यातायात के लिए एक नया रास्ता खोजने में मदद करेगा। लेकिन, जैसा कि मैंने कहा, प्रोटोकॉल में अभी भी कमियां हैं: सभी ब्राउज़र सभी प्रोटोकॉल एक्सटेंशन का समर्थन नहीं करते हैं, जैसे कि गारंटीकृत वितरण और पैकेट ऑर्डर समर्थन; यह भी प्रोटोकॉल बॉक्स से बाहर पाठ मोड के लिए gzip का समर्थन नहीं करता है। लेकिन इन सभी समस्याओं को आवेदन पक्ष में हल किया जा सकता है।

QUIC DataChannels: पहले चरण