Развој технологија у области софтвера и хардвера, појава нових комуникационих протокола довели су до експанзије Интернета ствари (ИоТ). Број уређаја расте из дана у дан и генеришу огромну количину података. Због тога постоји потреба за прикладном архитектуром система способном за обраду, складиштење и пренос ових података.
Сада се за ове сврхе користе услуге у облаку. Међутим, све популарнија парадигма рачунарства у магли (Фог) може да допуни решења у облаку скалирањем и оптимизацијом ИоТ инфраструктуре.
Облаци су у стању да покрију већину ИоТ захтева. На пример, да обезбеди праћење услуга, брзу обраду било које количине података које генеришу уређаји, као и њихову визуелизацију. Рачунање магле је ефикасније када се решавају проблеми у реалном времену. Они пружају брз одговор на захтеве и минимално кашњење у обради података. То јест, магла допуњује „облаке“ и проширује своје могућности.
Међутим, главно питање је другачије: како би све ово требало да интерагује у контексту интернета ствари? Који комуникациони протоколи ће бити најефикаснији када радите у комбинованом систему ИоТ-Фог-Цлоуд?
Упркос очигледној доминацији ХТТП-а, постоји велики број других решења која се користе у ИоТ, Фог и Цлоуд системима. То је зато што ИоТ мора комбиновати функционалност различитих сензора уређаја са безбедношћу, компатибилношћу и другим захтевима корисника.
Али једноставно не постоји јединствена идеја о референтној архитектури и стандарду комуникације. Стога је креирање новог протокола или модификација постојећег за специфичне ИоТ задатке један од најважнијих задатака са којима се суочава ИТ заједница.
Који протоколи се тренутно користе и шта могу да понуде? Хајде да то схватимо. Али прво, хајде да разговарамо о принципима екосистема у коме облаци, магла и интернет ствари комуницирају.
Архитектура ИоТ магле у облак (Ф2Ц).
Вероватно сте приметили колико се труда улаже у истраживање предности и предности повезаних са паметним и координисаним управљањем интернетом ствари, облаком и маглом. Ако не, ево три иницијативе за стандардизацију: , и .
Ако су се раније разматрала само 2 нивоа, облаци и крајњи уређаји, онда предложена архитектура уводи нови ниво - рачунање магле. У овом случају, ниво магле се може поделити на неколико поднивоа, у зависности од специфичности ресурса или скупа политика које одређују употребу различитих уређаја у овим поднивоима.
Како би ова апстракција могла да изгледа? Ево типичног екосистема ИоТ-Фог-Цлоуд. ИоТ уређаји шаљу податке бржим серверима и рачунарским уређајима како би решили проблеме који захтевају мало кашњење. У истом систему, облаци су одговорни за решавање проблема који захтевају велику количину рачунарских ресурса или простора за складиштење података.
Паметни телефони, паметни сатови и други геџети такође могу бити део интернета ствари. Али такви уређаји, по правилу, користе власничке комуникационе протоколе великих програмера. Генерисани ИоТ подаци се преносе у слој магле преко РЕСТ ХТТП протокола, који обезбеђује флексибилност и интероперабилност приликом креирања РЕСТфул услуга. Ово је важно у светлу потребе да се обезбеди компатибилност уназад са постојећом рачунарском инфраструктуром која ради на локалним рачунарима, серверима или серверском кластеру. Локални ресурси, названи „чворови магле“, филтрирају примљене податке и локално их обрађују или шаљу у облак ради даљих прорачуна.
Облаци подржавају различите комуникационе протоколе, а најчешћи су АМКП и РЕСТ ХТТП. Пошто је ХТТП добро познат и прилагођен Интернету, може се поставити питање: „зар не би требало да га користимо за рад са интернетом ствари и маглом?“ Међутим, овај протокол има проблема са перформансама. Више о овоме касније.
Генерално, постоје 2 модела комуникационих протокола погодних за систем који нам је потребан. То су захтев-одговор и објављивање-претплата. Први модел је шире познат, посебно у архитектури сервер-клијент. Клијент захтева информације од сервера, а сервер прима захтев, обрађује га и враћа поруку одговора. РЕСТ ХТТП и ЦоАП протоколи раде на овом моделу.
Други модел је произашао из потребе да се обезбеди асинхрона, дистрибуирана, лабава веза између извора који генеришу податке и прималаца ових података.
Модел претпоставља три учесника: издавача (извор података), брокера (диспечера) и претплатника (примаоца). Овде, клијент који делује као претплатник не мора да захтева информације од сервера. Уместо да шаље захтеве, он се претплаћује на одређене догађаје у систему преко брокера, који је одговоран за филтрирање свих долазних порука и њихово рутирање између издавача и претплатника. А издавач, када се деси догађај у вези са одређеном темом, то објављује брокеру, који претплатнику шаље податке о траженој теми.
У суштини, ова архитектура је заснована на догађајима. А овај модел интеракције је интересантан за апликације у ИоТ-у, облаку, магли због своје способности да обезбеди скалабилност и поједностави међусобну везу између различитих уређаја, подржава динамичку комуникацију „више-према-више“ и асинхрону комуникацију. Неки од најпознатијих стандардизованих протокола за размену порука који користе модел објављивања и претплате укључују МКТТ, АМКП и ДДС.
Очигледно, модел објављивања и претплате има много предности:
- Издавачи и претплатници не морају да знају за постојање једни других;
- Један претплатник може примати информације из више различитих публикација, а један издавач може слати податке многим различитим претплатницима (принцип много-према-више);
- Издавач и претплатник не морају бити активни истовремено да би комуницирали, јер ће брокер (који ради као систем чекања) моћи да сачува поруку за клијенте који тренутно нису повезани на мрежу.
Међутим, модел захтев-одговор такође има своје предности. У случајевима када способност сервера да обрађује више захтева клијената није проблем, има смисла користити доказана, поуздана решења.
Постоје и протоколи који подржавају оба модела. На пример, КСМПП и ХТТП 2.0, који подржавају опцију „сервер пусх“. ИЕТФ је такође објавио ЦоАП. У покушају да се реши проблем размене порука, креирано је неколико других решења, као што су ВебСоцкетс протокол или употреба ХТТП протокола преко КУИЦ-а (Брзе УДП Интернет везе).
У случају ВебСоцкетс-а, иако се користи за пренос података у реалном времену са сервера на веб клијент и обезбеђује трајне везе уз истовремену двосмерну комуникацију, није намењен уређајима са ограниченим рачунарским ресурсима. КУИЦ такође заслужује пажњу, јер нови транспортни протокол пружа много нових могућности. Али пошто КУИЦ још увек није стандардизован, преурањено је предвиђати његову могућу примену и утицај на ИоТ решења. Тако да имамо на уму ВебСоцкетс и КУИЦ са погледом на будућност, али за сада то нећемо детаљније проучавати.
Ко је најслађи на свету: упоређивање протокола
Хајде сада да причамо о предностима и слабостима протокола. Гледајући унапред, одмах резервишемо да нема јасног лидера. Сваки протокол има неке предности/недостатке.
Време одговора
Једна од најважнијих карактеристика комуникационих протокола, посебно у односу на Интернет ствари, јесте време одзива. Али међу постојећим протоколима, нема јасног победника који показује минимални ниво кашњења при раду у различитим условима. Али постоји читава гомила истраживања и поређења могућности протокола.
На пример, поређења ефикасности ХТТП-а и МКТТ-а при раду са ИоТ-ом показала су да је време одговора за захтеве за МКТТ мање него за ХТТП. И када Време повратног путовања (РТТ) МКТТ-а и ЦоАП-а је открило да је просечни РТТ ЦоАП-а 20% мањи од МКТТ-а.
Друго са РТТ-ом за МКТТ и ЦоАП протоколе спроведена је у два сценарија: локална мрежа и ИоТ мрежа. Испоставило се да је просечан РТТ 2-3 пута већи у ИоТ мрежи. МКТТ са КоС0 је показао нижи резултат у поређењу са ЦоАП, а МКТТ са КоС1 је показао већи РТТ због АЦК-ова на слојевима апликације и транспорта. За различите нивое КоС-а, кашњење мреже без загушења је било милисекунди за МКТТ, а стотине микросекунди за ЦоАП. Међутим, вреди запамтити да ће када радите на мање поузданим мрежама, МКТТ који ради на врху ТЦП-а показати потпуно другачији резултат.
време одзива за АМКП и МКТТ протоколе повећањем корисног оптерећења показало је да је са малим оптерећењем ниво кашњења скоро исти. Али када преноси велике количине података, МКТТ показује краће време одговора. у још једном ЦоАП је упоређен са ХТТП-ом у комуникацијском сценарију од машине до машине са уређајима постављеним на возилима опремљеним сензорима за гас, временским сензорима, сензорима локације (ГПС) и интерфејсом мобилне мреже (ГПРС). Време потребно за пренос ЦоАП поруке преко мобилне мреже било је скоро три пута краће од времена потребног за коришћење ХТТП порука.
Спроведене су студије које су упоређивале не два, већ три протокола. На пример, перформансе ИоТ протокола МКТТ, ДДС и ЦоАП у сценарију медицинске апликације користећи мрежни емулатор. ДДС је надмашио МКТТ у погледу тестиране латенције телеметрије у разним лошим мрежним условима. ЦоАП заснован на УДП-у је добро функционисао за апликације које захтевају брзо време одзива, међутим, због тога што је заснован на УДП-у, дошло је до значајног непредвидивог губитка пакета.
Пропусност
МКТТ и ЦоАП у смислу ефикасности пропусног опсега спроведен је као прорачун укупне количине података пренетих по поруци. ЦоАП је показао нижу пропусност од МКТТ-а при преносу малих порука. Али када се упореди ефикасност протокола у смислу односа броја корисних информационих бајтова и укупног броја пренетих бајтова, ЦоАП се показао ефикаснијим.
У користећи МКТТ, ДДС (са ТЦП као транспортним протоколом) и ЦоАП пропусни опсег, установљено је да је ЦоАП генерално показао релативно нижу потрошњу пропусног опсега, која се није повећавала са повећаним губитком мрежних пакета или повећаним кашњењем мреже, за разлику од МКТТ и ДДС, где је било повећање искоришћености пропусног опсега у поменутим сценаријима. Други сценарио је укључивао велики број уређаја који истовремено преносе податке, што је типично за ИоТ окружења. Резултати су показали да је за већу искоришћеност боље користити ЦоАП.
Под малим оптерећењем, ЦоАП је користио најмањи пропусни опсег, а следе МКТТ и РЕСТ ХТТП. Међутим, када се повећала величина корисног оптерећења, РЕСТ ХТТП је имао најбоље резултате.
Потрошња енергије
Питање потрошње енергије је увек од велике важности, а посебно у ИоТ систему. Ако Док МКТТ и ХТТП троше електричну енергију, ХТТП троши много више. А ЦоАП је више у поређењу са МКТТ, што омогућава управљање напајањем. Међутим, у једноставним сценаријима, МКТТ је погоднији за размену информација у мрежама Интернета ствари, посебно ако нема ограничења напајања.
Експеримент који је упоредио могућности АМКП-а и МКТТ-а на мобилној или нестабилној бежичној мрежи за тестирање открио је да АМКП нуди више безбедносних могућности док је МКТТ енергетски ефикаснији.
безбедност
Безбедност је још једно критично питање које се поставља приликом проучавања теме Интернета ствари и рачунарства у магли/облаку. Сигурносни механизам се обично заснива на ТЛС-у у ХТТП-у, МКТТ-у, АМКП-у и КСМПП-у или ДТЛС-у у ЦоАП-у и подржава обе ДДС варијанте.
ТЛС и ДТЛС почињу са процесом успостављања комуникације између клијентске и серверске стране ради размене подржаних пакета шифара и кључева. Обе стране договарају скупове како би осигурале да се даља комуникација одвија на безбедном каналу. Разлика између њих двоје лежи у малим модификацијама које омогућавају ДТЛС-у заснованом на УДП-у да ради преко непоуздане везе.
У Неколико различитих имплементација ТЛС-а и ДТЛС-а открило је да је ТЛС урадио бољи посао. Напади на ДТЛС су били успешнији због његове толеранције на грешке.
Међутим, највећи проблем са овим протоколима је то што они нису првобитно били дизајнирани за употребу у ИоТ-у и нису били намењени да раде у магли или облаку. Путем руковања, они додају додатни саобраћај при сваком успостављању везе, што исцрпљује рачунарске ресурсе. У просеку, постоји повећање трошкова од 6,5% за ТЛС и 11% за ДТЛС у поређењу са комуникацијама без безбедносног слоја. У окружењима богатим ресурсима, која се обично налазе на нивоу, то неће бити проблем, али у вези између ИоТ-а и нивоа магле, ово постаје важно ограничење.
Шта изабрати? Нема јасног одговора. Чини се да су МКТТ и ХТТП протоколи који највише обећавају јер се сматрају релативно зрелијим и стабилнијим ИоТ решењима у поређењу са другим протоколима.
Решења заснована на јединственом комуникационом протоколу
Пракса једнопротоколног решења има много недостатака. На пример, протокол који одговара ограниченом окружењу можда неће радити у домену који има строге безбедносне захтеве. Имајући ово на уму, остаје нам да одбацимо скоро сва могућа решења са једним протоколом у екосистему Фог-то-Цлоуд у ИоТ-у, осим МКТТ и РЕСТ ХТТП-а.
РЕСТ ХТТП као решење са једним протоколом
Постоји добар пример како РЕСТ ХТТП захтеви и одговори интерагују у ИоТ-то-Фог простору: . Животиње су опремљене сензорима за ношење (ИоТ клијент, Ц) и контролисане су путем рачунарства у облаку помоћу система паметне фарме (Фог сервер, С).
Заглавље ПОСТ методе наводи ресурс за модификовање (/фарм/анималс), као и ХТТП верзију и тип садржаја, што је у овом случају ЈСОН објекат који представља фарму животиња којом систем треба да управља (Дулцинеа/крава) . Одговор сервера показује да је захтев био успешан слањем ХТТПС статусног кода 201 (ресурс креиран). Метода ГЕТ мора навести само тражени ресурс у УРИ-ју (на пример, /фарм/анималс/1), који са сервера враћа ЈСОН приказ животиње са тим ИД-ом.
Метода ПУТ се користи када је потребно ажурирати неки специфични запис ресурса. У овом случају, ресурс наводи УРИ за параметар који треба променити и тренутну вредност (на пример, означава да крава тренутно хода, /фарм/анималс/1? стате=валкинг). Коначно, метода ДЕЛЕТЕ се користи једнако као и ГЕТ метода, али једноставно брише ресурс као резултат операције.
МКТТ као решење са једним протоколом
Узмимо исту паметну фарму, али уместо РЕСТ ХТТП-а користимо МКТТ протокол. Локални сервер са инсталираном библиотеком Москуитто делује као посредник. У овом примеру, једноставан рачунар (који се назива фармски сервер) Распберри Пи служи као МКТТ клијент, имплементиран кроз инсталацију Пахо МКТТ библиотеке, која је у потпуности компатибилна са Москуитто брокером.
Овај клијент одговара слоју апстракције ИоТ-а који представља уређај са сензорским и рачунарским могућностима. Посредник, с друге стране, одговара вишем нивоу апстракције, представљајући магловити рачунарски чвор који карактерише већи капацитет обраде и складиштења.
У предложеном сценарију паметне фарме, Распберри Пи се повезује са акцелерометром, ГПС-ом и сензорима температуре и објављује податке са ових сензора у чвор за маглу. Као што вероватно знате, МКТТ третира теме као хијерархију. Један МКТТ издавач може да објави поруке на одређени скуп тема. У нашем случају их има три. За сензор који мери температуру у штали за животиње, клијент бира тему (животињска фарма/шупа/температура). За сензоре који мере ГПС локацију и кретање животиња кроз акцелерометар, клијент ће објавити ажурирања за (анималфарм/анимал/ГПС) и (анималфарм/анимал/мовемент).
Ове информације ће бити прослеђене брокеру, који их може привремено ускладиштити у локалној бази података у случају да касније дође други заинтересовани претплатник.
Поред локалног сервера, који у магли делује као МКТТ брокер и коме Распберри Пис, који делује као МКТТ клијент, шаље податке сензора, можда постоји још један МКТТ брокер на нивоу облака. У овом случају, информације које се преносе локалном брокеру могу се привремено ускладиштити у локалној бази података и/или послати у облак. Фог МКТТ брокер у овој ситуацији се користи за повезивање свих података са Цлоуд МКТТ брокером. Са овом архитектуром, корисник мобилне апликације може бити претплаћен на оба брокера.
Ако веза са једним од брокера (на пример, облак) не успе, крајњи корисник ће добити информације од другог (магла). Ово је карактеристична карактеристика комбинованих система за маглу и рачунарство у облаку. Подразумевано, мобилна апликација се може конфигурисати да се прво повеже са брокером за маглу МКТТ, а ако то не успе, да се повеже са МКТТ брокером у облаку. Ово решење је само једно од многих у ИоТ-Ф2Ц системима.
Вишепротоколна решења
Решења са једним протоколом су популарна због лакше имплементације. Али јасно је да у ИоТ-Ф2Ц системима има смисла комбиновати различите протоколе. Идеја је да различити протоколи могу да раде на различитим нивоима. Узмите, на пример, три апстракције: слојеве интернета ствари, магле и рачунарства у облаку. Уређаји на нивоу интернета ствари се генерално сматрају ограниченим. За овај преглед, узмимо у обзир ИоТ нивое као највише ограничене, облаке најмање ограничене, а рачунање магле као „негде у средини“. Испоставило се да између апстракција интернета ствари и магле, тренутна решења протокола укључују МКТТ, ЦоАП и КСМПП. Између магле и облака, с друге стране, АМКП је један од главних протокола који се користи, заједно са РЕСТ ХТТП, који се због своје флексибилности такође користи између слојева ИоТ-а и магле.
Главни проблем овде је интероперабилност протокола и лакоћа преноса порука са једног протокола на други. У идеалном случају, у будућности, архитектура система Интернета ствари са ресурсима облака и магле биће независна од коришћеног комуникационог протокола и обезбедиће добру интероперабилност између различитих протокола.
Пошто то тренутно није случај, има смисла комбиновати протоколе који немају битне разлике. У том циљу, једно потенцијално решење је засновано на комбинацији два протокола који прате исти архитектонски стил, РЕСТ ХТТП и ЦоАП. Друго предложено решење заснива се на комбинацији два протокола који нуде комуникацију објављивања и претплате, МКТТ и АМКП. Коришћење сличних концепата (и МКТТ и АМКП користе брокере, ЦоАП и ХТТП користе РЕСТ) чини ове комбинације лакшим за имплементацију и захтева мање напора за интеграцију.
Слика (а) приказује два модела заснована на захтев-одговор, ХТТП и ЦоАП, и њихово могуће постављање у ИоТ-Ф2Ц решење. Пошто је ХТТП један од најпознатијих и најприхваћенијих протокола на савременим мрежама, мало је вероватно да ће га у потпуности заменити други протоколи за размену порука. Међу чворовима који представљају моћне уређаје који се налазе између облака и магле, РЕСТ ХТТП је паметно решење.
С друге стране, за уређаје са ограниченим рачунарским ресурсима који комуницирају између слојева магле и ИоТ-а, ефикасније је користити ЦоАП. Једна од великих предности ЦоАП-а је заправо његова компатибилност са ХТТП-ом, пошто су оба протокола заснована на РЕСТ принципима.
Слика (б) приказује два комуникациона модела објављивања и претплате у истом сценарију, укључујући МКТТ и АМКП. Иако би се оба протокола хипотетички могла користити за комуникацију између чворова на сваком слоју апстракције, њихов положај треба одредити на основу перформанси. МКТТ је дизајниран као лагани протокол за уређаје са ограниченим рачунарским ресурсима, тако да се може користити за ИоТ-Фог комуникацију. АМКП је погоднији за моћније уређаје, који би га идеално позиционирали између чворова магле и облака. Уместо МКТТ, КСМПП протокол се може користити у ИоТ-у јер се сматра лаганим. Али није тако широко коришћен у таквим сценаријима.
Налази
Мало је вероватно да ће један од разматраних протокола бити довољан да покрије све комуникације у систему, од уређаја са ограниченим рачунарским ресурсима до сервера у облаку. Студија је открила да су две опције које највише обећавају које програмери највише користе МКТТ и РЕСТфул ХТТП. Ова два протокола нису само најзрелији и најстабилнији, већ укључују и многе добро документоване и успешне имплементације и онлајн ресурсе.
Због своје стабилности и једноставне конфигурације, МКТТ је протокол који је током времена доказао своје супериорне перформансе када се користи на нивоу ИоТ-а са ограниченим уређајима. У деловима система где ограничена комуникација и потрошња батерије нису проблем, као што су неки домени магле и већина рачунарства у облаку, РЕСТфул ХТТП је лак избор. ЦоАП такође треба узети у обзир јер се такође брзо развија као ИоТ стандард за размену порука и вероватно ће достићи ниво стабилности и зрелости сличан МКТТ и ХТТП у блиској будућности. Али стандард се тренутно развија, што долази са краткорочним проблемима компатибилности.
Шта још можете прочитати на блогу?
→
→
→
→
→
Претплатите се на наш -канал, да не пропустите следећи чланак! Пишемо не више од два пута недељно и само пословно.
Извор: ввв.хабр.цом