WebTransport का इस्तेमाल करने का तरीका

Jeff Posnick

पब्लिश होने की तारीख: 8 जून, 2020

WebTransport एक वेब एपीआई है. यह एचटीटीपी/3 प्रोटोकॉल का इस्तेमाल, दोनों दिशाओं में डेटा ट्रांसफ़र करने के लिए करता है. इसे वेब क्लाइंट और HTTP/3 सर्वर के बीच दोनों तरफ़ से कम्यूनिकेशन करने के लिए बनाया गया है. यह डेटाग्राम एपीआई की मदद से, डेटा को भरोसेमंद तरीके से और स्ट्रीम एपीआई की मदद से, डेटा को बिना किसी भरोसे के भेज सकता है.

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

इसके उलट, स्ट्रीम एपीआई भरोसेमंद और क्रम से डेटा ट्रांसफ़र करते हैं. ये उन स्थितियों के लिए सबसे सही हैं जहां आपको क्रम से लगे डेटा की एक या उससे ज़्यादा स्ट्रीम भेजनी या पानी होती हैं. एक साथ कई WebTransport स्ट्रीम का इस्तेमाल करना, कई TCP कनेक्शन बनाने जैसा है. हालांकि, HTTP/3 में QUIC प्रोटोकॉल का इस्तेमाल किया जाता है, इसलिए इन्हें आसानी से खोला और बंद किया जा सकता है.

उपयोग के उदाहरण

यहां कुछ ऐसे तरीके दिए गए हैं जिनसे डेवलपर, WebTransport का इस्तेमाल कर सकते हैं.

• गेम की स्थिति को नियमित अंतराल पर सर्वर को भेजना. इसमें कम से कम देरी होनी चाहिए. साथ ही, छोटे, अविश्वसनीय, और क्रम से बाहर के मैसेज होने चाहिए.
• सर्वर से पुश की गई मीडिया स्ट्रीम को कम से कम देरी के साथ पाना. यह अन्य डेटा स्ट्रीम से अलग होती है.
• वेब पेज खुला होने पर, सर्वर से भेजी गई सूचनाएँ पाना.

हमें इस बारे में ज़्यादा जानकारी चाहिए कि WebTransport का इस्तेमाल कैसे किया जाएगा.

ब्राउज़र समर्थन

हमारा सुझाव है कि आप सुविधा का पता लगाने की सुविधा जोड़ें. ऐसा इसलिए, क्योंकि यह सुविधा उन सभी सुविधाओं के लिए ज़रूरी है जो सभी ब्राउज़र पर काम नहीं करती हैं.

अन्य टेक्नोलॉजी से संबंध

क्या WebTransport, WebSockets की जगह इस्तेमाल किया जा सकता है?

शायद. ऐसे इस्तेमाल के उदाहरण हैं जहां WebSockets या WebTransport, इस्तेमाल करने के लिए मान्य कम्यूनिकेशन प्रोटोकॉल हो सकते हैं.

WebSockets कम्यूनिकेशन को, मैसेज की एक ही भरोसेमंद और क्रम से लगी स्ट्रीम के हिसाब से मॉडल किया जाता है. यह कुछ तरह की कम्यूनिकेशन की ज़रूरतों के लिए ठीक है. अगर आपको इन सुविधाओं की ज़रूरत है, तो WebTransport के स्ट्रीम एपीआई भी इन्हें उपलब्ध करा सकते हैं. इसके उलट, WebTransport के डेटाग्राम एपीआई, कम समय में डेटा ट्रांसफ़र करते हैं. हालांकि, वे डेटा के सही क्रम में ट्रांसफ़र होने या भरोसेमंद तरीके से ट्रांसफ़र होने की गारंटी नहीं देते. इसलिए, वे WebSockets का सीधा विकल्प नहीं हैं.

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

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

क्या WebTransport, UDP सॉकेट एपीआई जैसा ही है?

नहीं. WebTransport, UDP सॉकेट एपीआई नहीं है. WebTransport, एचटीटीपी/3 का इस्तेमाल करता है. यह "अंडर द हुड" यूडीपी का इस्तेमाल करता है. WebTransport में, एनक्रिप्शन और कंजेशन कंट्रोल से जुड़ी ज़रूरी शर्तें होती हैं. इस वजह से, यह बुनियादी यूडीपी सॉकेट एपीआई से ज़्यादा है.

क्या WebTransport, WebRTC डेटा चैनलों का विकल्प है?

हां, क्लाइंट-सर्वर कनेक्शन के लिए. WebTransport में, WebRTC डेटा चैनल की तरह ही कई प्रॉपर्टी होती हैं. हालांकि, इसके बुनियादी प्रोटोकॉल अलग होते हैं.

आम तौर पर, एचटीटीपी/3 के साथ काम करने वाले सर्वर को सेट अप और कॉन्फ़िगर करने में, WebRTC सर्वर को मैनेज करने की तुलना में कम समय लगता है. WebRTC सर्वर को मैनेज करने के लिए, कई प्रोटोकॉल (ICE, DTLS, और SCTP) को समझना ज़रूरी होता है, ताकि ट्रांसपोर्ट की सुविधा काम कर सके. WebRTC में कई और मूविंग पीस शामिल होते हैं. इससे क्लाइंट/सर्वर के बीच बातचीत पूरी नहीं हो पाती.

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

हालांकि, अगर आपके पास पहले से ही काम करने वाला WebRTC क्लाइंट/सर्वर सेटअप है और आप उससे संतुष्ट हैं, तो WebTransport पर स्विच करने से आपको ज़्यादा फ़ायदे नहीं मिल सकते.

प्रयोग

WebTransport को आज़माने का सबसे अच्छा तरीका है कि आप एचटीटीपी/3 के साथ काम करने वाला सर्वर शुरू करें. क्लाइंट और सर्वर के बीच कम्यूनिकेशन की सुविधा आज़माने के लिए, इस पेज का इस्तेमाल बेसिक JavaScript क्लाइंट के साथ करें.

इसके अलावा, कम्यूनिटी की ओर से मैनेज किया जाने वाला एक ईको सर्वर, webtransport.day पर उपलब्ध है.

एपीआई का इस्तेमाल करना

WebTransport को आधुनिक वेब प्लैटफ़ॉर्म प्रिमिटिव के आधार पर डिज़ाइन किया गया था. जैसे, Streams API. यह प्रॉमिस पर काफ़ी हद तक निर्भर करता है. साथ ही, यह async और await के साथ अच्छी तरह से काम करता है.

Chromium में WebTransport की मौजूदा सुविधा, तीन तरह के ट्रैफ़िक के साथ काम करती है: डेटाग्राम, यूनिडायरेक्शनल स्ट्रीम, और बायडायरेक्शनल स्ट्रीम.

किसी सर्वर से कनेक्ट करना

WebTransport इंस्टेंस बनाकर, एचटीटीपी/3 सर्वर से कनेक्ट किया जा सकता है. यूआरएल की स्कीम https होनी चाहिए. आपको पोर्ट नंबर साफ़ तौर पर बताना होगा.

कनेक्शन स्थापित होने तक इंतज़ार करने के लिए, आपको ready प्रॉमिस का इस्तेमाल करना चाहिए. सेटअप पूरा होने तक यह प्रॉमिस पूरा नहीं होता. साथ ही, अगर 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 APIs

सर्वर से कनेक्ट किए गए WebTransport इंस्टेंस का इस्तेमाल करके, डेटा के अलग-अलग बिट भेजे और पाए जा सकते हैं. इन्हें डेटाग्राम कहा जाता है.

writeable getter, 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

सर्वर से कनेक्ट होने के बाद, WebTransport का इस्तेमाल करके भी डेटा भेजा और पाया जा सकता है. इसके लिए, WebTransport के Streams API का इस्तेमाल करें.

सभी स्ट्रीम का हर हिस्सा एक 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

सर्वर की ओर से बनाए गए WebTransportBidirectionalStream को सुना जा सकता है. इसके लिए, WebTransport इंस्टेंस के incomingBidirectionalStreams एट्रिब्यूट का इस्तेमाल करें. यह 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 की कुछ सुविधाओं को लागू करने वाला एक पॉलीफ़िल (यानी कि एक ऐसा पोनीफ़िल जो एक स्टैंडअलोन मॉड्यूल के तौर पर काम करता है और जिसे इस्तेमाल किया जा सकता है) उपलब्ध है. इसे webtransport-ponyfill-websocket कहा जाता है. प्रोजेक्ट के README में दी गई सीमाओं को ध्यान से पढ़ें. इससे आपको यह तय करने में मदद मिलेगी कि यह समाधान आपके इस्तेमाल के उदाहरण के लिए काम कर सकता है या नहीं.

निजता और सुरक्षा से जुड़ी बातें

ज़्यादा जानकारी के लिए, ड्राफ़्ट स्पेसिफ़िकेशन का संबंधित सेक्शन देखें.

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

क्या एपीआई के बारे में कुछ ऐसा है जो अजीब है या उम्मीद के मुताबिक काम नहीं करता? या क्या आपके पास अपने आइडिया को लागू करने के लिए ज़रूरी जानकारी नहीं है?

• WebTransport GitHub repo पर कोई समस्या दर्ज करें या किसी मौजूदा समस्या में अपने विचार जोड़ें.
• Chromium को लागू करने से जुड़ी गड़बड़ी की शिकायत करें. ज़्यादा से ज़्यादा जानकारी दें. साथ ही, समस्या को दोहराने के तरीके के बारे में निर्देश भी दें.

आपकी सार्वजनिक राय से Chrome को सुविधाओं को प्राथमिकता देने में मदद मिलती है. साथ ही, इससे अन्य ब्राउज़र वेंडर को यह पता चलता है कि इन सुविधाओं को सपोर्ट करना कितना ज़रूरी है.

• @ChromiumDev को ट्वीट करें. इसमें हैशटैग #WebTransport का इस्तेमाल करें. साथ ही, यह भी बताएं कि इसका इस्तेमाल कहां और कैसे किया जा रहा है.

सामान्य चर्चा

सामान्य सवालों या ऐसी समस्याओं के लिए web-transport-dev Google ग्रुप का इस्तेमाल किया जा सकता है जो किसी दूसरी कैटगरी में नहीं आती हैं.

Acknowledgements

हमने WebTransport के बारे में जानकारी देने वाले दस्तावेज़ और ड्राफ़्ट स्पेसिफ़िकेशन से जानकारी शामिल की है. इस जानकारी को उपलब्ध कराने के लिए, हम लेखकों का धन्यवाद करते हैं.