پروتکل MQTT در اینترنت اشیا؛ راهنمای فنی و مقایسه با CoAP و HTTP

در یک پروژهٔ پایش صنعتی با چند هزار سنسور، انتخاب پروتکل تبادل داده تعیین می‌کند قبض دیتای سیم‌کارت‌ها چقدر باشد، باتری دستگاه‌های میدانی چند ماه دوام بیاورد و سرور در اوج بار کم نیاورد. پروتکل MQTT در اینترنت اشیا دقیقاً برای همین محدودیت‌ها ساخته شده است: پهنای باند اندک، اتصال ناپایدار و دستگاه‌هایی با توان پردازشی محدود.

MQTT چیست و چرا استاندارد عملی صنعت شد؟

MQTT یک پروتکل پیام‌رسانی سبک بر پایهٔ الگوی انتشار/اشتراک (publish/subscribe) است که روی TCP اجرا می‌شود. نسخهٔ ۳.۱.۱ آن در سال ۲۰۱۴ استاندارد OASIS شد و بعدتر با شمارهٔ ISO/IEC 20922 نیز منتشر شد؛ نسخهٔ ۵.۰ در سال ۲۰۱۹ به استاندارد رسمی رسید.

تفاوت بنیادی آن با HTTP در معماری است، نه در جزئیات:

• بروکر (Broker): هر پیام به یک بروکر مرکزی می‌رود و از آنجا به مشترکان می‌رسد. افزودن یک مصرف‌کنندهٔ جدید داده، نیازی به تغییر میان‌افزار دستگاه ندارد.
• موضوع (Topic): آدرس‌دهی سلسله‌مراتبی مانند plant/line2/motor7/vibration اشتراک با الگوی wildcard را ممکن می‌کند.
• سرآیند کوچک: حداقل سرآیند ثابت MQTT تنها ۲ بایت است؛ یک درخواست HTTP معمولاً صدها بایت سرآیند متنی حمل می‌کند. روی سیم‌کارت NB-IoT این تفاوت مستقیم در صورت‌حساب دیده می‌شود.

سطوح کیفیت سرویس (QoS)

• QoS 0 — حداکثر یک بار: بدون تأیید دریافت؛ مناسب داده‌های پرتکرار و کم‌ارزش مانند دمای ثانیه‌به‌ثانیه.
• QoS 1 — دست‌کم یک بار: تا رسیدن تأیید بازارسال می‌شود. تکرار پیام ممکن است، پس منطق سمت سرور باید idempotent باشد.
• QoS 2 — دقیقاً یک بار: دست‌دادن چهارمرحله‌ای، بدون تکرار و بدون گم‌شدن؛ ترافیک و تأخیر بیشتری دارد و برای فرمان‌های حساس یا داده‌های تجاری کنتور منطقی است.

انتخاب بی‌دلیل QoS 2 برای همهٔ موضوع‌ها یکی از رایج‌ترین خطاهای پیاده‌سازی است.

MQTT در برابر CoAP و HTTP

CoAP

CoAP در RFC 7252 تعریف شده، روی UDP کار می‌کند و سرآیند ثابت ۴ بایتی دارد؛ مدلش درخواست/پاسخ و امنیتش بر پایهٔ DTLS است. برای دستگاه‌های بسیار کم‌توان و شبکه‌های مش مانند 6LoWPAN گزینهٔ خوبی است. ضعف‌ها: نبود بروکر مرکزی، دشواری عبور از NAT برای فرمان‌های سمت سرور.

HTTP/REST

ساده و برای هر تیم نرم‌افزاری قابل دیباگ است، اما سربار بالا، نبود push بلادرنگ و هزینهٔ برقراری اتصال در هر تراکنش آن را برای دستگاه‌های باتری‌محور نامناسب می‌کند. برای ارسال روزی چند نوبت داده یا یکپارچه‌سازی سرور به سرور همچنان انتخاب درستی است.

کدام را انتخاب کنیم؟

• ارسال مکرر همراه با فرمان دوطرفه: MQTT.
• دستگاه کم‌مصرف روی شبکهٔ مش با منابع بسیار محدود: CoAP.
• گزارش کم‌تکرار یا اتصال سامانه‌های سازمانی: HTTP/REST.
• شبکه‌های بدون IP مانند LoRaWAN: MQTT از سرور شبکه به بالا به کار می‌رود، نه روی خود گره.

معیار عملی: اگر نسبت حجم دادهٔ مفید به سرآیند زیر ده باشد، سربار پروتکل خودش به مسئله تبدیل شده است.

آنچه MQTT 5.0 اضافه کرد

نام مستعار موضوع (topic alias) رشته‌های بلند را با یک عدد کوتاه جایگزین می‌کند، اشتراک مشترک (shared subscription) بار را میان چند مصرف‌کننده توزیع می‌کند. اگر بروکر و کتابخانهٔ سمت دستگاه پشتیبانی می‌کنند، مهاجرت به ۵.۰ می‌ارزد.

پلتفرم روشنا هم‌زمان MQTT، CoAP و HTTP را برای اتصال دستگاه می‌پذیرد، پس لازم نیست کل ناوگان با یک پروتکل حرف بزند؛ داده پس از دریافت وارد موتور قواعد و پایگاه‌دادهٔ سری‌زمانی می‌شود. جزئیات معماری در صفحهٔ پلتفرم آمده، نمونهٔ کاربرد را در کنتورخوانی هوشمند ببینید و برای بررسی عملی درخواست دمو بدهید.