أدى تطوير التقنيات في مجال البرمجيات والأجهزة ، وبروز بروتوكولات الاتصال الجديدة إلى توسيع إنترنت الأشياء (IoT). يتزايد عدد الأجهزة يومًا بعد يوم ، وتولد كمية هائلة من البيانات. لذلك ، هناك حاجة إلى بنية نظام مريحة قادرة على معالجة وتخزين ونقل هذه البيانات.
الآن يستخدمون الخدمات السحابية لهذه الأغراض. ومع ذلك ، فإن النموذج الضبابي المتزايد (Fog) قادر على استكمال الحلول السحابية من خلال توسيع وتحسين البنية التحتية لإنترنت الأشياء. يمكن للسحب إغلاق معظم طلبات إنترنت الأشياء. على سبيل المثال ، لتوفير خدمات المراقبة ، والمعالجة السريعة لأي كمية من البيانات الناتجة عن الأجهزة ، وكذلك تصورها. الحوسبة الضبابية أكثر فعالية في حل المشكلات في الوقت الفعلي. أنها توفر استجابة سريعة للطلبات والحد الأدنى من التأخير في معالجة البيانات. وهذا هو ، الضباب يكمل بالضبط "الغيوم" ، يوسع قدراتها.
ومع ذلك ، فإن السؤال الرئيسي مختلف: كيف ينبغي أن يتفاعل كل هذا في سياق إنترنت الأشياء؟ ما هي بروتوكولات الاتصال التي ستكون أكثر فعالية عند العمل في نظام IoT-Fog-Cloud موحد؟
على الرغم من الهيمنة الظاهرة لـ HTTP ، فإن IoT و Fog و Cloud يستخدمون عددًا كبيرًا من الحلول الأخرى. وذلك لأن إنترنت الأشياء يجب أن تجمع بين وظائف مجموعة متنوعة من أجهزة الاستشعار مع الأمن ، وقابلية التشغيل البيني ، ومتطلبات المستخدم الأخرى.
هنا مجرد فكرة واحدة للهندسة المرجعية ومعيار الاتصالات ببساطة ليست هناك. لذلك ، فإن إنشاء بروتوكول جديد أو تحسين بروتوكول موجود لمهام إنترنت الأشياء المحددة هو واحد من أهم المهام التي تواجه مجتمع تكنولوجيا المعلومات.
ما هي البروتوكولات المستخدمة الآن وما الذي يمكن أن تقدمه؟ هيا بنا ولكن أولاً ، دعونا نناقش مبادئ النظام البيئي الذي تتفاعل فيه السحب والضباب وإنترنت الأشياء.
هندسة إنترنت الأشياء (Fog-to-Cloud) (F2C)
يجب أن تكون قد لاحظت مقدار الجهد المبذول في استكشاف فوائد وفوائد إدارة إنترنت الأشياء والسحب والضباب بطريقة عقلانية ومنسقة. إذا لم يكن الأمر كذلك ، فهناك بالفعل ثلاث مبادرات توحيد:
OpenFog Consortium و
Edge Computing Consortium و
mF2C H2020 EU project .
إذا تم في وقت سابق النظر فقط في مستويين وسحب وأجهزة نهاية ، فإن البنية المقترحة تقدم حوسبة ضباب جديدة. في هذه الحالة ، يمكن تقسيم مستوى الضباب إلى عدة مستويات فرعية ، اعتمادًا على تفاصيل الموارد أو مجموعة من السياسات التي تحدد استخدام أجهزة مختلفة في هذه المستويات الفرعية.
ما قد يبدو هذا التجريد؟ إليك نظام بيئي معتاد على الضباب IoT-Fog-Cloud. تقوم أجهزة إنترنت الأشياء بإرسال البيانات إلى خوادم وأجهزة حوسبة أكثر قوة لحل المهام التي تتطلب كمونًا منخفضًا. في نفس النظام ، تكون السحاب مسؤولة عن حل المشكلات التي تتطلب قدرًا كبيرًا من موارد الحوسبة أو مساحة تخزين البيانات.
يمكن أن تكون الهواتف الذكية والساعات الذكية والأدوات الأخرى جزءًا من إنترنت الأشياء. لكن مثل هذه الأجهزة ، كقاعدة عامة ، تستخدم بروتوكولات الاتصال الخاصة بالمطورين الكبار. يتم تمرير بيانات إنترنت الأشياء التي تم إنشاؤها إلى مستوى الضباب من خلال بروتوكول REST HTTP ، والذي يوفر المرونة وقابلية التشغيل البيني عند إنشاء خدمات RESTful. هذا مهم في ضوء الحاجة إلى التوافق مع الإصدارات السابقة مع البنية التحتية الحالية للحوسبة التي تعمل على أجهزة الكمبيوتر المحلية أو الخوادم أو مجموعة الخوادم. تقوم الموارد المحلية ، والتي تسمى "عقد الضباب" ، بتصفية البيانات المستلمة ومعالجتها محليًا أو إرسالها إلى السحابة لمزيد من العمليات الحسابية.
تدعم Cloud العديد من بروتوكولات الاتصال ، والتي من بينها 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 عند العمل مع IoT أن وقت الاستجابة لطلبات MQTT أقل من ذلك من HTTP. وعند
دراسة وقت الاستقبال والإرسال (RTT) لـ MQTT و CoAP ، اتضح أن متوسط RTT CoAP هو 20٪ أقل من MQTT.
تم
إجراء تجربة أخرى باستخدام RTT لبروتوكولي MQTT و CoAP في سيناريوهين: شبكة محلية وشبكة إنترنت الأشياء. اتضح أن معدل RTT هو أعلى 2-3 مرات في شبكة إنترنت الأشياء. أظهرت MQTT مع QoS0 نتيجة أقل مقارنةً بـ CoAP ، وأظهرت MQTT مع QoS1 أعلى RTT بسبب ACK على مستويات التطبيق والنقل. بالنسبة لمستويات جودة الخدمة المختلفة ، كانت تأخيرات الشبكة دون احتقان لـ 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 و HTTP REST. ومع ذلك ، عند زيادة حجم البيانات الفعلية ، كان 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 في إنترنت الأشياء ، باستثناء MQTT و REST HTTP.
REST HTTP كحل بروتوكول واحديوجد مثال جيد على طلب HTTP وتفاعل الاستجابة من IoT-to-Fog:
المزرعة الذكية . تم تجهيز الحيوانات بأجهزة استشعار يمكن ارتداؤها (عميل إنترنت الأشياء ، C) والتحكم فيها عن طريق الحوسبة السحابية من قبل نظام الزراعة الذكية (خادم الضباب ، S).
يشير عنوان طريقة POST إلى المورد المطلوب تغييره (/ مزرعة / حيوانات) ، بالإضافة إلى إصدار HTTP ونوع المحتوى ، وهو في هذه الحالة كائن JSON يمثل مزرعة الماشية التي يجب على النظام إدارتها (Dulcinea / cow). تشير استجابة الخادم إلى نجاح الطلب عن طريق إرسال رمز حالة HTTPS 201 (تم إنشاء المورد). يجب أن تشير طريقة GET إلى المورد المطلوب فقط في URI (على سبيل المثال ، / farm / animals / 1) ، والتي تُرجع تمثيل JSON للحيوان مع هذا المعرف من الخادم.
يتم استخدام طريقة PUT عندما تحتاج إلى تحديث سجل مورد معين. في هذه الحالة ، يشار إلى URI في المورد للمعلمة المراد تغييرها والقيمة الحالية (على سبيل المثال ، تشير إلى أن البقرة تمشي حاليًا ، / farm / animals / 1 - الحالة = المشي). أخيرًا ، يتم استخدام أسلوب DELETE بالتساوي مع أسلوب GET ، ولكن ببساطة يحذف المورد كنتيجة للعملية.
MQTT كحل بروتوكول واحد
استخدم المزرعة الذكية نفسها ، ولكن بدلاً من REST HTTP ، نستخدم بروتوكول MQTT. يعمل الخادم المحلي المزود بمكتبة Mosquitto كوسيط. في هذا المثال ، يعمل كمبيوتر بسيط (يشار إليه باسم خادم المزرعة) Raspberry Pi كعميل MQTT ، ويتم تنفيذه من خلال تثبيت مكتبة MQTT Paho ، وهو متوافق تمامًا مع وسيط Mosquitto.
يتوافق هذا العميل مع طبقة تجريد إنترنت الأشياء التي تمثل جهازًا يتمتع بقدرات الكشف والحوسبة. من ناحية أخرى ، يتوافق الوسيط مع مستوى أعلى من التجريد ، يمثل عقدة الحوسبة للضباب ، والتي تتميز بقوة كبيرة من حيث معالجة البيانات وتخزينها.
في سيناريو Smart Farm المقترح ، يتصل Raspberry Pi بجهاز استشعار التسارع ونظام تحديد المواقع ودرجة الحرارة وينشر البيانات من هذه المستشعرات في عقدة الضباب. كما تعلم ربما ، تعامل MQTT الموضوعات كهرمية. يستطيع ناشر MQTT النشر في مجموعة محددة من الموضوعات. في حالتنا هناك ثلاثة منهم. لجهاز استشعار يقيس درجة الحرارة في حظيرة للحيوانات ، يختار العميل سمة (حظيرة / سقيفة / درجة حرارة). بالنسبة لأجهزة الاستشعار التي تقيس موقع GPS وحركة الحيوانات من خلال مقياس التسارع ، سينشر العميل تحديثات (animalfarm / animal / GPS) و (animalfarm / animal / motion).
سيتم نقل هذه المعلومات إلى الوسيط الذي يمكنه تخزينها مؤقتًا في قاعدة بيانات محلية في حالة ظهور مشترك مهتم آخر في وقت لاحق.
بالإضافة إلى الخادم المحلي الذي يعمل كوسيط MQTT في الضباب والذي يقوم Raspberry Pi ، الذي يعمل كعملاء MQTT ، بإرسال البيانات من أجهزة الاستشعار ، قد يكون هناك وسيط MQTT آخر على مستوى السحابة. في هذه الحالة ، يمكن تخزين المعلومات المنقولة إلى الوسيط المحلي مؤقتًا في قاعدة البيانات المحلية و / أو إرسالها إلى السحابة. يستخدم وسيط MQTT الضبابي في هذه الحالة لربط جميع البيانات مع وسيط سحابة MQTT. باستخدام هذه البنية ، يمكن اشتراك مستخدم تطبيقات الهاتف المحمول في كلا الوسطاء.
في حالة فشل الاتصال مع أحد الوسطاء (على سبيل المثال ، سحابة) ، سيتلقى المستخدم النهائي معلومات من آخر (ضبابي). هذه هي ميزة الجمع بين أنظمة الضباب والحوسبة السحابية. بشكل افتراضي ، يمكن تكوين تطبيق الهاتف المحمول لأول اتصال بسمسار MQTT الضباب ، وفي حالة الفشل ، للاتصال بسمسار MQTT في السحابة. هذا الحل هو واحد فقط من العديد من أنظمة IoT-F2C.
حلول متعددة البروتوكولات
حلول بروتوكول واحد تحظى بشعبية بسبب سهولة تنفيذها. لكن من الواضح أنه في أنظمة IoT-F2C من المنطقي الجمع بين البروتوكولات المختلفة. النقطة المهمة هي أن البروتوكولات المختلفة يمكن أن تعمل على مستويات مختلفة. خذ على سبيل المثال ثلاثة أشكال تجريدية: مستويات إنترنت الأشياء والضباب والحوسبة السحابية. تعتبر أجهزة إنترنت الأشياء بوجه عام محدودة. في هذا الاستعراض ، دعنا ننظر إلى مستويات إنترنت الأشياء على أنها الأكثر محدودية ، والسحابة الأقل محدودة وحساب الضباب "في مكان ما في الوسط". ثم اتضح أن قرارات البروتوكول الحالية تشمل بين MoTT و CoAP و XMPP ، بين تجريد إنترنت الأشياء والضباب. بين الضباب والسحابة ، من ناحية أخرى ، يعد AMQP أحد البروتوكولات الرئيسية المستخدمة مع HTTP REST ، والذي بسبب مرونته يُستخدم أيضًا بين إنترنت الأشياء وطبقات الضباب.
المشكلة الرئيسية هنا هي قابلية التشغيل البيني للبروتوكولات وبساطة ترجمة الرسائل من بروتوكول إلى آخر. من الناحية المثالية ، في المستقبل ، ستكون بنية نظام إنترنت الأشياء مع موارد السحابة والضباب مستقلة عن بروتوكول الاتصال المستخدم وستوفر قابلية التشغيل البيني الجيدة بين البروتوكولات المختلفة.
نظرًا لأن هذا ليس كذلك في الوقت الحالي ، فمن المنطقي الجمع بين البروتوكولات التي ليس لها اختلافات كبيرة. تحقيقًا لهذه الغاية ، يعتمد أحد الحلول المحتملة على مجموعة من بروتوكولين يلتزمان بنفس الأسلوب المعماري ، REST HTTP و CoAP. يستند الحل المقترح الآخر إلى مجموعة من البروتوكولين اللذين يوفران تفاعلًا بين النشر والاشتراك ، MQTT و AMQP. باستخدام مفاهيم وثيقة (يستخدم كل من MQTT و AMQP وسطاء ، CoAP و HTTP use REST) ، يبسط تنفيذ هذه المجموعات ويتطلب جهد تكامل أقل.
يوضح الشكل (أ) نموذجين بناءً على طلب الاستجابة ، HTTP و CoAP ، ووضعهما المحتمل في حل IoT-F2C.
نظرًا لأن HTTP واحد من أكثر البروتوكولات المعروفة والمتكيفة في الشبكات الحديثة ، فمن غير المرجح أن يتم استبداله بالكامل ببروتوكولات المراسلة الأخرى. من بين العقد التي تمثل الأجهزة القوية الموجودة بين السحابة والضباب ، يعد HTTP REST حلاً ذكيًا.من ناحية أخرى ، بالنسبة للأجهزة ذات موارد الحوسبة المحدودة التي تتواصل بين مستويات الضباب وإنترنت الأشياء ، فإن استخدام CoAP أكثر فعالية. واحدة من المزايا الرائعة لبرنامج CoAP هي في الواقع توافقه مع HTTP ، حيث يعتمد كلا البروتوكولين على مبادئ REST.يوضح الشكل (ب) نموذجين لتفاعل اشتراك النشر في سيناريو واحد ، بما في ذلك MQTT و AMQP. على الرغم من أنه يمكن استخدام كلا البروتوكولين افتراضيًا للتواصل بين العقدتين في كل مستوى من مستويات التجريد ، إلا أنه ينبغي تحديد موقعهما استنادًا إلى الأداء. تم تطوير MQTT كبروتوكول مبسط للأجهزة ذات موارد الحوسبة المحدودة ، بحيث يمكن استخدامه للاتصال بين إنترنت الأشياء والضباب. AMQP هو أكثر ملاءمة للأجهزة الأكثر قوة التي تضعه بشكل مثالي بين العقد الضباب والسحابة. بدلاً من MQTT ، يمكن لـ IoT استخدام بروتوكول XMPP ، نظرًا لأنه يعتبر خفيف الوزن. لكنه لا يستخدم على نطاق واسع في مثل هذه السيناريوهات.النتائج
من غير المحتمل أن يكون أحد البروتوكولات المدروسة كافياً لتغطية جميع الاتصالات في النظام ، بدءًا من الأجهزة ذات موارد الحوسبة المحدودة وينتهي بخوادم السحابة. أظهرت الدراسة أن الخيارين الواعدين اللذين يستخدمهما المطورون في الغالب هما MQTT و RESTful HTTP. هذان البروتوكولان ليسا الأكثر نضجًا واستقرارًا ، بل يشمل أيضًا العديد من التطبيقات الموثقة جيدًا والناجحة والموارد عبر الإنترنت.نظرًا لاستقراره وتكوينه البسيط ، يعد MQTT بروتوكولًا أثبت مع مرور الوقت أدائه المتميز عند استخدامه على مستوى إنترنت الأشياء مع أجهزة محدودة. في أجزاء النظام التي لا يمثل فيها الاتصال المحدود واستهلاك البطارية مشكلة ، على سبيل المثال ، في بعض مناطق الضباب ومعظم الحوسبة السحابية ، يعد RESTful HTTP خيارًا سهلاً. يجب أيضًا أخذ CoAP في الاعتبار ، حيث إنه يتطور سريعًا أيضًا كمعيار للرسائل IoT ، ومن المحتمل أن يصل في المستقبل القريب إلى مستوى من الاستقرار والنضج يشبه MQTT و HTTP. ولكن يتم تطوير المعيار الآن ، والذي يرتبط بقضايا التوافق على المدى القصير.ما هو مفيد آخر للقراءة في مدونة Cloud4Y→
الكمبيوتر سوف تجعلك لذيذ→
يساعد الذكاء الاصطناعي في دراسة الحيوانات في إفريقيا→
الصيف قد انتهى تقريبا. تقريبا لا تسربت البيانات→
4 طرق للحفظ على النسخ الاحتياطية في السحابة→ على مورد معلومات اتحادي واحد يحتوي على معلومات السكاناشترك في قناة
Telegram الخاصة بنا حتى لا يفوتك مقال آخر! نكتب أكثر من مرتين في الأسبوع وفقط في الأعمال.