Развіццё тэхналогій у вобласці софту і жалеза, з'яўленне новых пратаколаў сувязі прывялі да пашырэння інтэрнэту рэчаў (IoT). Колькасць прылад расце з кожным днём, і яны генеруюць велізарны аб'ём дадзеных. Таму ўзнікае запатрабаванне ў зручнай архітэктуры сістэмы, здольнай апрацоўваць, захоўваць і перадаваць гэтыя дадзеныя.
Цяпер для гэтых мэт выкарыстоўваюць хмарныя сэрвісы. Аднак якая робіцца ўсё папулярнейшай парадыгма імглістых вылічэнняў (Fog) здольная дапоўніць хмарныя рашэнні, маштабаваўшы і аптымізаваўшы інфраструктуру IoT.
"Аблокі" здольныя закрыць большасць запытаў IoT. Напрыклад, забяспечыць маніторынг службаў, хуткую апрацоўку любых аб'ёмаў дадзеных, якія генерыруюцца прыладамі, а таксама іх візуалізацыю. Імглістыя ж вылічэнні эфектыўней пры рашэнні real-time задач. Яны забяспечваюць хуткі водгук на запыты і мінімальную затрымку пры апрацоўцы дадзеных. Гэта значыць Fog менавіта дапаўняе "аблокі", пашырае яго магчымасці.
Зрэшты, галоўнае пытанне ў іншым: як усё гэта павінна ўзаемадзейнічаць у кантэксце IoT? Якія пратаколы сувязі будуць найболей эфектыўнымі пры працы ў аб'яднанай сістэме IoT-Fog-Cloud?
Нягледзячы на ўяўнае дамінаванне HTTP, у сістэмах IoT, Fog і Cloud выкарыстоўваецца вялікая колькасць іншых рашэнняў. Гэта тлумачыцца тым, што IoT павінен спалучаць функцыянальныя магчымасці разнастайных датчыкаў прылад з бяспекай, сумяшчальнасцю і іншымі патрабаваннямі, якія прад'яўляюцца карыстальнікамі.
Вось толькі адзінага ўяўлення аб эталоннай архітэктуры і стандарце сувязі проста няма. Таму стварэнне новага пратакола або дапрацоўка існуючага пад канкрэтныя задачы IoT з'яўляецца адной з найважнейшых задач, якія стаяць перад ІТ-супольнасцю.
Якія пратаколы выкарыстоўваюцца зараз і што яны могуць прапанаваць? Давайце разбірацца. Але для пачатку абмяркуем прынцыпы экасістэмы, у якой узаемадзейнічаюць аблокі, туман і інтэрнэт рэчаў.
Архітэктура IoT Fog-to-Cloud (F2C)
Вы напэўна заўважалі, наколькі значныя намаганні прыкладаюцца для вывучэння пераваг і выгод, звязаных з рацыянальным і скаардынаваным кіраваннем IoT, аблокамі і туманам. Калі ж не, то вось вам ажно тры ініцыятывы па стандартызацыі: , и .
Калі раней разглядалі толькі 2 ўзроўню, аблокі і канчатковых прылад, то прапанаваная архітэктура ўводзіць новы ўзровень - імглістыя вылічэнні. Пры гэтым узровень туману можа быць падзелены на некалькі падузроўняў, у залежнасці ад спецыфікі рэсурсаў ці набору палітык, якія вызначаюць выкарыстанне розных прылад у гэтых падузроўнях.
Як можа выглядаць гэтая абстракцыя? Вось тыповая экасістэма IoT-Fog-Cloud. IoT-прылады адпраўляюць дадзеныя на больш прадукцыйныя серверы і вылічальныя прылады, каб вырашаць задачы, якія патрабуюць нізкага ўзроўню затрымкі. У гэтай жа сістэме аблокі адказваюць за рашэнне задач, якія патрабуюць вялікага аб'ёму вылічальных рэсурсаў ці месцы для захоўвання дадзеных.
Смартфоны, разумныя гадзіны і іншыя гаджэты таксама могуць быць часткай IoT. Але такія прылады, як правіла, выкарыстоўваюць прапрыетарныя пратаколы сувязі ад буйных распрацоўшчыкаў. Згенераваныя дадзеныя інтэрнэту рэчаў перадаюцца на ўзровень смугі праз пратакол REST HTTP, які забяспечвае гнуткасць і функцыянальную сумяшчальнасць пры стварэнні RESTful-сэрвісаў. Гэта важна ў святле неабходнасці забеспячэння зваротнай сумяшчальнасці з існай вылічальнай інфраструктурай, якая працуе на лакальных кампутарах, серверах ці кластары сервераў. Лакальныя рэсурсы, якія называюць "вузламі туману", фільтруюць атрыманыя дадзеныя і апрацоўваюць іх лакальна або перасылаюць у воблака для далейшых вылічэнняў.
Аблокі падтрымліваюць розныя пратаколы сувязі, сярод якіх часцей за ўсё сустракаюцца AMQP і REST HTTP. Так як HTTP агульнавядомы і заменчаны пад інтэрнэт, можа ўзнікнуць пытанне: "а ці не выкарыстоўваць яго для працы з IoT і туманам?". Аднак у дадзенага пратакола ёсць праблемы з прадукцыйнасцю. Пра гэта пазней.
У цэлым, існуе дзве мадэлі пратаколаў сувязі, падыходных пад патрэбную нам сістэму. Гэта запыт-адказ і публікацыя-падпіска. Першая мадэль вядомая шырэй, асабліва ў архітэктуры сервер-кліент. Кліент запытвае інфармацыю з сервера, а той атрымлівае запыт, апрацоўвае яго і вяртае паведамленне ў адказ. Па гэтай мадэлі працуюць пратаколы 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. Але стандарт зараз развіваецца, што спалучана з кароткатэрміновымі праблемамі сумяшчальнасці.
Што яшчэ карыснага можна пачытаць у блогу
→
→
→
→
→
Падпісвайцеся на наш -канал, каб не прапусціць чарговы артыкул! Пішам не часцей за два разы на тыдзень і толькі па справе.
Крыніца: habr.com