Реферат Протоколы для Интернета вещей (IoT): MQTT, CoAP и их применение
реклама
Федеральное агентство морского и речного транспорта Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования Волжский Государственный Университет Водного Транспорта Институт «Морская академия» Кафедра Систем информационной безопасности, управления и телекоммуникаций Реферат «Протоколы для Интернета вещей (IoT): MQTT, CoAP и их применение» Выполнил: Студент группы ОИСТ-311 Губанова П.Ю. Проверил: ассистент кафедры СИБУиТ Кораблев Е.Д. Нижний Новгород 2024 г. ОГЛАВЛЕНИЕ ВВЕДЕНИЕ ..................................................................................................................... 3 1. Интернет вещей (IoT). История развития ............................................................... 4 2. Протоколы передачи данных IoT ............................................................................ 7 3. Протокол MQTT ........................................................................................................ 8 4. Архитектура MQTT ................................................................................................ 12 5. Применение MQTT ................................................................................................. 15 6. Протокол CoAP ....................................................................................................... 17 7. Архитектура CoAP .................................................................................................. 20 8. Применение CoAP................................................................................................... 23 9. Сравнение протоколов MQTT и CoAP ................................................................ 24 10. Перспективы протоколов IoT ............................................................................... 27 ЗАКЛЮЧЕНИЕ ............................................................................................................ 28 СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ .................................................... 29 2 ВВЕДЕНИЕ Интернет вещей (IoT) представляет собой стремительно развивающуюся область технологий, которая обещает революционизировать различные отрасли промышленности функционировании и повседневную IoT играют жизнь людей. Ключевую сетевые протоколы, роль в обеспечивающие взаимодействие между устройствами и сервисами. Среди наиболее популярных и широко используемых протоколов для IoT выделяются Message Queuing Telemetry Transport (MQTT) и Constrained Application Protocol (CoAP). Целью данного реферата является анализ и сравнение двух основных протоколов для Интернета вещей: MQTT и CoAP. В работе будут рассмотрены их основные характеристики, преимущества и недостатки, а также приведены примеры практического применения этих протоколов в различных областях. Кроме того, будут обсуждены перспективы дальнейшего развития и адаптации этих протоколов в контексте быстро меняющихся потребностей рынка интернета вещей. 3 Интернет вещей (IoT). История развития Интернет вещей (Internet of Things – IoT) — это концепция сети предметов («вещей»), оснащенных технологиями для взаимодействия друг с другом или с внешней средой. Введение термина «интернет вещей» приписывают Кевину Эштону. В 1999 году Эштон занимался оптимизацией цепочек поставок в Procter & Gamble и использовал термин «интернет вещей» в качестве названия презентации нового проекта, связанного с применением датчиков. Впоследствии этот термин прижился. Однако сам интернет вещей появился задолго до введения этого термина. В 1970-е годы идея использования сетевых устройств тогда называлась «полная компьютеризация». В таблице 1 представлена краткая история развития интернета вещей, представлены открытия и новые технологии, которые привели к постепенному развитию данной отрасли. Таблица 1 - История развития интернета вещей Год Устройство 1973 Марио У. Кардулло получает патент на первую радиочастотную метку. 1982 Первое в мире устройство интернета вещей - подключенный к интернету автомат с газированной водой в университете КарнегиМеллон. Чтобы не посещать установленный в кампусе автомат для продажи Coca-Cola, если в нем закончились напитки, группа студентов настроила его так, что он сообщал о своем содержимом через сеть. Они установили в автомат микропереключатели, позволяющие определить, сколько банок кока-колы осталось и холодные ли они. 1989 Джон Ромки впервые подключил тостер к интернету на конференции Interop’89. 1991 Компания HP представила HP LaserJet IIISi: первый подключенный к сети Ethernet сетевой принтер 4 1993 Группа студентов Кембриджского университета использовала первый прототип веб-камеры для контроля количества кофе в кофеварке в их компьютерной лаборатории. Веб-камеру запрограммировали так, чтобы она делала по три фотографии кофеварки в минуту и отправляла изображения на локальные компьютеры, а пользователи могли проверить, есть ли в ней кофе. 1996 Подразделение General Motors OnStar (дистанционная диагностика 2001) 1998 Появление организации Bluetooth SIG 1999 LG Electronics представила первый в мире холодильник LG Internet Digital DIOS, подключенный к интернету. Это позволило покупать еду в интернете и совершать видеозвонки. Первые проявления разработанной компанией HP концепции 2000 всепроникающей компьютеризации (Cooltown): HP Labs, система вычислительных и коммуникационных технологий, которые в сочетании друг с другом создают подключение к интернету для людей, мест и объектов. 2001 Выпуск первого устройства, использующего технологию Bluetooth: мобильный телефон KDDI с поддержкой Bluetooth. 2005 Международный союз электросвязи, специализированное учреждение ООН, выпустил отчет, в котором впервые были сформулированы прогнозы развития интернета вещей. 2008 Появление первого IoT-сообщества IPSO Alliance, целью которого было содействие подключению вещей к интернету. 2010 Успешная разработка полупроводниковых светодиодных ламп привела к развитию концепции умного освещения. 2014 Компания Apple создала протокол iBeacon для маячков. В 2012 году в Европе прошла одна из крупнейших на тот момент конференций 5 по интернету вещей – Le Web. Примерно в то же время такие издания, как Forbes и Wired, начали активно применять термин «интернет вещей» в своих публикациях. В 2014 году компания Google объявила о приобретении Nest за 3,2 миллиарда долларов. Эта сделка привлекла внимание широкого рынка к концепции интернета вещей. В тот же год на выставке Consumer Electronics Show (CES), проходившей в Лас-Вегасе, интернет вещей был центральной темой. С середины 2010-х годов устройства с интегрированным Wi-Fi и поддержкой сетей 3G и 4G становились все более компактными, производительными и доступными по цене. Это способствовало значительному распространению интернета вещей. Современный индустриальный мир погружается в промышленный интернет вещей (IoT) с возможностью удаленного контроля ресурсов предприятия и управления ими в автоматизированном режиме. С помощью систем интернета вещей можно получать информацию о доступности оборудования, его техническом состоянии, загрузке, технологических нарушениях, графике технического обслуживания и т.п. Применение интернета вещей в промышленности создает новые возможности для развития производства и решает ряд важнейших задач: повышение производительности оборудования; снижение материальных и энергетических затрат; повышение качества, оптимизация и улучшение условий труда сотрудников компании; рост рентабельности производства и конкурентоспособности на мировом рынке [4, c.8]. По прогнозам, к 2025 году число подключённых IoT-устройств во всём мире составит 25,2 млрд. Это объясняется расширением применений интернета вещей в различных отраслях. Дальнейший рост вклада IoT в экономическое развитие зависит от масштабов и скорости внедрения инфраструктуры и сервисов связи 5G. В перспективе 2028–2030 годов она будет обеспечивать порядка 50% инфраструктуры и функциональных возможностей интернета вещей. 6 В России рынок промышленного интернета вещей (IoT) начал расти. По итогам 2023 года, по оценкам аналитиков, он увеличился на 5%, до 144,4 млрд руб., а к 2026 году составит 188,9 млрд руб.. Рост будет обеспечен активизацией спроса предприятий на автоматизацию производств на фоне дефицита кадров и инициативами, заложенными в нацпроект «Экономика данных». Протоколы передачи данных IoT Протокол HTTP предоставляет множество полезных возможностей для интернета на протяжении более 20 лет, изначально создаваясь для общих моделей взаимодействия клиент-сервер. Однако устройства IoT зачастую обладают строгими ограничениями по ресурсам, находятся в удаленных местах и имеют ограниченные каналы связи. Поэтому для эффективного управления большим количеством устройств в разнообразных сетевых топологиях требуются более экономные, защищенные и масштабируемые протоколы. При передаче данных в интернет разработка переносится на фундаментальные уровни TCP/IP. Протоколы TCP и UDP являются очевидным и единственным выбором в передаче данных, TCP значительно сложнее в реализации, чем UDP (который является протоколом многоадресной рассылки). Однако UDP не обладает стабильностью и надежностью TCP, компенсируя это добавлением отказоустойчивости в высокоуровневых приложениях. Стандартные протоколы – это инструменты, которые инкапсулируют необработанные данные от датчика к связывают и чему-то значимому и форматируют их для облака. Одно из основных различий между системой IOT и системой M2M (Machine-to-Machine) заключается в том, что M2M может связываться через WAN (глобальную вычислительную сеть) с выделенным сервером или системой без какого-либо инкапсулированного протокола. Система IoT, напротив, основана на коммуникации между конечными устройствами и службами, где интернет выступает в роли общей сетевой инфраструктуры. В данной главе рассматриваются важные протоколы, часто применяемые в сфере IoT, 7 включая телеметрический транспорт очереди сообщений (MQTT) и Constrained Application Protocol (CoAP). Протокол CoAP, предназначенный для использования устройствами с низкой скоростью, высокими потерями и многоадресной рассылкой в сети, стал заменой в сети IoT всем известного протокола HTTP. Протокол MQTT (Message Queuing Telemetry Transport) был представлен в 1999 году, но широко распространенным стал лишь после 2010 года. MQTT специализируется на низкоскоростных средах с высокой задержкой, поэтому хорошо подходит для обмена данными между машинами (M2M). В 2002 году была сформирована рабочая группа XMPP, для разработки протокола на основе Jabber для мгновенного обмена сообщениями. Рабочая группа сформировала четыре спецификации, которые были оформлены в качестве стандартов в 2004 году. Кроме того, часто разработчики используют собственные проприетарные протоколы, однако использование стандартных протоколов на IoT-платформах значительно ускоряют внедрение и разработку новых систем и приложений Интернета вещей. Протокол MQTT MQTT (Message Queuing Telemetry Transport) — клиент-серверный протокол передачи сообщений, основанный на модели «издатель — подписчик» (pub/sub). Первоначальную версию в 1999 году опубликовали Энди Стэнфорд-Кларк из IBM и Арлен Ниппер из Cirrus Link. Они рассматривали MQTT как способ поддержания связи между машинами в сетях с ограниченной пропускной способностью или непредсказуемой связью. Одним из первых вариантов его использования было обеспечение контакта фрагментов нефтепровода друг с другом и с центральными звеньями через спутники. Протокол является легким, открытым, простым, и спроектирован таким образом, чтобы его легко можно было реализовать. Эти характеристики делают его идеальным для использования во многих ситуациях, в том числе в ограниченных 8 средах, например, для организации связи в среде межмашинного взаимодействия (М2М) и Интернета вещей (IоТ), где требуется небольшой размер кода и/или важна пропускная способность сети. Протокол выполняется с использованием протоколов из набора TCP/IP или через другие сетевые протоколы (UDP), которые обеспечивают упорядоченные двунаправленные соединения без потерь. Его функции включают: 1) использование шаблона проектирования «издатель — подписчик», который обеспечивает распределение сообщений по принципу «один ко многим»; 2) доставка сообщений, не зависящая от содержимого информационного наполнения; 3) три уровня качества услуги (QoS) передачи данных: - «Не более одного раза», когда сообщения доставляются в соответствии с оптимальными затратами операционной среды. Следует использовать, когда сообщение не требуется сохранять в очереди, так как может произойти потеря сообщений. Лучше всего подходит для проводных соединений или когда система сильно ограничена в пропускной способности. Данный уровень может использоваться, например, для передачи данных датчика температуры окружающей среды, где потеря отдельного измерения не имеет значения, поскольку вскоре после этого будет опубликовано следующее измерение; - «Не реже одного раза», в этом случае гарантируется доставка сообщений, но возможны дубликаты. Следует использовать по умолчанию, так как значительно снижает стоимость передачи; - «Ровно один раз», в этом случае гарантируется доставка сообщений ровно один раз. Предназначен для критически важных приложений. Кроме того, для случаев, когда повторная передача дублированного сообщения может привести к ошибкам; 4) малый объем служебного трафика и протокольные обмены сводятся к минимуму для снижения сетевого трафика; 9 5) механизм уведомления заинтересованных сторон в случае аварийного разрыва связи [1, с.1]. Требования протокола MQTT: 1) Простота реализации; 2) Обеспечение формы качества обслуживания (QoS); 3) Лёгкая и эффективная пропускная способность; 4) Независимость от платформ; 5) Постоянное отслеживание сеанса; 6) Высокая безопасность. MQTT обеспечивает выполнение всех этих требований. Протокол Message Queuing Telemetry Transport (MQTT) используется в течение многих лет, но сейчас он особенно актуален благодаря взрывному росту IoT: и потребительские, и промышленные устройства внедряют распределённые сети и граничные вычисления, а устройства с постоянной трансляцией данных становятся частью повседневной жизни. Популярность этого протокола обеспечивается и большим количеством библиотек, реализующих его поверх TCP-IP, в том числе и для Arduino. Главные достоинства протокола MQTT: 1) Компактность и легковесность — минимальные накладные расходы на пересылку данных, для экономии трафика. 2) Устойчивость к потерям — гарантированная доставка в условиях нестабильных сетевых подключений. 3) Асинхронность — позволяет обслуживать большое количество устройств, и не зависит от сетевых задержек. 4) Поддержка QoS — возможность управлять приоритетом сообщений и гарантировать доставку сообщения адресату. 5) Динамическая конфигурация — не требует предварительно согласования полей и форматов данных, может конфигурироваться «на лету». 10 Удобная адресация — поля данных имеют текстовые названия, понятные для 6) человека. Не нужно запоминать цифровые адреса и битовые смещения. Основные недостатки протокола MQTT: 1) В системе маршрутизации брокеров сообщения передаются без учета их содержимого. Брокер просто пересылает данные, которые он получает, независимо от того, изменились ли значения параметров или нет. В сети отсутствует механизм, который бы предотвращал циклическую передачу сообщений, что может привести к повторению уже полученных данных и расходованию сетевых ресурсов и пропускной способности. 2) Брокер не способен отличать новые данные от тех, что были переданы ранее, что приводит к риску повторной отправки информации. Это может существенно увеличить нагрузку на сеть. Альтернативным способом обеспечения последовательной передачи данных является отправка всей информации каждому клиенту, что также создает максимальное давление на пропускную способность сети. 3) Так как брокер не анализирует содержание сообщений, он не ведет учет того, какие данные хранятся в его базе. Следовательно, клиенты не могут просматривать сохраненные данные напрямую через брокера. Для получения информации им необходимо знать темы или источники данных. Только имея эту информацию, клиент может создать соединение с брокером. Такой подход требует дублирования конфигурации для каждого клиента, что может быть приемлемо для небольших систем, но становится все более обременительным при увеличении масштаба системы. 4) Клиенты не получают уведомлений о том, что данные, опубликованные источником, стали недостоверными. В промышленных системах важно фиксировать такие случаи, будь то сбои в сети или отказ оборудования. Брокеры MQTT не способны автоматически информировать об этом. Идеальным решением было бы, чтобы брокер сам отправлял сообщение о недействительности данных, но из-за 11 отсутствия знания формата таких сообщений это невозможно. Эта трудность ставит под сомнение использование только протокола MQTT в производственных средах. 5) Протокол не позволяет запускать скрипты или иным образом обрабатывать данные для согласования систем, интерпретации, преобразования единиц измерения и т. д. в режиме реального времени. Без знания о формате данных невозможно разумно их обработать. Архитектура MQTT Протокол MQTT использует шаблон публикации-подписки и включает в себя следующие компоненты: 1) Сервер или брокер, который взаимодействует с клиентами (издателями и подписчиками) через интернет-соединение или локальную сеть; 2) Издатель, который создает сообщения и публикует их в определенной теме; 3) Подписчик, получающий сообщения по теме, на которую он подписан. Издатели и подписчики могут меняться ролями, а иногда клиенты MQTT берут на себя роль и того, и другого. Сервер определяет клиентов по их идентификаторам. Количество издателей и подписчиков ограничено только емкостью сервера. Каждый топик состоит из различных подтопиков или уровней, которые формируют иерархию. Публикуя сообщения в определенных подтопиках, издатель может донести их до предполагаемого получателя, который имеет на них подписку. Как и любой другой бинарный протокол, MQTT имеет преимущество перед текстовыми протоколами в межмашинном взаимодействии. Устройства могут отправлять и получать бинарные данные без дополнительной обработки, что ускоряет обмен сообщениями в Взаимодействие в протоколе MQTT представлено на рисунках 1 и 2. 12 сети. Рисунок 1 - Процесс взаимодействия в протоколе MQTT Рисунок 2 - Взаимодействие между брокером, издателем и подписчиком схематично Несмотря на то, что архитектура клиент-сервер долгие годы служит основой 13 для услуг центров обработки данных, модели публикация-подписка предлагают альтернативу, полезную для интернета вещей. Публикация-подписка, также известная как pub/sub, разделяет клиента, отправляющего сообщение, и другого клиента, получающего сообщение. В отличие от традиционной модели клиентсервер, клиенты не нуждаются в знании физических идентификаторов, таких как IPадрес или порт. MQTT – это архитектура pub/sub, но не очередь сообщений. Очереди сообщений по своей природе сохраняют сообщения, тогда как MQTT этого не делает. В MQTT, если никто не подписывается (или не слушает) на тему, она просто игнорируется и теряется. Очереди сообщений также поддерживают топологию клиент-сервер, где один потребитель связан с одним производителем. Клиент, отправляющий сообщение, называется издателем; клиент, принимающий сообщение, называется подписчиком. В центре находится брокер MQTT, отвечающий за соединение клиентов и фильтрацию данных. Такие фильтры обеспечивают: 1) фильтрация по темам – по задумке, клиенты подписываются на темы и определенные ветви тем и не получают данных больше, чем хотят. Каждое опубликованное сообщение должно содержать тему, и брокер несет ответственность за повторную передачу этого сообщения подписчикам или игнорирование его; 2) фильтрация по содержимому – брокеры имеют возможность проверять и фильтровать опубликованные данные. Таким образом, любые данные, которые не зашифрованы, могут управляться брокером до того, как сохранить их или передать другим клиентам; 3) фильтрация по типу – клиент, прослушивающий поток данных, на которые он подписан, может также применять свои собственные фильтры. Входящие данные могут анализироваться, и в зависимости от этого поток данных обрабатывается далее или игнорируется. По структуре пакет MQTT находится сверху уровня TCP сетевого стека в модели OSI. Пакет состоит из 2-байтового фиксированного заголовка, который всегда должен присутствовать, заголовка с переменным размером (необязательно) 14 и заканчивается полезной нагрузкой (тоже необязательно) [3, с.290]. Структура пакета MQTT представлена на рисунке 3. Рисунок 3 – Общая структура пакета MQTT Применение MQTT Поскольку приложения IoT ныне внедряются в огромных масштабах, MQTT попал в центр внимания как открытый, простой и масштабируемый способ развёртывания распределённых вычислений и функциональности IoT для более широкой пользовательской базы — как на потребительском, так и на промышленном рынке. Как было указано ранее, MQTT — легковесный протокол обмена сообщениями, построенный для ненадёжных сетей и устройств с ограничениями на источник питания и CPU. Однако это не означает, что связь с потенциальной 15 потерей пакетов — его единственное приложение. MQTT предоставляет различные уровни обслуживания для различных типов инфраструктуры IoT, от повторяющейся выборки данных до управления промышленными машинами: 1. Данные датчиков окружающей среды: как уже упоминалось, MQTT поддерживает модель доставки сообщений «Не более одного раза». В сетях с частичным покрытием территории или высокой задержкой это означает, что информация может потеряться или дублироваться. Это не является проблемой, в сферах, где удалённые датчики записывают и передают данные с заданными интервалами, так как новые показания поступают на регулярной основе. Датчики в удалённых средах — обычно маломощные устройства, что делает MQTT идеальным решением для сенсоров IoT с относительно низким приоритетом передачи данных. 2. Данные о работоспособности машин: для быстрого реагирования на возникающие проблемы ветроэлектрической и установки предотвращения нужна простоев. гарантированная Например, доставка для текущих показателей о работоспособности местным командам ещё до того, как эта информация попадёт в центр обработки данных. В таких ситуациях доставка сообщений «Не реже одного раза» гарантирует, что соответствующие флаги своевременно заметят нужные специалисты, даже если они поступают как дубликаты. Это важно для межмашинной связи с более высоким приоритетом. 3. Биллинговые системы: есть ещё более приоритетные и точные сообщения, которые требуется правильно обрабатывать. Биллинг необходим в различных видах бизнеса, главным образом — на рынке телекоммуникаций. С его помощью операторы связи собирают информацию об использовании услуг, тарифицируют их, выставляют счета абонентам и обрабатывают платежи. В бизнесситуациях, где дублирование записей неприемлемо, в том числе в биллинговых системах, пригодится флаг QoS-передачи «Ровно один раз». Это устраняет дублирование или потерю пакетов в системах выставления счетов или биллинга, сокращает количество аномалий и лишних противоречий по согласованию. 16 4. Рассылка информации множеству клиентов, например, о прибытии и отправлении поездов, самолетов, общественного транспорта. В этом сценарии протокол "один-к-одному", например такой, как HTTP, имеет большие накладные расходы и создает большую нагрузку на веб-серверы. Масштабирование этих вебсерверов может быть затруднено. Из-за того, что MQTT является протоколом "один ко многим", с помощью него клиенты быстро подключаются к брокеру. Протокол CoAP Ограниченный протокол приложений (Constrained Application Protocol) является разработкой IETF. Рабочая группа IETF Constreined RESTful Environments (CoRE) создала первый проект протокола в июне 2014 г., но еще несколько лет работала над его созданием. Он специально предназначен в качестве протокола связи для устройств с ограниченными возможностями. Протокол уникален, поскольку он впервые разработан для обмена данными типа машина-машина (M2M) между граничными узлами. Он также поддерживает работу с HTTP с использованием прокси. Это преобразование HTTP является встроенным средством для получения данных через интернет. CoAP превосходно обеспечивает аналогичную и легкую структуру адресации ресурсов, знакомую всем, у кого есть опыт использования интернета, но с ограниченными ресурсами и требованиями к пропускной способности. Исследование, проведенное Colitti et. al, продемонстрировало эффективность CoAP по сравнению со стандартным HTTP (Colitti, Walter & Steenhaut, Kris & De, Niccolò. (2017). Интеграция беспроводных сенсорных сетей с интернетом). CoAP обеспечивает аналогичную функциональность со значительно меньшими затратами и потребностями в мощности. Кроме того, некоторые реализации CoAP выполняются на x64 лучше, чем эквиваленты HTTP на аналогичном оборудовании. В рамках протокола существует четыре типа сообщений: CON — такое сообщение (запрос/ответ) требует ответного сообщения о подтверждении; ACK — ответное сообщение на пришедшие сообщение типа CON; 17 NON — сообщение (запрос/ответ), не требующее ответного подтверждения; RST — сброс сообщения (Reset). Такое сообщение отправляется в ответ, если полученная информация частично отсутствует или её невозможно принять. В том числе подобные сообщения можно использовать для того, чтобы тестировать работу узла, отправляя пустое сообщение типа CON. Протокол также позволяет объединение устройств в группы, для рассылки группового сообщения. Обмен сообщениями между сервером и клиентом возможен в асинхронном режиме, что существенно ускоряет работу системы. Информация об имеющихся в доступе ресурсах доступна клиенту в виде списка, включая метаданные. Это позволяет клиенту понять, какие ресурсы есть в наличии и их формат. CoAP был специально разработан для работы с устройствами, которые имеют весьма ограниченный объём ресурсов, например, порядка 10 КБ оперативной памяти и 100 КБ под прошивку. Кроме того, спецификация протокола рассчитана на достаточно скромные сетевые возможности, и именно поэтому в его рамках не реализуются многоуровневые транспорты для передачи сообщений. Вместо этого используется протокол UDP поверх IP. Главные достоинства протокола CoAP: 1) Простая архитектура. Конструкция протокола CoAP очень проста: он использует меньше заголовков и полей опций и занимает меньшую полосу пропускания и ресурсы сети. Это делает его идеальным для использования в устройствах и сетях с ограниченными ресурсами; 2) На основе UDP. CoAP обычно работает через UDP, а не через TCP. Это делает его более подходящим для эффективной связи без установления соединения, с низкой задержкой. Кроме того, CoAP также поддерживает надежную передачу сообщений через сообщения CON (подтверждаемое) и ACK (подтверждение) CoAP; 3) RESTful архитектура. CoAP использует архитектурный стиль RESTful (Representational State Transfer) и модель запроса-ответа, аналогичную HTTP. Он поддерживает распространенные методы HTTP, такие как GET, POST, PUT и DELETE, для чтения, создания, обновления и удаления ресурсов; 4) Низкое энергопотребление и низкое потребление полосы пропускания. 18 Протокол CoAP оптимизирован для устройств и сетей с ограниченными ресурсами и обладает характеристиками низкого энергопотребления и низкого потребления полосы пропускания. Он использует такие механизмы, как наблюдение и группировка, чтобы уменьшить накладные расходы на связь; 5) Идентификатор ресурса. CoAP использует универсальный идентификатор ресурса (URI) для идентификации ресурсов, чтобы клиенты могли находить и управлять определенными ресурсами через URI. Это похоже на URL-адреса HTTP; 6) Поддержка многоадресной IP-адресации. Обеспечивает связь «один ко многим», что полезно для одновременного получения обновлений несколькими устройствами в Интернете вещей; 7) Надежность. Протокол CoAP поддерживает надежную передачу, используя механизмы повторной передачи и подтверждения для обеспечения надежной доставки сообщений; 8) Безопасность. Протокол CoAP можно использовать в сочетании с DTLS (безопасность транспортного уровня дейтаграмм) для обеспечения сквозной безопасности. DTLS — это безопасный транспортный протокол на основе UDP, используемый для защиты конфиденциальности и целостности связи CoAP; 9) Пользовательские параметры. CoAP позволяет включать в заголовки сообщений специальные параметры для удовлетворения потребностей конкретных приложений, что делает его очень гибким и расширяемым. Основные недостатки протокола CoAP: 1) Ненадёжность. Из-за использования User Datagram Protocol (UDP) сообщения CoAP могут не дойти в том порядке, в котором они были отправлены, или быть потерянными по прибытии. Для повышения надёжности рекомендуется использовать функцию повторной передачи. 2) Более длительное время обработки. Протокол CoAP решает проблемы коммуникации для устройств, работающих за NAT. Каждое получение сообщения увеличивает время обработки. 3) Проблемы с методами реализации. CoAP — это зашифрованный протокол, 19 который использует DTLS для обеспечения безопасности. Он не проверяет, была ли получена правильная дешифровка сообщения. Архитектура CoAP Концепция CoAP основана на имитации и замене тяжелых элементов HTTP и использования легкого эквивалента для IoT. Это не замена HTTP, поскольку в ней отсутствуют некоторые качества; HTTP требует более мощных и ориентированных на сервисы систем. Возможности CoAP можно суммировать следующим образом: 1) Схожесть с HTTP; 2) Протоколы без установления соединения; 3) Безопасность с помощью DTLS, а не TLS, как при нормальной передаче HTTP; 4) Асинхронный обмен сообщениями; 5) Лёгкий дизайн и низкие требования к ресурсам, низкие накладные расходы в плане заголовка; 6) Поддержка URI и типов содержимого; 7) Построен на UDP вместо TCP/UDP, как для обычного HTTP-сеанса; 8) HTTP-сопоставление без сохранения состояния, позволяющее прокси-серверу подключаться к HTTP-сеансам. CoAP имеет два основных уровня: 1) Уровень запроса/ответа – отвечает за отправку и получение запросов на основе RESTful. Запросы REST включены в сообщения CON или NON. Ответ REST включен в соответствующее сообщение ACK; 2) Уровень транзакций – на этом уровне поддерживается обмен сообщениями между оконечными точками, используя один из четырех основных типов сообщений. Уровень транзакции также поддерживает управление многоадресной рассылкой и перегрузкой. На рисунке 4 представлен стек протоколов HTTP и CoAP. 20 Рисунок 4 – Стек HTTP по сравнению с CoAP Система CoAP состоит из семи основных участников: 1) Оконечные точки – это источники и адресаты сообщения CoAP. Конкретное определение оконечной точки зависит от используемого транспорта; 2) Прокси – оконечная точка CoAP, которой клиенты CoAP поручают выполнять запросы от своего имени. Снижение нагрузки на сеть, доступ к спящим узлам и обеспечение некоторого уровня безопасности – вот некоторые из функций прокси. Прокси могут быть явно выбраны клиентом (прямое проксирование) или могут использоваться как серверы insitu (обратное проксирование). В качестве альтернативы прокси может преобразовать один запрос CoAP в другой запрос CoAP или даже перевести на другой протокол (перекрестное проксирование). Общей ситуацией является пограничный маршрутизатор, проксирующий из сети CoAP до сервисов HTTP для облачных интернет-соединений; 3) Клиент: инициатор запроса. Оконечная точка назначения ответа; 4) Сервер: оконечная точка назначения запроса. Создатель ответа; 5) Посредник: клиент, выступающий в качестве и сервера и клиента по отношению к исходному серверу. Прокси является посредником; 6) Сервер происхождения: сервер, на котором находится данный ресурс; 7) Наблюдатели: клиент наблюдателя может зарегистрировать себя 21 с использованием измененного сообщения GET. Затем наблюдатель подключается к ресурсу, и, если состояние этого ресурса изменяется, сервер отправляет уведомление наблюдателю. Наблюдатели уникальны в CoAP и позволяют устройству следить за изменениями в конкретном ресурсе. По сути, это похоже на модель подписки MQTT, где узел подписывается на событие. Как в простой системе на основе HTTP, клиенты CoAP могут взаимодействовать друг с другом или с сервисами в облаке, поддерживающими CoAP. В качестве альтернативы, прокси могут использоваться для подключения к службам HTTP в облаке. Конечные точки CoAP могут устанавливать связи друг с другом даже на уровне датчиков. Наблюдатели поддерживают атрибуты, похожие на подписку, для отслеживания изменений ресурса, аналогично MQTT. Рисунок также показывает серверы происхождения, на которых размещаются общие ресурсы. Два прокси позволяют CoAP осуществлять преобразование запросов в HTTP или отправку запросов от имени клиента. На рисунке 5 представлена архитектура CoAP. Рисунок 5 – Архитектура CoAP 22 Применение CoAP Протокол CoAP применяется почти повсеместно и обеспечивает простой и эффективный способ связи и управления. Он хорошо подходит для различных сред с ограниченными ресурсами. Автоматизация умного дома CoAP все чаще используется в системах автоматизации умного дома благодаря низким накладным расходам и высокой надежности. В этих системах различные устройства, такие как освещение, термостаты и камеры видеонаблюдения, могут обмениваться данными по протоколу CoAP. Это обеспечивает высокий уровень совместимости и упрощает добавление новых устройств в сеть. Промышленный Интернет вещей В промышленных приложениях IoT надежность и эффективность имеют решающее значение. Такие устройства, как датчики и исполнительные механизмы, могут обмениваться данными с помощью CoAP, что позволяет осуществлять мониторинг и управление промышленными процессами в режиме реального времени. Поддержка протокола многоадресной связи особенно полезна в таких сценариях, поскольку она позволяет одному устройству взаимодействовать с несколькими другими одновременно. Носимые устройства и здравоохранение CoAP становится все более популярным в носимых устройствах и приложениях для здравоохранения. Эти приложения часто включают в себя небольшие устройства с питанием от батареек, которые должны взаимодействовать друг с другом или с центральным сервером. Низкие накладные расходы и низкие требования к энергопотреблению CoAP делают его полезным для таких приложений. Управление энергопотреблением CoAP используется в системах управления энергопотреблением, где он позволяет осуществлять мониторинг и контроль использования энергии в режиме реального времени. Такие устройства, 23 как интеллектуальные счетчики и контроллеры управления энергопотреблением, могут использовать протокол для связи друг с другом и с центральным сервером, обеспечивая высокий уровень контроля над использованием энергии. Сравнение протоколов MQTT и CoAP Несмотря на то, что оба протокола предназначены для решения вопросов IoT, они имеют существенные различия, касающиеся как логики работы, так и способа передачи данных. В отличие от MQTT, протокол CoAP предназначен для непосредственного соединения двух узлов между собой, используя взаимодействие в рамках логики сервер/клиент: здесь, во время взаимодействия с клиентом, сервер делает доступным свои ресурсы по определённому адресу, а клиенты обращаются к том адресу с помощью стандартных HTTP-методов: GET (получить ресурс), POST (создать ресурс), PUT (обновить ресурс), DELETE (удалить ресурс). На рисунке 6 представлено визуальное сравнение работы протоколов MQTT и CoAP. Рисунок 6– Визуальное сравнение работы протоколов MQTT и CoAP В таблице 2 дано резюме и сравнение спецификаций протоколов MQTT и CoAP. 24 Таблица 2 - Сводка и сравнение протоколов MQTT и CoAP Модель Протокол обнаружения Требования к ресурсам Размер заголовка (байт) Среднее потребление энергии Аутентификация Шифрование Контроль доступа Нагрузка на каналы Сложность протокола TCP/UDP Широковещание Качество обслуживания Цель Процесс коммуникации Поддерживаемый формат данных Типы сообщений Расходы на соединение Масштабируемость MQTT MOM pub/sub Нет CoAP RESTful Есть Низкие Очень низкие 2 4 Нижайшее Среднее Нет (SSL/TLS) Нет (SSL/TLS) Нет Низкая Нет (DTLS) Нет (DTLS) Нет (прокси) Очень низкая Низкая Низкая TCP Непрямое Есть UDP Есть С сообщениями CON Обмен сообщениями и коммуникации в IoT Разработано для устройств с ограниченными ресурсами в Интернете вещей Модель «запрос/ответ» Модель публикации/подписки Поддержка двоичных и текстовых полезных данных Publish, Subscribe, Connect, Disconnect, etc. Поддерживает постоянные соединения Хорошо подходит для крупномасштабных развертываний Сжатие заголовка Нет встроенного сжатия заголовка Сжатие сообщения Поддерживает сжатие полезных данных 25 Поддержка двоичных и текстовых полезных данных GET, POST, PUT, DELETE Облегченная настройка соединения Предназначен для устройств и сетей с ограниченными возможностями Использует сжатие заголовков, специфичное для CoAP Поддерживает сжатие полезных данных сообщений сообщений Примеры использования Широкий спектр приложений IoT Устройства с ограниченными возможностями и ограниченными ресурсами MQTT, CoAP и HTTP на сегодняшний день являются преобладающими протоколами в отрасли IoT с поддержкой почти всех облачных провайдеров. MQTT обеспечивает масштабируемую и эффективную модель передачи данных pub/sub, в то время как CoAP предоставляет все соответствующие возможности модели HTTP RESTful без увеличения накладных расходов. Архитектор должен учитывать накладные расходы, мощность, пропускную способность и ресурсы, необходимые для поддержки данного протокола, и иметь достаточное видение перспективы для обеспечения масштабирования решения. CoAP — протокол, который часто сравнивают с MQTT для разработки систем IoT. Они похожи, но есть заметные различия. MQTT — это протокол «многие ко многим», в то время как CoAP — это в основном протокол «один к одному» для связи между сервером и клиентом. В то же время CoAP предоставляет функции метаданных, обнаружения и согласования содержимого, которых нет у MQTT. Если говорить о надёжности двух протоколов, то для критических коммуникаций имеет смысл выбирать MQTT (там, где это возможно), так как он обеспечивает качество обслуживания (QoS), гарантирующее доставку и хранение сообщения на брокере. Протокол CoAP применим в рамках сбора данных с датчиков, а обеспечение качество обслуживания может быть реализовано на стороне приложения. По сравнению с MQTT, протокол CoAP является более интересным для ряда применений, так как позволяет устранить проблему временной задержки, которая возникает из-за наличия посредника, или же, в некоторых случаях, такая работа с посредниками является избыточной, тогда как устройства могут общаться напрямую друг с другом. 26 Оба протокола, и MQTT, и CoAP, не требуют постоянного соединения, что положительно сказывается на продолжительности работы микроконтроллеров от компактных источников энергии, однако ввиду того, что CoAP использует в своей основе протокол UDP, система, построенная на его базе, более подвержена потерям сообщений, в противовес MQTT, где с помощью уровней качества обслуживания можно в значительной степени их минимизировать. Перспективы протоколов IoT В рамках протокола MQTT представлено 3 уровня качества обслуживания (QoS), однако ни один из них не соответствует требованиям промышленного Интернета вещей. MQTT может успешно применяться для функционирования маломасштабных пользовательских систем, но режимы отказа, которые предлагаются в рамке качества обслуживания MQTT делают его непрактичным и неэффективным в промышленном масштабе. Таким образом, хотя протокол обмена сообщениями MQTT зачастую используется в обычных пользовательских приложениях Интернета вещей - это не лучшее решение для решений в сфере промышленности. Не смотря на все недостатки протокола MQTT, он всё же будет очень необходим в потребительском интернете вещей. Интернет вещей стал значимым фактором глобального макроэкономического развития, обеспечивая прирост национальных ВВП от 0,3 до 0,8% и генерируя триллионы долларов накопленного вклада в мировую экономику. Поэтому в связи с активно прогрессирующей популярностью и востребованностью интернета вещей в государстве и мире, и протокол CoAP, и протокол MQTT остаются одними из самых практичных, лёгких и эффективных протоколов интернета вещей в использовании, поэтому их популярность и дальнейшее развитие будет стремительно расти. 27 Заключение В данной работе было подробно написано о такой современной концепции, как интернет вещей, его истории и значении в современном мире, а также об архитектуре, функциональных возможностях и применении протоколов MQTT (Message Queuing Telemetry Transport) и CoAP (Constrained Application Protocol) в потребительском и промышленном интернете вещей. В реферате приведено развёрнутое описание положительных и отрицательных сторон протоколов MQTT и CoAP и их сравнение по различным пользовательским и функциональным характеристикам. В заключение можем сделать вывод, что на основании приведённой сравнительной характеристики мы выяснили, что оба протокола активно и успешно применяются в интернете вещей и оба не уступают друг другу в использовании, так как каждый имеет свои равнозначные достоинства и недостатки. 28 Список использованной литературы 1. ГОСТ Р 58603-2019. Информационные технологии. Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1 [Текст]. – Москва: Стандартинформ, 2019. – 62 с., 2. ГОСТ Р 71437-2024. Информационные технологии. Спецификация открытого взаимодействия (OCF). Спецификация служб «устройство-облако» [Текст]. – Москва: Российский институт стандартизации, 2024. – 40с., 3. Ли, П. Архитектура Интернета вещей: пер. с англ. / П. Ли; [пер. с англ. М. А. Райтмана]. — Москва: ДМК Пресс, 2019. — 454 с., 4. Основы интернета вещей : учебно-методическое пособие / Н. В. Папуловская ; М-во науки и высшего образования РФ. — Екатеринбург : Издво Урал. ун-та, 2022 — 104 с., 5. Суомалайнен, А. Интернет вещей: видео, аудио, коммутация / А. Суомалайнен; [перевод с англ. Д. А. Мовчана]. — Москва: ДМК Пресс, 2019. — 120 с., 6. Костенко, Н. Протокол MQTT: концептуальное погружение // Habr : [сайт]. - 2017. - URL: https://habr.com/ru/company/wavesoftware/blog/463669/. – Дата обращения: 03.10.2024., 7. Компания First. Альтернативный протокол для Интернета вещей — CoAP // Habr: [сайт]. 2021. URL: https://habr.com/ru/companies/first/blog/685184/. Дата обращения: 03.10.2024., 8. Иванов, А. Роль протокола MQTT в развитии промышленного интернета вещей // Habr : [сайт]. 2020. URL: https://habr.com/ru/companies/advantech/articles/490346/. Дата обращения: 04.10.2024., 9. Томас, Э. Сделает ли протокол MQTT промышленный IoT лучше? // Официальный дистрибьютор Cogent в России : [сайт]. - 2021. - URL: https://cogentdatahub.ru/about/news/202111101411?ysclid=m21v3ks5hd105284113/. Дата обращения: 05.10.2024., 10. Смирнов, Т. В. Обзор сетевых протоколов и протоколов обмена сообщениями для IoT // Habr: [сайт]. 2023. URL: https://habr.com/ru/companies/otus/articles/524140/. Дата обращения: 05.10.2024. 29
