اینترنت اشیا، مه و ابرها: بیایید در مورد فناوری صحبت کنیم؟

توسعه فناوری ها در زمینه نرم افزار و سخت افزار، ظهور پروتکل های ارتباطی جدید منجر به گسترش اینترنت اشیا (IoT) شده است. تعداد دستگاه ها روز به روز در حال افزایش است و حجم عظیمی از داده ها را تولید می کنند. بنابراین، نیاز به یک معماری سیستمی مناسب با قابلیت پردازش، ذخیره و انتقال این داده ها وجود دارد.

اکنون از خدمات ابری برای این اهداف استفاده می شود. با این حال، پارادایم محاسباتی مه (Fog) که به طور فزاینده ای محبوب می شود، می تواند راه حل های ابری را با مقیاس بندی و بهینه سازی زیرساخت اینترنت اشیا تکمیل کند.

ابرها قادر به پوشش بیشتر درخواست های اینترنت اشیا هستند. به عنوان مثال، برای ارائه نظارت بر خدمات، پردازش سریع هر مقدار از داده های تولید شده توسط دستگاه ها و همچنین تجسم آنها. محاسبات مه هنگام حل مسائل بلادرنگ موثرتر است. آنها پاسخ سریع به درخواست ها و حداقل تاخیر در پردازش داده ها را ارائه می دهند. یعنی Fog "ابرها" را تکمیل می کند و قابلیت های آن را گسترش می دهد.

با این حال، سوال اصلی متفاوت است: چگونه باید همه اینها در زمینه اینترنت اشیاء تعامل داشته باشند؟ چه پروتکل های ارتباطی هنگام کار در یک سیستم ترکیبی IoT-Fog-Cloud موثرتر خواهند بود؟

با وجود تسلط آشکار HTTP، تعداد زیادی راه حل دیگر در سیستم های IoT، Fog و Cloud استفاده می شود. این به این دلیل است که اینترنت اشیا باید عملکرد انواع سنسورهای دستگاه را با امنیت، سازگاری و سایر الزامات کاربران ترکیب کند.

اما به سادگی هیچ ایده واحدی در مورد معماری مرجع و استاندارد ارتباطات وجود ندارد. بنابراین، ایجاد یک پروتکل جدید یا اصلاح یک پروتکل موجود برای وظایف خاص اینترنت اشیا یکی از مهمترین وظایف جامعه فناوری اطلاعات است.

چه پروتکل هایی در حال حاضر در حال استفاده هستند و چه چیزی می توانند ارائه دهند؟ بیایید آن را بفهمیم. اما ابتدا، بیایید اصول اکوسیستمی را که در آن ابرها، مه و اینترنت اشیا با هم تعامل دارند، بحث کنیم.

معماری IoT Fog-to-Cloud (F2C).

احتمالاً متوجه شده اید که چقدر تلاش برای کشف مزایا و مزایای مرتبط با مدیریت هوشمند و هماهنگ اینترنت اشیا، ابر و مه انجام می شود. اگر نه، در اینجا سه ​​طرح استانداردسازی وجود دارد: کنسرسیوم OpenFog, کنسرسیوم محاسبات لبه и پروژه mF2C H2020 اتحادیه اروپا.

اگر قبلاً فقط 2 سطح در نظر گرفته می شد، ابرها و دستگاه های پایانی، پس معماری پیشنهادی سطح جدیدی را معرفی می کند - محاسبات مه. در این حالت، سطح مه را می توان به چند سطح فرعی تقسیم کرد، بسته به ویژگی های منابع یا مجموعه ای از سیاست ها که تعیین کننده استفاده از دستگاه های مختلف در این سطوح فرعی است.

این انتزاع چه شکلی می تواند داشته باشد؟ در اینجا یک اکوسیستم معمولی IoT-Fog-Cloud وجود دارد. دستگاه‌های اینترنت اشیا داده‌ها را به سرورها و دستگاه‌های محاسباتی سریع‌تر ارسال می‌کنند تا مشکلاتی را که به تأخیر کم نیاز دارند، حل کنند. در همین سیستم، ابرها مسئول حل مشکلاتی هستند که به مقدار زیادی منابع محاسباتی یا فضای ذخیره سازی داده نیاز دارند.

گوشی‌های هوشمند، ساعت‌های هوشمند و سایر ابزارها نیز می‌توانند بخشی از اینترنت اشیا باشند. اما چنین دستگاه هایی، به عنوان یک قاعده، از پروتکل های ارتباطی اختصاصی توسعه دهندگان بزرگ استفاده می کنند. داده های IoT تولید شده از طریق پروتکل REST HTTP به لایه مه منتقل می شود که انعطاف پذیری و قابلیت همکاری را هنگام ایجاد سرویس های RESTful فراهم می کند. این امر با توجه به نیاز به اطمینان از سازگاری با زیرساخت های محاسباتی موجود در رایانه های محلی، سرورها یا یک خوشه سرور مهم است. منابع محلی که «گره های مه» نامیده می شوند، داده های دریافتی را فیلتر کرده و به صورت محلی پردازش می کنند یا برای محاسبات بیشتر به ابر ارسال می کنند.

ابرها از پروتکل های ارتباطی مختلفی پشتیبانی می کنند که رایج ترین آنها AMQP و REST HTTP است. از آنجایی که HTTP به خوبی شناخته شده و برای اینترنت طراحی شده است، ممکن است این سوال پیش بیاید: "آیا نباید از آن برای کار با اینترنت اشیا و مه استفاده کنیم؟" با این حال، این پروتکل مشکلات عملکردی دارد. بیشتر در این مورد بعدا.

به طور کلی 2 مدل از پروتکل های ارتباطی مناسب برای سیستم مورد نیاز ما وجود دارد. اینها درخواست-پاسخ و انتشار-اشتراک هستند. مدل اول بیشتر در معماری سرور-کلینت شناخته شده است. مشتری اطلاعاتی را از سرور درخواست می کند و سرور درخواست را دریافت می کند، آن را پردازش می کند و یک پیام پاسخ را برمی گرداند. پروتکل های REST HTTP و CoAP بر روی این مدل عمل می کنند.

مدل دوم از نیاز به ارائه جفت ناهمزمان، توزیع شده، سست بین منابع تولید کننده داده و گیرندگان این داده ها ناشی شد.

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

اساساً این معماری مبتنی بر رویداد است. و این مدل تعامل به دلیل توانایی آن در ارائه مقیاس پذیری و ساده سازی اتصال بین دستگاه های مختلف، پشتیبانی از ارتباطات پویا چند به چند و ارتباطات ناهمزمان برای برنامه های کاربردی در اینترنت اشیا، ابر، مه جالب است. برخی از شناخته شده ترین پروتکل های پیام رسانی استاندارد شده که از مدل انتشار-اشتراک استفاده می کنند عبارتند از MQTT، AMQP و DDS.

بدیهی است که مدل انتشار-اشتراک مزایای زیادی دارد:

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

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

همچنین پروتکل هایی وجود دارند که از هر دو مدل پشتیبانی می کنند. به عنوان مثال، XMPP و HTTP 2.0 که از گزینه “server push” پشتیبانی می کنند. IETF همچنین یک CoAP منتشر کرده است. در تلاش برای حل مشکل پیام رسانی، چندین راه حل دیگر مانند پروتکل WebSockets یا استفاده از پروتکل HTTP بر روی QUIC (اتصالات اینترنت سریع UDP) ایجاد شده است.

در مورد WebSockets، اگرچه برای انتقال داده‌ها در زمان واقعی از یک سرور به یک سرویس گیرنده وب استفاده می‌شود و اتصالات دائمی را با ارتباطات دو طرفه همزمان فراهم می‌کند، اما برای دستگاه‌هایی با منابع محاسباتی محدود در نظر گرفته نشده است. QUIC نیز سزاوار توجه است، زیرا پروتکل حمل و نقل جدید فرصت های جدید زیادی را فراهم می کند. اما از آنجایی که QUIC هنوز استاندارد نشده است، پیش‌بینی کاربرد احتمالی و تأثیر آن بر راه‌حل‌های اینترنت اشیا زود است. بنابراین ما WebSockets و QUIC را با چشم‌اندازی به آینده در ذهن داریم، اما فعلاً آن را با جزئیات بیشتر مطالعه نمی‌کنیم.

چه کسی زیباترین در جهان است: مقایسه پروتکل ها

حال اجازه دهید در مورد نقاط قوت و ضعف پروتکل ها صحبت کنیم. با نگاهی به آینده، اجازه دهید فوراً قید کنیم که هیچ رهبر مشخصی وجود ندارد. هر پروتکل مزایا و معایبی دارد.

زمان پاسخگویی

یکی از مهم ترین ویژگی های پروتکل های ارتباطی، به ویژه در رابطه با اینترنت اشیا، زمان پاسخگویی است. اما در میان پروتکل‌های موجود، برنده مشخصی وجود ندارد که حداقل سطح تأخیر را هنگام کار در شرایط مختلف نشان دهد. اما یک دسته کامل از تحقیقات و مقایسه قابلیت های پروتکل وجود دارد.

برای مثال، یافته ها مقایسه اثربخشی HTTP و MQTT هنگام کار با IoT نشان داد که زمان پاسخگویی برای درخواست‌های MQTT کمتر از HTTP است. و وقتی که در حال مطالعه زمان رفت و برگشت (RTT) MQTT و CoAP نشان داد که میانگین RTT CoAP 20٪ کمتر از MQTT است.

دیگر یک آزمایش با RTT برای پروتکل های MQTT و CoAP در دو سناریو انجام شد: شبکه محلی و شبکه IoT. مشخص شد که میانگین RTT در یک شبکه IoT 2-3 برابر بیشتر است. MQTT با QoS0 در مقایسه با CoAP نتیجه کمتری نشان داد و MQTT با QoS1 به دلیل ACK ها در لایه های کاربردی و انتقال، RTT بالاتری را نشان داد. برای سطوح مختلف QoS، تأخیر شبکه بدون تراکم برای MQTT میلی‌ثانیه و برای CoAP صدها میکروثانیه بود. با این حال، شایان ذکر است که هنگام کار بر روی شبکه های کمتر قابل اعتماد، MQTT که در بالای TCP اجرا می شود، نتیجه کاملا متفاوتی را نشان می دهد.

مقایسه زمان پاسخ برای پروتکل های AMQP و MQTT با افزایش بار بار نشان داد که با یک بار سبک، سطح تاخیر تقریباً یکسان است. اما هنگام انتقال مقادیر زیاد داده، MQTT زمان پاسخ کوتاه‌تری را نشان می‌دهد. در یکی دیگر تحقیق CoAP در سناریوی ارتباطی ماشین به ماشین با HTTP با دستگاه‌های مستقر در بالای وسایل نقلیه مجهز به حسگرهای گاز، سنسورهای آب و هوا، سنسورهای مکان (GPS) و رابط شبکه تلفن همراه (GPRS) مقایسه شد. زمان لازم برای انتقال یک پیام CoAP از طریق شبکه تلفن همراه تقریباً سه برابر کمتر از زمان لازم برای استفاده از پیام های HTTP بود.

مطالعاتی انجام شده است که نه دو، بلکه سه پروتکل را مقایسه کردند. مثلا، مقایسه عملکرد پروتکل های IoT MQTT، DDS و CoAP در یک سناریوی کاربردی پزشکی با استفاده از شبیه ساز شبکه. DDS از نظر تأخیر تله متری آزمایش شده تحت انواع شرایط شبکه ضعیف بهتر از MQTT عمل کرد. CoAP مبتنی بر UDP برای برنامه‌هایی که نیاز به زمان پاسخ سریع داشتند، به خوبی کار می‌کرد، با این حال، به دلیل اینکه مبتنی بر UDP بود، از دست دادن بسته‌های غیرقابل پیش‌بینی قابل‌توجهی وجود داشت.

توان

مقایسه MQTT و CoAP از نظر کارایی پهنای باند به عنوان محاسبه مقدار کل داده ارسال شده در هر پیام انجام شد. CoAP در هنگام ارسال پیام های کوچک توان عملیاتی کمتری نسبت به MQTT نشان داده است. اما هنگام مقایسه کارایی پروتکل ها از نظر نسبت تعداد بایت های اطلاعات مفید به تعداد کل بایت های منتقل شده، CoAP موثرتر بود.

در تحلیل و بررسی با استفاده از MQTT، DDS (با TCP به عنوان پروتکل انتقال) و پهنای باند CoAP، مشخص شد که CoAP به طور کلی مصرف پهنای باند نسبتاً کمتری را نشان می دهد، که با افزایش از دست دادن بسته های شبکه یا افزایش تأخیر شبکه افزایش نمی یابد، بر خلاف MQTT و DDS، که در آنها وجود داشت. افزایش استفاده از پهنای باند در سناریوهای ذکر شده. سناریوی دیگر شامل تعداد زیادی دستگاه است که داده ها را به طور همزمان منتقل می کنند، که در محیط های اینترنت اشیا معمول است. نتایج نشان داد که برای استفاده بیشتر بهتر است از CoAP استفاده شود.

تحت بار سبک، CoAP از کمترین پهنای باند استفاده کرد و پس از آن MQTT و REST HTTP قرار گرفتند. با این حال، زمانی که اندازه بارها افزایش یافت، REST HTTP بهترین نتایج را داشت.

مصرف برق

موضوع مصرف انرژی همیشه و به ویژه در یک سیستم اینترنت اشیا از اهمیت بالایی برخوردار است. اگر مقایسه کنید در حالی که MQTT و HTTP برق مصرف می کنند، HTTP بسیار بیشتر مصرف می کند. و CoAP بیشتر است انرژی کارآمد در مقایسه با MQTT، امکان مدیریت توان را فراهم می کند. با این حال، در سناریوهای ساده، MQTT برای تبادل اطلاعات در شبکه‌های اینترنت اشیاء مناسب‌تر است، به‌ویژه اگر محدودیت برق وجود نداشته باشد.

دیگر آزمایشی که قابلیت‌های AMQP و MQTT را روی یک بستر آزمایشی شبکه بی‌سیم تلفن همراه یا ناپایدار مقایسه کرد، نشان داد که AMQP قابلیت‌های امنیتی بیشتری ارائه می‌کند در حالی که MQTT کارآمدتر انرژی است.

امنیت

امنیت یکی دیگر از مسائل مهمی است که هنگام مطالعه مبحث اینترنت اشیا و محاسبات مه/ابر مطرح می شود. مکانیسم امنیتی معمولاً بر اساس TLS در HTTP، MQTT، AMQP و XMPP یا DTLS در CoAP است و از هر دو نوع DDS پشتیبانی می‌کند.

TLS و DTLS با فرآیند برقراری ارتباط بین طرف مشتری و سرور برای تبادل مجموعه‌ها و کلیدهای رمز پشتیبانی شده شروع می‌شوند. هر دو طرف برای اطمینان از اینکه ارتباطات بیشتر در یک کانال امن اتفاق می‌افتد، درباره مجموعه‌هایی مذاکره می‌کنند. تفاوت بین این دو در تغییرات کوچکی نهفته است که به DTLS مبتنی بر UDP اجازه می دهد روی یک اتصال غیرقابل اعتماد کار کند.

در حملات آزمایشی چندین پیاده سازی مختلف از TLS و DTLS دریافتند که TLS کار بهتری انجام می دهد. حملات به DTLS به دلیل تحمل خطا موفقیت آمیزتر بود.

با این حال، بزرگترین مشکل این پروتکل ها این است که آنها در اصل برای استفاده در اینترنت اشیا طراحی نشده بودند و قرار نبودند در مه یا ابر کار کنند. از طریق دست دادن، آنها ترافیک اضافی را با هر برقراری اتصال اضافه می کنند که منابع محاسباتی را تخلیه می کند. به طور متوسط، افزایش 6,5٪ برای TLS و 11٪ برای DTLS در سربار در مقایسه با ارتباطات بدون لایه امنیتی وجود دارد. در محیط های غنی از منابع، که معمولاً در ابری سطح، این مشکلی نخواهد بود، اما در ارتباط بین IoT و سطح مه، این به یک محدودیت مهم تبدیل می شود.

چه چیزی را انتخاب کنیم؟ پاسخ روشنی وجود ندارد. به نظر می‌رسد MQTT و HTTP امیدوارکننده‌ترین پروتکل‌ها باشند، زیرا در مقایسه با سایر پروتکل‌ها، راه‌حل‌های نسبتاً بالغ‌تر و پایدارتر IoT در نظر گرفته می‌شوند.

راه حل های مبتنی بر یک پروتکل ارتباطی یکپارچه

تمرین راه حل تک پروتکلی دارای معایب بسیاری است. به عنوان مثال، پروتکلی که مناسب یک محیط محدود است ممکن است در دامنه ای که الزامات امنیتی سختی دارد کار نکند. با در نظر گرفتن این موضوع، ما باید تقریباً تمام راه‌حل‌های تک پروتکل ممکن را در اکوسیستم Fog-to-Cloud در اینترنت اشیا، به جز MQTT و REST HTTP کنار بگذاریم.

REST HTTP به عنوان یک راه حل تک پروتکل

مثال خوبی از نحوه تعامل درخواست‌ها و پاسخ‌های HTTP REST در فضای IoT-to-Fog وجود دارد: مزرعه هوشمند. این حیوانات به حسگرهای پوشیدنی (کلینت IoT، C) مجهز شده و از طریق محاسبات ابری توسط یک سیستم کشاورزی هوشمند (Fog Server، S) کنترل می شوند.

هدر متد POST منبعی را برای اصلاح (/farm/animals) و همچنین نسخه HTTP و نوع محتوا را مشخص می کند که در این مورد یک شی JSON است که نشان دهنده مزرعه حیواناتی است که سیستم باید مدیریت کند (Dulcinea/cow) . پاسخ سرور نشان می دهد که درخواست با ارسال کد وضعیت HTTPS 201 (منبع ایجاد شده) موفقیت آمیز بوده است. متد GET باید فقط منبع درخواستی را در URI مشخص کند (به عنوان مثال، /farm/animals/1)، که یک نمایش JSON از حیوان با آن شناسه را از سرور برمی‌گرداند.

روش PUT زمانی استفاده می شود که برخی رکوردهای منابع خاص نیاز به به روز رسانی داشته باشند. در این مورد، منبع URI پارامتری که باید تغییر کند و مقدار فعلی را مشخص می کند (به عنوان مثال، نشان می دهد که گاو در حال راه رفتن است، /farm/animals/1؟ state=walking). در نهایت، روش DELETE به همان اندازه روش GET استفاده می شود، اما به سادگی منبع را در نتیجه عملیات حذف می کند.

MQTT به عنوان یک راه حل تک پروتکل

بیایید همان مزرعه هوشمند را در نظر بگیریم، اما به جای REST HTTP از پروتکل MQTT استفاده می کنیم. یک سرور محلی با کتابخانه Mosquitto نصب شده به عنوان یک کارگزار عمل می کند. در این مثال، یک کامپیوتر ساده (که به آن سرور مزرعه می گویند) Raspberry Pi به عنوان یک کلاینت MQTT عمل می کند که از طریق نصب کتابخانه Paho MQTT که کاملاً با کارگزار Mosquitto سازگار است، پیاده سازی شده است.

این کلاینت مربوط به یک لایه انتزاعی اینترنت اشیا است که نشان دهنده دستگاهی با قابلیت های سنجش و محاسبات است. از سوی دیگر، واسطه با سطح بالاتری از انتزاع مطابقت دارد، که نشان دهنده یک گره محاسباتی مه است که با ظرفیت پردازش و ذخیره سازی بیشتر مشخص می شود.

در سناریوی مزرعه هوشمند پیشنهادی، Raspberry Pi به شتاب‌سنج، GPS و سنسورهای دما متصل می‌شود و داده‌های این سنسورها را در یک گره مه منتشر می‌کند. همانطور که احتمالا می دانید، MQTT با موضوعات به عنوان یک سلسله مراتب برخورد می کند. یک ناشر MQTT می تواند پیام هایی را برای مجموعه ای خاص از موضوعات منتشر کند. در مورد ما سه مورد از آنها وجود دارد. برای سنسوری که دما را در انبار حیوانات اندازه گیری می کند، مشتری موضوعی را انتخاب می کند (مزرعه حیوانات / سوله / دما). برای حسگرهایی که موقعیت GPS و حرکت حیوانات را از طریق شتاب‌سنج اندازه‌گیری می‌کنند، مشتری به‌روزرسانی‌هایی را برای (مزرعه حیوانات/حیوان/GPS) و (مزرعه حیوانات/حیوانات/حرکت) منتشر می‌کند.

این اطلاعات به کارگزار منتقل می‌شود، که می‌تواند به‌طور موقت آن‌ها را در یک پایگاه داده محلی ذخیره کند تا درصورتی‌که بعداً مشترک علاقه‌مند دیگری بیاید.

علاوه بر سرور محلی، که به عنوان یک کارگزار MQTT در مه عمل می کند و Raspberry Pis، به عنوان مشتریان MQTT، داده های حسگر را به آن ارسال می کند، ممکن است کارگزار MQTT دیگری در سطح ابر وجود داشته باشد. در این مورد، اطلاعات ارسال شده به کارگزار محلی می تواند به طور موقت در یک پایگاه داده محلی ذخیره شود و/یا به ابر ارسال شود. کارگزار fog MQTT در این شرایط برای مرتبط کردن تمام داده ها با کارگزار ابری MQTT استفاده می شود. با این معماری، کاربر اپلیکیشن موبایل می تواند در هر دو کارگزار مشترک شود.

اگر اتصال به یکی از کارگزاران (مثلاً ابر) با شکست مواجه شود، کاربر نهایی اطلاعاتی را از دیگری دریافت می کند (مه). این ویژگی مشخصه سیستم‌های محاسباتی ترکیبی مه و ابر است. به طور پیش فرض، برنامه تلفن همراه را می توان طوری پیکربندی کرد که ابتدا به کارگزار fog MQTT متصل شود و در صورت عدم موفقیت، به کارگزار ابر MQTT متصل شود. این راه حل تنها یکی از راه حل های موجود در سیستم های IoT-F2C است.

راه حل های چند پروتکلی

راه حل های تک پروتکل به دلیل اجرای آسان تر آنها محبوب هستند. اما واضح است که در سیستم های IoT-F2C ترکیب پروتکل های مختلف منطقی است. ایده این است که پروتکل های مختلف می توانند در سطوح مختلف عمل کنند. به عنوان مثال، سه انتزاع را در نظر بگیرید: لایه های اینترنت اشیا، مه و محاسبات ابری. دستگاه‌های سطح اینترنت اشیا معمولاً محدود در نظر گرفته می‌شوند. برای این بررسی اجمالی، اجازه دهید سطوح اینترنت اشیا را به عنوان محدودترین، ابری با کمترین محدودیت، و محاسبات مه را به عنوان "جایی در وسط" در نظر بگیریم. سپس معلوم می شود که بین انتزاعات IoT و fog، راه حل های پروتکل فعلی شامل MQTT، CoAP و XMPP است. از طرفی بین مه و ابر، AMQP یکی از پروتکل های اصلی مورد استفاده به همراه REST HTTP است که به دلیل انعطاف پذیری بین لایه های IoT و fog نیز استفاده می شود.

مشکل اصلی در اینجا قابلیت همکاری پروتکل ها و سهولت انتقال پیام از یک پروتکل به پروتکل دیگر است. در حالت ایده آل، در آینده، معماری یک سیستم اینترنت اشیا با منابع ابری و مه، مستقل از پروتکل ارتباطی مورد استفاده خواهد بود و قابلیت همکاری خوب بین پروتکل های مختلف را تضمین می کند.

از آنجایی که در حال حاضر اینطور نیست، ترکیب پروتکل هایی که تفاوت قابل توجهی ندارند منطقی است. برای این منظور، یک راه حل بالقوه مبتنی بر ترکیبی از دو پروتکل است که از یک سبک معماری پیروی می کنند، REST HTTP و CoAP. راه حل پیشنهادی دیگر مبتنی بر ترکیبی از دو پروتکل است که ارتباطات انتشار-اشتراک را ارائه می دهد، MQTT و AMQP. استفاده از مفاهیم مشابه (هم از کارگزاران MQTT و هم AMQP، CoAP و HTTP از REST استفاده می‌کنند) اجرای این ترکیب‌ها را آسان‌تر می‌کند و به تلاش ادغام کمتری نیاز دارد.

شکل (الف) دو مدل مبتنی بر درخواست پاسخ، HTTP و CoAP و قرارگیری احتمالی آنها در راه حل IoT-F2C را نشان می دهد. از آنجایی که HTTP یکی از شناخته شده ترین و پذیرفته ترین پروتکل ها در شبکه های مدرن است، بعید است که به طور کامل با پروتکل های پیام رسانی دیگر جایگزین شود. در میان گره‌هایی که دستگاه‌های قدرتمندی را نشان می‌دهند که بین ابر و مه قرار دارند، REST HTTP یک راه‌حل هوشمند است.

از سوی دیگر، برای دستگاه‌هایی با منابع محاسباتی محدود که بین لایه‌های Fog و IoT ارتباط برقرار می‌کنند، استفاده از CoAP کارآمدتر است. یکی از مزایای بزرگ CoAP در واقع سازگاری آن با HTTP است، زیرا هر دو پروتکل بر اساس اصول REST هستند.

شکل (ب) دو مدل ارتباطی انتشار-اشتراک را در یک سناریو نشان می‌دهد، از جمله MQTT و AMQP. اگرچه هر دو پروتکل به طور فرضی می توانند برای ارتباط بین گره ها در هر لایه انتزاعی استفاده شوند، موقعیت آنها باید بر اساس عملکرد تعیین شود. MQTT به عنوان یک پروتکل سبک وزن برای دستگاه هایی با منابع محاسباتی محدود طراحی شده است، بنابراین می توان از آن برای ارتباطات IoT-Fog استفاده کرد. AMQP برای دستگاه های قدرتمندتر مناسب تر است، که به طور ایده آل آن را بین گره های مه و ابر قرار می دهد. به جای MQTT، پروتکل XMPP را می توان در اینترنت اشیا استفاده کرد زیرا سبک وزن محسوب می شود. اما در چنین سناریوهایی چندان مورد استفاده قرار نمی گیرد.

یافته ها

بعید است که یکی از پروتکل های مورد بحث برای پوشش تمام ارتباطات در یک سیستم، از دستگاه هایی با منابع محاسباتی محدود گرفته تا سرورهای ابری، کافی باشد. این مطالعه نشان داد که دو گزینه امیدوارکننده که توسعه دهندگان بیشتر از آنها استفاده می کنند MQTT و RESTful HTTP هستند. این دو پروتکل نه تنها بالغ‌ترین و پایدارترین پروتکل‌ها هستند، بلکه شامل بسیاری از پیاده‌سازی‌های مستند و موفق و منابع آنلاین نیز می‌شوند.

به دلیل پایداری و پیکربندی ساده، MQTT پروتکلی است که عملکرد برتر خود را در طول زمان زمانی که در سطح اینترنت اشیا با دستگاه های محدود استفاده می شود ثابت کرده است. در بخش‌هایی از سیستم که ارتباط محدود و مصرف باتری مشکلی نیست، مانند برخی از حوزه‌های مه و بیشتر محاسبات ابری، RESTful HTTP انتخاب آسانی است. CoAP نیز باید در نظر گرفته شود زیرا به عنوان یک استاندارد پیام رسانی اینترنت اشیا نیز به سرعت در حال تکامل است و احتمالاً در آینده نزدیک به سطحی از ثبات و بلوغ مشابه MQTT و HTTP خواهد رسید. اما استاندارد در حال حاضر در حال تکامل است که با مشکلات سازگاری کوتاه مدت همراه است.

چه چیز دیگری می توانید در وبلاگ بخوانید؟ Cloud4Y

→ کامپیوتر شما را خوشمزه می کند
→ هوش مصنوعی به مطالعه حیوانات در آفریقا کمک می کند
→ تابستان تقریباً تمام شده است. تقریبا هیچ داده افشا نشده ای باقی نمانده است
→ 4 روش برای صرفه جویی در پشتیبان گیری ابری
→ در یک منبع اطلاعاتی یکپارچه فدرال حاوی اطلاعاتی در مورد جمعیت

مشترک ما شوید تلگرام-کانال، تا مقاله بعدی را از دست ندهید! ما بیش از دو بار در هفته نمی نویسیم و فقط به صورت تجاری.

منبع: www.habr.com