क्या?
RTCQuicTransport एक नया वेब प्लैटफ़ॉर्म एपीआई है. इसकी मदद से, QUIC प्रोटोकॉल का इस्तेमाल करके, रिमोट पीयर के साथ आर्बिट्रेरी डेटा का लेन-देन किया जा सकता है. यह पीयर-टू-पीयर इस्तेमाल के उदाहरण के लिए है. इसलिए, इसे स्टैंडअलोन RTCIceTransport API के साथ इस्तेमाल किया जाता है, ताकि ICE की मदद से पीयर-टू-पीयर कनेक्शन बनाया जा सके. डेटा को सही तरीके से और ऑर्डर में ट्रांसपोर्ट किया जाता है. बिना ऑर्डर वाली या गलत डिलीवरी के बारे में जानने के लिए, नीचे दिया गया सेक्शन देखें. यह एक सामान्य, दोनोंतरफ़ा डेटा ट्रांसपोर्ट है, इसलिए इसका इस्तेमाल गेमिंग, फ़ाइल ट्रांसफ़र, मीडिया ट्रांसपोर्ट, मैसेज सेवा वगैरह के लिए किया जा सकता है.
ऐसा क्यों हो रहा है?
कम लेवल वाला डेटा ट्रांसपोर्ट एपीआई, ऐप्लिकेशन (जैसे कि रीयल-टाइम कम्यूनिकेशन) को वेब पर नए काम करने के लिए चालू कर सकता है. एपीआई को बेहतर तरीके से इस्तेमाल करके, खुद के सलूशन बनाए जा सकते हैं. पीयर-टू-पीयर कनेक्शन की मदद से क्या-क्या किया जा सकता है, इसकी सीमाओं को बढ़ाने की कोशिश की जा सकती है. उदाहरण के लिए, पसंद के मुताबिक बिटरेट ऐलोकेशन वाले नॉब अनलॉक करना. आने वाले समय में, कोड में बदले गए मीडिया को ज़्यादा सहायता मिलने से, लो लेवल कंट्रोल की मदद से अपना वीडियो कम्यूनिकेशन ऐप्लिकेशन भी बनाया जा सकता है. WebRTC की NV की कोशिश लो लेवल के एपीआई की ओर बढ़ना है. इस पर जल्दी प्रयोग करना बहुत अच्छा है.
QUIC क्यों है?
रीयल टाइम में बातचीत करने के लिए, QUIC प्रोटोकॉल ज़रूरी है. इसे यूडीपी पर बनाया गया है. यह एन्क्रिप्शन और कंजेशन कंट्रोल में पहले से मौजूद है. साथ ही, इसे लाइन ब्लॉक किए बिना मल्टीप्लेक्स किया जाता है. RTCQuicTransport
, RTCDataChannel
एपीआई जैसी ही सुविधाएं देता है. हालांकि, इसके ट्रांसपोर्ट प्रोटोकॉल के तौर पर SCTP के बजाय, QUIC का इस्तेमाल किया जाता है. RTCQuicTransport
एक स्टैंडअलोन एपीआई है. इसलिए, इसमें RTCPeerConnection
API का ऊपरी हिस्सा नहीं होता. इसमें रीयल-टाइम मीडिया स्टैक भी शामिल होता है.
कैसे करें?
सामान्य एपीआई की खास जानकारी
इस एपीआई में तीन मुख्य ऐब्स्ट्रैक्शन हैं, RTCIceTransport
, RTCQuicTransport
, और RTCQuicStream
.
RTCIceTransport
ICE एक प्रोटोकॉल है, जिसका इस्तेमाल इंटरनेट पर पीयर-टू-पीयर कनेक्शन बनाने के लिए किया जाता है. फ़िलहाल, WebRTC में इसका इस्तेमाल किया जाता है. यह ऑब्जेक्ट, ICE कनेक्शन बनाने के लिए स्टैंडअलोन एपीआई
उपलब्ध कराता है. इसका इस्तेमाल, QUIC कनेक्शन के लिए पैकेट ट्रांसपोर्ट के तौर पर किया जाता है.
और RTCQuicTransport
इसे कंस्ट्रक्टर में लेता है.
RTCQuicTransport
यह QUIC कनेक्शन को दिखाता है. इसका इस्तेमाल QUIC कनेक्शन बनाने और QUIC स्ट्रीम बनाने में किया जाता है. यह QUIC कनेक्शन लेवल के काम के आंकड़े भी दिखाता है.
RTCQuicStream
इसका इस्तेमाल, रिमोट साइड पर या उससे डेटा को पढ़ने और लिखने के लिए किया जाता है. स्ट्रीम, डेटा को
भरोसेमंद तरीके से और क्रम में ले जाती है. एक ही RTCQuicTransport
से कई स्ट्रीम बनाई जा सकती हैं. किसी स्ट्रीम में डेटा लिखने के बाद, रिमोट ट्रांसपोर्ट पर “ऑनक्विकस्ट्रीम” इवेंट ट्रिगर किया जाता है. स्ट्रीम की मदद से, एक ही QUIC कनेक्शन पर
अलग-अलग डेटा को पहचाना जा सकता है. इसके सामान्य उदाहरणों में,
अलग-अलग स्ट्रीम में अलग-अलग फ़ाइलें, अलग-अलग स्ट्रीम में डेटा का छोटा हिस्सा या अलग-अलग स्ट्रीम में
अलग-अलग तरह के मीडिया शामिल हो सकते हैं.
RTCQuicStream
लाइटवेट होते हैं, क्यूआईसी कनेक्शन पर मल्टीप्लेक्स किए जाते हैं, और इनकी वजह से अन्य RTCQuicStream
s पर लाइन के हेड की वजह से ब्लॉक नहीं होता.
कनेक्शन सेटअप
पीयर-टू-पीयर QUIC कनेक्शन सेट अप करने का एक उदाहरण नीचे दिया गया है.
RTCPeerConnection
की तरह, RTCQuicTransport
एपीआई को कनेक्शन के पैरामीटर और उसके सुरक्षा पैरामीटर से जुड़े
पैरामीटर का इस्तेमाल करने के लिए, एक सुरक्षित सिग्नलिंग चैनल की ज़रूरत होती है. RTCIceTransport
अपने ICE पैरामीटर (ufras और पासवर्ड) के साथ-साथ 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
s या WebRTC केRTCDataChannel
) की तुलना में कैसे बेहतर बनाता है? इसे कैसे बेहतर बनाया जा सकता है? - परफ़ॉर्मेंस
- एपीआई अर्गोनॉमिक्स
ऑरिजिन ट्रायल के लिए रजिस्टर करें
- अपने ऑरिजिन के लिए, टोकन का अनुरोध करें.
- अपने पेजों में टोकन जोड़ें. अपने ऑरिजिन वाले किसी भी पेज पर इस टोकन को दो तरीके से उपलब्ध कराया जा सकता है:
- किसी भी पेज के हेड में
origin-trial
<meta>
टैग जोड़ें. उदाहरण के लिए, यह कुछ ऐसा दिख सकता है:<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
- अगर आपके सर्वर को कॉन्फ़िगर किया जा सकता है, तो
Origin-Trial
एचटीटीपी हेडर का इस्तेमाल करके भी पेजों पर टोकन दिया जा सकता है. रिस्पॉन्स हेडर कुछ ऐसा दिखना चाहिए:Origin-Trial: TOKEN_GOES_HERE
- किसी भी पेज के हेड में
वेब की विशेषताएं
ऑरिजिन ट्रायल में ड्राफ़्ट की खास जानकारी, एपीआई से आगे हो गई है. इसमें ये शामिल हैं:
- एक दिशा में चलने वाली स्ट्रीम, जो WHATWG स्ट्रीम के साथ अलाइन होती हैं
- ट्रांसमिशन की सुविधा बंद की जा रही है
- (जल्द आ रहा है) डेटाग्राम
हमारी दिलचस्पी पूरी जानकारी और उससे जुड़ी दूसरी चीज़ों को लागू करने में है (इसमें WhatWG स्ट्रीम के साथ काम करने की सुविधा भी शामिल है), लेकिन हम पहले आपके सुझाव, शिकायत या राय जानना चाहते हैं!
सुरक्षा
एन्क्रिप्ट (सुरक्षित) किए गए P2P QUIC कनेक्शन को लागू करने के लिए, पहले से शेयर की गई कुंजी का इस्तेमाल करके QUIC हैंडशेक में सुरक्षा लागू की जाती है. इस कुंजी के साथ बैंड चैनल से सुरक्षित होने की पुष्टि होनी चाहिए. यह गोपनीयता और सुरक्षा की गारंटी देता है. ध्यान दें कि कुंजी को JavaScript से ऐक्सेस किया जा सकता है.
ऐक्टिव अटैक
DTLS-SRTP के उलट, जिसमें सिर्फ़ सर्टिफ़िकेट फ़िंगरप्रिंट का सिग्नल देने के लिए पूरी सुरक्षा ज़रूरी होती है, पहले से शेयर की गई कुंजी का सिग्नल देने के लिए इंटिग्रिटी और गोपनीय की ज़रूरत होती है. अगर PSK से छेड़छाड़ की गई हो (जैसा कि सिग्नल देने वाले चैनल में सर्वर ने कहा हो), तो सक्रिय हमलावर QUIC हैंडशेक के ख़िलाफ़ मैन-इन-द-मिडल हमले कर सकता है.
मौजूदा स्थिति
चरण | स्थिति |
---|---|
1. जानकारी बनाएं | पूरा हुआ |
**2a. RTCQuicTransport की खास जानकारी ** | **प्रोसेस जारी है** |
**2b. RTCIceTransport के बारे में खास जानकारी ** | **प्रोसेस जारी है** |
**3. लोगों से सुझाव लें और डिज़ाइन को बार-बार दोहराएं** | **प्रोसेस जारी है** |
4. ऑरिजिन ट्रायल | Chrome 73 में शुरू होगा! |
5. लॉन्च करें | Not started |
सहायक लिंक्स
- अन्य दस्तावेज़
- सार्वजनिक तौर पर जानकारी देने वाला वीडियो
- गड़बड़ी को ट्रैक करना
- ऑरिजिन ट्रायल टोकन का अनुरोध करें
- ऑरिजिन ट्रायल टोकन को इस्तेमाल करने का तरीका
- RTCQuicTransport से जुड़ी समस्याओं पर चर्चा
- RTCIceTransport से जुड़ी समस्याओं पर चर्चा