web udp public
1.0.0
يهدف هذا الريبو إلى التعبير عن الحاجة العامة إلى تقنية لتمكين الاتصال منخفض زمن الوصول بين الخادم والعميل ، دون موثوقية إلزامية و/أو آليات تسليم مرتبة لبروتوكول النقل الأساسي.
وتشكيل المتطلبات من الاحتياجات الحالية والتطبيقات المستقبلية المحتملة. لتحفيز أعضاء W3C ومجتمع IETF وموردي المتصفحات لبدء المناقشة واقتراح RFC لدعم المزيد من التطوير للحل.
العلاقات العامة والمناقشات في القضايا هي موضع ترحيب. انشر الخبر، ونرحب بـ RT.
تطور الويب بسرعة خلال السنوات الماضية، مما أدى إلى تحسين قدرات الشبكات باستخدام تقنيات مثل: WebSockets، وWebRTC، وHTTP/2، والأحداث المرسلة من الخادم، وQUIC .
تتمتع هذه التقنيات بمجال تطبيق خاص بها وتمكن منصة الويب من أن تتمتع بما يلي:
والعديد من التجارب الغنية والقوية
في السنوات الأخيرة وُلدت وسيلة أخرى: ألعاب HTML5 . يختفي برنامج Adobe Flash، وتنمو صناعة ألعاب HTML5 بشكل مطرد.
مما أدى إلى ولادة ألعاب IO - واحدة من أكثر الألعاب متعددة اللاعبين التي يمكن الوصول إليها. بعض الأمثلة الشائعة: agar.io وslither.io وغيرها الكثير. يعتمدون جميعًا على التقنية الوحيدة القابلة للتطبيق حاليًا للاتصال بين الخادم والعميل في الوقت الفعلي - WebSockets. يعد WebRTC لعميل الخادم معقدًا للغاية (اقرأ المزيد).
ولكن هذا يحد من قدرات الشبكة حيث أن بروتوكول التحكم في الإرسال (TCP) للألعاب له حدود . تجدر الإشارة إلى أن الأمر لا يتعلق بالألعاب فقط - فهناك الكثير من حالات الاستخدام للاتصالات بين الخادم والعميل ذات زمن الوصول المنخفض وغير الموثوقة وغير المنظمة.
الكمون والازدحام . يتمتع TCP بتسليم حزم موثوق ومنظم وهو بروتوكول قائم على الاتصال. إن الحاجة إلى UDP (أو البديل) عبر TCP ليست موضع تساؤل حيث تمت مناقشتها على نطاق واسع في العديد من المقالات حول فوائد UDP (أو البديل) عبر TCP في حالات مختلفة. نحن هنا نحاول فقط تلخيص ذلك. ومن الجدير بالذكر أن UDP هو الخيار الأكثر شيوعًا، ولكنه ليس خيار بروتوكول النقل الوحيد لهذا الجهد.
الموثوقية - لا يكون هذا مطلوبًا دائمًا من خلال منطق التطبيق، فقد لا تكون المعلومات القديمة ذات صلة ويمكن تجاهلها. سيضمن TCP تسليم الحزم، مما يؤدي إلى ازدحام يؤدي إلى ارتفاع زمن الوصول بسبب الحاجة إلى الإقرارات وإعادة تسليم الحزم. لا يضمن UDP (أو البديل) الموثوقية خارج الصندوق، وبالتالي يتجنب مشكلة الازدحام التي يمكن استخدامها كميزة لضمان تسليم أحدث البيانات في أسرع وقت ممكن.
التسليم المطلوب - يستخدم TCP التسلسل والإقرارات لضمان قراءة الحزم المطلوبة وإعادة تسليمها. يؤدي هذا إلى حظر القراءة، مما يؤدي إلى ارتفاع زمن الوصول ويزداد سوءًا إذا كانت بيئة الشبكة تعاني من فقدان حزم أكبر.
بروتوكول لا يضمن الموثوقية والتسليم المطلوب خارج الصندوق، مما يسمح للمطور بتنفيذ أي من التقنيات فوقه إذا لزم الأمر أو استخدام الأساليب المختلطة. وهذا يوفر توقيتات تسليم مستقرة وزمن وصول منخفض في بيئات الشبكة الأقل من المثالية. مع التحكم في الازدحام للتخفيف من إرباك البنية التحتية للإنترنت لمعالجة المخاوف الأمنية.
أحد الخيارات لحل هذه المشكلة هو إضافة امتداد جديد لبروتوكول WebSockets الحالي باستخدام آليات التفاوض الموضحة في RFC 6455. والتي من شأنها تنفيذ وظائف إضافية لإنشاء اتصال بروتوكول UDP (أو بديل). سيستفيد هذا من نموذج الأمان الحالي القائم على الأصل لـ WebSockets ويسمح للمطورين باتباع النهج التقدمي حيث يمكنهم الرجوع إلى منطق TCP إذا لم يكن هذا الامتداد مدعومًا من قبل أي من الجانبين (الخادم أو العميل).
هناك طريقة أخرى تتمثل في تطوير واجهة برمجة تطبيقات جديدة تمامًا، تشبه إلى حد كبير WebSockets التي من شأنها معالجة الميزات الفريدة لمنطق شبكة UDP (أو البديل)، بالإضافة إلى إمكانية توفير ميزات إضافية للمطور مع خيارات دقيقة لكيفية إرسال الرسائل.
الحالة الحالية لـ WebRTC معقدة للغاية وقد تم تصميمها بشكل أساسي للتواصل بين نظير إلى نظير. ونتيجة لذلك، لم يتم اعتماده بشكل جيد للتواصل بين الخادم والعميل ويتطلب الكثير من موارد المطورين. ببساطة، إنها ليست صديقة لمطوري الويب الفرديين مثل WebSockets اليوم. خيار محتمل لتوسيع المواصفات لنموذجية وتبسيط المتطلبات التي من شأنها أن تسمح باستخدام بعض أجزاء WebRTC مما يجعلها أكثر سهولة في الوصول إلى سيناريوهات عميل الخادم وواجهة برمجة التطبيقات المبسطة التي من شأنها أن تجعلها في متناول مطوري الويب.
هناك مسودة مواصفات لواجهة برمجة تطبيقات WebTransport التي تسمح لتطبيقات الويب بإنشاء اتصالات شبكة تفاعلية وثنائية الاتجاه ومتعددة الإرسال - مع دعم الاتصالات الموثوقة وغير الموثوقة.
يجب أن تعالج واجهة برمجة التطبيقات (API) وتنفيذ البروتوكول الأساسي المخاوف الأمنية لجعلها صديقة للويب:
يجب أن تعالج واجهة برمجة التطبيقات هذه المخاوف الأمنية، دون المبالغة في تعقيد واجهة برمجة التطبيقات للواجهة الأمامية وكذلك التنفيذ للواجهة الخلفية. لهذا السبب فإن UDPSocket ليس خيارًا.
قائمة البروتوكولات الأساسية المحتملة التي يمكن استخدامها للتنفيذ:
