نموذج معالجة خادم مآخذ التوصيل

Question

لتنفيذ خادم يدعم العملاء باستخدام مآخذ الويب, ، هل تحافظ الخوادم على اتصال HTTP مفتوح مع كل عميل؟ كيف يمكن لهذا الحجم؟

ما هي "نماذج البرمجة" عند تنفيذ هذا النوع من الخادم؟ IE: تحتوي معظم تطبيقات الويب على servlets ، وما إلى ذلك والتي تدعم connect-> request-> response-> إغلاق نموذج النوع. بينما مع مآخذ الويب ، يبقى الاتصال مفتوحًا إلى أجل غير مسمى.

Answer 1

تحتاج عمومًا إلى العمل في غير متزامن نموذج لهذه الاتصالات طويلة العمر للعمل. هناك العديد من التقنيات المختلفة للقيام I/O غير متزامن ؛ وكلها لها مزايا وعيوب.

واحد يجب أن يكون مألوفًا بالفعل لأي شخص عمل مع JavaScript و أياكس هو نموذج رد الاتصال ؛ حيث ترسل طلبًا ، وتثبيت رد اتصال ليتم استدعاؤه عند اكتماله. هذه هي الطريقة XMLHTTPRequest يعمل ، دون منع جميع الصفحات الأخرى أثناء انتظار الانتهاء من طلب صفحة واحدة. هذا هو أيضا كيف ملتوية يعمل Python Networking Framework ، على الرغم من أنه يمكنه استدعاء طرق الكائنات أو وظائف رد الاتصال اعتمادًا على الواجهات التي تستخدمها.

نموذج قوي آخر هو إرلانج يحتوي نهج الأناقة ، الذي يطلق عليه نموذج الممثل ، على العديد من العمليات الخفيفة الوزن (مثل المواضيع ، ولكن بدون حالة مشتركة) ، يتواصل كل منها مع بعضها البعض عبر رسائل غير متزامنة. تم تنفيذ وقت تشغيل Erlang لجعل التفريخ الآلاف من العمليات فعالة للغاية ؛ بعد ذلك ، يمكنك فقط الحصول على عملية واحدة لكل اتصال ، وجعلهم يرسلون رسائل إلى عمليات أخرى تنفذ الواجهة الخلفية للتطبيق الخاص بك. يمكن أيضًا جدولة عمليات Erlang تلقائيًا على مؤشرات ترابط OS متعددة ، للاستفادة الكاملة من الأنظمة متعددة النواة. إجببرد, ، يتم تنفيذ خادم Jabber الشهير (بروتوكول الدردشة ، والذي يتطلب العديد من الاتصالات المفتوحة طويلة الأمد) ، في Erlang ، وكذلك نظام الدردشة فيسبوك.

الجديد اذهب إلى اللغة من Google ، تستخدم Google مقاربة مماثلة ، أقرب إلى تواصل Hoare المتتابع من نموذج ممثل Erlang ، ولكن لديه الكثير من أوجه التشابه.

في Mac OS X 10.6 ، قدمت Apple الإرسال الكبرى الكبير, ، جنبا إلى جنب مع الكتل (الإغلاق بشكل أساسي) في C ، C ++ ، والهدف C. يتيح ذلك شيئًا مثل نموذج رد الاتصال Ajax أو Twisted Style الذي يحركه ، ولكن مع قوائم قوائم الإدارة بشكل صريح التي يتم تنفيذها بالتتابع لإدارة الوصول إلى الموارد المشتركة في بيئة متعددة النوى. تقوم كل من Twisted و JavaScript بتشغيل خيوط واحدة ، وبالتالي لا يمكن الاستفادة إلا من نواة واحدة ، إلا إذا كنت تستخدم عمليات نظام تشغيل متعددة ، والتي يمكن أن تكون ثقيلة إلى حد ما وزيادة تكاليف الاتصال بينهما.

ثم هناك النماذج التقليدية ، مثل UNIX select الوظيفة ، أو أكثر حداثة وقادرة epoll أو kqueue(). في هذه ، لديك عمومًا حلقة رئيسية في البرنامج ، والتي تقوم بإعداد مجموعة من الأحداث التي يجب مراقبتها (شبكة الإدخال/الإخراج التي تُرجع بعض البيانات ، وإرجاع ملف الإدخال/الإخراج ، يتم إجراء المزيد من البيانات ، واتصال شبكة جديد ، إلخ) ، ثم يستدعي استدعاء النظام الذي يحجبه حتى يحدث أحد هذه الأحداث ، وعندها تقوم بالتحقق من أي واحد حدث ثم التعامل معها بشكل مناسب. يتم استخدام مكالمات النظام هذه بشكل عام لتوفير الأطر ذات المستوى الأعلى الموضحة أعلاه.

للحصول على نظرة عامة جيدة جدًا على المجموعة المذهلة من الخيارات المتاحة (مع التركيز على الأساليب الأكثر تقليدية وأقل ، فإن UNIX مقاربات) ، انظر مشكلة C10K, ، دراسة استقصائية للتقنيات المختلفة للمساعدة في التعامل مع 10000 اتصال متزامن في وقت واحد. يحتوي هذا أيضًا على قائمة جيدة من مكتبات C و C ++ لاستخلاصها على مختلف واجهات برمجة التطبيقات المتاحة ، مثل libevent.

الخيار النهائي ، بالطبع ، هو استخدام عملية واحدة أو مؤشر ترابط OS واحد لكل اتصال. المشكلة هي أن العمليات هي وزن ثقيل للغاية ، وحتى الخيوط ثقيلة إلى حد ما مقارنة بالعديد من هذه الخيارات. بشكل عام ، للحصول على أفضل أداء ، قد ترغب في الحصول على عملية أو مؤشر ترابط واحد لكل وحدة معالجة مساعدة ، كل منها يستخدم واجهة برمجة تطبيقات I/O غير متزامنة لمعرفة متى يحتاج إلى عمل ، ثم إرسال هذا العمل إلى أحد الكائنات العديدة أو عمليات الاسترجاعات تم تسجيلها للتعامل مع الاتصالات ، أو واحدة من عدة عمليات خفيفة الوزن على غرار Erlang التي تنتظر رسالة ، أو شيء من هذا القبيل.

كملاحظة جانبية ، فإن الاتصال في مآخذ الويب ليس اتصالات HTTP ، ولكن بروتوكول جديد ، بروتوكول WebSocket, ، على الرغم من أنه يمكنك استخدام نفس المنفذ مثل HTTP ، وترقية اتصال HTTP بمقبس الويب من أجل أن تكون متوافقة مع قواعد جدار الحماية الحالي.

Answer 2

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

Answer 3

إنه يختلف عن HTTP في أن كل طلب / استجابة لاحق لا يحتاج إلى لفه في رسالة HTTP برؤوس HTTP. لذلك لن تحتاج التطبيقات في الوقت الفعلي إلى الحمل من رؤوس التحليل. بعد المصافحة الأولية التي تشبه HTTP ، تتصرف بشكل أساسي مثل مقبس OL 'TCP العادي.

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

Answer 4

ألقِ نظرة على HTML 5 Websockets المنفذة في خادم الويب Tornado:http://bret.apppot.com/entry/web-sockets-in-tornado

لم ألعب مع هذه الوحدة بعد.