MQTT، CoAP یا HTTP؟ مقایسه پروتکل‌های کاربردی اینترنت اشیا

نقشه کلی پروتکل‌ها

قبل از مقایسه باید لایه‌ها را جدا کرد. MQTT و CoAP پروتکل‌های کاربردی برای تبادل داده‌اند؛ HTTP نیز پروتکل وب با مدل درخواست/پاسخ است. LoRaWAN، Wi‑Fi، Ethernet و شبکه سلولی در لایه اتصال قرار می‌گیرند. پس می‌توان حسگر را از طریق یک شبکه محلی به gateway رساند و gateway داده را با MQTT به broker بفرستد؛ این انتخاب‌ها رقیب مستقیم هم نیستند.

MQTT چگونه کار می‌کند؟

MQTT مدل publish/subscribe و یک broker مرکزی دارد. دستگاه روی topic پیام منتشر می‌کند و مصرف‌کنندگان topicهای مورد نیاز را subscribe می‌کنند. فرستنده لازم نیست آدرس مستقیم همه مصرف‌کنندگان را بداند؛ این جداسازی برای داشبورد، هشدار و ذخیره‌سازی هم‌زمان مفید است. MQTT 5.0 بر یک انتقال مرتب و قابل‌اعتماد تکیه دارد؛ TCP رایج‌ترین بستر است و می‌توان TLS را برای محرمانگی و احراز هویت به‌کار برد. در QoS 0 پیام بدون تأیید و حداکثر یک بار می‌رسد؛ QoS 1 با تأیید، تحویل حداقل یک بار را هدف می‌گیرد و ممکن است پیام تکراری دیده شود؛ QoS 2 جریان دست‌دهی بیشتری دارد تا تحویل پروتکلی دقیق‌تری فراهم کند، اما سربار و وضعیت بیشتری می‌خواهد. این QoS به معنای «اجرای دقیقاً یک‌بار پمپ» نیست: مصرف‌کننده باید شناسه پیام، ذخیره‌سازی پایدار و عملیات idempotent داشته باشد.

ویژگی‌های مهم دیگر MQTT شامل پیام retained برای آخرین وضعیت شناخته‌شده، نشست پایدار/منقضی‌شونده، پیام Will در قطع غیرمنتظره، سطح QoS اشتراک و کنترل جریان است. تنظیم نادرست retained ممکن است وضعیت قدیمیِ فرمان را هنگام اتصال دستگاه جدید دوباره نشان دهد؛ برای topicهای کنترل، تفکیک command از state و تعیین expiry اهمیت دارد. broker نیز نقطه تمرکز دسترسی و امنیت می‌شود و باید TLS، احراز هویت، ACL موضوعی، محدودیت اتصال و ثبت رخدادها پیکربندی شود.

CoAP چه زمانی مناسب‌تر است؟

CoAP برای دستگاه‌های محدود طراحی شده و مدل REST شبیه وب دارد: کلاینت منبعی مانند /soil/moisture را GET می‌کند یا با PUT/POST آن را تغییر می‌دهد. در شکل رایج، پیام‌ها روی UDP هستند و قالب فشرده، Confirmable/Non-confirmable، تأیید، بازفرست و کنترل ازدحام در خود پروتکل وجود دارد. Confirmable می‌گوید گیرنده پیام را در سطح CoAP دریافت کرده، نه اینکه کار فیزیکی قطعی شده است. CoAP از مشاهده منبع (Observe)، کش، proxy و multicast نیز پشتیبانی می‌کند؛ این‌ها می‌توانند برای خواندن دوره‌ای وضعیت چند گره مناسب باشند.

در مسیر UDP، DTLS یا سازوکارهای مناسب دیگر باید امنیت را فراهم کنند؛ انتخاب امنیت را به «شبکه داخلی است» موکول نکنید. بعضی شبکه‌ها UDP را محدود می‌کنند. RFC 8323 انتقال CoAP روی TCP، TLS و WebSocket را هم تعریف می‌کند؛ این راه‌ها عبور از شبکه‌های محدودکننده را ساده‌تر می‌کنند، اما اتصال و سربار متفاوتی دارند.

HTTP ساده‌ترین انتخاب

برای بسیاری از APIهای وب و اتصال به سرویس‌های موجود است: درخواست GET/POST، ابزارها و proxyهای فراوان و فهم آسان برای تیم وب. ولی سربار سرآیندها و رفتار اتصال می‌تواند برای ارسال مکررِ payloadهای کوچک از یک میکروکنترلر محدود نامتناسب باشد. فشرده‌سازی، HTTP/2 یا اتصال ماندگار بخشی از مسئله را تغییر می‌دهد؛ بنابراین مقایسه باید روی نسخه و پشته واقعی انجام شود، نه فقط نام پروتکل.

مقایسه تصمیم‌محور

• الگوی تبادل: MQTT انتشار/اشتراک با broker؛ CoAP درخواست/پاسخ REST و امکان Observe؛ HTTP درخواست/پاسخ متعارف وب.

• انتقال متداول: MQTT روی TCP/TLS؛ CoAP غالباً روی UDP/DTLS، و طبق RFC 8323 همچنین روی TCP/TLS/WebSocket؛ HTTP روی TCP/TLS و نسخه‌های وب مربوط.

• سربار: CoAP برای پیام‌های کوچک دستگاه محدود بهینه شده است؛ MQTT سربار کاربردی کم و وابسته به topic و QoS دارد اما اتصال و state broker هم هزینه دارند؛ HTTP ابزارپذیر و آشناست اما سرآیندهایش برای payloadهای خیلی کوچک می‌تواند زیاد باشد. سربار واقعی را با payload و پیاده‌سازی اندازه بگیرید.

• پایداری اتصال: MQTT با session و broker برای fan-out و reconnect مناسب است؛ CoAP با تأیید پیام و Observe برای تبادل منبعی محدود کارآمد است؛ HTTP با retry برنامه و صف محلی دستگاه می‌تواند پایدار شود ولی باید تکرار POST و idempotency کنترل شود.

• مصرف‌کنندگان متعدد: MQTT با یک publish می‌تواند به چند مشترک توزیع کند؛ CoAP معمولاً کلاینت-سرور است و multicast در شرایط کنترل‌شده ممکن است؛ HTTP برای هر سرویس درخواست جداگانه یا لایه واسط لازم دارد.

مثال ساده در مزرعه

یک نود دما را با شناسه سنسور، زمان اندازه‌گیری، مقدار، واحد، کیفیت و شماره ترتیبی بسته‌بندی می‌کند. اگر gateway باید داده را هم‌زمان برای داشبورد، هشدار و آرشیو بفرستد، MQTT غالباً انتخاب عملی است: topicها را مانند farm/12/zone/3/soil تعریف کنید و ACL را طوری محدود سازید که حسگر فقط در مسیر خودش publish کند. اگر gateway مستقیماً منابع کوچک دستگاه‌ها را می‌خواند و درخواست سبک لازم است، CoAP را بررسی کنید. اگر دستگاه فقط هر چند ساعت یک‌بار یک گزارش را به API موجود می‌فرستد و backend حاضر است، HTTP ممکن است هزینه توسعه کمتری داشته باشد. معماری ترکیبی رایج است: CoAP در سمت دستگاه و MQTT یا HTTP در gateway و backend؛ translation باید زمان، شناسه، کیفیت و معنای خطا را حفظ کند.

روش آزمون پیش از انتخاب

۱. سناریوی واقعی را بازسازی کنید: اندازه فریم، تعداد گره، نرخ گزارش، کیفیت رادیو، مدت قطع شبکه و تعداد مصرف‌کننده. ۲. مصرف RAM/flash، زمان اتصال مجدد، حجم handshake و انرژی را روی سخت‌افزار خودتان اندازه بگیرید. ۳. قطع برق هنگام ارسال، پیام تکراری، broker unavailable، پاسخ دیررس و ساعت نادرست را آزمایش کنید. ۴. برای داده‌های ماندگار، صف پایدار محلی و سیاست حذف/ارسال مجدد را تعریف کنید؛ هرگز فرض نکنید QoS یا HTTP 200 به معنی ثبت پایدار در سامانه کسب‌وکار است. ۵. TLS/DTLS، گواهی یا کلید، rotation، pinning در صورت نیاز، ACL و به‌روزرسانی firmware را جزو طراحی قرار دهید. ۶. برای فرمان شیر، درخواست باید شناسه یکتا، زمان انقضا، مقدار هدف و وضعیت پاسخ داشته باشد؛ رسیدن پیام با اجرای واقعی عملگر یکی نیست.

نتیجه‌گیری

برای جریان رویداد از تعداد زیادی دستگاه به چند مصرف‌کننده، MQTT معمولاً گزینه پیش‌فرض خوبی است، به‌خصوص وقتی broker و مدیریت دسترسی قابل اتکا دارید. برای دستگاه‌های محدود و تعامل منبع‌محور با نیاز به پیام‌های کوچک، CoAP را ارزیابی کنید و محدودیت عبور UDP از شبکه را بسنجید. برای اتصال مستقیم به API وب و تیمی که HTTP را نگهداری می‌کند، HTTP ساده و قابل‌فهم است؛ حجم تبادل و reconnect را اندازه بگیرید. راه درست یک برنده ثابت ندارد: معیار باید هزینه کل چرخه عمر، الزامات latency، قابلیت observability، امنیت و تجربه تیم باشد.

منابع استاندارد

OASIS، MQTT Version 5.0: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html IETF RFC 7252، CoAP: https://www.rfc-editor.org/rfc/rfc7252.html IETF RFC 8323، CoAP over TCP/TLS/WebSockets: https://www.rfc-editor.org/rfc/rfc8323.html