что такое туманные вычисления
Fog computing
Если вам кажется, что на картинке ничего не видно, то я отвечу, на картинке отчетливейшим образом изображен туман! 😉 В связи с выходом из вынужденного захабренного молчания публикую свой небольшой футурологический очерк.
Ура! То, о чем так давно боялись спросить большевики, случилось! В след за облачными вычислениями сегодня мы открываем эпоху туманных (fog) вычислений!
Туманные вычисления — и звучит как-то туманно. Попробую в двух словах донести эту парадигму до читателя, невооруженного википедией и гуглом. Для вооруженных же придется сказать, что сие словосочетание уже было испохаблено одним из видов облачных вычислений, которые принципиально ни чем от них не отличаются.
Итак, туманные вычисления. Как нетрудно догадаться, «туман» — это, как и «облако» некоторая связанная распределенная вычислительная мощность. Применим дифференциальный подход к облаку и положим, что вместо одного дискретного узла облака (да, в настоящих облаках нет узлов и в этом кроется вся фальшивость этого термина) в составе: процессор, ОЗУ, ПЗУ, устройства ввода/вывода мы имеем скалярное поле (распределение в объеме плотности) вычислительной мощности, оперативной и постоянной памяти, а также векторное поле потоков данных.
В этой точке можно выдохнуть и дальше попробую без этих заморочек. Компьютеры становятся меньше. Компьютеры становятся дешевле. Сейчас МП3 плейер имеет вычислительную мощность на порядки больше, чем первый компьютер, созданный для решения сверх ответственных военных и научных задач. Про размер и самое главное — потребление энергии я молчу. Сейчас плотность вычислительных устройств настолько высока, что впору применять к ней статистические методы. Когда-то видел отличную статью, где приводилась суммарная выч. мощность устройств в разрезе выч. мощности одного устройства и оказалось, что вся сила не в суперкомпьютерах, а в дешевых мобильных телефонах.
Вместе с удешевлением компьютеров подешевели и системы связи. Блютус есть почти везде и я не уверен, что в моих кроссовках его нет. И вот именно сейчас не осталось преград для того, чтоб все эти маленькие слабенькие вычислительные машинки объединились в один большой сиреневый вычислительный туман.
В основе «тумана» лежит «капля» — чип микроконтроллера с памятью и интерфейсом для передачи данных на борту, и чип беспроводной связи типа Mesh (сенсорная сеть). Питание «капля» получает от маленькой батарейки, которой тем не менее хватит на пару лет работы с регулярными перерывами на сон (picoPower от Atmel рулит). К «капле» могут быть подключены устройства ввода (датчики всех мастей, от температуры и напряжения до положения в пространстве и уровня ультрафиолетового излучения) и вывода (светодиоды, жк и лед индикторы, сухие контакты и т.п.) Уже попахивает Скайнетом, не правда ли?
«И вот когда мы в двух шагах от груды сказочных богатств. » — как пел герой известного мультмюзикла, остается самое интересное — в этой сети может хранится и обрабатываться информация, непосредственно не связанная с этими самыми датчиками. Очевидно, что для большинства задач производительности современных микроконтроллеров более чем достаточно и мы получаем поле избыточной вычислительной мощности. А денег, патронов и вычислительной мощности, как известно, лишних никогда не бывает.
Для обеспечения более производительной передачи данных, в тумане будут создаваться дополнительные туннели — некоторые «капли» могут иметь высокоскоростные интерфейсы и обеспечивать лучшую связность тумана. Не пройдет и 10 лет как вычислительный туман охватит весь ареал обитания человека разумного и из коммерческих частных облаков вычисления уйдут в туман, который не имеет собственника. Программы будут паразитировать на вычислительном тумане и конкурировать между собой. Это будет экосистема, на порядок более живая, чем Интернет.
Вот такая вот у нас получается штука. Поживем увидим, был ли прав С.Лем в своем «Футурологическом конгрессе» и я в вычислительном тумане?
Что такое туманные вычисления
За последнее десятилетие IT-индустрия перепрела серьезные изменения. Наиболее кардинальным решением стало появление облачных технологий в области хранения данных, вычислений, сетевого взаимодействия. Но в современных реалиях даже его возможностей уже недостаточно. Сегодня с наибольшими ограничениями столкнулся интернет вещей. Решить такие проблемы должны туманные вычисления. Это передовая концепция в облачной архитектуре, предполагающая обработку данных на периферийных устройствах сети – ПК, смартфонах, персональных гаджетах и пр., выводя их из облака. Познакомимся более подробно, что такое туманные вычисления, что стало причиной их развития, как они построены и где могут использоваться.
В чем же проблема?
Как показала практика, облачные технологии имеют ряд ограничений. И они негативно сказываются на удобстве работы. Судите сами:
Технологии идут вперед, а возможности для их реализации стоят на месте. И с этим надо что-то делать. На устранение таких проблем и направлены технологии туманных вычислений.
Эффективное решение: туманные вычисления
Наиболее уязвимое место виртуальных технологий – полоса связи между периферийными устройствами и облаком. Уменьшить нагрузку на нее можно только единственным способом – снизить количество передаваемых данных. Если же работы ведутся с время-чувствительными коммуникациями, требуется снизить время задержки. И реализовать это можно только, если весь аналитический блок перенести их облака на персональные компьютеры, смартфоны и другие периферийные устройства. Именно этим и занимаются туманные технологии. Они помогают решать ключевые проблемы интернета вещей, что и стало основной причиной их популярности.
Итак, туманные вычисления – это передовой подход к построению софтов, при котором центр обработки данных размещается не в облаке, а в непосредственной близости от конечных пользователей. Применяется он преимущественно для обслуживания транзакций, критически зависящих от времени. Без классического облака здесь не обходится. Но между ним и периферией включается несколько дополнительных слоев, мини-ЦОДов. Это и есть туманные облака. Они берут на себя время-зависимые операции, обрабатывают их. Так исключается обращение к основному облаку. Туманные слои способные покрывать географические территории так же, как сотовые операторы: в непосредственной близости от каждого пользователя есть своя «вышка». Все обработки выполняются в режиме реального времени. Здесь задержки составляют от 1 до 10 миллисекунд, что в 100-10 раз меньше, чем в случае использования основного облака.
Получается, что большие облака и туманные распределяют обязанности:
То есть туман – это новый этап в эволюции виртуальных технологий. Он открывает перед бизнесом новые возможности благодаря местной обработке данных. Подобные вычисления преимущественно работают с интернетом вещей, то есть с услугами и софтами, слабо совместимыми с Cloud или вовсе с ним не функционируют. Они требуют изначальной обработки информации или ее фильтрации перед отправкой в облако.
На практике туманные технологии позволяют получать отличный результат при работе с программами, которые:
Туман – это не альтернатива, а дополнение Cloud, особенно в области администрирования, аналитики данных и пр.
Реализация и построение туманных облаков
Работает технология на стандартной структуре, которую мировое сообщество знает под термином OpenFog RA. Она была создана в 2015 году консорциумом OpenFog, в который вошли передовые компании из области IT-индустрии.
По своей инфраструктуре и архитектуре облачные и туманные вычисления очень схожи. И первые, и вторые используют серверы и процессоры периферийных гаджетов, коммутационные узлы, блоки хранения информации. Но вот техническая сторона у Fog и классического облака разная.
Архитектура туманного облака – некий аналог «прослойки» между классическим облаком, оборудованием, работающими с интернетом вещей и периферическими гаджетами. В отличие от построения Cloud, туман имеет свои особенности:
Согласно туманной архитектуре те полслойки, которые географически будут располагаться ближе к виртуальным дата-центрам, будут обладать более высокими вычислительными возможностями и объемами для хранения данных. А вот туманные облака, находящиеся ближе к персональным устройствам и сенсорам интернета вещей имеют более высокую скорость отклика и интерактивность.
Чтобы ПК или другой гаджет смог стать узлом туманной сети, владелицу необходимо дать оператору доступ к нему в фоновом режиме. Операторы же в свою очередь за такую услугу предоставляют дополнительные льготы такому пользователю.
Сценарии использования туманных вычислений
Уже сегодня существует огромное количество сценариев, использующих туманные вычисления. Но технологии, в том числе и смежные, не стоят на месте. И это дает старт развитию как Fog Computing, так и появления новых сценариев его применения.
Рассмотрим несколько примеров, где могут использоваться туманные вычисления:
Автономные системы управления транспортом
Работа всех автономных систем управления транспортом (ADS) основана на:
Программы, согласно которым функционируют данные системы, требуют мгновенного быстродействия. Поэтому их размещают в самом автомобиле.
Электронное здравоохранение
Туманные технологии в eHealth применяются для мгновенного снятия данных с датчиков, которые носит пациент. Это позволит врачам быстро принимать соответствующие меры в случае возникновения критических ситуаций. На практике такие системы применяются для мониторинга состояния здоровья пациентов, страдающих сахарным диабетом и автоматического выполнения инъекции.
Работает это так: сенсор срабатывает в случае критического повышения уровня глюкозы в крови. Через туманное облако он передает сигнал на введение лекарства – на теле пациента предусмотрен микро-шприц с одной дозой препарата. То есть человеку, страдающему сахарным диабетом, самостоятельно больше не надо контролировать уровень глюкозы в крови и лично делать уколы инсулина.
Облачные провайдеры
Буквально сразу после появления туманных технологий, ведущие мировые провайдеры Amazon, Google, Microsoft запустили в работу ряд проектов в области безсерверной архитектуры на базе собственных экосистем интернета вещей. Так, у Amazon это была платформа Greengrass – контейнер для реализации программного модуля. Google создала Android-платформу для интернета вещей. Microsoft работает с поддержкой функционала Azure.
Это не единственные проекты, которые сегодня находятся в разработке. Рынок постоянно развивается, совершенствуется, открываются новые направления. И все говорит о том. что речь идет о технологии будущего.
Если вам нужна помощь во внедрении туманных вычислений в собственные бизнес-процессы, обращайтесь за профессиональной помощью к специалистам компании «Xelent». Консультации можно получить по телефону и через форму обратной связи.
Облачные, туманные и граничные вычисления: отличия и перспективы развития технологий
Облачными вычислениями уже никого не удивишь — они стабильно развиваются и завоевывают российский рынок. Но туманные и граничные технологии только приходят в нашу страну, и у них есть своя ценность для бизнеса.
Разберемся, чем отличаются виды вычислений, в чём их преимущества и недостатки, а также в каких индустриях они наиболее актуальны.
Облачные вычисления (Cloud computing)
Облачные вычисления — это технология, которая позволяет хранить и обрабатывать данные удаленно в «облаке». Для этого используются центры обработки данных (ЦОДы). Компании, применяющей облачные технологии, не обязательно создавать свою IT-инфраструктуру — все необходимое ей может предоставить провайдер. Нужен только доступ в интернет, чтобы открыть сайт или приложение.
Преимущества и недостатки
Сфера применения
Облачные технологии применяются повсеместно: в госсекторе, производстве, ритейле, IT-компаниях, финансовой сфере и телекоммуникациях. Сложно представить современную жизнь без электронной почты, Google Docs, магазинов приложений и публичных облаков вроде Dropbox, Google Drive или «Яндекс.Диска».
«Cloud Computing наиболее динамично развивается последнее десятилетие, уровень проникновения технологии в развитых странах превышает 90%. Компании-операторы облаков и дата-центров обладают значительной экспертизой в этой области и могут предоставить пользователю наиболее совершенные технологические решения в области IT-инфраструктуры on-demand».
Облака важны для сбора, хранения и обработки больших объемов информации — например, там, где применяются технологии Big Data и искусственный интеллект.
Туманные вычисления (Fog computing)
Туманные вычисления — это технология, благодаря которой хранение и обработка данных происходят в локальной сети между конечным устройством и ЦОД. «Туман», в отличие от «облака», находится ближе к пользователям. Это децентрализованная система, которая фильтрует информацию, поступающую в дата-центр.
Преимущества и недостатки
Сфера применения
Туманные вычисления применяются для связи устройств интернета вещей (IoT). С помощью «тумана» данные передаются и анализируются почти без задержек, что критично для некоторых IoT-устройств — например, датчиков в беспилотных автомобилях.
«Проще говоря, туманные вычисления заточены под межмашинное взаимодействие и применяться могут в любой отрасли, где оно используется — в производстве, здравоохранении, энергетике, финансовой сфере и других».
Межмашинное взаимодействие (Machine-to-Machine, M2M) — технология, связанная с интернетом вещей. Она позволяет передавать данные с устройства на устройство без взаимодействия с человеком. Для этого используют сотовую связь, поэтому мобильные операторы предлагают свои услуги в сфере M2M.
Технологию применяют для передачи данных из банкоматов и торговых автоматов, мониторинга состояния пациентов, в системах сигнализации и видеонаблюдения, в датчиках топлива, счетчиках электроэнергии и воды, для отслеживания транспорта и грузов. Туманные вычисления позволят машинам общаться быстрее и эффективнее.
Граничные вычисления (Edge computing)
Граничные вычисления — это технология обработки и хранения данных на конечном устройстве. Они находятся еще ближе к пользователю, чем «облако» и «туман».
Преимущества и недостатки
Сфера применения
Сферы применения граничных и туманных технологий во многом пересекаются. Главное их преимущество — скорость передачи и анализа данных. Поэтому эти технологии используются там, где важна обработка информации в реальном времени — например, в сферах IoT и VR/AR.
На производстве граничные вычисления нужны для своевременного обслуживания оборудования, в нефтяной индустрии они помогут обнаружить неисправности и протечки, а в банковской сфере технология позволит быстро принять решение по кредиту или обнаружить мошенничество. Во всех примерах граничные вычисления помогают действовать без задержек.
«Edge нашел широкое применение на промышленных предприятиях. Облачные вычисления демонстрируют гибкость и эффективность, но распространение IIoT и мобильных вычислений привело к ограничению диапазона частот для обработки. Также нюанс заключается в том, что “умное” оборудование на предприятиях не всегда требует подключения к cloud для выполнения расчетов. В таких случаях проектировщики сетей делают ставку на периферию и повышают эффективность обработки данных».
Источник: CB Insights
Перспективы развития облаков
Популярнее всех оказались публичные облака — затраты на них составили 85% расходов. Остальное потратили на частные облака. По прогнозам цифры будут расти: в 2019 году расходы увеличатся на 23,6%, а среднегодовые темпы роста рынка до 2023 года будут составлять 14,6%.
Государство тоже заинтересовано в облачных технологиях. Минкомсвязи вместе с «Ростелекомом» давно разрабатывает идею «Гособлака». А в конце августа 2019 года была утверждена концепция единой государственной облачной платформы. Госструктуры будут выбирать между частными провайдерами облачных услуг.
Развитие edge/fog computing
В мире
Уже сейчас компании начинают применять граничные и туманные вычисления наряду с облаками. Конечно, на Западе эти технологии более развиты — их используют и крупные корпорации, и стартапы.
Большие компании, которые продают облачные услуги, расширяют ассортимент. Microsoft предлагает не только облако, но и решения с граничными технологиями. Например, систему, которая позволяет перенести часть вычислений на IoT-устройства, или пограничный сервер для обработки данных с искусственным интеллектом. Amazon тоже не отстает и предлагает свой сервис для интернета вещей с граничными вычислениями. При этом компании не забывают про основной продукт — данные не только обрабатываются на периферии, но и передаются в облако.
Новые технологические услуги помогают в обработке данных на производстве, где задержки — серьёзная помеха в работе.
«В первую очередь это, конечно же, машиностроение и автомобилестроение, так как в этих отраслях производятся технически сложные изделия, а производственные линии генерируют большой объём данных. Но технологии периферийных и облачных вычислений внедряются в самые разнообразные отрасли промышленности, включая нефтегазовую, пищевую, химическую промышленность, производство батарей, в инфраструктурные объекты, распределение электроэнергии, водоснабжение, аэропорты и железнодорожный транспорт».
Появляются стартапы, которые фокусируются на применении граничных и туманных вычислений. Например, FogHorn и Pixeom предлагают услуги для компаний в энергетике, телекоме, производстве, ритейле, финансах, безопасности и других сферах. SimShine разрабатывает граничные технологии для камер видеонаблюдения. Компаний, которые предоставляют услуги производству и простым пользователям, становится все больше.
«Таких компаний и решений на самом деле много. В качестве актуального наглядного примера можно привести компании, которые сейчас внедряют решения по видеоаналитике. При отсутствии объектов или событий видео не передаётся на центральный сервер и не загружает каналы связи. При этом в ЦОД передаётся только информация о тревожных событиях и инцидентах».
В России
Но и в России туманные и граничные вычисления уже не новые понятия.
Пока государственные организации экспериментируют со связью, стартапы внедряют практические решения. С туманными вычислениями работает SONM — предлагает платформу с технологией блокчейна. Идея состоит в том, чтобы создать децентрализованный суперкомпьютер. Пользователи могут сдать мощность своего компьютера в аренду и присоединиться к распределенной сети. Компании в свою очередь покупают возможности туманной платформы для своих вычислений.
С граничными технологиями также связан стартап Facemetric. Он предоставляет клиентам камеры видеонаблюдения и ЦОД с нейросетями, чтобы искать образы в видео — лица, автомобильные номера, ценники и многое другое. Но хранить и обрабатывать большой видеопоток в облаке тяжело и не всегда целесообразно.
Поэтому компания решила использовать граничные вычисления. «В данном случае мы используем более высокопроизводительные вычислители, которые дублируют в себе функционал распознавания, хранят оперативный слепок базы данных и могут работать автономно при потере связи с облачным сервисом. Такой подход повышает требования к производительности вычислителей, их стоимость, но обеспечивает стабильную работу при потере связи с центральным узлом», — рассказывает Юрий Годына, основатель Facemetric.
В России новые технологии будут развиваться и дальше. Как отмечает Юрий Годына, они уже вошли в нашу жизнь:
«В настоящее время появилось множество вариантов реализации проектов в области интернета вещей и граничных вычислений — сбор показаний счетчиков, умные автобусные остановки, системы контроля за водителями общественного транспорта и так далее. Еще пару лет назад на конференциях и круглых столах можно было услышать мнения о раздутости пузыря интернета вещей, умного дома, неподъемной стоимости решений. А сейчас мы видим реализацию этих технологий, они постепенно приходят в нашу жизнь и делают ее комфортнее».
Конечно, туманные и граничные вычисления не вытеснят облако. Технологии будут развиваться вместе и дополнять друг друга. Там, где нужны надежные мощные ЦОДы и экономия IT-ресурсов, облако останется в приоритете. А там, где важна скорость принятия решений, будут развиваться edge и fog computing — при этом облако будет хранить важные данные.
Татьяна Бочарникова, глава представительства NetApp в России и СНГ:
«Бытует мнение, что Edge и Fog computing в конечном итоге полностью заменят собой уже ставшие привычными облачные решения. Но это вовсе не так. Да, бывает, что периферийные технологии обеспечивают более серьезные преимущества, чем полностью централизованные облачные платформы, особенно с точки зрения хранения данных. Но всегда ядром корпоративной ИТ-инфраструктуры остается гибридная и мультиоблачная концепция. Иначе говоря, периферийные и туманные вычисления не заменят облачные, так как, по сути, и являются не чем иным, как “расширением” и “продолжением” облака».
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
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью! Пишем не чаще двух раз в неделю и только по делу.