پروتکل CoAP چیست؟

CoAP مخفف Constrained Application Protocol یک پروتکل کاربردی که IETF آن را برای دستگاه‌های اینترنت‌اشیا با منابع محدود طراحی کرده است. منظور از «محدودشده» دستگاه‌هایی است که پردازنده ضعیف، حافظه کم (چند کیلوبایت تا چند ده کیلوبایت) و منبع تغذیه باتری دارند. یک سنسور دما روی باتری سکه‌ای، یک کلید هوشمند بی‌سیم یا یک نشاندار محیطی در کشاورزی دقیق، نمونه‌هایی از این دسته‌اند.

CoAP مدل REST را پیاده می‌کند؛ همان افعال GET، POST، PUT و DELETE که در HTTP به‌کار می‌روند در CoAP نیز وجود دارند. تفاوت اصلی در لایه انتقال است. HTTP روی TCP اجرا می‌شود و هر اتصال چند مرحله Handshake دارد که برای دستگاه ضعیف پرهزینه است. CoAP روی UDP اجرا می‌شود و بدون نیاز به اتصال، مستقیم بسته می‌فرستد. هدر هر پیام CoAP فقط ۴ بایت است در حالی که هدر یک درخواست HTTP معمولی صدها بایت است.

این دو ویژگی (UDP و هدر کم‌حجم) باعث می‌شود CoAP برای دستگاه‌هایی که باید ماه‌ها یا سال‌ها روی یک باتری کار کنند، مناسب باشد. در عین حال، چون CoAP مدل REST را حفظ کرده، توسعه‌دهنده‌ای که با HTTP آشناست می‌تواند به‌سرعت با آن کار کند. این ترکیب سادگی و بهره‌وری، CoAP را به یکی از گزینه‌های اصلی ارتباطی در لایه کاربرد IoT تبدیل کرده است.

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

تاریخچه و استاندارد RFC7252؛ چرا IETF این پروتکل را طراحی کرد؟

کار روی CoAP در سال ۲۰۱۰ در IETF با تشکیل کارگروه CoRE یا (Constrained RESTful Environments) آغاز شد. هدف کارگروه، تعریف یک پروتکل کاربردی بود که بتواند روی شبکه‌های کم‌منبع مانند 6LoWPAN، شبکه‌های سنسور IEEE ۸۰۲.۱۵.۴ و لینک‌های با نرخ داده پایین کار کند. نسخه نهایی استاندارد در ژوئن ۲۰۱۴ با شماره RFC ۷۲۵۲ منتشر شد و از آن زمان به یک مرجع اصلی ارتباطات IoT در لایه کاربرد تبدیل گشت.

انگیزه اصلی IETF، این بود که HTTP برای دستگاه‌های اینترنت‌اشیا بیش از حد سنگین بود. یک درخواست HTTP ساده با هدرها و TCP Handshake می‌توانست چندین کیلوبایت ترافیک تولید کند؛ برای سنسوری که روی باتری سکه‌ای کار می‌کند و روی لینک ۲۵۰ کیلوبیت بر ثانیه داده می‌فرستد، این حجم به‌سرعت باتری را خالی می‌کرد. علاوه بر این، TCP با تاخیر و سربار اتصال، برای لینک‌های ناپایدار IoT مناسب نبود.

IETF راه‌حل را در طراحی پروتکلی دید که عناصر اصلی REST را حفظ کند اما روی UDP اجرا شود و خودش مکانیزم تایید دریافت را در لایه کاربرد پیاده کند. CoAP دقیقاً همین کار را انجام می‌دهد و مدل درخواست/پاسخ HTTP را با مکانیزم تایید قابل‌تنظیم در لایه پیام ترکیب می‌نماید. این طراحی، CoAP را در نقطه‌ای بین HTTP و پروتکل‌های باینری اختصاصی قرار می‌دهد.

پس از RFC ۷۲۵۲، چند سند مکمل نیز منتشر شد. RFC ۷۶۴۱ قابلیت مشاهده یا Observe را تعریف کرد، RFC ۷۹۵۹ انتقال بلوکی (Block-wise Transfer) برای داده‌های حجیم را اضافه نمود، و RFC ۸۳۲۳ حالت TCP و WebSockets را پشتیبانی کرد. این توسعه‌ها، CoAP را از یک پروتکل ساده سنسور به یک پلتفرم ارتباطی کامل ارتقا دادند.

یکی از تصمیمات طراحی مهم IETF، حفظ سازگاری مفهومی با HTTP بود. CoAP کدهای وضعیت مشابه HTTP دارد (مانند ۲.۰۵ معادل ۲۰۰، ۴.۰۴ معادل ۴۰۴، ۵.۰۰ معادل ۵۰۰) و از همان مفاهیم URI، Content-Format و Method بهره می‌برد. این تصمیم دو پیامد مثبت داشت: نخست، توسعه‌دهندگان وب می‌توانستند به‌سرعت CoAP را بیاموزند؛ دوم، پل‌های (Proxy) میان CoAP و HTTP به‌سادگی قابل پیاده‌سازی شدند. امروزه بسیاری از سرورهای IoT همزمان CoAP برای دستگاه‌های کم‌منبع و HTTP برای اپلیکیشن‌های وب را پشتیبانی می‌کنند.

جایگاه CoAP در لایه کاربرد مدل OSI و تفاوت آن با HTTP

در مدل OSI، CoAP در لایه ۷ (کاربرد) قرار دارد؛ همان لایه‌ای که HTTP، MQTT و FTP در آن هستند. این یعنی CoAP مستقیماً با برنامه کاربردی درگیر است و خودش را به نوع دستگاه محدود نمی‌کند. زیر CoAP، لایه انتقال (UDP) قرار دارد و زیر آن لایه شبکه (IP) و لایه فیزیک (اترنت، وای‌فای، IEEE ۸۰۲.۱۵.۴).

تفاوت اصلی CoAP با HTTP در سه محور است:

• نخست، پروتکل انتقال: HTTP روی TCP با اتصال پایدار، CoAP روی UDP بدون اتصال.
• دوم، حجم هدر: هدر HTTP حداقل چند صد بایت است (شامل User-Agent، Accept، Cookie و غیره) در حالی که هدر CoAP فقط ۴ بایت است.
• سوم، مدل تایید: HTTP به TCP متکی است برای تایید دریافت، CoAP خودش در لایه کاربرد تأیید را مدیریت می‌کند.

تفاوت دیگر در سربار اتصال است. هر اتصال TCP شامل سه‌مرحله Handshake یا (SYN، SYN-ACK، ACK) برای راه‌اندازی و چهار مرحله برای بسته‌شدن است. این هشت بسته اضافی برای هر درخواست، در دستگاه‌های ضعیف و لینک‌های کند، هزینه قابل‌توجهی دارد. CoAP این سربار را حذف می‌کند؛ یک درخواست GET می‌تواند در یک بسته UDP ارسال شود و پاسخ در یک بسته برگردد. این ویژگی، CoAP را برای دستگاه‌هایی که هر چند ساعت یک داده کوتاه می‌فرستند، ایده‌آل می‌سازد.

تفاوت دیگری که در عمل اهمیت دارد، کشش پروتکل در برابر قطعی‌های کوتاه شبکه است. TCP در صورت قطع موقت لینک، اتصال را از دست می‌دهد و باید از نو برقرار شود؛ این روند می‌تواند چند ثانیه طول بکشد. CoAP بدون اتصال است و هر بسته مستقلاً ارسال می‌شود؛ در صورت قطع موقت، بسته‌های بعدی بدون نیاز به بازسازی اتصال ارسال می‌شوند. این ویژگی در شبکه‌های LPWAN و وای‌فای با تداخل بالا، برتری قابل‌توجهی به CoAP می‌دهد. در خانه‌هایی که روتر بی‌سیم ناپایدار است یا دستگاه در حاشیه پوشش قرار دارد، CoAP می‌تواند پایداری بهتری نسبت به HTTP ارائه دهد.

ویژگی‌های فنی و معماری

سبک‌وزن و بهینه برای دستگاه‌ها با هدر فقط ۴ بایتی

هر پیام CoAP با یک هدر ۴ بایتی آغاز می‌شود. این هدر شامل پنج فیلد است: نسخه پروتکل (۲ بیت)، نوع پیام (۲ بیت: CON، NON، ACK یا RST)، طول Token (۴ بیت)، کد درخواست یا پاسخ (۸ بیت)، و شناسه پیام (۱۶ بیت). پس از هدر اصلی، یک Token اختیاری (۰ تا ۸ بایت) و سپس گزینه‌ها (Options) و در نهایت Payload قرار می‌گیرند.

برای مقایسه، یک درخواست HTTP GET ساده به این شکل است:

که حدود ۶۵ بایت است.

همین درخواست در CoAP می‌تواند در ۱۲ بایت ارسال شود؛ یعنی تقریباً یک‌پنجم. برای سنسوری که روزی ۱۰۰ بار داده می‌فرستد، این کاهش حجم به معنای چندین برابر افزایش عمر باتری است.

علاوه بر هدر کم‌حجم، CoAP از فشرده‌سازی گزینه‌ها نیز بهره می‌برد. گزینه‌های پرکاربرد (مانند Uri-Path، Content-Format) با کدهای عددی کوتاه نشان داده می‌شوند و تکرار آن‌ها در یک پیام با تکنیک Delta Encoding فشرده می‌گردد. این ساختار طراحی، CoAP را قادر می‌سازد حتی پیام‌های پیچیده را در زیر ۱۰۰ بایت، جا دهد.

در سطح سخت‌افزار، سبک‌وزنی CoAP امکان اجرای آن روی میکروکنترلرهای بسیار پایه را فراهم می‌سازد. یک چیپ ARM Cortex-M0 با ۳۲ کیلوبایت حافظه Flash و ۸ کیلوبایت RAM می‌تواند کامل پشته CoAP را اجرا کند. این در حالی است که اجرای HTTP با TLS معمولاً حداقل ۲۵۶ کیلوبایت Flash و ۶۴ کیلوبایت RAM می‌طلبد. تفاوت در سخت‌افزار مستقیماً به قیمت نهایی دستگاه منعکس می‌شود؛ یک ماژول CoAP-محور می‌تواند ۱.۵ تا ۳ دلار هزینه داشته باشد در حالی که یک ماژول HTTP-محور معمولاً ۵ تا ۱۰ دلار است. این تفاوت هزینه در تولید انبوه دستگاه‌های IoT قابل‌توجه است.

چرا CoAp از UDP به جای TCP استفاده می‌کند؟

TCP یک پروتکل اتصال‌محور است؛ قبل از ارسال داده، دو طرف باید یک اتصال برقرار کنند و این اتصال تا پایان انتقال داده حفظ می‌شود. این مدل برای کاربردهایی که داده پیوسته و طولانی دارند (مانند وب، ایمیل، انتقال فایل) مناسب است. اما برای دستگاه‌های IoT که داده کوتاه و پراکنده می‌فرستند، سربار اتصال بیش از حد است.

UDP یک پروتکل بدون اتصال است و هر بسته مستقلاً ارسال می‌شود و هیچ وضعیت اتصال روی فرستنده یا گیرنده نگه‌داری نمی‌شود. این ویژگی دو مزیت اصلی دارد. نخست، مصرف حافظه پایین؛ دستگاه نیازی به نگه‌داری Connection Table ندارد. دوم، تأخیر کمتر؛ بدون Handshake، بسته مستقیم ارسال می‌شود.

اما UDP یک نقطه ضعف بزرگ دارد: هیچ تضمینی برای تحویل بسته نیست. اگر بسته‌ای گم شود، UDP آن را بازارسال نمی‌کند. CoAP این نقص را با مکانیزم تأیید در لایه کاربرد جبران می‌کند؛ فرستنده می‌تواند نوع پیام را CON (Confirmable) انتخاب کند و گیرنده باید با پیام ACK تایید کند. اگر ACK در زمان مشخص نرسد، فرستنده بسته را بازارسالی می‌نماید. این مکانیزم، قابلیت‌اعتماد TCP را در لایه کاربرد بازتولید می‌کند اما با سربار بسیار کمتر.

یک دلیل دیگر برای استفاده از UDP، تناسب با شبکه‌های کم‌منبع مانند 6LoWPAN است. در این شبکه‌ها، حداکثر اندازه بسته (MTU) حدود ۱۲۷ بایت است. TCP با هدر ۲۰ بایتی و سربار Handshake، بخش بزرگی از این ظرفیت را اشغال می‌کند. UDP با هدر ۸ بایتی، فضای بیشتری برای داده واقعی باقی می‌گذارد.

یکی از انتقاداتی که به انتخاب UDP وارد می‌شود، مشکل عبور از فایروال و NAT است. بسیاری از شبکه‌های سازمانی ترافیک UDP ورودی را مسدود می‌کنند و NAT برای اتصال‌های بدون وضعیت UDP پیچیدگی دارد. برای رفع این مشکل، RFC ۸۳۲۳ حالت TCP و WebSockets را به CoAP اضافه کرد تا در محیط‌هایی که UDP محدود است، CoAP بتواند روی TCP کار کند. این انعطاف، CoAP را قادر می‌سازد در هر دو محیط شبکه داخلی و اینترنت عمومی به‌کار رود. در عمل، دستگاه‌های کم‌منبع معمولاً UDP را به‌کار می‌برند و سرورهای پشت فایروال از TCP برای پذیرش اتصال استفاده می‌کنند.

مدل دوگانه CoAP: لایه پیام‌رسانی (Messaging) و لایه درخواست/پاسخ (Request/Response)

معماری CoAP از دو لایه مجزا تشکیل شده که هر کدام مسئولیت مشخصی دارند.

1. لایه پایین، پیام‌رسانی (Messaging)، مسئول انتقال بسته‌های UDP و تأیید دریافت است.
2. لایه بالا، درخواست/پاسخ (Request/Response)، مسئول منطق REST و پردازش افعال GET، POST، PUT و DELETE است.

این تفکیک عمدی است. لایه پیام‌رسانی با UDP کار می‌کند و مکانیزم‌های تایید و بازارسال را مدیریت می‌نماید. این لایه چهار نوع پیام دارد: CON (تاییدشدنی)، NON (تاییدنشدنی)، ACK (تایید) و RST (بازنشانی). لایه درخواست/پاسخ روی این پیام‌ها سوار می‌شود و کدهای درخواست/پاسخ را (مانند ۲.۰۵ Content یا ۴.۰۴ Not Found) حمل می‌کند.

مزیت این دوگانگی، انعطاف در انتخاب سطح قابلیت‌اعتماد است. یک دستگاه می‌تواند برای داده حیاتی (مانند دستور خاموش‌کردن) از CON استفاده کند و برای داده تله‌متری دوره‌ای (مانند دما در هر ۱۰ دقیقه) از NON. این انتخاب، تعادل بین قابلیت‌اعتماد و مصرف انرژی را به توسعه‌دهنده می‌سپارد. در HTTP، چنین انتخابی وجود ندارد؛ همیشه TCP با تایید کامل استفاده می‌شود.

این تفکیک در عملیات چندمرحله‌ای نیز مفید است. یک دستگاه می‌تواند در حالت عادی NON بفرستد اما در صورت شناسایی رویداد بحرانی (مانند تشخیص نشت آب)، به حالت CON تغییر وضعیت دهد تا تحویل هشدار تضمین شود. این انعطاف پویا در سطح قابلیت‌اعتماد، یکی از نقاط قوت طراحی CoAP است. همچنین، لایه‌بندی باعث می‌شود پیاده‌کننده‌ها بتوانند بخش‌های مختلف را مستقلاً توسعه دهند؛ مثلاً یک کتابخانه لایه پیام‌رسانی می‌تواند روی چندین لایه کاربردی مختلف به‌کار رود.

پیام‌های تأییدشده (CON) و تأییدنشده (NON) و مکانیزم ارسال مجدد

پیام CON (Confirmable) نیازمند تایید گیرنده است. وقتی فرستنده یک پیام CON می‌فرستد، یک تایمر آغاز می‌کند. اگر در زمان ACK_TIMEOUT (پیش‌فرض ۲ ثانیه) پیام ACK دریافت نشود، بسته بازارسال می‌شود. تعداد بازارسالی‌ها و افزایش زمان انتظار قابل‌پیکربندی است؛ معمولاً پس از هر بار، زمان دو برابر می‌شود (Exponential Backoff). پس از چهار بار ناموفق، فرستنده اعلام شکست می‌کند.

پیام NON یا (Non-confirmable) نیازی به تایید ندارد. فرستنده آن را یک بار می‌فرستد و منتظر پاسخ نمی‌ماند. این نوع برای داده‌هایی مناسب است که از دست رفتن یک نمونه مانند گزارش دوره‌ای دما که هر ۱۰ دقیقه ارسال می‌شود و گم شدن یک نمونه اهمیت چندانی ندارد، قابل‌تحمل است.

پیام ACK یا (Acknowledgement) تایید دریافت پیام CON است. این پیام می‌تواند خالی باشد (فقط تایید دریافت) یا حاوی پاسخ درخواست باشد (Pattern Known as Piggybacking). اگر گیرنده نتواند فوراً پاسخ تولید کند، می‌تواند یک ACK خالی بفرستد و سپس پاسخ واقعی را در یک پیام جداگانه در زمان بعد ارسال نماید (Separate Response).

پیام RST یا (Reset) برای اعلام «این پیام را نمی‌توانم پردازش کنم» استفاده می‌شود. این پیام معمولاً به معنای خطای پیکربندی یا عدم پشتیبانی از قابلیت درخواست‌شده است. ترکیب این چهار نوع پیام، CoAP را قادر می‌سازد در شرایط شبکه متفاوت (از لینک پایدار اترنت تا لینک ناپایدار LoRa) به‌درستی کار کند.

در پیاده‌سازی عملی، چند نکته باید رعایت شود. نخست، تنظیم ACK_TIMEOUT بر اساس لینک؛ در شبکه 6LoWPAN با تاخیر بالا، این مقدار باید افزایش یابد تا از بازارسالی‌های بی‌مورد جلوگیری شود. دوم، مدیریت Max Retransmit؛ دستگاه‌های باتری‌خور باید این مقدار را پایین نگه دارند تا در صورت قطع شبکه، باتری صرف بازارسالی‌های بی‌نتیجه نشود. سوم، استفاده از NON برای داده‌های دوره‌ای؛ این کار می‌تواند مصرف انرژی را تا ۵۰ درصد کاهش دهد. این تنظیمات در عمل تفاوت چند برابری در عمر باتری ایجاد می‌کنند.

کاربردهای CoAP در خانه هوشمند

کنترل روشنایی، دما و تجهیزات امنیتی با CoAP

در خانه هوشمند، CoAP می‌تواند پروتکل اصلی ارتباط بین دستگاه‌های نهایی و سرور محلی یا گیت‌وی باشد. یک لامپ هوشمند با CoAP می‌تواند یک Resource با آدرس «coap://lamp.local/brightness» داشته باشد. کنترل از طریق اپلیکیشن با یک GET مقدار فعلی را می‌خواند و با یک PUT آن را تغییر می‌دهد. این سادگی، CoAP را برای دستگاه‌های ساده مناسب می‌سازد.

در کنترل دما، یک ترموستات CoAP می‌تواند همگام با سنسور دما کار کند. سنسور هر چند دقیقه دما را به‌صورت NON می‌فرستد و ترموستات بر اساس آن Setpoint را تنظیم می‌کند. اگر دستور تغییر Setpoint از سوی کاربر بیاید، آن دستور به‌صورت CON ارسال می‌شود تا تحویل آن تضمین گردد. این تفکیک نوع پیام، مصرف انرژی را بهینه می‌کند.

در تجهیزات امنیتی، CoAP برای سنسورهای در و پنجره، سنسورهای حرکت و قفل‌های هوشمند کاربرد دارد. یک سنسور در، هنگام باز شدن، یک پیام CON به سرور می‌فرستد و منتظر ACK می‌ماند. اگر ACK نرسد (مثلاً به‌دلیل قطع موقت شبکه)، بسته بازارسال می‌شود. این قابلیت‌اعتماد برای کاربردهای امنیتی حیاتی است. قفل هوشمند نیز می‌تواند با CoAP دستور باز کردن را دریافت کند؛ در این حالت، استفاده از DTLS برای رمزنگاری الزامی است.

یک نمونه عملی، خانه‌ای با ۱۵ نقطه CoAP است: ۵ سنسور حرکت، ۸ سنسور در و پنجره، ۲ قفل هوشمند. همه این دستگاه‌ها با هدر ۴ بایتی و UDP به یک گیت‌وی محلی یا لوکال متصل‌اند. گیت‌وی داده‌ها را به سرور ابری یا اپلیکیشن موبایل منتقل می‌کند. در این معماری، کل ترافیک روزانه خانه ممکن است تنها چند ده کیلوبایت باشد؛ همین ترافیک با HTTP می‌توانست چند مگابایت باشد. این تفاوت در شبکه‌های با تعرفه حجمی (مانند NB-IoT) به معنای صرفه‌جویی قابل‌توجه در هزینه عملیاتی است.

در روشنایی هوشمند، CoAP قابلیت‌های پیشرفته‌ای را ممکن می‌سازد. یک لامپ می‌تواند چندین Resource ارائه دهد: روشن/خاموش، شدت، رنگ، و وضعیت. کنترل از طریق اپلیکیشن با GET مقدار فعلی را می‌خواند و با PUT آن را تغییر می‌دهد. قابلیت Observe امکان push تغییرات را فراهم می‌کند؛ اگر لامپ توسط کلید فیزیکی خاموش شود، سرور به‌طور خودکار مطلع می‌گردد. این هم‌گامی وضعیت، تجربه کاربری روان‌تری نسبت به حالت Polling ایجاد می‌کند.

در کنترل تهویه هوشمند، CoAP در سناریوهای چندسنسوره برتری دارد. یک سیستم می‌تواند همزمان از چند سنسور دما، رطوبت و CO2 داده بخواند و با الگوریتم بهینه، تنظیمات HVAC را تعیین کند. همه این تبادل‌ها با پیام‌های کوتاه CoAP انجام می‌شود و تاخیر کل سیستم زیر یک ثانیه می‌ماند. در مقیاس یک ساختمان تجاری با صدها زون، این بهینه‌سازی می‌تواند به صرفه‌جویی ۱۵ تا ۲۰ درصدی مصرف انرژی منجر شود.

نقش CoAP در شبکه‌های کم‌مصرف و پرتعداد (LPWAN مانند NB-IoT و LoRa)

LPWAN (Low Power Wide Area Network) خانواده‌ای از شبکه‌های بی‌سیم است که برای دستگاه‌های کم‌مصرف با برد طولانی طراحی شده‌اند. NB-IoT و LoRaWAN دو نمونه اصلی این خانواده هستند. در این شبکه‌ها، نرخ داده بسیار پایین است (چند کیلوبیت بر ثانیه)، هزینه ارسال هر بایت بالاست و باتری دستگاه باید سال‌ها دوام بیاورد.

CoAP با هدر کم‌حجم و UDP، ایده‌آل برای LPWAN است. یک دستگاه NB-IoT که گزارش روزانه سطح مخزن آب را می‌فرستد، با CoAP می‌تواند کل پیام را در ۲۰ تا ۳۰ بایت جا دهد. همان گزارش با HTTP حداقل ۵۰۰ بایت می‌شد؛ این تفاوت در شبکه‌ای که هر بایت هزینه دارد و باتری محدود است، حیاتی است.

در LoRaWAN، CoAP به‌صورت گسترده استفاده می‌شود. بسیاری از پلتفرم‌های LoRaWAN (مانند The Things Network و ChirpStack) از CoAP برای ارتباط با دستگاه‌ها پشتیبانی می‌کنند. یک نشاندار خاک در کشاورزی، با باتری لیتیوم و پنل خورشیدی کوچک، می‌تواند هر ساعت یک پیام CoAP با حجم ۱۵ بایت بفرستد و چندین سال بدون تعویض باتری کار کند.

نکته مهم در LPWAN، انتخاب نوع پیام است. چون هر ارسال هزینه انرژی دارد، دستگاه‌ها معمولاً از NON استفاده می‌کنند تا از بازارسالی پرهزینه جلوگیری کنند. اگر داده‌ای گم شود، نمونه بعدی در دوره بعدی ارسال می‌شود. این رویکرد با ذهنیت LPWAN هم‌خوان است: بهینه‌سازی برای مصرف انرژی، نه برای قابلیت‌اعتماد مطلق.

در بازار ایران، NB-IoT از طریق اپراتورهای همراه (همراه اول و ایرانسل) در حال راه‌اندازی است. دستگاه‌های مبتنی بر NB-IoT با CoAP می‌توانند در سناریوهایی مانند پایش مخازن آب، مانیتورینگ خطوط انتقال گاز، نشاندار میدانی در کشاورزی و کنتورهای هوشمند به‌کار روند. هزینه هر دستگاه NB-IoT حدود ۱۰ تا ۲۰ دلار است و هزینه اشتراک ماهانه ۱ تا ۳ دلار تعرفه دارد. این هزینه برای کاربردهایی که نیاز به برد طولانی و باتری چندساله دارند، قابل‌قبول است. LoRa نیز از طریق شبکه‌های خصوصی و نمونه‌های عمومی (مانند The Things Network) در ایران در حال توسعه است.

کاربرد CoAP در فرایند اتصال و راه‌اندازی (پیکربندی) دستگاه‌های Wi-Fi

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

CoAP به‌دلیل سادگی و سازگاری با UDP، برای این مرحله مناسب است. دستگاه در حالت Setup به‌صورت نقطه دسترسی وای‌فای عمل می‌کند و موبایل به آن متصل می‌شود. سپس موبایل با CoAP به دستگاه دستور می‌دهد که SSID و رمز عبور شبکه اصلی را ذخیره کند. بسیاری از پلتفرم‌های خانه هوشمند از CoAP در این مرحله استفاده می‌کنند.

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

علاوه بر Commissioning یا کامیشنینگ، CoAP برای پیکربندی دوره‌ای دستگاه نیز کاربرد دارد. یک دستگاه می‌تواند با GET یک Resource تنظیمات خود را از سرور بخواند و در صورت تغییر، رفتار خود را به‌روزرسانی کند. این الگو (Configuration over CoAP) در دستگاه‌های NB-IoT و LoRa رایج است که دسترسی فیزیکی به آن‌ها دشوار است.

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

در فرایند OTA (Over-the-Air) به‌روزرسانی فریم‌ور نیز CoAP نقش دارد. CoAP با قابلیت Block-wise Transfer یا (RFC ۷۹۵۹) اجازه می‌دهد فایل‌های بزرگ فریم‌ور را در بلوک‌های کوچک منتقل کند. این قابلیت در دستگاه‌های LPWAN که MTU پایینی دارند حیاتی است. دستگاه می‌تواند در چندین بسته کوچک، فایل فریم‌ور جدید را دریافت و نصب کند. این الگو در کنتورهای هوشمند و سنسورهای صنعتی که به‌صورت گسترده پخش شده‌اند، استفاده می‌شود.

قابلیت مشاهده‌گری (Observe)؛ دریافت خودکار تغییرات دستگاه بدون درخواست مکرر

قابلیت Observe که در RFC ۷۶۴۱ تعریف شده، یکی از مهم‌ترین ویژگی‌های CoAP است. در HTTP، اگر کلاینت بخواهد از تغییرات یک Resource مطلع شود، باید دائماً GET بفرستد (Polling). این کار هم پهنای باند مصرف می‌کند و هم باتری دستگاه را خالی می‌کند. Observe این مشکل را با معکوس کردن الگو حل می‌کند.

در Observe، کلاینت یک بار یک GET با گزینه Observe می‌فرستد و سرور (دستگاه) او را در فهرست «ناظران» قرار می‌دهد. هر بار که Resource تغییر می‌کند، سرور به‌صورت خودکار یک پیام به کلاینت می‌فرستد. این الگو شبیه Publish/Subscribe در MQTT است اما در چارچوب REST و بدون نیاز به Broker.

برای مثال، یک سنسور دما با Observe می‌تواند هر بار که دما ۰.۵ درجه تغییر می‌کند، یک پیام به سرور بفرستد. بدون Observe، سرور باید هر ۳۰ ثانیه یک GET بفرستد تا دما را بخواند؛ این یعنی ۲۸۸۰ درخواست در روز. با Observe، اگر دما روزی ۲۰ بار تغییر کند، فقط ۲۰ پیام ارسال می‌شود و این در عمل صرفه‌جویی ۹۹ درصدی در ترافیک و باتری است.

Observe در کاربردهای امنیتی اهمیت بیشتری دارد. یک سنسور حرکت می‌تواند با Observe به‌محض تشخیص حرکت، به سرور اطلاع دهد؛ تاخیر بین رویداد و اعلان در حد چند صد میلی‌ثانیه است. بدون Observe، سرور باید هر چند ثانیه Polling کند و احتمال از دست رفتن رویداد کوتاه وجود دارد. این ویژگی، CoAP را برای سناریوهای حساس به زمان در خانه هوشمند جذاب می‌سازد.

مدیریت نشست‌ها یا Sessions در Observe نیازمند توجه است. اگر کلاینت بدون ارسال RST از نشست خارج شود (مثلاً به‌دلیل قطع برق)، سرور همچنان به او پیام می‌فرستد و منابع مصرف می‌کند. برای رفع این مشکل، RFC ۷۶۴۱ مکانیزم Timeout را تعریف کرده؛ اگر کلاینت در زمان مشخصی تایید نکند، سرور او را از فهرست ناظران حذف می‌نماید. در عمل، این تنظیمات در پیکربندی سرور اهمیت دارند و باید بر اساس الگوی ارتباطی دستگاه تنظیم شوند. یک پیاده‌سازی نادرست می‌تواند منجر به نشت منابع روی سرور شود.

CoAP در اکوسیستم تویا

پشتیبانی تویا از CoAP به‌عنوان یکی از پروتکل‌های اصلی ارتباط ابری

تویا (Tuya Smart) چندین پروتکل را برای ارتباط بین دستگاه‌ها و سرور ابری خود پشتیبانی می‌کند. MQTT و HTTPS برای دستگاه‌های پرمصرف (دوربین، کنترلرهای BMS، گیت‌وی‌ها) و CoAP برای دستگاه‌های کم‌مصرف (سنسورها، کلیدهای باتری‌خور، لامپ‌های کم‌منبع) رایج‌اند. این چندپروتکلی‌بودن، تویا را قادر می‌سازد طیف گسترده‌ای از دستگاه‌ها را با بهینه‌ترین پروتکل پشتیبانی کند.

CoAP در تویا عمدتاً برای دستگاه‌های دارای ماژول‌های Wi-Fi کم‌مصرف (مانند TYWE1S و TYWE2S) یا دستگاه‌های NB-IoT به‌کار می‌رود. این دستگاه‌ها معمولاً هر چند ساعت یک داده کوتاه (مانند دما، وضعیت باتری، شمارش رویداد) می‌فرستند و نیازمند پروتکلی هستند که سربار کمی داشته باشد. CoAP با هدر ۴ بایتی و UDP، این نیاز را به‌خوبی برآورده می‌کند.

یک نمونه عملی، کلید هوشمند باتری‌خور تویا است. این کلید روی دیوار نصب می‌شود و با هر فشار، یک پیام کوتاه به سرور تویا می‌فرستد. اگر از HTTP استفاده می‌شد، هر فشار چند کیلوبایت ترافیک و چند ثانیه اتصال TCP می‌طلبید و باتری در چند ماه خالی می‌شد. با CoAP، هر فشار حدود ۵۰ بایت و چند صد میلی‌ثانیه است و باتری می‌تواند یک تا دو سال دوام بیاورد.

علاوه بر دستگاه‌های نهایی، تویا از CoAP در لایه‌های میانی نیز بهره می‌برد. گیت‌وی‌های تویا برای هماهنگ‌سازی با سرورهای ابری از CoAP در کنار MQTT استفاده می‌کنند. همچنین، در فرایند Discovery و Commissioning دستگاه‌های جدید، CoAP به‌دلیل سرعت و سبک‌وزنی، نقش اصلی را ایفا می‌کند. این استفاده چندگانه از CoAP، نشان‌دهنده بلوغ این پروتکل در پلتفرم تجاری است. تویا همچنین توسعه‌دهندگان شخص ثالث را قادر می‌سازد با SDK رسمی، دستگاه‌های CoAP-محور خود را به پلتفرم متصل کنند.

در عمل، تویا از یک الگوی هیبریدی بهره می‌برد: CoAP برای دستگاه‌های بسیار کم‌‌مصرف با منابع پایین، MQTT برای دستگاه‌های متوسط، و HTTPS برای دستگاه‌های پرفشار. این تفکیک به تویا اجازه می‌دهد طیف گسترده‌ای از دستگاه‌ها را با هزینه و مصرف انرژی بهینه پشتیبانی کند. برای مثال، یک حسگر دما با باتری سکه‌ای روی CoAP، یک لامپ هوشمند روی MQTT، و یک دوربین روی HTTPS کار می‌کنند. همه این‌ها در یک اپلیکیشن واحد به کاربر ارائه می‌شوند و پیچیدگی زیرساخت پنهان می‌ماند.

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

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

MQTT و CoAP هر دو برای IoT طراحی شده‌اند اما الگوی ارتباطی متفاوتی دارند. MQPT بر پایه Publish/Subscribe با یک Broker مرکزی کار می‌کند؛ دستگاه‌ها به Topic ها پیام می‌فرستند و علاقه‌مندان آن Topic را دریافت می‌کنند. CoAP بر پایه Request/Response با مدل REST کار می‌کند؛ دستگاه‌ها مستقیماً با هم یا با سرور به‌صورت نقطه‌به‌نقطه ارتباط برقرار می‌کنند.

MQTT برای دستگاه‌هایی مناسب است که اتصال پایدار به شبکه دارند و می‌توانند یک اتصال طولانی‌مدت به Broker نگه دارند. این دستگاه‌ها معمولاً به برق متصل‌اند (مانند گیت‌وی‌ها، کنترلرهای BMS، دوربین‌ها). CoAP برای دستگاه‌هایی مناسب است که گهگاه بیدار می‌شوند، یک داده کوتاه می‌فرستند و دوباره به خواب می‌روند. این دستگاه‌ها معمولاً باتری‌خور و کم‌منبع‌اند.

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

نکته دیگر، تأخیر است. MQTT به‌دلیل اتصال دائمی، تأخیر کمی دارد (در حد چند ده میلی‌ثانیه). CoAP بدون اتصال، برای هر پیام باید یک دور ارسال و ACK داشته باشد؛ تأخیر آن کمی بیشتر است اما هنوز در حد چند صد میلی‌ثانیه. برای کاربردهایی که تأخیر حیاتی است (مانند کنترل زنده صوتی)، MQTT برتری دارد؛ برای کاربردهایی که مصرف انرژی حیاتی است، CoAP.

در یک پروژه تویا، معمولاً هر دو پروتکل همزمان به‌کار می‌روند. به‌عنوان مثال، یک گیت‌وی مرکزی MQTT را برای ارتباط با سرور ابری و کنترل دستگاه‌های برقی به‌کار می‌برد، اما برای ارتباط با سنسورهای باتری‌خور Zigbee یا Bluetooth Mesh داخلی، CoAP را به‌کار می‌گیرد. این تفکیک به توسعه‌دهندگان اجازه می‌دهد هر دستگاه را با بهینه‌ترین پروتکل طراحی کنند. برای کاربر نهایی، این پیچیدگی پنهان است و همه چیز در یک اپلیکیشن واحد پدیدار می‌شود.

امنیت در CoAP با استفاده از DTLS برای ارتباط امن دستگاه‌ها

CoAP به‌تنهایی رمزنگاری ندارد و پیام‌ها به‌صورت Plain Text ارسال می‌شوند. برای تأمین امنیت، CoAP از DTLS (Datagram Transport Layer Security) استفاده می‌کند. DTLS نسخه‌ای از TLS است که برای UDP طراحی شده و با حفظ مدل بدون اتصال، رمزنگاری و احراز هویت را فراهم می‌سازد.

DTLS سه مکانیزم امنیتی اصلی ارائه می‌دهد. نخست، رمزنگاری داده‌ها با الگوریتم‌هایی مانند AES-128 یا AES-256 که از شنود جلوگیری می‌کند. دوم، یکپارچگی داده‌ها با HMAC که از دستکاری بسته‌ها جلوگیری می‌نماید. سوم، احراز هویت طرفین با گواهی دیجیتال یا کلید از پیش‌مشترک (PSK). این سه لایه، امنیتی معادل TLS در HTTPS فراهم می‌کند.

در تویا، DTLS به‌صورت پیش‌فرض فعال است. هر دستگاه دارای یک کلید منحصربه‌فرد است که در زمان تولید در کارخانه بارگذاری می‌شود و برای احراز هویت با سرور تویا استفاده می‌گردد. این الگو (Factory Provisioning) امنیت بالایی دارد زیرا کلیدها در زمان تولید ثبت و هرگز به‌صورت Plain Text منتقل نمی‌شوند.

نکته عملی، سربار DTLS است. Handshake اولیه DTLS چند بسته اضافی نیاز دارد که برای دستگاه ضعیف هزینه دارد. برای کاهش این سربار، CoAP از Session Resumption پشتیبانی می‌کند؛ دستگاه می‌تواند نشست قبلی را از سر بگیرد بدون نیاز به Handshake کامل. این بهینه‌سازی، DTLS را برای دستگاه‌های کم‌منبع قابل‌تحمل می‌سازد.

در انتخاب مود امنیتی، دو گزینه رایج وجود دارد: PSK (Pre-Shared Key) و گواهی دیجیتال (Certificate). PSK سبک‌تر و ساده‌تر است؛ هر دستگاه یک کلید مشترک با سرور دارد. این مود برای دستگاه‌های بسیار کم‌منبع مناسب است اما مدیریت کلیدها در مقیاس بزرگ چالش دارد. گواهی دیجیتال امن‌تر است و مدیریت کلید مرکزی را امکان می‌سازد اما سربار پردازشی بالاتری دارد. در تویا، ترکیبی از هر دو به‌کار می‌رود: PSK برای دستگاه‌های بسیار پایه و گواهی برای دستگاه‌های با توان پردازشی بالاتر.

مزایا و چالش‌های CoAP در عمل

کاهش مصرف انرژی و تأخیر کمتر نسبت به HTTP و حتی MQTT

کاهش مصرف انرژی، مهم‌ترین برتری CoAP است. مطالعات میدانی نشان داده که یک دستگاه باتری‌خور که با HTTP کار می‌کند، می‌تواند با مهاجرت به CoAP تا ۱۰ برابر عمر باتری طولانی‌تر داشته باشد. این کاهش به سه عامل برمی‌گردد: حجم کمتر داده (هدر ۴ بایتی)، حذف TCP Handshake، و امکان انتخاب نوع پیام NON برای داده‌های غیرحیاتی.

در مقایسه با MQTT نیز CoAP در مصرف انرژی برتری دارد. MQTT برای نگه‌داری اتصال به Broker، نیاز به پیام‌های دوره‌ای Keep-Alive دارد (معمولاً هر ۶۰ ثانیه). این پیام‌ها برای دستگاه باتری‌خور هزینه دارد. CoAP بدون اتصال، این هزینه را حذف می‌کند؛ دستگاه فقط هنگام نیاز بیدار می‌شود و داده می‌فرستد.

در حوزه تأخیر، CoAP برای اولین درخواست برتری دارد زیرا بدون Handshake مستقیم داده می‌فرستد. اما برای درخواست‌های متوالی، MQTT با اتصال دائمی برتری دارد. این تفاوت در عمل تعیین می‌کند کدام پروتکل برای کدام کاربرد مناسب است: CoAP برای دستگاه‌هایی که گهگاه داده می‌فرستند، MQTT برای دستگاه‌هایی که داده پیوسته دارند.

در کاربردهای حساس به تأخیر مانند کنترل صنعتی یا ایمنی‌حیاتی، CoAP می‌تواند با QoS مناسب بازارسالی را تنظیم کند. RFC ۸۳۲۳ حالت TCP را نیز اضافه کرده که برای این کاربردها می‌تواند اتصال پایدار فراهم کند. با این حال، در خانه هوشمند، کاربردهای حساس به تأخیر معمولاً روی پروتکل‌های لایه پایین‌تر (مانند Zigbee یا KNX) پیاده می‌شوند و CoAP برای داده‌های غیرحساس به‌کار می‌رود. این تقسیم کار، هر پروتکل را در نقطه قوت خود نگه می‌دارد.

کاهش مصرف برق آماده‌به‌کار (Standby) با پیاده‌سازی CoAP

مصرف Standby یکی از چالش‌های خانه هوشمند است. یک لامپ هوشمند حتی وقتی خاموش است، برای حفظ اتصال به شبکه، مصرف دارد. این مصرف اگرچه برای یک دستگاه کم است (معمولاً ۰.۵ تا ۲ وات)، در یک خانه با ۳۰ دستگاه هوشمند می‌تواند به ۳۰ تا ۶۰ وات برسد؛ معادل یک لامپ دائمی روشن.

CoAP می‌تواند این مصرف را کاهش دهد. دستگاهی که با CoAP کار می‌کند، نیازی به اتصال دائمی ندارد؛ می‌تواند در حالت خواب عمیق باشد و فقط هنگام نیاز بیدار شود. این الگو (Sleepy End Device) در CoAP رایج است و می‌تواند مصرف Standby را به چند میلی‌وات کاهش دهد.

در عمل، پیاده‌سازی این الگو نیازمند طراحی سخت‌افزار مناسب است. دستگاه باید بتواند رادیو را خاموش کند و فقط در زمان‌های مشخص بیدار شود. همچنین، اپلیکیشن باید بداند که دستگاه ممکن است در زمان‌های طولانی در دسترس نباشد و از الگوی Observe یا Polling با فواصل طولانی استفاده نماید. این طراحی، در دستگاه‌های NB-IoT و LoRa رایج است اما در دستگاه‌های وای‌فای هنوز کمتر پیاده شده است.

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

چالش‌ها: پیچیدگی پیاده‌سازی، عدم وجود صف پیام و محدودیت در سناریوهای پیچیده

CoAP با وجود مزایا، چند چالش عملی دارد:

نخست، پیچیدگی پیاده‌سازی. CoAP ساده‌تر از HTTP است اما پیاده‌سازی DTLS، مکانیزم تأیید و Observe، نیازمند دانش فنی قابل‌توجه است. توسعه‌دهنده‌ای که به HTTP و TLS عادت دارد، باید با مفاهیم جدیدی مانند Handshake بدون اتصال و Session Resumption آشنا شود.

دوم، عدم وجود صف پیام (Message Queue) ذاتی. MQTT به‌دلیل مدل Pub/Sub، می‌تواند پیام‌ها را در Broker صف کند و در صورت آفلاین بودن گیرنده، بعداً تحویل دهد. CoAP این قابلیت را ذاتی ندارد؛ اگر گیرنده آفلاین باشد، پیام از دست می‌رود مگر اینکه فرستنده بازارسال کند. این محدودیت در کاربردهایی که تحویل تضمینی لازم است، چالش ایجاد می‌کند.

سوم، محدودیت در سناریوهای پیچیده. CoAP برای درخواست/پاسخ ساده طراحی شده؛ برای سناریوهای پیچیده چندمرحله‌ای، تراکنش‌ها یا هماهنگی چند دستگاه، CoAP به‌تنهایی کافی نیست. در این موارد، باید از لایه‌های بالاتر (مانند OCF یا یکپارچه‌سازی با MQTT) استفاده شود. این پیچیدگی، CoAP را برای پروژه‌های ساده مناسب می‌سازد اما برای پروژه‌های پیچیده، نیاز به معماری ترکیبی دارد.

چهارم، عدم پشتیبانی گسترده در ابزارها. HTTP ابزارهای فراوانی دارد (مرورگر، curl، Postman) اما CoAP ابزارهای کمتری دارد. اگرچه کتابخانه‌هایی مانند libcoap (C)، aiocoap (Python) و Copper (Firefox addon) وجود دارند، اما تجربه توسعه همچنان از HTTP دشوارتر است. این محدودیت، پذیرش CoAP را در پروژه‌های کوچک‌تر کند کرده.

پنجم، چالش عبور از NAT و فایروال. UDP در بسیاری از شبکه‌های سازمانی و عمومی محدود می‌شود. این یعنی یک سرور CoAP خارج از شبکه محلی ممکن است از طریق اینترنت عمومی قابل دسترس نباشد. راه‌حل، استفاده از TCP CoAP یا (RFC ۸۳۲۳) یا WebSockets در این موارد است اما این راه‌حل‌ها برخی مزایای اصلی CoAP را کاهش می‌دهند. این چالش در پروژه‌هایی که دستگاه در شبکه داخلی و سرور در ابر است، ملموس‌تر می‌شود. بسیاری از پلتفرم‌ها از Reverse Proxy یا تونل‌های MQTT برای دور زدن این محدودیت استفاده می‌کنند.

 در برابر سایر پروتکل‌ها

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

MQTT و CoAP دو پروتکل اصلی در لایه کاربرد IoT هستند. انتخاب بین آن‌ها به ماهیت دستگاه و الگوی ارتباطی بستگی دارد. جدول زیر مقایسه فشرده‌ای از این دو پروتکل ارائه می‌دهد:

در خانه هوشمند، انتخاب معمولاً بر اساس منبع تغذیه دستگاه است. دستگاه‌های باتری‌خور (سنسورها، کلیدها، قفل‌های هوشمند) به CoAP گرایش دارند زیرا مصرف انرژی برایشان حیاتی است. دستگاه‌های برقی (دوربین، کنترلر، گیت‌وی) به MQTT گرایش دارند زیرا قابلیت‌اعتماد و تحویل تضمینی برایشان مهم‌تر است.

نکته دیگر، معماری شبکه است. MQTT به Broker مرکزی نیاز دارد؛ اگر Broker از کار بیفتد، کل ارتباط قطع می‌شود. CoAP نقطه‌به‌نقطه است و حتی در صورت قطع سرور، دستگاه‌های محلی می‌توانند با هم کار کنند. این ویژگی در خانه‌هایی با اینترنت ناپایدار اهمیت دارد.

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

یکی از معیارهای انتخاب که اغلب نادیده گرفته می‌شود، پشتیبانی اپراتورها از پروتکل است. در شبکه‌های سلولی با تعرفه حجمی، حجم ترافیک CoAP می‌تواند یک‌دهم MQTT باشد؛ این یعنی هزینه اشتراک ماهانه نیز یک‌دهم. در پروژه‌های NB-IoT با هزاران دستگاه، این تفاوت به صرفه‌جویی چند هزار دلاری در سال منجر می‌شود. همچنین، در شبکه‌هایی با محدودیت تعداد اتصال همزمان، CoAP به‌دلیل عدم نیاز به اتصال دائمی، ظرفیت بیشتری فراهم می‌کند.

هم‌نشینی CoAP با پروتکل‌های دیگر (Zigbee، 6LoWPAN و Matter) در یک خانه هوشمند

در یک خانه هوشمند واقعی، معمولاً چندین پروتکل همزمان وجود دارند. Zigbee برای حسگرها و لامپ‌های کم‌مصرف، Wi-Fi برای دستگاه‌های پرفشار، و CoAP برای ارتباط با سرور ابری یا بین دستگاه‌های IP-محور. این هم‌نشینی چالش‌هایی دارد اما با طراحی مناسب قابل‌مدیریت است.

در شبکه 6LoWPAN (شبکه IPv6 روی IEEE ۸۰۲.۱۵.۴)، CoAP پروتکل اصلی لایه کاربرد است. دستگاه‌های 6LoWPAN آدرس IPv6 دارند و مستقیماً با CoAP قابل دسترسی‌اند. این یکپارچگی، CoAP را در شبکه‌های سنسور با دستگاه‌های فراوان مناسب می‌سازد. Zigbee و 6LoWPAN هر دو روی IEEE ۸۰۲.۱۵.۴ کار می‌کنند اما Zigbee پروتکل کاربردی اختصاصی دارد در حالی که 6LoWPAN از IP و CoAP استفاده می‌کند.

Matter، استاندارد نوین خانه هوشمند، از چند پروتکل انتقال پشتیبانی می‌کند: Wi-Fi برای دستگاه‌های پرمصرف، Thread برای دستگاه‌های کم‌مصرف. روی Thread، اتصال Matter می‌تواند از CoAP به‌عنوان لایه کاربرد استفاده کند (با رمزنگاری اضافی Matter). این یعنی CoAP یکی از اجزای زیرین Matter است و در آینده با گسترش Matter، کاربرد CoAP نیز گسترش می‌یابد.

در عمل، یک خانه هوشمند می‌تواند چنین معماری داشته باشد: سنسورهای Zigbee به گیت‌وی متصل‌اند، گیت‌وی داده‌ها را با CoAP یا MQTT به سرور محلی می‌فرستد، دستگاه‌های Matter روی Thread با هم و با Border Router کار می‌کنند، و سرور محلی همه این منابع را در یک رابط واحد به کاربر ارائه می‌دهد. CoAP در این معماری، نقش چسبندگی را بین لایه‌های مختلف ایفا می‌کند.

در سطح شهر هوشمند، CoAP نقش گسترده‌تری پیدا می‌کند. سنسورهای محیطی (آلودگی هوا، ترافیک، پارکینگ) روی شبکه‌های NB-IoT یا LoRa با CoAP به سرور شهری متصل می‌شوند. این حسگرها با باتری چندساله و هزینه پایین، می‌توانند در هزاران نقطه شهر نصب شوند. همچنین، کنتورهای هوشمند آب و برق در بسیاری از کشورها از CoAP برای ارسال گزارش مصرف استفاده می‌کنند. این کاربردها در مقیاس بزرگ، CoAP را به یکی از پروتکل‌های اصلی زیرساخت شهر هوشمند تبدیل کرده‌اند.

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

آینده و چشم‌انداز

جایگاه CoAP در استانداردهای نوین اینترنت‌اشیا و خانه‌های هوشمند

CoAP در چند استاندارد نوین IoT جایگاهی دارد. OCF یا (Open Connectivity Foundation) که توسط Intel، Samsung و Microsoft پشتیبانی می‌شود، CoAP را به‌عنوان پروتکل اصلی لایه کاربرد انتخاب کرده. Thread Group نیز CoAP را در پشته پروتکل خود گنجانده. Matter نیز در لایه کاربرد از الگوهای الهام‌گرفته از CoAP بهره می‌برد.

در استانداردهای صنعتی، CoAP در OPC UA Binary جایگزین شده اما نسخه OPC UA PubSub از CoAP برای سناریوهای کم‌منبع پشتیبانی می‌کند. در oneM2M (استاندارد مخابراتی IoT) هم CoAP یکی از پروتکل‌های پشتیبانی‌شده است. این حضور در چندین استاندارد، CoAP را به یک پروتکل فراگیر در IoT تبدیل کرده است.

روند آینده، همگرایی بیشتر CoAP با IP و Matter است. با گسترش IPv6 و Thread، دستگاه‌های کم‌مصرف می‌توانند مستقیماً آدرس IP داشته باشند و با CoAP کار کنند. یعنی حذف گیت‌وی‌های اختصاصی و ساده‌تر شدن معماری در عمل بیش از پیش محقق میشود. پیش‌بینی می‌شود تا ۲۰۲۸، اکثر دستگاه‌های کم‌مصرف خانه هوشمند روی Thread با CoAP کار کنند.

نکته دیگر، ادغام CoAP با Edge AI است. با ارزان‌تر شدن چیپ‌های با NPU (مانند ESP32-S3)، دستگاه‌های ساده می‌توانند مدل‌های TinyML را اجرا کنند. این دستگاه‌ها برای ارسال نتایج به سرور یا دریافت به‌روزرسانی مدل، به پروتکلی سبک نیاز دارند و CoAP گزینه طبیعی است. این ترکیب، خانه هوشمند تطبیقی را در آینده ممکن می‌سازد.

جمع‌بندی

CoAP پروتکلی است که نقطه قوت آن در کاربردهای خاص است، نه به‌عنوان پروتکلی همه‌کاره برای همه کاربردها در نظر گرفته شود. برای دستگاه‌های باتری‌خور با داده پراکنده، CoAP بهترین انتخاب است؛ هدر کم‌حجم، UDP بدون اتصال، و قابلیت Observe، مصرف انرژی را به حداقل می‌رسانند. برای دستگاه‌های برقی با داده پیوسته، MQTT یا HTTP مناسب‌ترند.

CoAP انتخاب درستی است اگر دستگاه شما این ویژگی‌ها را دارد: منبع تغذیه باتری با نیاز به عمر چندساله، داده‌های کوتاه و پراکنده، لینک شبکه ناپایدار یا کم‌پهنای‌باند، و نیاز به مدل REST. این مشخصات در سنسورهای محیطی، کلیدهای هوشمند، نشاندارهای LPWAN و تجهیزات کشاورزی هوشمند دقیق رایج است.

CoAP انتخاب درستی نیست اگر دستگاه شما این ویژگی‌ها را دارد: منبع تغذیه برق ثابت، داده‌های پیوسته یا حجیم (مانند جریان ویدئویی)، نیاز به تحویل تضمینی پیام (بدون Broker)، یا نیاز به ابزار توسعه گسترده. در این موارد، MQTT یا HTTP گزینه‌های بهتری هستند.

در بازار ایران، CoAP کمتر به‌صورت مستقیم توسط مصرف‌کننده شناخته می‌شود اما در پشت‌صحنه بسیاری از دستگاه‌های تویا و پلتفرم‌های LPWAN فعال است. برای توسعه‌دهندگانی که روی دستگاه‌های NB-IoT یا LoRa کار می‌کنند، CoAP یک ابزار ضروری است. برای سیستم‌اینگریگرها، شناخت CoAP کمک می‌کند تا در انتخاب دستگاه‌های هوشمند، کیفیت زیرساخت ارتباطی را بهتر ارزیابی کنند.

برای کاربر نهایی، CoAP معمولاً پنهان است؛ او فقط اپلیکیشن را می‌بیند و دستگاه‌ها را کنترل می‌کند. اما انتخاب CoAP در پشت‌صحنه مستقیماً بر تجربه او اثر می‌گذارد: عمر باتری طولانی‌تر، پایداری بیشتر در شبکه‌های ناپایدار، و قیمت پایین‌تر دستگاه. این منافع پنهان، CoAP را به یک انتخاب زیرساختی مهم تبدیل کرده است. هنگام خرید دستگاه هوشمند، بررسی پشتیبانی از CoAP (یا Matter که از CoAP استفاده می‌کند) می‌تواند معیار کیفیت زیرساخت باشد.

برای سیستم‌اینگریگرها و تیم‌های فنی، چند توصیه عملی وجود دارد. نخست، در پروژه‌های LPWAN، CoAP را به‌عنوان پروتکل پیش‌فرض در نظر بگیرید. دوم، در پروژه‌های خانه هوشمند با ترکیب دستگاه‌های باتری‌خور و برقی، از CoAP برای اولی و MQTT برای دومی استفاده کنید. سوم، در انتخاب دستگاه‌های تویا یا سایر پلتفرم‌ها، پشتیبانی از CoAP را در مستندات بررسی کنید. چهارم، برای توسعه دستگاه سفارشی، کتابخانه‌‌های libcoap و aiocoap نقطه شروع خوبی هستند.

آینده CoAP با گسترش Matter و Thread روشن به نظر می‌رسد. با همگرایی بیشتر خانه هوشمند حول IP و استانداردهای باز، CoAP جایگاه خود را به‌عنوان پروتکل کاربردی پیش‌فرض برای دستگاه‌های کم‌منبع تثبیت خواهد کرد. برای پروژه‌های جدید، انتخاب دستگاه‌های دارای پشتیبانی CoAP یا Matter، یک بیمه آینده‌نگرانه است. در نهایت، موفقیت یک پروژه IoT کمتر به انتخاب پروتکل و بیشتر به کیفیت پیاده‌سازی، پیکربندی صحیح و پشتیبانی بلندمدت بستگی دارد.