كيف تتواصل الآلات - بروتوكول MQTT

في مقال سابق ، نظرنا في بروتوكول Modbus ، وهو المعيار الفعلي في الصناعة للتفاعل M2M . وضعت مرة أخرى في عام 1979 ، لديها عدد من العيوب الهامة التي يحلها MQTT.

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

الميزات الرئيسية لبروتوكول MQTT:

• مدمجة وخفيفة الوزن - الحد الأدنى لنقل البيانات العامة لتوفير حركة المرور.
• مقاومة الخسائر - التسليم المضمون في ظروف اتصالات الشبكة غير المستقرة.
• غير متزامن - يسمح لك بتقديم عدد كبير من الأجهزة ، ولا يعتمد على تأخير الشبكة.
• دعم جودة الخدمة - القدرة على التحكم في أولوية الرسالة وضمان تسليم الرسالة إلى المستلم.
• التكوين الديناميكي - لا يتطلب التنسيق المسبق للحقول وتنسيقات البيانات ، يمكن تهيئته بسرعة.
• يعمل لـ NAT - يمكن للعملاء أن يكونوا وراء NAT ، فقط يجب أن يكون لدى الخادم (الوسيط) IP حقيقي. يتيح لك الاستغناء عن VPN وإعادة توجيه المنفذ.
• عنونة مريحة - تحتوي حقول البيانات على أسماء نصية مفهومة للبشر. لا حاجة لتذكر العناوين الرقمية والإزاحة بت.

في المقالة ، سنقارن MQTT و Modbus ، ونحلل بنية البروتوكول والمفاهيم الأساسية ، ونحاول استخدام وسيط سحابة MQTT كمثال في اتصال إنترنت غير مستقر.

تاريخ بروتوكول MQTT

تم تطوير MQTT بواسطة IBM في عام 1999 ، وتم استخدامه مبدئيًا داخليًا لحلولها.

في نوفمبر 2011 ، أعلنت IBM و Eurotech عن مشاركتهما في مجموعة عمل Eclipse M2M ونقل كود MQTT إلى مشروع Eclipse Paho.

في عام 2013 ، بدأ اتحاد OASIS (منظمة النهوض بمعايير المعلومات الهيكلية) عملية توحيد بروتوكول MQTT. حتى هذه المرحلة ، تم نشر مواصفات البروتوكول بموجب ترخيص مجاني ، وتستخدم شركات مثل Eurotech (المعروفة سابقًا باسم Arcom) البروتوكول في منتجاتها.

في أكتوبر 2014 ، نشرت OASIS المعيار الرسمي الأول لبروتوكول MQTT.

في عام 2016 ، تم توحيد البروتوكول من قبل المنظمة الدولية للتوحيد القياسي ISO وحصل على الرقم ISO / IEC 20922.

منذ عام 2014 ، بدأ الاهتمام بالبروتوكول ينمو بسرعة ، واستنادا إلى جدول Google Trends ، فإنه يفوق اليوم الاهتمام بـ Modbus.


جوجل اتجاهات المعيار

المفاهيم الأساسية

لدى MQTT بنية خادم عميل. تتم المراسلة من خلال خادم مركزي يسمى وسيط. في ظل الظروف العادية ، لا يمكن للعملاء التواصل مباشرة مع بعضهم البعض ، ويحدث كل تبادل البيانات من خلال وسيط.

يمكن للعملاء العمل كموفري بيانات (Publisher) وكمتلقين للبيانات (مشترك). في الترجمة الروسية ، غالبًا ما تُترجم هذه المصطلحات كناشر ومشترك ، ولكن لتجنب الالتباس ، سوف نستخدم المصطلحات الأصلية فقط.


في بروتوكول MQTT ، يتواصل العملاء مع بعضهم البعض من خلال عقدة مركزية

على مستوى التطبيق ، يعمل البروتوكول على رأس TCP / IP ويمكنه بسهولة توصيل الكائنات البعيدة مباشرة عبر الإنترنت ، دون الحاجة إلى أنفاق VPN. يكفي أن يكون لدى الوسيط عنوان IP حقيقي ويمكن لجميع العملاء الاتصال به. في هذه الحالة ، قد يكون العملاء موجودين خلف NAT. نظرًا لأن العملاء يبدأون الاتصال في بروتوكول MQTT ، فإن إعادة توجيه المنافذ غير مطلوبة لإنشاء اتصال ، بينما في Modbus / TCP ، يبدأ الخادم في اتصال (رئيسي) ، الأمر الذي يتطلب الوصول المباشر إلى الشبكة.

منفذ وسيط MQTT القياسي لاتصالات TCP الواردة هو 1883 . عند استخدام اتصال SSL آمن ، يتم استخدام المنفذ 8883 .

وسيط

الوسيط هو مركز MQTT المركزي لتفاعل العملاء. يحدث تبادل البيانات بين العملاء فقط من خلال وسيط. يمكن أن يكون الوسيط برنامج خادم أو وحدة تحكم. تشمل مهامه تلقي البيانات من العملاء ومعالجة البيانات وتخزينها وتسليم البيانات للعملاء ومراقبة تسليم الرسائل.

الناشر / المشترك

لفهم الفرق بين Publisher والمشترك ، دعنا نأخذ مثالًا بسيطًا: مستشعر الرطوبة يقيس الرطوبة في الغرفة ، وإذا انخفض إلى أقل من مستوى معين ، يتم تشغيل المرطب.

في هذه الحالة ، يعمل مستشعر الرطوبة باعتباره ناشرًا : مهمته هي فقط نشر البيانات إلى الوسيط. يعمل المرطب كمشترك: فهو يشترك في تحديثات بيانات الرطوبة ويتلقى بيانات محدثة من الوسيط ، بينما يستطيع المرطب أن يقرر عند نقطة تشغيل الترطيب.

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


يرسل الناشر البيانات إلى الوسيط ، يشترك المشترك في تحديثات هذه البيانات

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

موضوع

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

مثال على المواضيع في MQTT

#     home/kitchen/temperature #     home/sleeping-room/temperature #     home/outdoor/light 

تتيح لك هذه الطريقة رؤية البيانات التي يتم نقلها بشكل مرئي ، كما أنها ملائمة لتطوير التعليمات البرمجية وتصحيحها دون الحاجة إلى حفظ العنوان الرقمي لموضع البيانات ، كما هو الحال في Modbus.

تشمل الموضوعات أيضًا بناء جملة أحرف البدل ، المألوف بالنسبة لأولئك الذين عملوا مع نظام ملفات UNIX. يمكن أن تكون أحرف البدل من مستوى واحد ومتعدد المستويات.

يشار إلى أحرف البدل ذات المستوى الواحد بعلامة + .

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

 home/+/temperature 

نتيجة لذلك ، سوف يشترك في استلام البيانات من هذه المستشعرات:

 home/kitchen/temperature home/sleeping-room/temperature home/living-room/temperature home/outdoor/temperature 

يشار إلى البدل متعدد المستويات بالرمز " # ".
مثال على الحصول على البيانات من جميع أجهزة الاستشعار في جميع الغرف في المنزل:

 home/# 

سيسمح لك الاشتراك في هذا الموضوع بتلقي البيانات من هذه المستشعرات:

 home/kitchen/temperature home/kitchen/humidity home/kitchen/light home/sleeping-room/temperature home/sleeping-room/humidity home/sleeping-room/light .... 

تحديد هوية العميل

للتحكم في الوصول ، يوفر MQTT مصادقة العميل ، على عكس بروتوكول Modbus ، الذي لا يحتوي على مثل هذه الوظيفة. تستخدم الحقول التالية للتحكم في الوصول:

ClientId - (الحقل المطلوب) معرف فريد للعميل. يجب أن تكون فريدة لكل عميل. يتيح لك الإصدار الحالي من المعيار MQTT 3.1.1 استخدام حقل ClientId الفارغ إذا لم تكن بحاجة إلى حفظ حالة الاتصال.

اسم المستخدم - (حقل اختياري) تسجيل الدخول للمصادقة ، بتنسيق UTF-8. قد لا تكون فريدة من نوعها. على سبيل المثال ، يمكن لمجموعة من العملاء تسجيل الدخول باستخدام نفس اسم المستخدم / كلمة المرور.

كلمة المرور - (الحقل الاختياري) يمكن إرساله فقط مع حقل اسم المستخدم ، بينما يمكن إرسال اسم المستخدم بدون حقل كلمة المرور. أقصى 65535 بايت. من المهم معرفة أن الاسم وكلمة المرور يتم إرسالهما بشكل واضح ، وبالتالي ، إذا تم نقل البيانات عبر الشبكات العامة ، يجب عليك استخدام SSL لتشفير الاتصال.

هيكل الحزمة

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


حزمة MQTT المنقولة عبر قناة غير مشفرة

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

رأس

نوع الرسالة هو Connect (أمر 0x0001) ، وهو يقوم بتأسيس اتصال مع الوسيط. الفرق الرئيسية: الاتصال ، قطع الاتصال ، النشر ، الاشتراك ، إلغاء الاشتراك. هناك أيضًا أوامر إقرار ، والحفاظ على الحياة ، إلخ.

الإبلاغ عن DUP - يعني إعادة إرسال الرسالة ، حيث يتم استخدامها فقط في أنواع الرسائل PUBLISH و SUBSCRIBE و UNSUBSCRIBE و PUBREL ، للحالات التي لا يتلقى فيها الوسيط تأكيدًا باستلام الرسالة السابقة.
مستوى جودة الخدمة - علم جودة الخدمة. سنناقش هذا الموضوع بمزيد من التفصيل في وقت لاحق.
الاحتفاظ - يتم تخزين البيانات المنشورة مع علامة الاحتفاظ على الوسيط. عند الاشتراك اللاحق في هذا الموضوع ، سيرسل الوسيط رسالة على الفور مع هذه العلامة. يستخدم فقط في رسائل النوع Publish.

الاستخدام العملي

الآن ، بعد أن تعرفنا على النظرية ، دعونا نحاول العمل مع MQTT في الممارسة. لهذا الغرض ، سوف نستخدم برنامج Mosquitto المفتوح ، والذي يمكنه العمل في وضع العميل ووضع الخادم (وسيط). وهو يعمل على ويندوز ، ماك ، لينكس. البرنامج مناسب للغاية لتصحيح الأخطاء ودراسة بروتوكول MQTT ، بينما يستخدم أيضًا على نطاق واسع في العملية الصناعية. سنستخدمه كعميل لإرسال واستقبال البيانات من وسيط سحابة عن بعد.

يوفر العديد من موفري الخدمات السحابية خدمات وسيط MQTT ، مثل Microsoft Azure IoT Hub و Amazon AWS IoT وغيرها. في هذا المثال ، سوف نستخدم خدمة Cloudmqtt.com ، نظرًا لأن لديها أبسط تسجيل ، والتعرفة المجانية كافية للتدريب.

بعد التسجيل ، تتوفر تفاصيل الاتصال بالوسيط في حسابك. نظرًا لأننا نتصل بالخادم عبر شبكات الإنترنت العامة ، فمن المعقول استخدام منفذ SSL لتشفير حركة المرور.


تفاصيل وصول وسيط MQTT في الحساب الشخصي لمزود السحابة

تسمح مرونة بروتوكول MQTT للعميل بنقل البيانات غير المحددة مسبقًا من قبل الوسيط. بمعنى ، ليست هناك حاجة إلى إنشاء الموضوعات الضرورية مسبقًا التي يستطيع Publisher من خلالها كتابة البيانات. باستخدام البيانات الواردة من حسابك الشخصي ، سنحاول إنشاء طلب لنشر البيانات يدويًا إلى habr / test / عشوائي الموضوع والقراءة منه.

mosquitto_sub - فائدة عميل المشترك
mosquitto_pub - أداة عميل الناشر

أولاً ، اتصل بالوسيط كمشترك ، والاشتراك لتلقي البيانات من الموضوع
هابر / اختبار / عشوائي .

 mosquitto_sub -d --capath /etc/ssl/certs/ --url mqtts://hwjspxxt:7oYugN7Fa5Aa@postman.cloudmqtt.com:27529/habr/test/random Client mosq/zEPZz0glUiR4aEipZA sending CONNECT Client mosq/zEPZz0glUiR4aEipZA received CONNACK (0) Client mosq/zEPZz0glUiR4aEipZA sending SUBSCRIBE (Mid: 1, Topic: habr/test/random, QoS: 0, Options: 0x00) Client mosq/zEPZz0glUiR4aEipZA received SUBACK 

يمكن ملاحظة أن الاتصال كان ناجحًا ، وقد اشتركنا في الموضوع habr / test / عشوائي ، ونحن الآن في انتظار البيانات في هذا الموضوع من الوسيط.

نظرًا لاستخدام اتصال SSL ، للتحقق من الشهادة ، يجب عليك تحديد المسار الذي سيبحث به البرنامج عن شهادات تشفير الجذر. نظرًا لأن الخدمة في مثالنا تستخدم شهادة صادرة عن مرجع مصدق موثوق به ، فإننا نشير إلى المسار إلى متجر النظام للحصول على شهادات الجذر: --capath / etc / ssl / certs /

في حالة الشهادة الموقعة ذاتيا ، يجب عليك تحديد المسار إلى المرجع المصدق المطلوب. من المهم أيضًا مراعاة الفرق في تنسيق URI لاتصالات SSL - mqtt s : // ، والاتصالات غير المشفرة - mqtt: //. في حالة وجود خطأ في التحقق من الشهادة ، يتم إنهاء البرنامج دون ظهور رسالة خطأ. لمزيد من الإخراج المفصل ، يمكنك استخدام مفتاح التبديل - debug

الآن دعونا نحاول نشر البيانات في الموضوع دون مقاطعة البرنامج الأول.

 mosquitto_pub -d --capath /etc/ssl/certs/ --url mqtt://hwjspxxt:7oYugN7Fa5Aa@postman.cloudmqtt.com:27529/habr/test/random -m " !" Client mosq/sWjh9gf8DRASrRZjk6 sending CONNECT Client mosq/sWjh9gf8DRASrRZjk6 received CONNACK (0) Client mosq/sWjh9gf8DRASrRZjk6 sending PUBLISH (d0, q0, r0, m1, 'habr/test/random', ... (22 bytes)) Client mosq/sWjh9gf8DRASrRZjk6 sending DISCONNECT 

يمكن ملاحظة أن البيانات قد تم استلامها بنجاح بواسطة الخادم ونشرها في الموضوع المطلوب. في الوقت نفسه ، في النافذة الأولى التي يعمل فيها برنامج mosquitto_sub ، نرى كيف تم استلام الرسالة ، وحتى يونيكود تعمل ، الرسالة باللغة الروسية.

 Client mosq/zEPZz0glUiR4aEipZA received PUBLISH (d0, q0, r0, m0, 'habr/test/random', ... (22 bytes))  ! 

جودة الخدمة وضمان التسليم

ومع ذلك ، فإن إرسال رسالة في الوقت الحقيقي لن يفاجئ أي شخص ، لأنه يمكن القيام بنفس الشيء حتى مع nal. لذلك ، سنحاول محاكاة اتصال غير مستقر بين المشترك والمرسل. تخيل أن كلا العميلين يعملان من خلال GPRS ، مع خسارة كبيرة في الحزمة ، وحتى أن اتصال TCP الناجح أمر نادر الحدوث ، وعليك التأكد من أن المشترك مضمون لتلقي رسالة مرسل. في هذه الحالة ، تأتي خيارات جودة الخدمة في عملية الإنقاذ.

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

جودة الخدمة 1: مرة واحدة على الأقل - واحدة على الأقل . تعني هذه العلامة أنه حتى يتلقى Publisher تأكيد التسليم للمشترك ، سيتم إرسال هذا المنشور إلى الوسيط ، ثم إلى المشترك. وبالتالي ، يجب أن يتلقى المشترك هذه الرسالة مرة واحدة على الأقل.

جودة الخدمة 2: مرة واحدة مضمونة تمامًا . علامة جودة الخدمة (QoS) ، والتي توفر أعلى ضمان لتسليم الرسائل من خلال استخدام إجراءات إضافية لتأكيد واستكمال المنشور (PUBREC ، PUBREL ، PUBCOMP). تنطبق على الحالات التي يكون فيها من الضروري استبعاد أي فقد وازدواجية للبيانات من أجهزة الاستشعار. على سبيل المثال ، عندما يتم تشغيل إنذار من رسالة مستلمة ، يتم إجراء مكالمة طوارئ.

لمحاكاة الاتصال الضعيف ، قم بتعطيل كل من العملاء ومحاولة إرسال رسالة بأولوية جودة الخدمة ، وقم أيضًا بإضافة خيار "الاحتفاظ" بحيث يتم حفظ الرسالة المرسلة على الوسيط.

 mosquitto_pub --retain --qos 2 -d --capath /etc/ssl/certs/ --url mqtt://hwjspxxt:7oYugN7Fa5Aa@postman.cloudmqtt.com:27529/habr/test/random -m "  !" Client mosq/Xwhua3GAyyY9mMd05V sending CONNECT Client mosq/Xwhua3GAyyY9mMd05V received CONNACK (0) Client mosq/Xwhua3GAyyY9mMd05V sending PUBLISH (d0, q2, r1, m1, 'habr/test/random', ... (37 bytes)) Client mosq/Xwhua3GAyyY9mMd05V received PUBREC (Mid: 1) Client mosq/Xwhua3GAyyY9mMd05V sending PUBREL (m1) Client mosq/Xwhua3GAyyY9mMd05V received PUBCOMP (Mid: 1, RC:0) Client mosq/Xwhua3GAyyY9mMd05V sending DISCONNECT 

الآن ، بعد مرور بعض الوقت ، تمكن المستلم أخيرًا من إنشاء اتصال بالإنترنت ومتصل بالوسيط:

 mosquitto_sub -d --capath /etc/ssl/certs/ -d --url mqtts://hwjspxxt:7oYugN7Fa5Aa@postman.cloudmqtt.com:27529/habr/test/random Client mosq/VAzcLVMB1MiWhYxoJS sending CONNECT Client mosq/VAzcLVMB1MiWhYxoJS received CONNACK (0) Client mosq/VAzcLVMB1MiWhYxoJS sending SUBSCRIBE (Mid: 1, Topic: habr/test/random, QoS: 0, Options: 0x00) Client mosq/VAzcLVMB1MiWhYxoJS received SUBACK Subscribed (mid: 1): 0 Client mosq/r6UwPnDvx8aNInpPF6 received PUBLISH (d0, q0, r1, m0, 'habr/test/random', ... (37 bytes))   ! 

استنتاج

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