WebTransport एक ऐसा एपीआई है जो कम इंतज़ार, दोतरफ़ा, क्लाइंट-सर्वर मैसेजिंग की सुविधा देता है. इसके इस्तेमाल के उदाहरणों के बारे में ज़्यादा जानें. साथ ही, आने वाले समय में इसे लागू करने के बारे में सुझाव, शिकायत या राय देने का तरीका जानें.
बैकग्राउंड
WebTransport क्या है?
WebTransport एक वेब एपीआई है, जो एचटीटीपी/3 प्रोटोकॉल का इस्तेमाल, डेटा को दोनों तरफ़ भेजने के लिए करता है. इसका मकसद, वेब क्लाइंट और एचटीटीपी/3 सर्वर के बीच दोतरफ़ा कम्यूनिकेशन करना है. यह अपने डेटाग्राम एपीआई के ज़रिए डेटा भेजने की सुविधा देता है. हालांकि, यह डेटा पूरी तरह से भरोसेमंद नहीं होता. इसके अलावा, यह अपने स्ट्रीम एपीआई के ज़रिए भी डेटा भेजने की सुविधा देता है. यह डेटा पूरी तरह से भरोसेमंद होता है.
डेटाग्राम, ऐसे डेटा को भेजने और पाने के लिए सबसे सही होते हैं जिसकी डिलीवरी की गारंटी ज़रूरी नहीं होती. डेटा के अलग-अलग पैकेट का साइज़, उस कनेक्शन के मैक्सिमम ट्रांसमिशन यूनिट (एमटीयू) से सीमित होता है. साथ ही, यह भी हो सकता है कि डेटा के पैकेट ट्रांसफ़र न हो पाएं या ट्रांसफ़र हो जाएं. अगर वे ट्रांसफ़र हो जाते हैं, तो वे किसी भी क्रम में पहुंच सकते हैं. इन विशेषताओं की वजह से, डेटाग्राम एपीआई कम इंतज़ार के साथ, डेटा ट्रांसमिशन के लिए सबसे सही होते हैं. डेटाग्राम को यूज़र डेटाग्राम प्रोटोकॉल (यूडीपी) मैसेज के तौर पर देखा जा सकता है. हालांकि, ये मैसेज एन्क्रिप्ट (सुरक्षित) किए जाते हैं और ट्रैफ़िक के हिसाब से कंट्रोल किए जाते हैं.
इसके उलट, स्ट्रीम एपीआई, क्रम में डेटा ट्रांसफ़र करने की भरोसेमंद सुविधा देते हैं. ये उन स्थितियों के लिए बेहतर हैं जहां आपको क्रम में लगाए गए डेटा की एक या उससे ज़्यादा स्ट्रीम भेजनी या पाना है. एक से ज़्यादा WebTransport स्ट्रीम का इस्तेमाल करना, एक से ज़्यादा TCP कनेक्शन बनाने जैसा है. हालांकि, HTTP/3 में QUIC प्रोटोकॉल का इस्तेमाल किया जाता है, जो कम डेटा इस्तेमाल करता है. इसलिए, इन स्ट्रीम को बिना किसी रुकावट के खोला और बंद किया जा सकता है.
उपयोग के उदाहरण
यहां उन संभावित तरीकों की एक छोटी सूची दी गई है जिनसे डेवलपर, WebTransport का इस्तेमाल कर सकते हैं.
- गेम की स्थिति को नियमित अंतराल पर, सर्वर पर कम से कम इंतज़ार के साथ भेजना. इसके लिए, छोटे, भरोसेमंद नहीं, और क्रम से नहीं भेजे गए मैसेज का इस्तेमाल किया जाता है.
- सर्वर से भेजी गई मीडिया स्ट्रीम को कम से कम इंतज़ार के साथ पाना. यह अन्य डेटा स्ट्रीम से अलग होता है.
- वेब पेज खुला होने पर, सर्वर से सूचनाएं पाना.
हमें यह जानने में दिलचस्पी है कि WebTransport का इस्तेमाल कैसे किया जा सकता है. इस बारे में ज़्यादा जानकारी दें.
ब्राउज़र समर्थन
सुविधा की पहचान करने की सुविधा की मदद से, कोडिंग को सुरक्षित रखना सबसे सही तरीका है. ऐसा उन सभी सुविधाओं के लिए किया जाता है जो सभी ब्राउज़र पर काम नहीं करती हैं.
मौजूदा स्थिति
चरण | स्थिति |
---|---|
1. एक्सप्लेनर वीडियो बनाना | पूरा हो गया |
2. स्पेसिफ़िकेशन का शुरुआती ड्राफ़्ट बनाना | पूरा हो गया |
3. सुझाव/राय इकट्ठा करना और डिज़ाइन में बदलाव करना | पूरा हुआ |
4. ऑरिजिन ट्रायल | पूरा हुआ |
5. लॉन्च करना | Chromium 97 |
WebTransport और दूसरी टेक्नोलॉजी के बीच का संबंध
क्या WebTransport, WebSockets की जगह लेगा?
शायद. ऐसे कुछ मामले हैं जहां WebSockets या WebTransport, कम्यूनिकेशन प्रोटोकॉल के तौर पर इस्तेमाल किए जा सकते हैं.
वेबसोकेट कम्यूनिकेशन, मैसेज की एक ऐसी स्ट्रीम पर आधारित होते हैं जो भरोसेमंद और क्रम में होती है. यह स्ट्रीम, कम्यूनिकेशन की कुछ ज़रूरतों के लिए सही होती है. अगर आपको ये सुविधाएं चाहिए, तो WebTransport के स्ट्रीम एपीआई भी ये सुविधाएं दे सकते हैं. इसकी तुलना में, WebTransport के डेटाग्राम एपीआई कम इंतज़ार के साथ डिलीवरी देते हैं. हालांकि, इनसे यह गारंटी नहीं मिलती कि डेटा भरोसेमंद है या नहीं या उसे सही क्रम में भेजा गया है या नहीं. इसलिए, वे वेबसोकेट की जगह सीधे तौर पर इस्तेमाल नहीं किए जा सकते.
डेटाग्राम एपीआई या एक से ज़्यादा Streams API इंस्टेंस के ज़रिए WebTransport का इस्तेमाल करने का मतलब है कि आपको हेड-ऑफ़-लाइन ब्लॉकिंग के बारे में चिंता करने की ज़रूरत नहीं है. यह WebSockets के साथ समस्या हो सकती है. इसके अलावा, नए कनेक्शन बनाने पर परफ़ॉर्मेंस बेहतर होती है. इसकी वजह यह है कि QUIC हैंडशेक, TLS पर TCP शुरू करने से ज़्यादा तेज़ है.
WebTransport, ड्राफ़्ट में मौजूद नई खास जानकारी का हिस्सा है. इसलिए, क्लाइंट और सर्वर लाइब्रेरी के आस-पास मौजूद WebSocket नेटवर्क, फ़िलहाल ज़्यादा बेहतर है. अगर आपको ऐसा कुछ चाहिए जो सामान्य सर्वर सेटअप के साथ "आसान तरीके से" काम करे और ज़्यादातर वेब क्लाइंट के साथ काम करे, तो WebSockets आज का बेहतर विकल्प है.
क्या WebTransport और यूडीपी सॉकेट एपीआई एक ही हैं?
नहीं. WebTransport, यूडीपी सॉकेट एपीआई नहीं है. WebTransport, एचटीटीपी/3 का इस्तेमाल करता है, जो "अंदरूनी तौर पर" यूडीपी का इस्तेमाल करता है. हालांकि, WebTransport में एन्क्रिप्शन और ट्रैफ़िक कंट्रोल से जुड़ी ज़रूरी शर्तें होती हैं, जो इसे एक बुनियादी यूडीपी सॉकेट एपीआई से ज़्यादा बनाती हैं.
क्या WebTransport, WebRTC डेटा चैनलों का विकल्प है?
हां, क्लाइंट-सर्वर कनेक्शन के लिए. WebTransport में कई ऐसी प्रॉपर्टी होती हैं जो WebRTC डेटा चैनलों में भी होती हैं. हालांकि, इनमें इस्तेमाल किए जाने वाले प्रोटोकॉल अलग-अलग होते हैं.
आम तौर पर, एचटीटीपी/3 के साथ काम करने वाले सर्वर को चलाने के लिए, WebRTC सर्वर को मैनेज करने के मुकाबले कम सेटअप और कॉन्फ़िगरेशन की ज़रूरत होती है. इसके लिए, काम करने वाले ट्रांसपोर्ट को पाने के लिए, कई प्रोटोकॉल (ICE, DTLS, और एससीटीपी) को समझना ज़रूरी होता है. WebRTC में कई और चीज़ें शामिल होती हैं, जिनकी वजह से क्लाइंट/सर्वर के बीच बातचीत पूरी नहीं हो पाती.
WebTransport API को वेब डेवलपर के इस्तेमाल के उदाहरणों को ध्यान में रखकर डिज़ाइन किया गया था. यह WebRTC के डेटा चैनल इंटरफ़ेस का इस्तेमाल करने के बजाय, आधुनिक वेब प्लैटफ़ॉर्म कोड लिखने जैसा महसूस होना चाहिए. WebRTC के उलट, WebTransport वेब वर्कर्स में काम करता है. इसकी मदद से, किसी एचटीएमएल पेज से अलग क्लाइंट-सर्वर कम्यूनिकेशन किया जा सकता है. WebTransport, Streams के साथ काम करने वाला इंटरफ़ेस दिखाता है. इसलिए, यह बैकप्रेशर के लिए ऑप्टिमाइज़ेशन की सुविधा देता है.
हालांकि, अगर आपके पास पहले से ही कोई ऐसा WebRTC क्लाइंट/सर्वर सेटअप है जिससे आप संतुष्ट हैं, तो हो सकता है कि WebTransport पर स्विच करने से आपको ज़्यादा फ़ायदे न मिलें.
इसे आज़माएं
WebTransport के साथ प्रयोग करने का सबसे अच्छा तरीका, काम करने वाला एचटीटीपी/3 सर्वर शुरू करना है. इसके बाद, क्लाइंट/सर्वर कम्यूनिकेशन आज़माने के लिए, इस पेज का इस्तेमाल सामान्य JavaScript क्लाइंट के साथ किया जा सकता है.
इसके अलावा, webtransport.day पर कम्यूनिटी के रखरखाव वाला एक इको सर्वर उपलब्ध है.
एपीआई का इस्तेमाल करना
WebTransport को आधुनिक वेब प्लैटफ़ॉर्म प्राइमिटिव के आधार पर डिज़ाइन किया गया था. जैसे, Streams API. यह वादों पर काफ़ी निर्भर करता है. साथ ही, async
और await
के साथ अच्छी तरह से काम करता है.
Chromium में मौजूदा WebTransport, तीन अलग-अलग तरह के ट्रैफ़िक के साथ काम करता है: डेटाग्राम, साथ ही एकतरफ़ा और दोतरफ़ा स्ट्रीम, दोनों.
किसी सर्वर से कनेक्ट करना
WebTransport
इंस्टेंस बनाकर, HTTP/3 सर्वर से कनेक्ट किया जा सकता है. यूआरएल का स्कीम https
होना चाहिए. आपको पोर्ट नंबर साफ़ तौर पर बताना होगा.
आपको ready
promise to wait for the connection to be established का इस्तेमाल करना चाहिए. सेटअप पूरा होने तक यह वादा पूरा नहीं होगा. साथ ही, QUIC/TLS चरण में कनेक्शन न होने पर, इसे अस्वीकार कर दिया जाएगा.
closed
प्रॉमिस तब पूरा होता है, जब कनेक्शन सामान्य तरीके से बंद होता है. अगर कनेक्शन अचानक बंद होता है, तो प्रॉमिस अस्वीकार कर दिया जाता है.
अगर क्लाइंट से मिले निर्देश की वजह से सर्वर कनेक्शन को अस्वीकार करता है (उदाहरण के लिए, यूआरएल का पाथ अमान्य है), तो closed
अस्वीकार हो जाता है. हालांकि, ready
का समाधान नहीं किया जाता.
const url = 'https://example.com:4999/foo/bar';
const transport = new WebTransport(url);
// Optionally, set up functions to respond to
// the connection closing:
transport.closed.then(() => {
console.log(`The HTTP/3 connection to ${url} closed gracefully.`);
}).catch((error) => {
console.error(`The HTTP/3 connection to ${url} closed due to ${error}.`);
});
// Once .ready fulfills, the connection can be used.
await transport.ready;
Datagram API
जब आपके पास सर्वर से कनेक्ट किया गया WebTransport इंस्टेंस हो, तो इसका इस्तेमाल डेटा के अलग-अलग हिस्सों को भेजने और पाने के लिए किया जा सकता है. इन हिस्सों को डेटाग्राम कहा जाता है.
writeable
गटर, WritableStream
दिखाता है. वेब क्लाइंट इसका इस्तेमाल, सर्वर को डेटा भेजने के लिए कर सकता है. readable
गटर, ReadableStream
दिखाता है. इससे, सर्वर से डेटा को सुनने में मदद मिलती है. दोनों स्ट्रीम में डेटा को सुरक्षित नहीं रखा जा सकता. इसलिए, हो सकता है कि आपने जो डेटा डाला है वह सर्वर को न मिले और सर्वर से जो डेटा मिला है वह आपको न मिले.
दोनों तरह की स्ट्रीम, डेटा ट्रांसफ़र के लिए Uint8Array
इंस्टेंस का इस्तेमाल करती हैं.
// Send two datagrams to the server.
const writer = transport.datagrams.writable.getWriter();
const data1 = new Uint8Array([65, 66, 67]);
const data2 = new Uint8Array([68, 69, 70]);
writer.write(data1);
writer.write(data2);
// Read datagrams from the server.
const reader = transport.datagrams.readable.getReader();
while (true) {
const {value, done} = await reader.read();
if (done) {
break;
}
// value is a Uint8Array.
console.log(value);
}
Streams API
सर्वर से कनेक्ट होने के बाद, Streams API के ज़रिए डेटा भेजने और पाने के लिए, WebTransport का इस्तेमाल भी किया जा सकता है.
सभी स्ट्रीम का हर चंक एक Uint8Array
होता है. Datagram API के मुकाबले, ये स्ट्रीम भरोसेमंद होती हैं. हालांकि, हर स्ट्रीम अलग-अलग होती है. इसलिए, यह गारंटी नहीं दी जा सकती कि सभी स्ट्रीम में डेटा का क्रम एक जैसा होगा.
WebTransportSendStream
वेब क्लाइंट, WebTransport
इंस्टेंस के createUnidirectionalStream()
तरीके का इस्तेमाल करके WebTransportSendStream
बनाता है. इससे WebTransportSendStream
के लिए एक प्रॉमिस मिलता है.
इससे जुड़ी एचटीटीपी/3 स्ट्रीम को बंद करने के लिए, WritableStreamDefaultWriter
के close()
तरीके का इस्तेमाल करें. ब्राउज़र, स्ट्रीम को बंद करने से पहले, उससे जुड़ा सारा डेटा भेजने की कोशिश करता है.
// Send two Uint8Arrays to the server.
const stream = await transport.createUnidirectionalStream();
const writer = stream.writable.getWriter();
const data1 = new Uint8Array([65, 66, 67]);
const data2 = new Uint8Array([68, 69, 70]);
writer.write(data1);
writer.write(data2);
try {
await writer.close();
console.log('All data has been sent.');
} catch (error) {
console.error(`An error occurred: ${error}`);
}
इसी तरह, सर्वर पर RESET_STREAM
भेजने के लिए, WritableStreamDefaultWriter
के abort()
तरीके का इस्तेमाल करें. abort()
का इस्तेमाल करने पर, ब्राउज़र उस डेटा को खारिज कर सकता है जो अभी तक भेजा नहीं गया है.
const ws = await transport.createUnidirectionalStream();
const writer = ws.getWriter();
writer.write(...);
writer.write(...);
await writer.abort();
// Not all the data may have been written.
WebTransportReceiveStream
सर्वर से WebTransportReceiveStream
शुरू किया जाता है. वेब क्लाइंट के लिए, WebTransportReceiveStream
पाने की प्रक्रिया दो चरणों में पूरी होती है. सबसे पहले, यह WebTransport
इंस्टेंस के incomingUnidirectionalStreams
एट्रिब्यूट को कॉल करता है, जो ReadableStream
दिखाता है. उस ReadableStream
का हर चंक, एक WebTransportReceiveStream
होता है. इसका इस्तेमाल, सर्वर से भेजे गए Uint8Array
इंस्टेंस को पढ़ने के लिए किया जा सकता है.
async function readFrom(receiveStream) {
const reader = receiveStream.readable.getReader();
while (true) {
const {done, value} = await reader.read();
if (done) {
break;
}
// value is a Uint8Array
console.log(value);
}
}
const rs = transport.incomingUnidirectionalStreams;
const reader = rs.getReader();
while (true) {
const {done, value} = await reader.read();
if (done) {
break;
}
// value is an instance of WebTransportReceiveStream
await readFrom(value);
}
ReadableStreamDefaultReader
के closed
प्रॉमिस का इस्तेमाल करके, स्ट्रीम के बंद होने का पता लगाया जा सकता है. जब एचटीटीपी/3 स्ट्रीम को FIN बिट के साथ बंद किया जाता है, तो पूरा डेटा पढ़ने के बाद closed
वादा पूरा हो जाता है. जब एचटीटीपी/3 स्ट्रीम अचानक बंद हो जाती है (उदाहरण के लिए, RESET_STREAM
से), तो closed
प्रॉमिस अस्वीकार हो जाता है.
// Assume an active receiveStream
const reader = receiveStream.readable.getReader();
reader.closed.then(() => {
console.log('The receiveStream closed gracefully.');
}).catch(() => {
console.error('The receiveStream closed abruptly.');
});
WebTransportBidirectionalStream
WebTransportBidirectionalStream
को सर्वर या क्लाइंट, दोनों में से कोई भी बना सकता है.
वेब क्लाइंट, WebTransport
इंस्टेंस के createBidirectionalStream()
तरीके का इस्तेमाल करके एक प्रोमिज़ बना सकते हैं. यह प्रोमिज़, WebTransportBidirectionalStream
के लिए एक प्रोमिज़ दिखाता है.
const stream = await transport.createBidirectionalStream();
// stream is a WebTransportBidirectionalStream
// stream.readable is a ReadableStream
// stream.writable is a WritableStream
WebTransport
इंस्टेंस के incomingBidirectionalStreams
एट्रिब्यूट की मदद से, सर्वर से बनाए गए WebTransportBidirectionalStream
को सुना जा सकता है. यह ReadableStream
दिखाता है. उस ReadableStream
का हर हिस्सा, एक WebTransportBidirectionalStream
होता है.
const rs = transport.incomingBidirectionalStreams;
const reader = rs.getReader();
while (true) {
const {done, value} = await reader.read();
if (done) {
break;
}
// value is a WebTransportBidirectionalStream
// value.readable is a ReadableStream
// value.writable is a WritableStream
}
WebTransportBidirectionalStream
, WebTransportSendStream
और WebTransportReceiveStream
का सिर्फ़ एक कॉम्बिनेशन है. पिछले दो सेक्शन में दिए गए उदाहरणों से, इन दोनों का इस्तेमाल करने का तरीका पता चलता है.
और उदाहरण
WebTransport ड्राफ़्ट स्पेसिफ़िकेशन में, सभी तरीकों और प्रॉपर्टी के लिए पूरा दस्तावेज़ शामिल है. साथ ही, इसमें कई अन्य इनलाइन उदाहरण भी शामिल हैं.
Chrome के DevTools में WebTransport
माफ़ करें, फ़िलहाल Chrome के DevTools में WebTransport की सुविधा काम नहीं करती. DevTools इंटरफ़ेस पर अपडेट के बारे में सूचना पाने के लिए, Chrome से जुड़ी इस समस्या को "स्टार" किया जा सकता है.
Polyfill
webtransport-ponyfill-websocket
नाम का एक पॉलीफ़िल (यानी ऐसा पॉनीफ़िल जो स्टैंडअलोन मॉड्यूल के तौर पर काम करने की सुविधा देता है) उपलब्ध है. यह WebTransport की कुछ सुविधाओं को लागू करता है. प्रोजेक्ट के README
में दी गई पाबंदियों को ध्यान से पढ़ें. इससे यह पता चलेगा कि यह समाधान आपके इस्तेमाल के उदाहरण के लिए काम कर सकता है या नहीं.
निजता और सुरक्षा से जुड़ी बातें
आधिकारिक दिशा-निर्देश के लिए, ड्राफ़्ट स्पेसिफ़िकेशन का उससे जुड़ा सेक्शन देखें.
सुझाव/राय दें या शिकायत करें
Chrome की टीम इस एपीआई का इस्तेमाल करने के बारे में आपके विचार और अनुभव जानना चाहती है.
एपीआई के डिज़ाइन के बारे में सुझाव/राय/शिकायत
क्या एपीआई में कोई ऐसी समस्या है जो मुश्किल है या उम्मीद के मुताबिक काम नहीं करती? क्या आपको अपने आइडिया को लागू करने के लिए, कुछ और जानकारी चाहिए?
Web Transport GitHub repo पर कोई समस्या दर्ज करें या किसी मौजूदा समस्या में अपने सुझाव/राय जोड़ें.
क्या लागू करने में समस्या आ रही है?
क्या आपको Chrome में इस सुविधा को लागू करने में कोई गड़बड़ी मिली?
https://new.crbug.com पर जाकर, गड़बड़ी की शिकायत करें. इसमें ज़्यादा से ज़्यादा जानकारी शामिल करें. साथ ही, गड़बड़ी को दोहराने के लिए आसान निर्देश भी दें.
क्या आपको एपीआई का इस्तेमाल करना है?
सार्वजनिक तौर पर सहायता पाने की सुविधा से, Chrome को सुविधाओं को प्राथमिकता देने में मदद मिलती है. साथ ही, इससे अन्य ब्राउज़र वेंडर को यह पता चलता है कि इन सुविधाओं को उपलब्ध कराना कितना ज़रूरी है.
- @ChromiumDev को ट्वीट करें. इसके लिए, हैशटैग
#WebTransport
का इस्तेमाल करें. साथ ही, यह जानकारी दें कि आपने इसे कहां और कैसे इस्तेमाल किया है.
सामान्य चर्चा
सामान्य सवालों या ऐसी समस्याओं के लिए, web-transport-dev Google ग्रुप का इस्तेमाल किया जा सकता है जो किसी अन्य कैटगरी में नहीं आती हैं.
आभार
इस लेख में, WebTransport के बारे में जानकारी देने वाले लेख, ड्राफ़्ट स्पेसिफ़िकेशन, और इससे जुड़े डिज़ाइन दस्तावेज़ की जानकारी शामिल है. इस जानकारी को उपलब्ध कराने के लिए, लेखकों का धन्यवाद.
इस पोस्ट की हीरो इमेज, Unsplash पर रॉबिन पियरे की है.