قنوات بيانات سريعة: الخطوات الأولى

تعتبر قنوات DataChan-based QUIC بديلاً عن نقل SCTP الحالي. تقوم مجموعة عمل Google WebRTC بالتجربة معهم بالفعل:


لنجربها أيضًا. للقيام بذلك ، سننشئ تطبيقًا من صفحة واحدة شبيهًا بمثال قناة WebRTC لإرسال النص - وهذا مثال يعمل بشكل كامل (بدون خوادم الإشارة) ، والذي ، علاوة على ذلك ، سيجعل من السهل مقارنة الأساليب المتبعة لتطبيق WebRTC DataChannels.

قبل البدء ، دعنا نتذكر أساسيات DataChannel .

باختصار حول DataChannel

تسمح DataChannels الخاصة بـ WebRTC للمشاركين بتبادل البيانات التعسفية. يمكن أن يكون كلاهما موثوقًا - وهو أمر مفيد جدًا عند نقل الملفات - وغير موثوق به ، وهو أمر مقبول للحصول على معلومات حول المواقف في الألعاب. واجهة برمجة التطبيقات (API) هي امتداد لـ RTCPeerConnection وتبدو كما يلي:

 const dc = pc.createDataChannel("some label string"); // ,    – ,   – //    send dc.send("some string"); //    otherPc.addEventListener('datachannel', e => { const channel = e.channel; channel.onmessage = event => { console.log('received', event.data); }); }); 

في صفحة عينات WebRTC الرسمية ، توجد أمثلة على إرسال السلاسل والبيانات الثنائية .

يستخدم DataChannel SCTP . يعمل بالتوازي مع نقل RTP لتدفقات الصوت والفيديو. بخلاف UDP ، والذي يشيع استخدامه في تدفقات الصوت والفيديو ، توفر SCTP الكثير من الوظائف الأخرى ، مثل قنوات الإرسال المتعدد عبر اتصال واحد أو أوضاع موثوقة وجديرة بالثقة جزئيًا (مثل ، وسائط موثوقة ولكن غير منظمة).

قدمت Google QUIC في عام 2012 (يمكن الاطلاع على المزيد حول تاريخ البروتوكول والفروق الدقيقة في المواد الأخرى - ملاحظة المترجم). مثل WebRTC ، تم اتخاذ بروتوكول QUIC أيضًا تحت جناح IETF وهو الآن HTTP / 3 . لدى QUIC عددًا من الابتكارات الرائعة ، مثل: تقليل زمن الوصول ، وحساب عرض النطاق الترددي استنادًا إلى التحكم في الازدحام وتصحيح التأخير المباشر (FEC) والتنفيذ في مساحة المستخدم (بدلاً من النواة) من أجل التدوير بشكل أسرع.

قد تكون QUIC بديلاً لـ RTCP لـ WebRTC - مثل النقل لـ DataChannel. تحاول التجربة الحالية تجنب استخدام RTCPeerConnection API ( و SDP! ) باستخدام إصدار منفصل من النقل ICE. فكر في الأمر كاتصال افتراضي يضيف القليل من الأمان والكثير من عبور NAT .

في الفيديو أدناه ، يشرح Ian Swett من فريق شبكة Chrome هذا المفهوم. وعلى الرغم من أن هذا الخطاب كان عمره عدة سنوات ، إلا أنه لا يزال يوفر معلومات إضافية حول الموضوع:

الخطوات الأولى مع QUIC

لحسن الحظ ، تظل معظم الشفرة الواردة في مقالة عام 2015 ذات صلة وتتكيف بسهولة مع واجهة برمجة التطبيقات الجديدة. دعونا معرفة ذلك.

قم بنسخ الكود من هنا أو جربه هنا . يرجى ملاحظة أنه يجب تشغيل Chrome (الإصدار 73+ الآن Canary) مع إشارات خاصة للتجربة للعمل محليا:

 google-chrome-unstable --enable-blink-features=RTCQuicTransport,RTCIceTransportExtension 

إعداد النقل ICE

تعتمد مواصفات RTCIceTransport على ORTC ، لذلك يشبه الإعداد الرمز القديم:

 const ice1 = new RTCIceTransport(); ice1.onstatechange = function() { console.log('ICE transport 1 state change', ice1.state); }; const ice2 = new RTCIceTransport(); ice2.onstatechange = function() { console.log('ICE transport 2 state change', ice2.state); }; //  ICE- ice1.onicecandidate = function(evt) { console.log('1 -> 2', evt.candidate); if (evt.candidate) { ice2.addRemoteCandidate(evt.candidate); } }; ice2.onicecandidate = function(evt) { console.log('2 -> 1', evt.candidate); if (evt.candidate) { ice1.addRemoteCandidate(evt.candidate); } }; //  ICE- ice1.start(ice2.getLocalParameters(), 'controlling'); ice2.start(ice1.getLocalParameters(), 'controlled'); ice1.gather(iceOptions); ice2.gather(iceOptions); 

لاحظ أن واجهة برمجة التطبيقات هذه لا تحتوي على RTCIceGatherer ، على عكس ORTC. لأن لدينا بالفعل كل ما نحتاجه لتثبيت النقل ICE.

تكوين النقل السريع

 const quic1 = new RTCQuicTransport(ice1); quic1.onstatechange = function() { console.log('QUIC transport 1 state change', quic1.state); }; const quic2 = new RTCQuicTransport(ice2); quic2.onstatechange = function() { console.log('QUIC transport 2 state change', quic2.state); }; //     QUIC quic2.addEventListener('quicstream', (e) => { console.log('QUIC transport 2 got a stream', e.stream); receiveStream = e.stream; }); 

هنا ، تنطلق التجربة من أحد المواصفات التي تستخدم المصادقة المستندة إلى الشهادة. بدلاً من ذلك ، يتم استخدام المفتاح العمومي ، كما يقول منشور Google Developers :

يتم تكوين اتصال RTCQuicTransport باستخدام مفتاح عمومي API. لا نخطط حاليًا لواجهة برمجة التطبيقات هذه لاستبدال التحقق الأصلي. سيتم استبداله بشهادة عن بُعد تشير إلى التحقق من صحة الشهادات الموقعة ذاتياً - عندما تبدأ QUIC في دعمها في Chromium.

جيد جدا

QUICStream لإرسال واستقبال البيانات

يعد استخدام QUICStream أكثر تعقيدًا من WebRTC DataChannel. تم قبول API Stream ( راجع التفاصيل على MDN ) التي أنشأتها مجموعة عمل WHATWG ولكن لم يتم تنفيذها .

نقوم بإنشاء sendStream فقط بعد sendStream النقل sendStream إلى الحالة "المتصلة" - وفي حالة مختلفة ، قد يؤدي ذلك إلى حدوث خطأ:

 quic1.onstatechange = function() { console.log('QUIC transport 1 state change', quic1.state); if (quic1.state === 'connected' && !sendStream) { sendStream = quic1.createStream('webrtchacks'); //   createDataChannel. document.getElementById('sendButton').disabled = false; document.getElementById('dataChannelSend').disabled = false; } }; 

ثم نعلق المعالجين على زر الإرسال وحقل الإدخال: بعد النقر على الزر ، يتم تشفير النص من حقل الإدخال في Uint8Array وكتابته إلى الدفق:

 document.getElementById('sendButton').onclick = () => { const rawData = document.getElementById('dataChannelSend').value; document.getElementById('dataChannelSend').value = ''; //  Uint8Array. ,       TextEncoder. const data = encoder.encode(rawData); sendStream.write({ data, }); }; 

سيتم تشغيل الإدخال الأول الحدث onquicstream على نقل QUIC البعيد:

 //     QUIC quic2.addEventListener('quicstream', (e) => { console.log('QUIC transport 2 got a stream', e.stream); receiveStream = e.stream; receiveStream.waitForReadable(1) .then(ondata); }); 

... ثم ننتظر أن تكون البيانات قابلة للقراءة:

 function ondata() { const buffer = new Uint8Array(receiveStream.readBufferedAmount); const res = receiveStream.readInto(buffer); const data = decoder.decode(buffer); document.getElementById('dataChannelReceive').value = data; receiveStream.waitForReadable(1) .then(ondata); } 

سيتم قراءة جميع البيانات من receiveStream ، فك تشفيرها في النص ووضعها في حقل الإخراج. وهكذا في كل مرة تظهر البيانات المقروءة.

الخلاصة والتعليقات

آمل أن يكون هذا المثال أسهل في الفهم من المثال المماثل في مدونة Google . لا تكاد هذه الطريقة مناسبة لتوصيلات P2P ، بل إن DataChannel على SCTP تعمل بشكل جيد بالفعل. ومع ذلك ، يمكن أن يكون هذا بديلًا مثيرًا للاهتمام لمآخذ توصيل الويب مع خادم QUIC على الطرف الآخر. حتى يحدث هذا ، يجب عليك تحديد طريقة لائقة للعمل مع قنوات غير موثوقة وغير منظمة. في رأيي ، تبدو الاقتراحات من المنشور المذكور أعلاه أشبه بالقرصنة وليس بالقرارات.

كما أنه من غير الواضح ماهية التعليقات التي ينتظرها المطورون من الخارج. "أعرض المواصفات بالفعل بدلاً من نحت الاختصارات مرة أخرى ، والتي ستبقى معنا لعدة سنوات" ، يبدو واضحًا للغاية. بالإضافة إلى ذلك ، يميل الرأي العام للمجتمع إلى استخدام تدفقات WHATWG ، والتي تضع مطوري إضاءة غريبين يطلبون اختبار واجهة برمجة التطبيقات الخاصة بهم لقراءة البيانات.

أود أيضًا أن تتمتع SCTP في Chromium بميزات إضافية. على سبيل المثال ، ظل هذا الاستعلام عن DataChannel - الأعلى تصنيفًا ، بالمناسبة - دون تغيير تقريبًا لمدة ثلاث سنوات. ليس من الواضح تمامًا سبب وجود تركيز على QUIC عندما لا تزال هناك مهام SCTP ؛ ومع ذلك ، يجب ألا يمنع هذا أي شخص من اختبار QUIC والتعليقات على النتائج.

تعليق Voximplant

كلمة لنا الواجهة الأمامية irbisadm :

لفترة طويلة ، تم استخدام SDKs لدينا للإشارة إلى مقبس ويب. هذا معيار ممتاز تم اختباره على مدار الوقت ، ولكن هناك بعض المشكلات المتعلقة به. الأول هو TCP. و TCP ليس جيدًا وسريعًا على شبكات المحمول ، بالإضافة إلى أنه لا يدعم التجوال بين الشبكات. ثانياً ، غالبًا ما يكون نصيًا (يوجد وضع ثنائي أيضًا ، ولكن نادرًا ما تراه).

أطلقنا مؤخرًا اختبارًا تجريبيًا مغلقًا لبروتوكول التشوير على DataChannel. لا يخلو هذا البروتوكول أيضًا من السلبيات ، ولكن نظرًا لأنه يعمل في شبكات ضعيفة وعند التجوال ، فإنه ينتصر من النظرة الأولى. هل غيرت الشبكة؟ لا حاجة لإعادة الاتصال. ستساعد ICE Restart في معظم الحالات على إيجاد طريقة جديدة لحركة المرور. ولكن ، كما قلت ، لا يزال للبروتوكول عيوب: لا تدعم جميع المتصفحات جميع امتدادات البروتوكول ، مثل التسليم المضمون ودعم ترتيب الحزمة ؛ أيضا لا يدعم البروتوكول gzip لوضع النص من خارج منطقة الجزاء. ولكن كل هذه المشاكل يمكن حلها على جانب التطبيق.