أدى تطور التقنيات في مجال البرمجيات والأجهزة ، وظهور بروتوكولات اتصال جديدة إلى توسع إنترنت الأشياء (IoT). يتزايد عدد الأجهزة يومًا بعد يوم ، وهي تولد كمية هائلة من البيانات. لذلك ، هناك حاجة إلى بنية نظام ملائمة قادرة على معالجة هذه البيانات وتخزينها ونقلها.
في الوقت الحاضر ، يتم استخدام الخدمات السحابية لهذه الأغراض. ومع ذلك ، فإن نموذج الحوسبة الضبابية (Fog) الشائع بشكل متزايد قادر على استكمال الحلول السحابية من خلال توسيع البنية التحتية لإنترنت الأشياء وتحسينها.
الغيوم قادرة على إغلاق معظم طلبات إنترنت الأشياء. على سبيل المثال ، لتوفير مراقبة الخدمات ، والمعالجة السريعة لأي كمية من البيانات التي يتم إنشاؤها بواسطة الأجهزة ، بالإضافة إلى تصورها. تعد حوسبة الضباب أكثر كفاءة في حل مشاكل الوقت الفعلي. أنها توفر استجابة سريعة للطلبات وأقل تأخير في معالجة البيانات. أي أن الضباب يكمل "الغيوم" ، يوسع قدراته.
ومع ذلك ، فإن السؤال الرئيسي مختلف: كيف يجب أن يتفاعل كل هذا في سياق إنترنت الأشياء؟ ما هي بروتوكولات الاتصال التي ستكون أكثر فاعلية عند العمل في نظام IoT-Fog-Cloud موحد؟
على الرغم من الهيمنة الواضحة لـ HTTP ، يتم استخدام عدد كبير من الحلول الأخرى في أنظمة IoT و Fog و Cloud. وذلك لأن إنترنت الأشياء يجب أن تجمع بين وظائف مجموعة متنوعة من مستشعرات الأجهزة مع الأمان وقابلية التشغيل البيني ومتطلبات المستخدم الأخرى.
ولكن ببساطة لا توجد فكرة واحدة عن العمارة المرجعية ومعيار الاتصال. لذلك ، يعد إنشاء بروتوكول جديد أو تعديل بروتوكول موجود لمهام إنترنت الأشياء المحددة أحد أهم المهام التي تواجه مجتمع تكنولوجيا المعلومات.
ما هي البروتوكولات المستخدمة حاليًا وما الذي يمكن أن تقدمه؟ دعونا نفهم ذلك. لكن أولاً ، دعنا نناقش مبادئ النظام البيئي الذي تتفاعل فيه الغيوم والضباب وإنترنت الأشياء.
هندسة إنترنت الأشياء من الضباب إلى السحابة (F2C)
ربما لاحظت مقدار الجهد المبذول لاستكشاف الفوائد والفوائد المرتبطة بالإدارة العقلانية والمنسقة لإنترنت الأشياء والسحب والضباب. إذا لم يكن الأمر كذلك ، فإليك ثلاث مبادرات للتوحيد القياسي: , и .
إذا تم النظر سابقًا في مستويين فقط ، السحاب والأجهزة الطرفية ، فإن البنية المقترحة تقدم مستوى جديدًا - حوسبة الضباب. في الوقت نفسه ، يمكن تقسيم مستوى الضباب إلى عدة مستويات فرعية ، اعتمادًا على مواصفات الموارد أو مجموعة من السياسات التي تحدد استخدام الأجهزة المختلفة في هذه المستويات الفرعية.
كيف يمكن أن يبدو هذا التجريد؟ إليك نظام إيكولوجي نموذجي لـ IoT-Fog-Cloud. ترسل أجهزة إنترنت الأشياء البيانات إلى خوادم وأجهزة حوسبة أسرع لحل المهام التي تتطلب زمن انتقال منخفض. في نفس النظام ، تكون السحابة مسؤولة عن حل المشكلات التي تتطلب قدرًا كبيرًا من موارد الحوسبة أو مساحة التخزين.
يمكن أيضًا أن تكون الهواتف الذكية والساعات الذكية والأدوات الأخرى جزءًا من إنترنت الأشياء. لكن مثل هذه الأجهزة تميل إلى استخدام بروتوكولات الاتصال الخاصة بالمطورين الرئيسيين. يتم تمرير بيانات إنترنت الأشياء التي تم إنشاؤها إلى طبقة الضباب عبر بروتوكول REST HTTP ، والذي يوفر المرونة وقابلية التشغيل البيني عند إنشاء خدمات RESTful. هذا مهم في ضوء الحاجة إلى ضمان التوافق مع الإصدارات السابقة مع البنية التحتية للحوسبة الحالية التي تعمل على أجهزة الكمبيوتر أو الخوادم أو مجموعة الخوادم المحلية. الموارد المحلية ، التي تسمى "عقد الضباب" ، تقوم بتصفية البيانات المستلمة ومعالجتها محليًا أو إرسالها إلى السحابة لإجراء مزيد من العمليات الحسابية.
تدعم السحابة بروتوكولات الاتصال المختلفة ، من بينها AMQP و REST HTTP الأكثر شيوعًا. نظرًا لأن HTTP معروف جيدًا ومخصص للإنترنت ، فقد يطرح السؤال التالي: "ألا يجب استخدامه للعمل مع إنترنت الأشياء والضباب؟". ومع ذلك ، يحتوي هذا البروتوكول على مشكلات في الأداء. المزيد عن ذلك لاحقًا.
بشكل عام ، هناك نموذجان من بروتوكولات الاتصال المناسبة للنظام الذي نحتاجه. هذه هي استجابة الطلب والنشر والاشتراك. النموذج الأول معروف على نطاق واسع ، لا سيما في بنية الخادم والعميل. يطلب العميل معلومات من الخادم ، ويقوم الأخير باستلام الطلب ومعالجته وإرجاع رسالة استجابة. تعمل بروتوكولات REST HTTP و CoAP وفقًا لهذا النموذج.
نشأ النموذج الثاني من الحاجة إلى توفير اقتران غير متزامن وموزع وفضفاض بين المصادر التي تولد البيانات ومستلمي هذه البيانات.
يفترض النموذج ثلاثة مشاركين: ناشر (مصدر بيانات) ، وسيط (مرسل) ومشترك (مستلم). هنا ، لا يحتاج العميل الذي يتصرف بصفته المشترك إلى طلب معلومات من الخادم. بدلاً من إرسال الطلبات ، تشترك في أحداث معينة في النظام من خلال وسيط مسؤول عن تصفية جميع الرسائل الواردة وتوجيهها بين الناشرين والمشتركين. والناشر ، عند وقوع حدث يتعلق بموضوع معين ، ينشره إلى الوسيط الذي يرسل البيانات إلى المشترك حول الموضوع المطلوب.
في الأساس ، تستند هذه العمارة على الأحداث. ويعد نموذج التفاعل هذا مثيرًا للاهتمام للتطبيقات في إنترنت الأشياء ، والسحابة ، والضباب نظرًا لقدرته على توفير قابلية التوسع وتبسيط الاتصال البيني بين الأجهزة المختلفة ، ودعم الاتصال الديناميكي متعدد إلى كثير والتواصل غير المتزامن. تتضمن بعض أشهر بروتوكولات المراسلة القياسية للاشتراك في النشر MQTT و AMQP و DDS.
من الواضح أن نموذج الاشتراك - النشر له العديد من المزايا:
- لا يحتاج الناشرون والمشتركون إلى معرفة وجود بعضهم البعض ؛
- يمكن لمشترك واحد تلقي معلومات من العديد من المنشورات المختلفة ، ويمكن لناشر واحد إرسال البيانات إلى العديد من المشتركين المختلفين (مبدأ متعدد إلى متعدد) ؛
- لا يحتاج الناشر والمشترك إلى أن يكونا نشطين في نفس الوقت لتبادل البيانات ، لأن الوسيط (الذي يعمل كنظام انتظار) سيكون قادرًا على تخزين الرسالة للعملاء غير المتصلين حاليًا بالشبكة.
ومع ذلك ، فإن نموذج الطلب والاستجابة له أيضًا نقاط قوته. في الحالات التي لا تمثل فيها قدرة جانب الخادم على معالجة الطلبات من عدة عملاء مشكلة ، فمن المنطقي استخدام حلول موثوقة مثبتة بالفعل.
هناك أيضًا بروتوكولات تدعم كلا النموذجين. على سبيل المثال ، يدعم XMPP و HTTP 2.0 خيار "دفع الخادم". أصدرت IETF أيضًا CoAP. تم إنشاء العديد من الحلول الأخرى في محاولة لحل مشكلة المراسلة ، مثل بروتوكول WebSockets أو استخدام بروتوكول HTTP عبر QUIC (اتصالات إنترنت UDP السريعة).
في حالة WebSockets ، على الرغم من استخدامه لنقل البيانات في الوقت الفعلي من الخادم إلى عميل الويب ويوفر اتصالات مستمرة مع اتصال ثنائي الاتجاه متزامن ، إلا أنه غير مخصص للأجهزة ذات موارد الحوسبة المحدودة. تستحق QUIC أيضًا الاهتمام ، نظرًا لأن بروتوكول النقل الجديد يوفر الكثير من الميزات الجديدة. ولكن نظرًا لأن QUIC لم يتم توحيدها بعد ، فمن السابق لأوانه التنبؤ بتطبيقها المحتمل وتأثيرها على حلول إنترنت الأشياء. لذلك نترك WebSockets و QUIC في الذاكرة مع التركيز على المستقبل ، لكننا لن ندرس بمزيد من التفاصيل بعد.
من هو الأفضل في العالم: مقارنة البروتوكولات
الآن دعنا نتحدث عن نقاط القوة والضعف في البروتوكولات. بالنظر إلى المستقبل ، سنحجز على الفور أنه لا يوجد قائد واحد واضح. كل بروتوكول له بعض المزايا / العيوب.
وقت الاستجابة
من أهم خصائص بروتوكولات الاتصال ، خاصة فيما يتعلق بإنترنت الأشياء ، زمن الاستجابة. ولكن من بين البروتوكولات الحالية ، لا يوجد فائز واضح يوضح الحد الأدنى من التأخير عند العمل في ظروف مختلفة. ولكن هناك مجموعة كاملة من الدراسات والمقارنات لقدرات البروتوكول.
على سبيل المثال، أظهرت مقارنات فعالية HTTP و MQTT عند العمل مع إنترنت الأشياء أن وقت الاستجابة لطلبات MQTT أقل من HTTP. وعندما وقت الذهاب والإياب (RTT) لـ MQTT و CoAP ، اتضح أن متوسط RTT لـ CoAP أقل بنسبة 20٪ من MQTT.
آخر تم تنفيذ بروتوكول RTT لبروتوكولات MQTT و CoAP في سيناريوهين: شبكة محلية وشبكة إنترنت الأشياء. اتضح أن متوسط وقت الإرسال والاستقبال هو 2-3 مرات أعلى في شبكة إنترنت الأشياء. أظهر MQTT مع QoS0 نتيجة أقل مقارنةً بـ CoAP ، وأظهر MQTT مع QoS1 ارتفاع RTT بفضل ACKs في طبقات التطبيق والنقل. بالنسبة إلى مستويات جودة الخدمة المختلفة ، كانت تأخيرات الشبكة بدون ازدحام ملي ثانية بالنسبة إلى MQTT ، ومئات الميكروثانية بالنسبة إلى CoAP. ومع ذلك ، تجدر الإشارة إلى أنه عند العمل في شبكات أقل موثوقية ، فإن تشغيل MQTT عبر TCP سيظهر نتيجة مختلفة تمامًا.
أظهر وقت استجابة بروتوكولات AMQP و MQTT عن طريق زيادة الحمولة أنه مع وجود حمل صغير ، يكون مستوى التأخير متماثلًا تقريبًا. ولكن عند نقل كميات كبيرة من البيانات ، يُظهر MQTT وقت استجابة أقل. في واحد آخر تمت مقارنة CoAP بـ HTTP في سيناريو من آلة إلى آلة مع الأجهزة المنتشرة فوق المركبات المزودة بأجهزة استشعار الغاز وأجهزة استشعار الطقس والموقع (GPS) وواجهة شبكة الهاتف المحمول (GPRS). كان الوقت المستغرق لإرسال رسالة CoAP عبر شبكة الهاتف المحمول أقصر بثلاث مرات تقريبًا من الوقت المستغرق لاستخدام رسائل HTTP.
تم إجراء دراسات لم تقارن بروتوكولين ، بل ثلاثة بروتوكولات. على سبيل المثال، أداء بروتوكولات إنترنت الأشياء MQTT و DDS و CoAP في سيناريو تطبيق طبي باستخدام محاكي الشبكة. لقد تفوقت DDS على MQTT من حيث زمن انتقال القياس عن بُعد الذي تم اختباره في ظل ظروف الشبكة السيئة المختلفة. عملت CoAP المستندة إلى UDP بشكل جيد للتطبيقات التي تحتاج إلى استجابة سريعة ، ومع ذلك ، نظرًا لكونها قائمة على UDP ، كان هناك فقدان كبير غير متوقع للحزم.
قدرة
تم تنفيذ MQTT و CoAP من حيث كفاءة عرض النطاق كحساب المبلغ الإجمالي للبيانات المرسلة لكل رسالة. أظهر CoAP إنتاجية أقل من MQTT للرسائل الصغيرة. ولكن عند مقارنة كفاءة البروتوكولات من حيث نسبة عدد بايتات المعلومات المفيدة إلى العدد الإجمالي للبايتات المرسلة ، تبين أن CoAP أكثر فعالية.
في الإنتاجية باستخدام MQTT و DDS (مع TCP كبروتوكول النقل) و CoAP ، وجد أن CoAP يميل إلى إظهار استهلاك نطاق ترددي أقل نسبيًا ، والذي لم يزداد مع زيادة فقدان حزم الشبكة أو زيادة تأخير الشبكة ، على عكس MQTT و DDS ، حيث في السيناريوهات المذكورة كانت هناك زيادة في استخدام النطاق الترددي. سيناريو آخر تضمن عددًا كبيرًا من الأجهزة التي تنقل البيانات في نفس الوقت ، وهي حالة نموذجية في بيئات إنترنت الأشياء. أظهرت النتائج أنه من الأفضل استخدام CoAP للتحميل العالي.
في ظل الحمل الخفيف ، استخدم CoAP أقل عرض نطاق ترددي ، متبوعًا بـ MQTT و REST HTTP. ومع ذلك ، مع زيادة حجم الحمولات ، حقق REST HTTP أفضل النتائج.
استهلاك الطاقة
تحظى مسألة استهلاك الطاقة دائمًا بأهمية كبيرة ، وخاصة في نظام إنترنت الأشياء. لو استهلاك الطاقة لـ MQTT و HTTP ، "يأكل" HTTP أكثر من ذلك بكثير. و CoAP هو أكثر من ذلك مقارنة بـ MQTT ، مما يسمح بإدارة الطاقة. في الوقت نفسه ، في سيناريوهات بسيطة ، يكون MQTT أكثر ملاءمة لتبادل المعلومات في شبكات إنترنت الأشياء ، خاصةً إذا لم تكن هناك قيود على الطاقة.
أظهرت تجربة قارنت إمكانيات AMQP و MQTT على منصة اختبار شبكة لاسلكية متنقلة أو غير مستقرة أن AMQP يوفر المزيد من ميزات الأمان ، في حين أن MQTT أكثر كفاءة في استخدام الطاقة.
أمن
الأمن هو قضية رئيسية أخرى أثيرت في دراسة إنترنت الأشياء والحوسبة الضبابية / السحابية. تعتمد آلية الأمان عادةً على TLS في HTTP و MQTT و AMQP و XMPP أو DTLS في CoAP ، وتدعم كلا خياري DDS.
تبدأ TLS و DTLS بعملية إنشاء اتصال بين العميل والخادم لتبادل مجموعات ومفاتيح التشفير المدعومة. يتفاوض الطرفان على مجموعات لضمان إجراء مزيد من الاتصالات في قناة آمنة. الفرق بين الاثنين هو تعديل بسيط يسمح لـ DTLS المستندة إلى UDP بالعمل عبر اتصال غير موثوق به.
في في العديد من التطبيقات المختلفة لـ TLS و DTLS ، اتضح أن TLS قام بعمل أفضل. كانت الهجمات على DTLS أكثر نجاحًا نظرًا لتحملها للخطأ.
ومع ذلك ، فإن أكبر مشكلة في هذه البروتوكولات هي أنها لم تكن مصممة أصلاً للاستخدام في إنترنت الأشياء ولم يكن من المفترض أن تعمل في الضباب أو السحابة. من خلال المصافحة ، يضيفون حركة مرور إضافية مع كل مؤسسة اتصال ، والتي تستنزف موارد الحوسبة. في المتوسط ، هناك زيادة بنسبة 6,5٪ في TLS و 11٪ في DTLS في الحمل مقارنةً بالاتصالات بدون طبقة أمان. في البيئات الغنية بالموارد التي توجد عادةً في المستوى ، لن تكون هذه مشكلة ، ولكن نظرًا للعلاقة بين إنترنت الأشياء ومستوى الضباب ، يصبح هذا قيدًا مهمًا.
ماذا تختار؟ لا توجد إجابة واحدة. يبدو أن MQTT و HTTP هما أكثر البروتوكولات الواعدة حيث أنهما يعتبران حلول إنترنت الأشياء أكثر نضجًا واستقرارًا نسبيًا من البروتوكولات الأخرى.
تعتمد الحلول على بروتوكول اتصال واحد
ممارسة حل بروتوكول واحد له العديد من العيوب. على سبيل المثال ، قد لا يعمل البروتوكول الذي يناسب بيئة مقيدة في مجال يحتوي على متطلبات أمان صارمة. مع وضع ذلك في الاعتبار ، يُترك لنا تجاهل جميع حلول البروتوكول الفردي الممكنة تقريبًا في النظام البيئي Fog-to-Cloud في IoT ، باستثناء MQTT و REST HTTP.
REST HTTP كحل بروتوكول واحد
هناك مثال جيد على تفاعل طلب / استجابة REST HTTP في مجال إنترنت الأشياء إلى الضباب: . تم تجهيز الحيوانات بأجهزة استشعار يمكن ارتداؤها (عميل إنترنت الأشياء ، C) وتتم إدارتها عبر الحوسبة السحابية بواسطة نظام الزراعة الذكية (خادم الضباب ، S).
يحدد عنوان طريقة POST المورد المراد تعديله (/ مزرعة / حيوانات) ، بالإضافة إلى إصدار HTTP ونوع المحتوى ، والذي يمثل في هذه الحالة كائن JSON يمثل مزرعة الحيوانات التي يجب على النظام إدارتها (Dulcinea / cow). تشير الاستجابة من الخادم إلى أن الطلب كان ناجحًا باستخدام رمز حالة HTTPS 201 (تم إنشاء المورد). يجب أن تحدد طريقة GET المورد المطلوب فقط في URI (على سبيل المثال ، / مزرعة / حيوانات / 1) ، والذي يعرض تمثيل JSON للحيوان بهذا المعرف من الخادم.
يتم استخدام طريقة PUT عندما يلزم تحديث بعض سجلات الموارد المحددة. في هذه الحالة ، يحدد المورد URI للمعامل المراد تغييره والقيمة الحالية (على سبيل المثال ، الإشارة إلى أن البقرة تسير حاليًا ، / مزرعة / حيوانات / 1؟ state = Walking). أخيرًا ، يتم استخدام طريقة DELETE بنفس طريقة طريقة GET ، ولكن يتم حذف المورد ببساطة كنتيجة للعملية.
MQTT كحل بروتوكول واحد
لنأخذ نفس المزرعة الذكية ، ولكن بدلاً من REST HTTP ، نستخدم بروتوكول MQTT. الخادم المحلي المثبت عليه مكتبة Mosquitto يعمل كوسيط. في هذا المثال ، يعمل جهاز كمبيوتر بسيط (يشار إليه باسم خادم المزرعة) Raspberry Pi كعميل MQTT ، يتم تنفيذه من خلال تثبيت مكتبة Paho MQTT ، والتي تتوافق تمامًا مع وسيط Mosquitto.
يتوافق هذا العميل مع طبقة تجريد إنترنت الأشياء التي تمثل جهازًا ذا قدرات اكتشاف وحوسبة. من ناحية أخرى ، يتوافق الوسيط مع مستوى أعلى من التجريد ، يمثل عقدة حوسبة ضبابية ، تتميز بقدرات معالجة وتخزين كبيرة.
في سيناريو المزرعة الذكية المقترح ، يتصل Raspberry Pi بمقياس التسارع ونظام تحديد المواقع العالمي (GPS) ومستشعرات درجة الحرارة وينشر البيانات من تلك المستشعرات إلى عقدة الضباب. كما تعلم على الأرجح ، يتعامل MQTT مع الموضوعات كتسلسل هرمي. يمكن لأحد ناشري MQTT نشر الرسائل إلى مجموعة محددة من الموضوعات. في حالتنا ، هناك ثلاثة. بالنسبة للمستشعر الذي يقيس درجة الحرارة في حظيرة الحيوانات ، يختار العميل موضوعًا (مزرعة حيوانات / سقيفة / درجة حرارة). بالنسبة لأجهزة الاستشعار التي تقيس موقع GPS وحركة الحيوانات من خلال مقياس التسارع ، سينشر العميل تحديثات لـ (مزرعة الحيوانات / الحيوان / نظام تحديد المواقع العالمي) و (مزرعة الحيوانات / الحيوان / الحركة).
ستتم مشاركة هذه المعلومات مع الوسيط ، الذي قد يخزنها مؤقتًا في قاعدة بيانات محلية في حالة ظهور مشترك آخر مهتم لاحقًا.
بالإضافة إلى الخادم المحلي الذي يعمل كوسيط MQTT في الضباب والذي يقوم Raspberry Pi ، بصفته عملاء MQTT ، بإرسال البيانات من أجهزة الاستشعار ، يمكن أن يكون هناك وسيط MQTT آخر على مستوى السحابة. في هذه الحالة ، قد يتم تخزين المعلومات المرسلة إلى الوسيط المحلي مؤقتًا في قاعدة بيانات محلية و / أو إرسالها إلى السحابة. يتم استخدام وسيط MQTT السحابي في هذه الحالة لربط جميع البيانات إلى وسيط MQTT السحابي. باستخدام هذه البنية ، يمكن لمستخدم تطبيقات الهاتف المحمول الاشتراك في كلا الوسيطين.
في حالة فشل الاتصال بأحد الوسطاء (على سبيل المثال ، السحابة) ، سيتلقى المستخدم النهائي معلومات من جهة أخرى (ضبابية). هذه سمة مميزة لأنظمة الضباب والحوسبة السحابية المدمجة. بشكل افتراضي ، يمكن تكوين تطبيق الهاتف المحمول للاتصال أولاً بوسيط MQTT الضبابي ، وفشل ذلك ، للاتصال بوسيط MQTT السحابي. هذا الحل هو مجرد واحد من العديد من أنظمة IoT-F2C.
حلول متعددة البروتوكولات
تحظى حلول البروتوكول الفردي بشعبية بسبب سهولة تنفيذها. لكن من الواضح أنه في أنظمة IoT-F2C يكون من المنطقي الجمع بين بروتوكولات مختلفة. النقطة المهمة هي أن البروتوكولات المختلفة يمكن أن تعمل على مستويات مختلفة. خذ على سبيل المثال ثلاثة مفاهيم تجريدية: إنترنت الأشياء ، والضباب ، وطبقات الحوسبة السحابية. تعتبر الأجهزة على مستوى إنترنت الأشياء بشكل عام محدودة. في هذه النظرة العامة ، دعنا نلقي نظرة على طبقات إنترنت الأشياء باعتبارها أكثر طبقات الحوسبة تقييدًا والأقل تقييدًا والقائمة على السحابة والحوسبة الضبابية باعتبارها "في مكان ما بين". ثم اتضح أنه بين إنترنت الأشياء وتجريد الضباب ، تشمل حلول البروتوكول الحالية MQTT و CoAP و XMPP. من ناحية أخرى ، بين الضباب والسحابة ، يعد AMQP أحد البروتوكولات الرئيسية المستخدمة مع REST HTTP ، والتي نظرًا لمرونتها تُستخدم أيضًا بين طبقات إنترنت الأشياء والضباب.
المشكلة الرئيسية هنا هي قابلية التشغيل البيني للبروتوكولات وسهولة نقل الرسائل من بروتوكول إلى آخر. من الناحية المثالية ، في المستقبل ، ستكون بنية نظام إنترنت الأشياء مع موارد السحابة والضباب مستقلة عن بروتوكول الاتصال المستخدم وستضمن إمكانية التشغيل البيني الجيد للبروتوكولات المختلفة.
نظرًا لأن هذا ليس هو الحال في الوقت الحالي ، فمن المنطقي دمج البروتوكولات التي لا تحتوي على اختلافات كبيرة. تحقيقا لهذه الغاية ، يعتمد أحد الحلول المحتملة على مجموعة من بروتوكولين يتبعان نفس النمط المعماري ، REST HTTP و CoAP. حل آخر مقترح يعتمد على مزيج من بروتوكولين يوفران تفاعل النشر والاشتراك ، MQTT و AMQP. استخدام مفاهيم متشابهة (كلا من وسطاء استخدام MQTT و AMQP ، يستخدم CoAP و HTTP REST) يجعل هذه المجموعات أسهل في التنفيذ وتتطلب جهد تكامل أقل.
يوضح الشكل (أ) نموذجين للطلب والاستجابة ، HTTP و CoAP ، وموضعهما المحتمل في حل IoT-F2C. نظرًا لأن HTTP هو أحد البروتوكولات الأكثر شهرة واعتمادًا في شبكات اليوم ، فمن غير المرجح أن يتم استبداله تمامًا ببروتوكولات المراسلة الأخرى. من بين العقد التي تمثل الأجهزة القوية الموجودة بين السحابة والضباب ، يعد REST HTTP حلاً معقولاً.
من ناحية أخرى ، بالنسبة للأجهزة المقيدة حسابيًا التي تتواصل بين طبقات الضباب وإنترنت الأشياء ، يكون استخدام CoAP أكثر كفاءة. تتمثل إحدى المزايا الكبيرة لـ CoAP في توافقه مع HTTP نظرًا لأن كلا البروتوكولين يعتمدان على مبادئ REST.
يوضح الشكل (ب) نموذجين لتفاعل النشر والاشتراك في نفس السيناريو ، بما في ذلك MQTT و AMQP. على الرغم من أنه يمكن استخدام كلا البروتوكولين افتراضيًا للتواصل بين العقد في كل مستوى من مستويات التجريد ، إلا أنه يجب تحديد موضعهما بناءً على الأداء. تم تصميم MQTT كبروتوكول خفيف الوزن للأجهزة ذات موارد الحوسبة المحدودة ، بحيث يمكن استخدامه للتواصل بين إنترنت الأشياء والضباب. يعد AMQP أكثر ملاءمة للأجهزة الأكثر قوة التي من شأنها أن تضعه بشكل مثالي بين عُقد الضباب والسحابة. بدلاً من MQTT في إنترنت الأشياء ، يمكنك استخدام بروتوكول XMPP ، حيث يعتبر خفيف الوزن. لكنها لا تستخدم على نطاق واسع في مثل هذه السيناريوهات.
النتائج
من غير المحتمل أن يكون أحد البروتوكولات المدروسة كافياً لتغطية جميع الاتصالات في النظام ، من الأجهزة ذات موارد الحوسبة المحدودة إلى الخوادم السحابية. أظهرت الدراسة أن الخيارين الواعدين اللذين يستخدمهما المطورون كثيرًا هما MQTT و RESTful HTTP. هذان البروتوكولان ليسا الأكثر نضجًا واستقرارًا فحسب ، بل يشتملان أيضًا على العديد من عمليات التنفيذ الناجحة والموثقة جيدًا والموارد عبر الإنترنت.
نظرًا لاستقراره وتكوينه البسيط ، يعد بروتوكول MQTT بروتوكولًا أثبت أدائه المتفوق بمرور الوقت عند استخدامه في طبقة إنترنت الأشياء مع أجهزة محدودة. في أجزاء النظام التي لا يمثل فيها الاتصال المحدود واستهلاك البطارية مشكلة ، مثل بعض مناطق الضباب ومعظم الحوسبة السحابية ، يعد RESTful HTTP خيارًا سهلاً. يجب أيضًا أخذ CoAP في الاعتبار نظرًا لأنه يتطور بسرعة أيضًا كمعيار لمراسلة إنترنت الأشياء ومن المحتمل أنه سيصل إلى مستوى من الاستقرار والنضج مشابه لـ MQTT و HTTP في المستقبل القريب. لكن المعيار يتطور الآن ، والذي يأتي مع مشكلات التوافق على المدى القصير.
ماذا يمكنك أن تقرأ في المدونة؟
→
→
→
→
→
اشترك في موقعنا -قناة حتى لا تفوت المقالة القادمة! لا نكتب أكثر من مرتين في الأسبوع وفقط عن العمل.
المصدر: www.habr.com