IoT, туман и облака: поговорим про технологии?

Развитие технологий в области софта и железа, появление новых протоколов связи привели к расширению интернета вещей (IoT). Количество устройств растёт день ото дня, и они генерируют огромный объём данных. Поэтому возникает потребность в удобной архитектуре системы, способной обрабатывать, хранить и передавать эти данные.

Сейчас для этих целей используют облачные сервисы. Однако становящаяся всё более популярной парадигма туманных вычислений (Fog) способна дополнить облачные решения, масштабировав и оптимизировав инфраструктуру IoT.

«Облака» способны закрыть большинство запросов IoT. Например, обеспечить мониторинг служб, быструю обработку любых объёмов данных, генерируемых устройствами, а также их визуализацию. Туманные же вычисления эффективнее при решении real-time задач. Они обеспечивают быстрый отклик на запросы и минимальную задержку при обработке данных. То есть Fog именно дополняет «облака», расширяет его возможности.

Впрочем, главный вопрос в другом: как всё это должно взаимодействовать в контексте IoT? Какие протоколы связи будут наиболее эффективными при работе в объединённой системе IoT-Fog-Cloud?

Несмотря на кажущееся доминирование HTTP, в системах IoT, Fog и Cloud используется большое количество других решений. Это объясняется тем, что IoT должен сочетать функциональные возможности разнообразных датчиков устройств с безопасностью, совместимостью и другими требованиями, предъявляемыми пользователями.

Вот только единого представления об эталонной архитектуре и стандарте связи попросту нет. Поэтому создание нового протокола или доработка существующего под конкретные задачи IoT является одной из важнейших задач, стоящих перед ИТ-сообществом.

Какие протоколы используются сейчас и что они могут предложить? Давайте разбираться. Но для начала обсудим принципы экосистемы, в которой взаимодействуют облака, туман и интернет вещей.

Архитектура IoT Fog-to-Cloud (F2C)

Вы наверняка замечали, сколь значительные усилия прикладываются для изучения преимуществ и выгод, связанных с рациональным и скоординированным управлением IoT, облаками и туманом. Если же нет, то вот вам аж три инициативы по стандартизации: OpenFog Consortium, Edge Computing Consortium и mF2C H2020 EU project.

Если раньше рассматривали только 2 уровня, облака и конечных устройств, то предлагаемая архитектура вводит новый уровень — туманные вычисления. При этом уровень тумана может быть разделён на несколько подуровней, в зависимости от специфики ресурсов или набора политик, определяющих использование разных устройств в этих подуровнях.

Как может выглядеть эта абстракция? Вот типичная экосистема IoT-Fog-Cloud. IoT-устройства отправляют данные на более производительные сервера и вычислительные устройства, чтобы решать задачи, требующие низкого уровня задержки. В этой же системе облака отвечают за решение задач, требующих большого объёма вычислительных ресурсов или места для хранения данных.

Смартфоны, умные часы и другие гаджеты тоже могут быть частью IoT. Но такие устройства, как правило, используют проприетарные протоколы связи от крупных разработчиков. Сгенерированные данные интернета вещей передаются на уровень тумана через протокол REST HTTP, который обеспечивает гибкость и функциональную совместимость при создании RESTful-сервисов. Это важно в свете необходимости обеспечения обратной совместимости с существующей вычислительной инфраструктурой, работающей на локальных компьютерах, серверах или кластере серверов. Локальные ресурсы, которые называют «узлами тумана», фильтруют полученные данные и обрабатывают их локально либо пересылают в облако для дальнейших вычислений.

Облака поддерживают разные протоколы связи, среди которых чаще всего встречаются AMQP и REST HTTP. Так как HTTP общеизвестен и заточен под интернет, может возникнуть вопрос: «а не использовать ли его для работы с IoT и туманом?». Однако у данного протокола есть проблемы с производительностью. Об этом позже.

В целом, существует 2 модели протоколов связи, подходящих под нужную нам систему. Это запрос-ответ и публикация-подписка. Первая модель известна шире, особенно в архитектуре сервер-клиент. Клиент запрашивает информацию с сервера, а тот получает запрос, обрабатывает его и возвращает ответное сообщение. По этой модели работают протоколы REST HTTP и CoAP.

Вторая модель возникла из-за необходимости обеспечить асинхронную, распределённую, слабую связь между источниками, генерирующими данные, и получателями этих данных.

Модель предполагает трёх участников: издатель (источник данных), брокер (диспетчер) и подписчик (получатель). Здесь клиент, выступающий в роли подписчика, не должен запрашивать информацию с сервера. Вместо отправки запросов он подписывается на определённые события в системе через брокера, ответственного за фильтрацию всех входящих сообщений и их маршрутизацию между издателями и подписчиками. А издатель, когда происходит событие, касающееся определённой темы, публикует его брокеру, который отправляет подписчику данные по запрошенной теме.

По сути, эта архитектура основана на событиях. И такая модель взаимодействия интересна для приложений в IoT, облаке, тумане из-а её способности обеспечивать масштабируемость и упрощать взаимосвязь между различными устройствами, поддерживать динамическую связь «многие ко многим» и асинхронную связь. Среди наиболее известных стандартизированных протоколов обмена сообщениями, использующих модель «публикация-подписка», можно назвать MQTT, AMQP и DDS.

Очевидно, что у модели «публикация-подписка» есть масса преимуществ:

• Издателям и подписчикам не нужно знать о существовании друг друга;
• Один подписчик может получить информацию от множества разных изданий, а один издатель может отправлять данные множеству разных подписчиков (принцип «многие ко многим»);
• Издатель и подписчик не обязаны быть активными одновременно для обмена данными, потому что брокер (работающий в качестве системы очередей) сможет хранить сообщение для клиентов, которые в данный момент не подключены к сети.

Однако и у модели «запрос-ответ» есть свои сильные стороны. В тех случаях, когда возможности серверной стороны для обработки запросов нескольких клиентов не являются проблемой, имеет смысл использовать уже проверенные надёжные решения.

Также есть протоколы, которые поддерживают обе модели. Например, XMPP и HTTP 2.0, поддерживающие опцию «server push». IETF также выпустил CoAP. В попытке решить проблему обмена сообщениями было создано несколько других решений, таких как протокол WebSockets или использование протокола HTTP через QUIC (Quick UDP Internet Connections).

В случае с WebSockets, хотя он и используется для передачи данных в режиме реального времени с сервера на веб-клиент и обеспечивает постоянные соединения с одновременной двунаправленной связью, он не предназначен для устройств с ограниченными вычислительными ресурсами. QUIC тоже заслуживает внимания, поскольку новый транспортный протокол даёт массу новых возможностей. Но так как QUIC ещё не стандартизирован, преждевременно прогнозировать его возможное применение и влияние на решения в сфере IoT. Так что WebSockets и QUIC мы оставляем в памяти с прицелом на будущее, но подробнее изучать пока не будем.

Кто на свете всех милее: сравниваем протоколы

Теперь поговорим о сильных и слабых сторонах протоколов. Забегая вперёд, сразу оговоримся, что нет одного явного лидера. Какие-то достоинства/недостатки есть у каждого протокола.

Время отклика

Одной из важнейших характеристик протоколов связи, особенно применительно к интернету вещей, является время отклика. Но среди существующих протоколов нет безусловного победителя, демонстрирующего минимальный уровень задержки при работе в разных условиях. Зато есть целая куча исследований и сравнений возможностей протоколов.

Например, результаты сравнения эффективности HTTP и MQTT при работе с IoT показали что время отклика для запросов у MQTT меньше, чем у HTTP. А при изучении времени приёма-передачи (RTT) MQTT и CoAP выяснилось, что средний RTT CoAP на 20% меньше, чем у MQTT.

Другой эксперимент с RTT у протоколов MQTT и CoAP проводился в двух сценариях: локальной сети и сети IoT. Оказалось, что средний RTT в 2-3 раза выше в сети IoT. MQTT с QoS0 показал более низкий результат в сравнении с CoAP, а MQTT с QoS1 продемонстрировал более высокий RTT благодаря ACK на прикладном и транспортном уровнях. Для разных уровней 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, где в упомянутых сценариях наблюдался рост использования пропускной способности канала. В другом сценарии было задействовано большое количество устройств, передающих данные одновременно, что является типичным случаем в средах IoT. Результаты показали, что для более высокой загрузки лучше использовать CoAP.

При небольшой нагрузке CoAP использовал наименьшую пропускную способность, за ним следовали MQTT и REST HTTP. Однако, когда размер полезных нагрузок увеличился, наилучшие результаты были у REST HTTP.

Энергопотребление

Вопрос энергопотребления всегда имеет большое значение, а в системе IoT — особенно. Если сравнивать потребление электроэнергии у 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 были успешнее из-за его терпимости к ошибкам.

Впрочем, самая большая проблема этих протоколов заключается в том, что они изначально не были предназначены для использования в IoT и не предполагали работу в тумане или облаке. Через согласованный обмен (handshaking) они добавляют дополнительный трафик с каждым установлением соединения, что истощает вычислительные ресурсы. В среднем наблюдается увеличение на 6,5% для TLS и 11% для DTLS в служебной нагрузке по сравнению со связью без уровня безопасности. В богатых ресурсами средах, которые обычно расположены на облачном уровне, это не будет проблемой, но в связи между IoT и уровнем тумана это становится важным ограничением.

Что же выбрать? Однозначного ответа нет. MQTT и HTTP кажутся наиболее перспективными протоколами, так как считаются сравнительно более зрелыми и более стабильными решениями для IoT в сравнении с другими протоколами.

Решения на основе единого коммуникационного протокола

Практика однопротокольного решения имеет много недостатков. Например, протокол, который удовлетворяет ограниченной среде, может не работать в домене, который имеет строгие требования безопасности. Имея это в виду, нам остаётся отбросить почти все возможные решения на основе одного протокола в экосистеме Fog-to-Cloud в IoT, кроме MQTT и REST HTTP.

REST HTTP как однопротокольное решение

Есть хороший пример взаимодействия запросов и ответов REST HTTP в сфере IoT-to-Fog: интеллектуальная ферма. Животные снабжаются носимыми датчиками (IoT-клиент, C) и управляются через облачные вычисления умной фермерской системой (Fog-сервер, S).

В заголовке метода POST указывается ресурс для изменения (/farm/animals), а также версия HTTP и тип содержимого, который в данном случае является объектом JSON, представляющим животноводческую ферму, которой должна управлять система (Дульсинея/корова). Ответ от сервера указывает, что запрос был успешен, присылая код состояния HTTPS 201 (resource created). Метод GET должен указывать только запрошенный ресурс в URI (например, /farm/animals/1), который возвращает JSON-представление животного с этим идентификатором с сервера.

Метод PUT используется, когда необходимо обновить некоторую конкретную запись ресурса. В этом случае в ресурсе указывается URI для параметра, подлежащего изменению, и текущего значения (например, указывающего, что корова в данный момент гуляет, /farm/animals/1? состояние=ходьба). Наконец, метод DELETE используется в равной степени для метода GET, но просто удаляет ресурс в результате операции.

MQTT как однопротокольное решение

Возьмём всё ту же умную ферму, но вместо REST HTTP используем протокол MQTT. Локальный сервер с установленной библиотекой Mosquitto выполняет роль брокера. В этом примере простой компьютер (обозначается как сервер фермы) Raspberry Pi служит клиентом MQTT, реализованным через установку библиотеки MQTT Paho, полностью совместимой с брокером Mosquitto.

Данный клиент соответствует уровняю абстракции IoT представляющему устройство с возможностями обнаружения и вычислений. Посредник, с другой стороны, соответствует более высокому уровню абстракции, представляющему вычислительный узел тумана, характеризующийся большими мощностями в плане обработки и хранения данных.

В предлагаемом сценарии «умной фермы» Raspberry Pi подключается к акселерометру, GPS и датчикам температуры и публикует данные с этих датчиков в узле тумана. Как вы наверняка знаете, MQTT рассматривает темы как иерархию. Один издатель MQTT может публиковать сообщения в определенном наборе тем. В нашем случае их три. Для датчика, который измеряет температуру в сарае для животных, клиент выбирает тему (animalfarm/shed/temperature). Для датчиков, которые измеряют местоположение GPS и движение животных через акселерометр, клиент опубликует обновления (animalfarm/animal/GPS) и (animalfarm/animal/movement).

Эта информация будет передана брокеру, который может временно сохранить его в локальной базе данных на случай, если позже появится другой заинтересованный подписчик.

Кроме локального сервера, выполняющего роль брокера MQTT в тумане и которому Raspberry Pi, выступающие в роли клиентов MQTT, отправляют данные с датчиков, на облачном уровне может быть ещё один брокер MQTT. В этом случае информация, передаваемая локальному брокеру, может временно храниться в локальной базе данных и/или отправляться в облако. Туманный MQTT-брокер в данной ситуации используется для связывания всех данных с облачным MQTT-брокером. При такой архитектуре пользователь мобильного приложения может быть подписан на обоих брокеров.

В случае сбоя соединения с одним из брокеров (например, облачным), конечный пользователь получит информацию от другого (туманного). Это характерная особенность комбинированных систем тумана и облачных вычислений. По умолчанию мобильное приложение может быть настроено на первое подключение к туманному MQTT-брокеру, а в случае неудачи — на подключение к MQTT-брокеру в облаке. Это решение является лишь одним из многих в системах IoT-F2C.

Многопротокольные решения

Решения с одним протоколом популярны из-за их более лёгкой реализации. Но очевидно, что в системах IoT-F2C имеет смысл комбинировать разные протоколы. Смысл в том, что на разных уровнях могут работать разные протоколы. Возьмём, к примеру, три абстракции: уровни IoT, тумана и облачных вычислений. Устройства на уровне IoT обычно считаются ограниченными. Для этого обзора давайте рассмотрим уровни IoT как наиболее ограниченные, облачные наименее ограниченные и вычисление тумана как «где-то посередине». Тогда получается, что между IoT и абстракциями тумана текущие протокольные решения включают в себя MQTT, CoAP и XMPP. Между туманом и облаком, с другой стороны, AMQP является одним из основных используемых протоколов вместе с REST HTTP, который благодаря своей гибкости также используется между IoT и слоями тумана.

Основной проблемой тут выступает функциональная совместимость протоколов и простота перевода сообщений из одного протокола в другой. В идеале, в будущем архитектура системы интернета вещей с облачными и туманными ресурсами будет независимой от используемого протокола связи и обеспечит хорошее взаимодействие разных протоколов.

Поскольку на данный момент это не так, имеет смысл объединять протоколы, не имеющих значительных различий. С этой целью одно потенциальное решение основано на комбинации двух протоколов, которые придерживаются одного и того же архитектурного стиля, REST HTTP и CoAP. Другое предлагаемое решение основано на сочетании двух протоколов, которые предлагают взаимодействие по модели «публикация-подписка», MQTT и AMQP. Использование близких концепций (и MQTT, и AMQP используют брокеров, CoAP и HTTP используют REST), упрощает реализацию этих комбинаций и требует меньших усилий по интеграции.

На рисунке (а) показаны две модели на основе запросов-ответов, HTTP и CoAP, и их возможное размещение в решении IoT-F2C. Поскольку HTTP является одним из наиболее известных и адаптированных протоколов в современных сетях, маловероятно, что он будет полностью заменен другими протоколами обмена сообщениями. Среди узлов, представляющих мощные устройства, которые находятся между облаком и туманом, REST HTTP является разумным решением.

С другой стороны, для устройств с ограниченными вычислительными ресурсами, которые связываются между уровнями тумана и IoT, более эффективно использовать CoAP. Одним из больших преимуществ CoAP на самом деле является его совместимость с HTTP, так как оба протокола основаны на принципах REST.

На рисунке (б) показаны две модели взаимодействия «публикация-подписка» в одном сценарии, включая MQTT и AMQP. Хотя гипотетически оба протокола могут использоваться для связи между узлами на каждом уровне абстракции, их положение должно определяться на основе производительности. MQTT был разработан как упрощенный протокол для устройств с ограниченными вычислительными ресурсами, поэтому его можно использовать для связи между IoT и туманом. AMQP больше подходит для более мощных устройств, которые идеально расположили бы его между узлами тумана и облака. Вместо MQTT в IoT можно использовать протокол XMPP, так как он считается легковесным. Но он не так широко используется в подобных сценариях.

Выводы

Маловероятно, что одного из рассмотренных протоколов будет достаточно для охвата всей связи в системе, начиная с устройств с ограниченными вычислительными ресурсами и заканчивая облачными серверами. Исследование показало, что два наиболее перспективных варианта, которые чаще используют разработчики, это MQTT и RESTful HTTP. Эти два протокола являются не только наиболее зрелыми и стабильными, но также включают в себя множество хорошо документированных и успешных реализаций и онлайн-ресурсов.

Благодаря своей стабильности и простой конфигурации, MQTT является протоколом, который с течением времени доказал свою превосходную производительность при использовании на уровне IoT с ограниченными устройствами. В частях системы, где ограниченная связь и потребление батареи не являются проблемой, например, в некоторых сферах тумана и большинстве облачных вычислений, RESTful HTTP является простым выбором. CoAP также следует принимать во внимание, поскольку он также быстро развивается как стандарт обмена сообщениями IoT, и вполне вероятно, что в ближайшем будущем он достигнет уровня стабильности и зрелости, аналогичного MQTT и HTTP. Но стандарт сейчас развивается, что сопряжено с краткосрочными проблемами совместимости.

Что ещё полезного можно почитать в блоге Cloud4Y

→ Компьютер сделает вам вкусно
→ AI помогает изучать животных Африки
→ Лето почти закончилось. Не утекших данных почти не осталось
→ 4 способа сэкономить на бэкапах в облаке
→ О едином федеральном информационном ресурсе, содержащем сведения о населении

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью! Пишем не чаще двух раз в неделю и только по делу.

Источник: habr.com