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

क्या?

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

क्यों?

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

QUIC क्यों?

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

कैसे?

एपीआई के बारे में खास जानकारी

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

RTCIceTransport

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

RTCQuicTransport

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

RTCQuicStream

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

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

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

क्लाइंट के नज़रिए से:

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 स्ट्रीम की सुविधा भी शामिल है. हालांकि, हमें पहले आपका सुझाव चाहिए!

सुरक्षा

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

ऐक्टिव अटैक

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

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

सहायक लिंक्स

• अन्य दस्तावेज़
• सार्वजनिक तौर पर जानकारी देने की सुविधा
• बग को ट्रैक करना
• ऑरिजिन ट्रायल टोकन का अनुरोध करना
• ऑरिजिन ट्रायल टोकन का इस्तेमाल कैसे करें
• RTCQuicTransport से जुड़ी समस्याओं पर चर्चा
• RTCIceTransport से जुड़ी समस्याओं पर चर्चा