هل سيسمح HTML5 لتطبيقات الويب بإجراء اتصالات HTTP من نظير إلى نظير؟

https://stackoverflow.com/questions/1032006

06-07-2019
|

سؤال

هل من الممكن إنشاء تطبيق ويب يمكنه، بمساعدة خادم مركزي، إنشاء اتصالات مباشرة مع مستخدمين آخرين لنفس تطبيق الويب؟أتخيل عملية مشابهة لتثقيب ثقب UDP.

لقد قرأت عن WebSockets API الجديد في HTML5، ولكن يبدو أنه يجب عليك بدء الاتصال بخادم متوافق مع WS قبل أن يبدأ الاتصال المزدوج الكامل.أفكر أكثر في عملية إجراء اتصالات مباشرة بين العملاء، مع مشاركة الخادم فقط في المصافحة الأولية.

ملحوظة:تطبيقات جافا لا تحسب.أنا مهتم فقط بتقنيات المتصفح القياسية.

المحلول

بدلاً من التخمينات الذكية، إليك إجابة مدروسة:

يخطط HTML 5 للسماح باتصالات نظير إلى نظير من جافا سكريبت، لكن هذه الاتصالات لن تكون عبارة عن TCP خام.

المواصفات الكاملة يمكن العثور عليها في http://dev.w3.org/html5/websockets/

jrh

يحرر:مع إشارة محددة إلى اتصالات نظير إلى نظير، راجع هذه الروابط:

فيما يتعلق بالاتصالات من نظير إلى نظير: http://www.w3.org/TR/2008/WD-html5-20080122/#peer-to-peer
فيما يتعلق باتصالات البث بالشبكة المحلية: http://www.w3.org/TR/2008/WD-html5-20080122/#broadcast
فيما يتعلق باتصالات TCP (في البروتوكول المشفر): http://www.w3.org/TR/2008/WD-html5-20080122/#tcp-connections
استكمال المواصفات المقترحة: http://www.w3.org/TR/2008/WD-html5-20080122/#network

من المهم أن نلاحظ أن القدرات لا تزال قيد التفاوض.سيكون من الرائع أن تكون قادرًا على إنشاء تطبيقات الويب "للدردشة المحلية" :)

jrh

نصائح أخرى

تحديث 10/17/2012: هذه الوظيفة موجودة الآن في الإصدار 22 من Chrome Stable.لاستخدام هذه الوظيفة في Chrome، يجب تمكين علامتين في chrome://flags:

تمكين ميدياستريم
تمكين اتصال النظير

ومن ثم يمكنك زيارة الصفحة التجريبية لـ AppRTC لتجربة العرض التوضيحي.انظر WebRTC - تشغيل العروض التوضيحية للحصول على إرشادات أكثر تفصيلاً حول إعداد Chrome لاستخدام وظيفة نظير إلى نظير وتمكين التقاط الجهاز.

تحديث: يمتلك المهندسون في Ericcson Labs إثباتًا للمفهوم في تصميم WebKit الذي يقوم بذلك HTML5 فيديو محادثة نظير إلى نظير.

لديهم عروض توضيحية في مدونتهم حول التكنولوجيا قيد التنفيذ، بالإضافة إلى الرسوم البيانية والشروحات حول كيفية عمل التكنولوجيا.

إنهم يعملون على تحقيق الاستقرار والالتزام بمستودع WebKit.

نعم أخيرا.

اعتبارًا من كتابة هذه السطور (2017)، أصبح WebRTC الآن جزءًا قياسيًا من معظم المتصفحات الحديثة (حوالي 70% من المتصفحات المستخدمة)، ويسمح ببث الوسائط المتعددة، ونظير إلى نظير، والثقب.

يمكن العثور على المستندات ونموذج التعليمات البرمجية والأمثلة الحية لـ WebRTC على html5rocks.com.

وفق caniuse.com و html5rocks.com, المتصفحات التالية تدعم WebRTC:

دعم كامل: إيدج 14، فايرفوكس 22، فايرفوكس أندرويد 55
الدعم الجزئي: متصفح أندرويد 56، كروم 20، كروم أندرويد 29، إيدج 12، فايرفوكس 17، أوبرا 18، أوبرا أندرويد 20، أوبرا موبايل 12، متصفح UC أندرويد 11.4
الدعم المستقبلي (الربع الثالث 2017): Chrome لنظام التشغيل iOS 11، وSafari 11 لنظام التشغيل iOS 11، وOS X 10.11
لا دعم: آي إي، آي إي موبايل، أوبرا ميني

معدل تشبع WebRTC محدود على أجهزة Apple، نظرًا لأن Safari 11 لم يتم إصداره بعد ويتطلب iOS 11 أو OS X 10.11.على الرغم من توقع اتجاهات الترقية السابقة، إلا أن WebRTC يجب أن يكون متاحًا على حوالي 75% من أجهزة iOS بحلول عام 2018، و100% بحلول عام 2020.

هناك عدد من الأسباب التي تجعل هذا الأمر صعبًا:

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

تم تصميم WebSockets لحل المشكلة الثانية من هذه المشكلات، ولكن (بشكل متعمد، كما أتوقع) ليس حل المشكلتين الأخريين.عندما يتحدثون عن نظير إلى نظير في مواصفات HTML5، فإنهم يتحدثون عن الاتصالات المزدوجة الكاملة بين الخادم والعميل، وليس بين عميل وآخر.

ومع ذلك، سيكون من السهل تنفيذ مكدس شبكة مناسب أعلى مآخذ الويب - بشرط أن تتم جميع الاتصالات من خلال الخادم.لقد رأيت ذلك يتم باستخدام الاستقصاء الطويل (كتب صديق لي في Uni مكدس TCP/IP كاملًا باستخدام الاستقصاء الطويل).

وأنا harshath.jr الثانية: هل يمكن أن يكون جيدا جدا الخادم بوصفها دليل (فضح "أصول" من كل وكيل على اتصال، الأصل أن يكون مخطط + المضيف + الميناء كما هو الحال في <لأ href = "HTTP: // الأدوات. ietf.org/html/draft-abarth-origin "يختلط =" نوفولو noreferrer "> مسودة أبارث الأصل ، مع مخطط يجري إما" WS "أو" WSS "). هل يمكن بعد ذلك الشروع في اتصالات WebSocket الند للند. و يجري العمل من خلال بفضل <لأ href = "HTTP: //www.w3. غزاله / TR / كر / "يختلط =" نوفولو noreferrer "> CORS . وبطبيعة الحال، وهذا يعني أن كل وكيل (متصفح أي) سيكون لتضمين الملقم الخاص به WebSocket الخاصة (à لا أوبرا اتحدوا).

في الوقت نفسه، أن تفعل ذلك في XMPP / IRC / الخ الطريقة: لا علاقة الند للند ولكن WebSocket الاتصالات إلى خادم مركزي لتمرير رسائل إلى وكلاء متصل (النهاية باستخدام بعض (أو شبكة!) WebSocket محددة "subprotocol")

وتحرير: لاحظ أن جميع هذا هو في الواقع خارج نطاق HTML5 (كانت كل هذه الأشياء مرة واحدة جزءا من HTML5 ولكن تم تقسيم بعيدا في المواصفات الخاصة)

وكانت الفكرة كاملة من مآخذ ويب لحل المشاكل مع الجدران النارية والوكلاء <لأ href = "http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket "يختلط =" noreferrer نوفولو "> http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow