ما هي مميزات MQTT مقارنة ببروتوكول HTTP التقليدي؟

HTTP هو البروتوكول الأكثر استخدامًا وشعبية. لكن MQTT اكتسبت أرضًا بسرعة خلال السنوات القليلة الماضية. عند مناقشة تطوير إنترنت الأشياء، يجب على المطورين الاختيار بين هذين الاثنين.

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

لا تزال هناك العديد من المزايا لـ MQTT، كما يلي:

1. انخفاض عبء البروتوكول، تعد MQTT فريدة من نوعها من حيث أن رأسها لكل رسالة يمكن أن يصل إلى 2 بايت. يتمتع كل من MQ وHTTP بحمل أعلى بكثير لكل رسالة. باستخدام HTTP، تؤدي إعادة تأسيس اتصال HTTP لكل رسالة طلب جديدة إلى تحمل عبء كبير. تعمل الاتصالات المستمرة التي يستخدمها MQ وMQTT على تقليل هذا الحمل بشكل كبير.

2. التسامح مع الشبكات غير المستقرة، يمكن لـ MQTT وMQ التعافي من حالات الفشل مثل قطع الاتصال، ولا توجد متطلبات رمزية أخرى. ومع ذلك، لا يمكن لـ HTTP القيام بذلك محليًا، مما يتطلب من العملاء إعادة محاولة الترميز، مما قد يزيد من مشكلات عدم الكفاءة.

3. استهلاك منخفض للطاقة، تم تصميم MQTT خصيصًا لاستهلاك منخفض للطاقة. ولم يتم تصميم HTTP ليأخذ ذلك في الاعتبار، وبالتالي زيادة استهلاك الطاقة.

4. العملاء الذين لديهم ملايين الاتصالات، على مكدس HTTP، يتطلب الاحتفاظ بملايين الاتصالات المتزامنة الكثير من العمل لتقديم الدعم. على الرغم من أن هذا الدعم ممكن، إلا أن معظم المنتجات التجارية تم تحسينها للتعامل مع الاتصالات المستمرة بهذا الحجم. تقدم شركة IBM IBM messageSight، وهو خادم مثبت على حامل واحد تم اختباره للتعامل مع ما يصل إلى مليون جهاز متصل بشكل متزامن عبر MQTT. في المقابل، لم يتم تصميم MQTT لعدد كبير من العملاء المتزامنين.

5. دفع الإشعارات، يجب أن تكون قادرًا على توصيل الإشعارات إلى العملاء في الوقت المناسب. ولهذا يجب استخدام نوع ما من الاقتراع الدوري أو الدفع؛ يعد Push هو الحل الأفضل من منظور البطارية وتحميل النظام وعرض النطاق الترددي.

قد تحتاج أعمالنا إلى إرسال معلومات حساسة دون وساطة طرف ثالث. وهذا يقلل من قيمة الحلول الخاصة بنظام التشغيل (مثل Apple iOS وإشعارات Google Play) باعتبارها آلية النقل الأساسية.

يسمح HTTP فقط بطريقة واحدة تسمى COMET، وذلك باستخدام طلبات HTTP المستمرة لإجراء عمليات الدفع. هذا الأسلوب مكلف من وجهة نظر العميل والخادم. يدعم كل من MQ وMQTT الدفع كميزة أساسية لهما.

6. اختلافات النظام الأساسي للعميل، تم تنفيذ كل من عملاء HTTP وMQTT على عدد كبير من الأنظمة الأساسية. تساعد بساطة MQTT على تنفيذ MQTT على عملاء إضافيين بجهد قليل جدًا.

7. التسامح مع خطأ جدار الحماية، تقوم بعض جدران الحماية الخاصة بالشركات بتقييد الاتصالات الصادرة لبعض المنافذ المحددة. تقتصر هذه المنافذ عادةً على HTTP (المنفذ 80)، وHTTPS (المنفذ 443)، وما إلى ذلك. ومن الواضح أن HTTP يمكن أن يعمل في هذه المواقف. يمكن تغليف MQTT في اتصال WebSockets الذي يظهر كطلب ترقية HTTP، مما يسمح بالتشغيل في هذه الحالات. MQTT لا يسمح بهذا النمط.

بالمقارنة مع HTTP، يضمن بروتوكول MQTT معدل نقل مرتفع. هناك ثلاثة مستويات لجودة الخدمة:

أ. مرة واحدة على الأكثر: حاول التأكد من التسليم.

ب. مرة واحدة على الأقل: تأكد من إرسال البريد الإلكتروني مرة واحدة على الأقل، ولكن من الممكن أيضًا تسليم الرسالة أكثر من مرة.

ج. مرة واحدة فقط: التأكد من أن كل رسالة يتم استلامها مرة واحدة فقط من قبل الطرف الآخر.

في الواقع، يتم استخدام MQTT على نطاق واسع. يمكنك العثور على MQTT في أي شركة أجهزة وإنترنت كبيرة تقريبًا، مثل Facebook وBP وalibaba وbaidu وما إلى ذلك.

نظرًا للمزايا التقنية المتنوعة لـ MQTT نفسها، تميل المزيد والمزيد من الشركات إلى اختيار MQTT كبروتوكول قياسي لاتصالات منتجات إنترنت الأشياء. لذلك، اكتشف المهندسون تدريجيًا أن بروتوكول MQTT لديه بعض الوظائف التي تحتاج إلى تحسين إذا أردنا تسويقها على نطاق واسع. على سبيل المثال:

1. لا يوجد SDK كامل، وتحتاج المحطات غير المتجانسة المختلفة إلى حزم SDK للبرامج المقابلة للتواصل مع خادم MQTT. على سبيل المثال، لتحقيق الاتصال البيني بين MCU وLinux وAndroid وIOS وWEB وما إلى ذلك، يجب أن تكون هناك حاجة إلى حزم SDK مختلفة.

2. الملف وAV غير مدعومين. في بعض سيناريوهات التطبيق، قد لا تقتصر المعلومات التي سيتم إرسالها على التعليمات، مثل إشارات الصوت وإشارات الفيديو، والتي تحتاج إلى التواصل من خلال ملف وAV.

3. لا يدعم التكامل مع HTTP لجهة خارجية. على الرغم من أن بروتوكول MQTT يتفوق على بروتوكول HTTP العادي، إلا أن خوادم الويب المستندة إلى بروتوكول HTTP التقليدي لا تزال تشغل السوق السائد، لذا فإن هذه الخوادم م

يجب أن ندرك أن الاتصال البيني مع بروتوكول MQTT لتقليل تكلفة الترقيات أمر بالغ الأهمية أيضًا.

4. لا يدعم موازنة التحميل. من أجل منع التزامن العالي والهجمات الضارة، يعد خادم موازنة التحميل ضروريًا أيضًا.

5. لا يدعم واجهة إدارة المستخدم. من المهم بشكل خاص للمستخدمين تحليل بيانات سلوك الجهاز، وهو مطلب لا مفر منه للصناعة 4.0 وعصر البيانات الضخمة.

6. لا يدعم الرسائل غير المتصلة بالإنترنت، ويعوض عن مشكلة فقدان خادم MQTT لمعلومات التحكم الخاصة بالجهاز بعد أن يكون الجهاز غير متصل بالإنترنت.

7. لا يتم دعم الاتصال من نقطة إلى نقطة، ويتم اعتماد بروتوكول MQTT القياسي. من الناحية النظرية، يمكن تحقيق الاتصال من نقطة إلى نقطة من خلال الاشتراك المتبادل، ولكن المنطق معقد نسبيًا، وهناك مخاوف بشأن أمان الجهاز. عندما يكون الجهاز B والجهاز C على نفس الموضوع، لا يستطيع الجهاز A معرفة ما إذا كان الجهاز B أو الجهاز C هو الذي أرسل الرسالة، ومن الممكن أيضًا أن يتم التنصت على الرسالة بواسطة الجهاز D.

8. لا يدعم التواصل الجماعي وإدارة المجموعة، ويدرك إدارة أعضاء المجموعة، ويمكن لأعضاء المجموعة التواصل مع بعضهم البعض. في السيناريو الذي يتم فيه التحكم في جهاز واحد بواسطة عدة أشخاص، أو يتم التحكم في أجهزة متعددة بواسطة شخص واحد، يكون ذلك مفيدًا بشكل خاص.