RTCQuicTransport को आपके आस-पास के ऑरिजिन ट्रायल पर आने वाला है (Chrome 73)

क्या?

RTCQuicTransport एक नया वेब प्लैटफ़ॉर्म है एपीआई, जो QUIC का इस्तेमाल करके रिमोट पीयर के साथ आर्बिट्रेरी डेटा शेयर करने की सुविधा देता है प्रोटोकॉल का इस्तेमाल करना चाहिए. यह ऐप्लिकेशन, एक-दूसरे के ऐप्लिकेशन के लिए बनाया गया है. इसलिए, इसे एक स्टैंडअलोन RTCIceTransport एपीआई की मदद से पीयर-टू-पीयर कनेक्शन बनाया जा सकता है ICE. डेटा को सही तरीके से और सही क्रम में भेजा जाए (नीचे सेक्शन देखें ऑर्डर न करने की जानकारी के लिए और भरोसेमंद नहीं है). यह एक सामान्य बात है, इसलिए दो-तरफ़ा डेटा ट्रांसपोर्ट, इसका इस्तेमाल गेमिंग, फ़ाइल ट्रांसफ़र, और कई दूसरे कामों के लिए किया जा सकता है. मीडिया ट्रांसपोर्ट, मैसेज सेवा वगैरह

क्यों?

एक बेहतरीन लो लेवल डेटा ट्रांसपोर्ट एपीआई, ऐप्लिकेशन (जैसे, रीयल-टाइम में) को चालू कर सकता है संचार) करने के लिए डिज़ाइन किया गया है. एपीआई का इस्तेमाल करके, बेहतर बनाया जा सकता है. हम अपनी सुविधा के हिसाब से, एआई की मदद से कई तरह के काम करने की क्षमता को कंट्रोल करते हैं जैसे, एक-दूसरे से कनेक्ट करने के लिए, पसंद के मुताबिक बिटरेट तय करने वाले नॉब को अनलॉक करना. तय सीमा में आने वाले समय में, एन्कोड किए गए मीडिया के लिए ज़्यादा मदद मिलने से, वीडियो बातचीत करने वाला खुद का ऐप्लिकेशन होना चाहिए, जिसमें कम लेवल का कंट्रोल हो. WebRTC का NV लोअर लेवल एपीआई का इस्तेमाल करना है. साथ ही, इसे शुरुआत में ही आज़माना है कीमती है.

QUIC का इस्तेमाल क्यों करता है?

रीयल टाइम कम्यूनिकेशन के लिए, QUIC प्रोटोकॉल की ज़रूरत होती है. इसे सबसे ऊपर बनाया गया है इसमें एन्क्रिप्शन, कंजेशन कंट्रोल पहले से मौजूद होता है. साथ ही, इसके मल्टीप्लेक्स हेड ऑफ़ लाइन ब्लॉकिंग. RTCQuicTransport में भी काफ़ी कुछ मिलती है RTCDataChannel API का इस्तेमाल करता है, लेकिन ट्रांसपोर्ट के तौर पर SCTP के बजाय QUIC का इस्तेमाल करता है प्रोटोकॉल का इस्तेमाल करना चाहिए. RTCQuicTransport एक स्टैंडअलोन एपीआई है, इसलिए उसके पास RTCPeerConnection एपीआई का ओवरहेड, जिसमें रीयल-टाइम मीडिया शामिल है स्टैक.

कैसे?

सामान्य एपीआई की खास जानकारी

एपीआई में तीन मुख्य ऐब्स्ट्रैक्ट हैं, RTCIceTransport, RTCQuicTransport और RTCQuicStream.

एपीआई का आर्किटेक्चर दिखाने वाला RTCQuicTransport का डायग्राम

RTCIceTransport

ICE एक प्रोटोकॉल है. इसकी मदद से, इंटरनेट पर पीयर-टू-पीयर कनेक्शन बनाया जा सकता है और का उपयोग आज WebRTC में किया जाता है. यह ऑब्जेक्ट, इंस्टॉल करने के लिए एक स्टैंडअलोन एपीआई उपलब्ध कराता है एक ICE कनेक्शन है. इसका इस्तेमाल QUIC कनेक्शन के लिए पैकेट ट्रांसपोर्ट के तौर पर किया जाता है, और RTCQuicTransport इसे अपने कंस्ट्रक्टर में लेता है.

RTCQuicTransport

QUIC कनेक्शन को दिखाता है. इसका इस्तेमाल QUIC कनेक्शन बनाने और QUIC स्ट्रीम बनाता है. यह QUIC कनेक्शन के लिए काम के आंकड़े भी दिखाता है लेवल.

RTCQuicStream

रिमोट साइड से डेटा को पढ़ने और उसमें बदलाव करने के लिए इस्तेमाल किया जाता है. स्ट्रीम परिवहन भरोसेमंद तरीके से डेटा इकट्ठा किया है. एक ही ऐसेट से कई स्ट्रीम बनाई जा सकती हैं RTCQuicTransport और जब डेटा को किसी स्ट्रीम में लिखा जाता है, तो यह रिमोट ट्रांसपोर्ट पर “onquicstream” इवेंट. Streams की मदद से एक ही QUIC कनेक्शन पर अलग-अलग डेटा में अंतर करता है. सामान्य उदाहरणों से अलग-अलग स्ट्रीम में अलग-अलग फ़ाइलें भेज रहा हो, यानी कि या अलग-अलग स्ट्रीम या अलग-अलग तरह के मीडिया का इस्तेमाल करना. RTCQuicStream लाइटवेट होते हैं, जो QUIC कनेक्शन पर मल्टीप्लेक्स किए जाते हैं और अन्य RTCQuicStream पर हेड ऑफ़ लाइन ब्लॉक न होने दें.

कनेक्शन सेटअप

पीयर-टू-पीयर QUIC कनेक्शन सेट अप करने का उदाहरण नीचे दिया गया है. RTCPeerConnection की तरह, RTCQuicTransport एपीआई के लिए कनेक्शन के पैरामीटर पर मोल-भाव करने के लिए, सुरक्षित सिग्नलिंग चैनल, इसके सुरक्षा पैरामीटर भी शामिल हैं. RTCIceTransport ने बातचीत के दौरान ICE से बातचीत की पैरामीटर (ufरैग और पासवर्ड) के साथ-साथ RTCIceCandidate.

एपीआई का आर्किटेक्चर दिखाने वाला RTCQuicTransport का डायग्राम

क्लाइंट का नज़रिया:

const iceTransport = new RTCIceTransport();
const quicTransport = new RTCQuicTransport(iceTransport);
// Signal parameters, key and candidates.
signalingChannel.send({
  iceParams: iceTransport.getLocalParameters(),
  quicKey: quicTransport.getKey(),
});
iceTransport.onicecandidate = e => {
  if (e.candidate) {
    signalingChannel.send({candidate: e.candidate});
  }
};

// When remote parameters are signaled, start connection.
signalingChannel.onMessage = async ({iceParams, candidate}) => {
  if (iceParams) {
    iceTransport.start(iceParams);
    quicTransport.connect();
  } else if (candidate) {
    iceTransport.addRemoteCandidate(candidate);
  }
};

सर्वर का नज़रिया:

const iceTransport = new RTCIceTransport();
const quicTransport = new RTCQuicTransport(iceTransport);
// Signal parameters, key and candidates.
signalingChannel.send({
  iceParams: iceTransport.getLocalParameters(),
});
iceTransport.onicecandidate = e => {
  if (e.candidate) {
    signalingChannel.send({candidate: e.candidate});
  }
};

// When remote parameters are signaled, start connection.
signalingChannel.onMessage = async ({iceParams, quicKey, candidate}) => {
  if (iceParams && quicKey) {
    iceTransport.start(iceParams);
    quicTransport.listen(quicKey);
  } else if (candidate) {
    iceTransport.addRemoteCandidate(candidate);
  }
};

Data Transfer

RTCQuicStream API का इस्तेमाल करके, डेटा ट्रांसफ़र करने के लिए लिखा जा रहा है:

RTCQuicStreamReadResult readInto(Uint8Array data);
void write(RTCQuicStreamWriteParameters data);
Promise<void> waitForWriteBufferedAmountBelow(unsigned long amount);
Promise<void> waitForReadable(unsigned long amount);

बफ़र हो रहा है

waitFor* तरीकों से दिखाए जाने वाले वादे, डेटा को बफ़र करने की अनुमति देते हैं. ऐसा तब होता है, जब JavaScript व्यस्त है. भेजने वाले हिस्से पर पीछे का दबाव तब लागू होता है, जब पाने वाले हिस्से में रीड बफ़र भर जाता है. भेजने वाले हिस्से में एक राइट है यह बफ़र, बैक प्रेशर लागू होने पर भर सकता है. इसलिए राइट साइड में भी waitForWriteBufferedAmountBelow तरीका है बफ़र में खाली जगह में डेटा सेव करने तक इंतज़ार करें. ज़्यादा जानकारी यहां पाएं डेटा को लिखने/पढ़ने के लिए, आगे के डेवलपर में देखा जा सकता है दस्तावेज़.

बिना ऑर्डर वाली/गलत डिलीवरी

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

कब?

ऑरिजिन ट्रायल, Chrome 73 वर्शन में शुरू होगा और यह उपलब्ध होगा इसमें M75 वर्शन तक के सभी वर्शन शामिल हैं. इसके बाद, ऑरिजिन ट्रायल खत्म. सुझाव/शिकायत/राय और दिलचस्पी के आधार पर, हम इसमें ज़रूरी बदलाव करेंगे साथ ही, एपीआई को शिप करें, इस एपीआई के ऑरिजिन ट्रायल के साथ इसे जारी रखें या एपीआई बंद करें.

कहां?

iOS को छोड़कर सभी प्लैटफ़ॉर्म में Chrome ब्राउज़र.

और क्या?

सुझाव/राय दें या शिकायत करें

ऑरिजिन ट्रायल का एक मुख्य मकसद आपके सुझाव, शिकायत या राय पाना है. डेवलपर के पास जाएं. हमारी दिलचस्पी इन विषयों में है:

  • इस एपीआई की मदद से आपको क्या-क्या सुविधाएं मिलती हैं?
  • यह एपीआई, डेटा ट्रांसफ़र करने वाले अन्य एपीआई की तुलना में कैसे बेहतर होता है (WebSocket या WebRTC की RTCDataChannel)? इसे और बेहतर कैसे बनाया जा सकता है?
  • परफ़ॉर्मेंस
  • एपीआई एर्गोनॉमिक्स

ऑरिजिन ट्रायल के लिए रजिस्टर करें

  1. अपनी साइट के ऑरिजिन के लिए टोकन का अनुरोध करें.
  2. अपने पेजों पर टोकन जोड़ें. इसके लिए, इन दो तरीकों से आपकी साइट के ऑरिजिन के किसी भी पेज पर:
    • किसी भी पेज के हेडर पर origin-trial <meta> टैग जोड़ें. उदाहरण के लिए, यह कुछ ऐसा दिखेगा: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE"> अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
    • अगर आपके पास अपने सर्वर को कॉन्फ़िगर करने का विकल्प है, तो पेजों पर भी टोकन उपलब्ध कराएं Origin-Trial एचटीटीपी हेडर का इस्तेमाल करके. इससे मिलने वाला रिस्पॉन्स हेडर यह होना चाहिए कुछ ऐसा दिखेगा: Origin-Trial: TOKEN_GOES_HERE

वेब स्पेसिफ़िकेशन

ऑरिजिन ट्रायल में, ड्राफ़्ट की खास बातों को एपीआई से आगे ले जाया गया है शामिल हैं:

  • एक दिशा में चलने वाली ऐसी स्ट्रीम जो WhatWG वाली स्ट्रीम से ज़्यादा मिलती-जुलती हैं
  • रीट्रांसमिशन की सुविधा बंद की जा रही है
  • डेटाग्राम (जल्द आ रहा है)

हम पूरी विशेषता और उससे आगे (इसमें ये शामिल हैं) को लागू करने में दिलचस्पी रखते हैं WhatWG स्ट्रीम सहायता), लेकिन पहले अपना फ़ीडबैक सुनना चाहेंगे!

सुरक्षा

QUIC हैंडशेक में सुरक्षा को पहले से शेयर की गई कुंजी के इस्तेमाल से लागू किया जाता है, एन्क्रिप्ट (सुरक्षित) किया गया P2P QUIC कनेक्शन बनाएं. इस डिजिटल बटन से साइन इन करने की ज़रूरत है एक सुरक्षित बैंड चैनल से बाहर, गोपनीयता और अखंडता की गारंटी देता है. ध्यान दें कि कुंजी को JavaScript की जानकारी में दिखाया जाएगा.

ऐक्टिव अटैक

DTLS-SRTP के उलट, जिसमें सिर्फ़ प्रमाणपत्र को सिग्नल देने के लिए इंटिग्रिटी की ज़रूरत होती है पहले से शेयर की गई कुंजी को सिग्नल देने के लिए, इंटिग्रिटी ज़रूरी है और गोपनीयता बनाए रखते हैं. अगर PSK को हैक किया गया हो (जैसे कि सिग्नल में दिखाया गया सर्वर चैनल), तो एक सक्रिय हमलावर संभावित रूप से मैन इन द मिडल अटैक को माउंट कर सकता है के ख़िलाफ़ हैं.

मौजूदा स्थिति

चरण स्थिति
1. जानकारी देने वाला वीडियो बनाएं पूरा हुआ
**2a. RTCQuicTransport की खास बातें ** **प्रोसेस जारी है**
**2बी. RTCIceTransport की विशेषताएं ** **प्रोसेस जारी है**
**3. लोगों के सुझाव जानें और डिज़ाइन को दोहराएं** **प्रोसेस जारी है**
4. ऑरिजिन ट्रायल Chrome 73 में शुरू होता है!
5. लॉन्च करें Not started

सहायक लिंक्स