مقاله آشنایی با پروتکل MQTT

آشنایی با پروتکل MQTT

پروتکل MQTT یکی از رایج‌ترین پروتکل‌های مورد استفاده در پروژه‌های IoT و یک پروتکل لایه هفتی است. نام آن از اختصار عبارت Message Queuing Telemetry Transport گرفته شده است. علاوه بر این، MQTT بصورت یک پروتکل lightweight messaging طراحی شده که وظیفه Publish/ Subscribe را در انتقال دیتا مابین کلاینت‌ها و سرور انجام می‌دهد. علاوه بر موارد گفته شده، وجود ویژگی‌هایی همچون نمونه‌های ذیل،MQTT را تبدیل به پروتکلی مناسب و ایده‌آل در دنیای IoT کرده است:

•دارای سایز کوچک

•کم مصرف (توان کمی را از جهت اجرا شدن از سیستم مصرف می‌کند)

•Data packet های کوچک شده

•سهولت در پیاده‌سازی

همانطور که گفته شد، MQTT لایه هفتی است؛ بنابراین اگر دیوایس مورد نظر ما کامپیوتر، لپ‌تاپ و یا موبایل باشد، لایه اپلیکیشن معمولا توسط مرورگر پیاده‌سازی می‌شود اما اگر دیوایس مورد نظر، در دسته دیوایس‌های IoT باشد، لایه هفت ممکن است توسط سیستم عامل در حال اجرا و یا توسط یک firmware پیاده سازی شده باشد. در این مقاله اول به سراغ این خواهیم رفت که اصلا چرا از MQTT استفاده می‌کنیم و جایگاه آن را در دنیای واقعی IoT با مثال نشان خواهیم داد.

نکته: اگر با مفهوم IoT آشنایی لازم را ندارید، بهتر است پیش از ادامه، نسبت به این موضوع اقدام کرده و سپس مقاله را ادامه دهید.

چرا از MQTT استفاده می‌کنیم؟ MQTT

علت استفاده از MQTT بخاطر وجود ویژگی‌هایی در آن است که به ندرت می‌توانید بصورت یکجا آن‌ها را در پروتکل‌های دیگر پیدا کنید؛ ویژگی‌های نظیر:

MQTT به لحاظ عملکردی، پروتکلی سبُک یا اصطلاحا Lightweight است؛ براحتی روی ترم‌افزار پیاده شده و در انتقال دیتا چابُک است. MQTT بر مبنای تکنیک messaging طراحی شده است؛ به همین دلیل سرعت انتقالی را که در پیام‌رسان‌ها مانند تلگرام می‌بینید، می‌توانید از پروتکل MQTT هم انتظار داشته باشید. بسته‌های اطلاعاتی کوچک شده‌ای دارد؛ بنابراین از نظر مصرف پهنای باند شبکه، کم مصرف محسوب می‌شود. در استفاده از انرژی مصرف کمی دارد؛ در نتیجه میزان شارژ باطری دیوایس‌های کانکت شده را ذخیره می‌کند. MQTT به معنای واقعی کلمه، real time است! همین ویژگی، آن را بطور خاص برای اپلیکیشن‌های IoT منحصربفرد کرده است.

ساختار کاری MQTT

مثل پروتکل‌های اینترنتی دیگر، MQTT هم بر مبنای کلاینت/ سرور است. با این توضیح، سرور دیوایسی‌ست که به عنوان واسطه، مسئول پردازش درخواست‌ کلاینت‌ها است؛ این درخواست‌ها مابین کلاینت‌ها ردوبدل شده و می‌تواند ارسالی و یا دریافتی باشد. سرور MQTT را در اصطلاح broker گویند و کلاینت‌ها به تبع آن، دیوایس‌های متصل به broker خواهند بود. بر همین اساس: زمانی که یک دیوایس (کلاینت) قصد ارسال دیتا به سمت broker را دارد، این عمل یک "publish" نامیده خواهد شد. زمانی که یک دیوایس (کلاینت) قصد دریافت دیتا از سمت broker را دارد، این عمل یک "subscribe" نامیده خواهد شد.

در تکمیل موارد بالا، این کلاینت‌ها publishing و subscribing را روی " topic" ها انجام می‌دهند. در مورد "topic" نگران نباشید، در ادامه بیشتر متوجه ماهیت آن خواهید شد. مثال: در مثال زیر دیوایسی با یک سنسور دما (دماسنج) وجود دارد. طبق قاعده، این دیوایس سعی دارد تا اطلاعات ثبت شده خود از میزان دما را به broker انتقال دهد. در طرف دیگر، اپلیکیشن‌هایی داریم که منتظر دریافت اطلاعات دمایی هستند. با تجمیع اطاعات موجود در سناریو، دو اتفاق رخ خواهد داد: دیوایس، topic ای را که می‌خواهد بر روی آن publish را انجام دهد، تعریف می‌کند، مثلا "temp" . سپس پیام "temperature value" را پابلیش خواهد کرد. در طرف دیگر اپلیکیشن‌ها ابتدا topic (“temp”) را subscribe کرده و سپس پیغامی را که دیوایس پابلیش کرده است، دریافت خواهند کرد؛ محتوای این پیغام همان “temperature value” است. در این بین، نقش broker این خواهد بود که پیغام “temperature value” را از سمت دیوایس تحویل گرفته و به اپلیکیشن‌ها برساند.

MQTT Components

Broker، سروری‌ست که انتقال دیتا بین کلاینت‌ها را مدیریت‌ می‌کند. یک topic، بستری‌ست که یک دیوایس می‌خواهد پیامی را روی آن بگذارد یا از روی آن دریافت کند. Massage یا payload، دیتایی‌ست که یک دیوایس در موقع subscribing از یک topic دریافت کرده و یا موقع publishing روی یک topic ارسال می‌کند. Publish، عملی‌ست که یک دیوایس برای ارسال پیام به سمت broker انجام می‌دهد. Subscribe، عملی‌ست که یک دیوایس برای دریافت پیام از سمت broker، انجام می‌دهد.

Broker ظرفیت اتصال به چند دیوایس را دارد؟

تعداد کلاینت‌هایی که به broker متصل خواهند شد، بستگی به سرویس‌دهنده broker دارد. در حقیقت، broker می‌تواند بخودی خود حجم بالایی از کلاینت‌هایی که در حال publishing و subscribing هستند را در هر زمانی ساپورت کند. اما نکته قابل توجه در این‌جا، تنها تعداد بالایی دیوایس‌های کانکت شده نیست، بلکه این موضوع است که هر دیوایسی، با هر دیوایس دیگری در هرزمان خواهد توانست دیتا رد و بدل کند؛ در نتیجه، شاهد ظهور اپلیکیشن‌هایی زیادی هستیم که می‌توانند به این سرعت دیتا را به اشتراک بگذارند.

اما یه سوال هنوز ممکن است ذهن خواننده این مقاله را بخود مشغول کرده باشد و آن اینست که اساسا چرا از همان پروتکل http برای این کار استفاده نمی‌کنیم؟

چرا http نه؟

پروتکل http، کند، سنگین و مصرف انرژی بالایی در قیاس با MQTT دارد. اگر بخواهیم بصورت تفکیک شده بگوییم: کُند است: به علت آن‌که http از data packet های بزرگتری برای ارتباط با سرور استفاده می‌کند. بار پردازشی بالایی دارد: چون http request در هر درخواست خود، کانکشنی را باز کرده و متعاقبا خواهد بست، در حالی که MQTT به منظور باز بودن همیشگی کانال بین کلاینت‌ها و broker، همیشه آنلاین است. مصرف انرژی بالایی دارد: به علت آنکه پردازش http زمان بیشتری را بخود اختصاص می‌دهد و بسته‌های اطلاعاتی بیشتری به نسبت MQTT رد و بدل خواهد کرد، به تبع، انرژی بیشتری را مصرف می‌کند.

جایگاه broker در سیستم IoT

قبل از ادامه این بحث، بهتر است کمی در رابطه با IoT و کامپوننت‌های آن صحبت شود. همانطور که می‌دانید و شاید آن برای اولین بار با آن آشنا می‌شوید، IoT بر مبنای چهار مولفه یا کامپوننت زیر، اجرا می‌شود:

1.Devices هر دیوایس، با استفاده از یک یا چند سنسور، پارامترهای محیطی را شناسایی کرده و آن‌ها را بسمت cloud (پلت‌فرم) ارسال می‌کند.

2.Internet connectivity این مولفه مسئول برقراری ارتباط بین دیوایس‌ها با اینترنت است. از طریق این کامپوننت است که دیوایس‌ها می‌توانند بصورت آنلاین با پلت‌فرم ارتباط بگیرند. شبکه وای‌فای یکی از پرکاربردترین روش‌های برقراری ارتباط با اینترنت است. علاوه بر وای‌فای، اینترانت هم یکی از متدهای برقراری ارتباط است که امروز به ندرت از این روش استفاده می‌شود.

3.IoT Platform این بخش در کنار مهم بودن، کمی هم گیج‌کننده به نظر می‌رسد. بطور ساده، IoT platform یک نرم‌افزار است که بصورت آنلاین میزبانی (host) می‌شود. برای راحتی می‌توان این‌طور فرض کرد که پلت‌فرم شبکه‌ای است که تمام دیوایس‌ها به آن متصل هستند. هوش پلت‌فرم به اندازه‌ای است که بتواند دیتای مربوط به دیوایس‌ها را جمع‌آوری، آنالیز و پردازش کند و در نهایت بر اساس این دیتا تصمیم‌گیری کند. اساسا، یک IoT platform مسئول انجام موارد زیر است:

o همه دیوایس‌ها را به یک محدوده آنلاینِ مشخص شده، وصل کند. o دیتای رسیده از دیوایس‌ها را جمع‌آوری کند. o مانیتورینگ، ذخیره‌سازی، پردازش، آنالیز و محاسبه این دیتاها o تصمیم‌گیری بر اساس آستانه از پیش تعیین شده روی دیتای پردازش شده o کار با پروتکل‌های مختلف o یکپارچگی با اپلیکیشن‌ها (سرویس‌های آنلاین، اپلیکیشن‌های تحت وب، اپلیکیشن‌های موبایل و ...)

4.Applications اپلیکیشن‌ها در واقع واسطه‌ای هستند بین کاربر و پلت‌فرم؛ بنابراین هرگاه کاربر بخواهد دیوایسی را مانیتور، پیکربندی و یا کنترل کند، از طریق اپلیکیشن این کار را انجام خواهد داد.

اما برگردیم به بحث اصلی خودمان؛ جایگاه Broker در کجای سیستم IoT قرار دارد؟ همانطور که اشاره کردیم، یکی از کامپوننت‌های اصلی در IoT، پلت‌فرم بود که مسئولیت آن برقراری ارتباط دیوایس‌ها با یکدیگر است. بنابراین IoT platform یک نرم‌افزار تحت Cloud است که Broker و برخی نرم‌افزارهای دارای واسط گرافیکی بر روی آن پیاده‌سازی می‌شوند.

MQTT در کجا استفاده نمی‌شود؟

هر پروتکلی در کنار مزیت‌هایی که باعث استفاده از آن شده است، قطعا معایبی هم دارد؛ MQTT هم از این امر مستثنا نیست:

1.استفاده از این پروتکل در شبکه‌های محدود مثلا شبکه‌هایی با پهنای باند پایین، تاخیر زیاد، محدودیت دیتا و کانکشن‌های شکننده، مورد تقاضا است.

2.در صورتی که یک wireless sensor network داشته باشیم، که پشته TCP/IP را ساپورت نکند، متعاقبا MQTT هم مورد استفاده‌ای در این شبکه نخواهد داشت. در چنین سناریویی از MQTT-SN استفاده خواهد شد. MQTT-SN نسخه ویرایش شده‌ای از MQTT است که بطور خاص برای استفاده در wireless sensor network های با قدرت پایین که TCP/IP را نمی‌فهمند، طراحی شده است.

متدهای مورد استفاده در MQTT

همانطور که پروتکل http، برای مشخص کردن عمل مورد نظر خود بر روی مقصد متدهایی مانند POST,GET,PUT,DELETE و .. را دارد، پروتکل MQTT هم از این موضوع مستثنا نیست. متدهای مورد استفاده در MQTT عبارتند از:

•CONNECT

•CONNACK

•PUBLISH

•PUBACK

•PUBREC

•PUBCOMP

•SUBSCRIBE

•SUBACK

•UNSUBSCRIBE

•UNSUBACK

•PINGREQ

•PINGRESP

•DISCONNECT

منابع

1.MQTT Protocol_ How it Works 2.IoT: Understanding the Concepts 3.Understanding MQTT Protocol

مانا باشید احسان امجدی/ کارشناس ارشد و مدرس دوره‌های تحلیل امنیت ” اگر بر این باورید که با نقض قانون کپی‌رایت، وضعیتی بهتر در انتظار است، بدون ذکر نام نویسنده و منبع مجاز به انتشار متن هستید