Rozvoj technologií v oblasti softwaru a hardwaru, vznik nových komunikačních protokolů vedl k rozšíření internetu věcí (IoT). Počet zařízení roste každým dnem a generují obrovské množství dat. Proto vzniká potřeba pohodlné architektury systému, schopného tyto data zpracovávat, ukládat a přenášet.
V současnosti se k těmto účelům používají cloudové služby. Nicméně stále populárnější paradigma mlžného výpočtu (Fog) může doplnit cloudová řešení, škálovat a optimalizovat infrastrukturu IoT.
Cloudy dokážou splnit většinu požadavků IoT. Například zajistit monitoring služeb, rychlé zpracování jakéhokoliv objemu dat generovaných zařízeními, stejně jako jejich vizualizaci. Mlhavé výpočty jsou efektivnější při řešení úloh v reálném čase. Zajišťují rychlou odezvu na požadavky a minimální zpoždění při zpracování dat. To znamená, že Fog skutečně doplňuje cloudy a rozšiřuje jejich možnosti.
Nicméně hlavní otázka leží jinde: jak by to vše mělo interagovat v kontextu IoT? Které komunikační protokoly budou nejefektivnější při práci v integrovaném systému IoT-Fog-Cloud?
I přes zdánlivé dominování HTTP se v systémech IoT, Fog a Cloud používá velké množství jiných řešení. To je dáno tím, že IoT musí kombinovat funkční možnosti různých senzorů zařízení s bezpečností, kompatibilitou a dalšími požadavky uživatelů.
Ale jednotné představy o referenční architektuře a standardu komunikace prostě neexistuje. Proto je vytvoření nového protokolu nebo úprava stávajícího pro konkrétní úkoly IoT jednou z nejdůležitějších úloh, které stojí před IT komunitou.
Jaké protokoly se nyní používají a co mohou nabídnout? Pojďme to prozkoumat. Ale nejprve prodiskutujme principy ekosystému, ve kterém interagují cloudy, mlha a internet věcí.
Architektura IoT Fog-to-Cloud (F2C)
Určitě jste si všimli, jak významné úsilí je vynaloženo na studium výhod a zisků spojených s efektivním a koordinovaným řízením IoT, cloudů a mlhy. Pokud ne, pak zde máte tři iniciativy pro standardizaci: , a .
Pokud dříve byly zvažovány pouze 2 úrovně, cloud a koncová zařízení, navrhovaná architektura zavádí novou úroveň - mlžné výpočty. Úroveň mlhy může být rozdělena do několika podúrovní, v závislosti na specifikaci zdrojů nebo souboru politik, které určují použití různých zařízení na těchto podúrovních.
Jak by mohla tato abstrakce vypadat? Zde je typická ekosystém IoT-Mist-Cloud. Zařízení IoT posílají data na výkonnější servery a výpočetní zařízení, aby řešily úkoly, které vyžadují nízkou latenci. V tomto systému cloudu odpovídají za řešení úloh, které vyžadují velké množství výpočetních zdrojů nebo úložného prostoru.
Smartphony, chytré hodinky a další gadgety mohou být také součástí IoT. Tato zařízení však obvykle používají proprietární komunikační protokoly od velkých výrobců. Generovaná data internetu věcí jsou přenášena na úroveň mlhy prostřednictvím protokolu REST HTTP, který zajišťuje flexibilitu a funkční kompatibilitu při vytváření RESTful služeb. To je důležité vzhledem k nutnosti zajištění zpětné kompatibility se stávající výpočetní infrastrukturou fungující na lokálních počítačích, serverech nebo clusteru serverů. Lokální zdroje, které se nazývají 'uzly mlhy', filtrují přijatá data a zpracovávají je lokálně nebo je zasílají do cloudu pro další výpočty.
Cloudy podporují různé komunikační protokoly, mezi kterými se nejčastěji objevují AMQP a REST HTTP. Vzhledem k tomu, že HTTP je veřejně známý a je určen pro internet, může vzniknout otázka: 'nezapnout ho pro práci s IoT a mlhou?'. Tento protokol však má výkonové problémy. O tom později.
Celkově existují 2 modely komunikačních protokolů, které vyhovují našemu systému. Jsou to model požadavek-odpověď a publikace-předplatné. První model je známější, zejména v architektuře server-klient. Klient požaduje informace ze serveru, server přijímá požadavek, zpracovává ho a vrací odpovědní zprávu. Podle tohoto modelu pracují protokoly REST HTTP a CoAP.
Druhý model vznikl z potřeby zajistit asynchronní, distribuované, slabé spojení mezi zdroji generujícími data a příjemci těchto dat.
Model zahrnuje tři účastníky: vydavatele (zdroj dat), brokera (dispečera) a odběratele (příjemce). Zde klient, který vystupuje jako odběratel, nemusí vyžadovat informace ze serveru. Místo zasílání požadavků se přihlašuje k určitém událostem v systému prostřednictvím brokera, který filtruje všechny příchozí zprávy a směruje je mezi vydavateli a odběrateli. Když dojde k události, která se týká určitého tématu, vydavatel ji zveřejňuje brokerovi, který posílá odběrateli data o požadovaném tématu.
V podstatě je tato architektura založena na událostech. A takový model interakce je zajímavý pro aplikace v IoT, cloudu, rámci kvůli své schopnosti zajistit škálovatelnost a usnadnit vzájemné propojení mezi různými zařízeními, podporovat dynamické spojení „mnoho-k-mnohým“ a asynchronní spojení. Mezi nejznámější standardizované protokoly pro výměnu zpráv, které využívají model „publikování - odběr“, patří MQTT, AMQP a DDS.
Je zřejmé, že model „publikování - odběr“ má řadu výhod:
- Vydavatele a odběratele nemusí znát existenci jeden druhého;
- Jeden odběratel může získávat informace od mnoha různých vydavatelů, a jeden vydavatel může zasílat data mnoha různým odběratelům (princip „mnoho-k-mnohým“);
- Vydavatel a odběratel nemusí být aktivní současně pro výměnu dat, protože broker (fungující jako systém front) může uchovat zprávu pro klienty, kteří nejsou momentálně připojeni k síti.
Nicméně model „požadavek-odpověď“ má také své silné stránky. V případech, kdy možnosti serverové strany pro zpracování požadavků více klientů nejsou problémem, má smysl používat již osvědčená spolehlivá řešení.
Existují také protokoly, které podporují obě modely. Například XMPP a HTTP 2.0, které podporují možnost „server push“. IETF také vydalo CoAP. V pokusu vyřešit problém přenosu zpráv bylo vytvořeno několik dalších řešení, jako je protokol WebSockets nebo použití protokolu HTTP přes QUIC (Quick UDP Internet Connections).
Pokud jde o WebSockets, i když je používán pro přenos dat v reálném čase ze serveru na webového klienta a zajišťuje trvalé spojení s oboustrannou komunikací, není určen pro zařízení s omezenými výpočetními zdroji. QUIC také stojí za pozornost, protože nový transportní protokol přináší řadu nových možností. Ale protože QUIC ještě nebyl standardizován, je předčasné předpovídat jeho možné využití a vliv na řešení v oblasti IoT. Takže WebSockets a QUIC si uchováváme v paměti s výhledem do budoucnosti, ale podrobněji je zatím zkoumat nebudeme.
Kdo je na světě nejmilejší: porovnáváme protokoly
Nyní budeme mluvit o silných a slabých stránkách protokolů. Abychom to shrnuli, ihned je třeba říci, že neexistuje jednoznačný lídr. Každý protokol má nějaké výhody a nevýhody.
Doba odezvy
Jednou z nejdůležitějších charakteristik komunikačních protokolů, zejména ve vztahu k internetu věcí, je doba odezvy. Ovšem mezi existujícími protokoly neexistuje bezpodmínečný vítěz, který by prokazoval minimální úroveň latence v různých podmínkách. Existuje však celá řada výzkumů a porovnání schopností protokolů.
Například, srovnání efektivity HTTP a MQTT při práci s IoT ukázala, že doba odezvy pro požadavky u MQTT je kratší než u HTTP. A při doby příjmu a vysílání (RTT) MQTT a CoAP se ukázalo, že průměrný RTT CoAP je o 20 % kratší než u MQTT.
Jiný S RTT protokolů MQTT a CoAP byl proveden ve dvou scénářích: v místní síti a v síti IoT. Ukázalo se, že průměrný RTT je ve síti IoT 2-3krát vyšší. MQTT s QoS0 vykázal nižší výsledek ve srovnání s CoAP, zatímco MQTT s QoS1 demonstroval vyšší RTT díky ACK na aplikační a transportní úrovni. Pro různé úrovně QoS byly latence v síti bez přetížení pro MQTT v milisekundách, zatímco pro CoAP byly v řádu stovek mikrosekund. Je však třeba mít na paměti, že ve špatně spolehlivých sítích ukáže MQTT, fungující nad TCP, zcela odlišný výsledek.
Doba odezvy protokolů AMQP a MQTT při zvyšování užitečné zátěže ukázala, že při malé zátěži je úroveň latence téměř stejná. Ale při přenosu velkého objemu dat vykazuje MQTT menší dobu odezvy. Ještě v jednom CoAP byl porovnán s HTTP ve scénáři strojové komunikace s zařízeními, která byla nasazena na vozidlech a vybavena plynovými senzory, meteorologickými senzory, lokalizací (GPS) a rozhraním mobilní sítě (GPRS). Čas potřebný k přenosu zprávy CoAP přes mobilní síť byl téměř třikrát kratší než čas potřebný pro použití zpráv HTTP.
Byly provedeny studie, které porovnávaly nejen dva, ale tři protokoly. Například výkonnosti IoT protokolů MQTT, DDS a CoAP ve scénáři lékařské aplikace s využitím síťového emulátoru. DDS překonal MQTT z hlediska zjištěné latence telemetrie za různých špatných podmínek sítě. CoAP založený na UDP pracovál dobře pro aplikace vyžadující rychlou odezvu, avšak kvůli tomu, že je založen na UDP, došlo k výrazné nepředvídatelné ztrátě paketů.
Šířka pásma
MQTT a CoAP z hlediska efektivity využití propustnosti bylo provedeno jako výpočet celkového množství dat přenášených v jedné zprávě. CoAP vykázal nižší propustnost než MQTT při přenosu malých zpráv. Ale při porovnání efektivity protokolů z hlediska poměru počtu užitečných informačních bytů k celkovému množství přenesených bytů se CoAP ukázal jako efektivnější.
Při Při používání propustnosti kanálu MQTT, DDS (s TCP jako transportním protokolem) a CoAP se ukázalo, že CoAP obvykle vykazuje relativně nižší spotřebu šířky pásma, která se nezvyšovala se zvyšujícími se ztrátami síťových paketů nebo zvýšenou latencí sítě, na rozdíl od MQTT a DDS, kde v uvedených scénářích docházelo k růstu využití propustnosti kanálu. V jiném scénáři bylo zapojeno velké množství zařízení, která předávala data současně, což je typický případ v prostředích IoT. Výsledky ukázaly, že pro vyšší zátěž je lepší používat CoAP.
Při nízké zátěži používal CoAP nejmenší propustnost, následovaný MQTT a REST HTTP. Nicméně, když se velikost payloadů zvýšila, nejlepší výsledky byly u REST HTTP.
Spotřeba energie
Otázka spotřeby energie je vždy důležitá, a v systému IoT obzvlášť. Pokud spotřebu elektrické energie u MQTT a HTTP, pak HTTP „spotřebovává“ mnohem více. A CoAP je více ve srovnání s MQTT, což umožňuje řízení napájení. V jednoduchých scénářích je však MQTT vhodnější pro výměnu informací v sítích internetu věcí, zejména pokud neexistují žádná omezení výkonu.
experiment, při kterém byly porovnány možnosti AMQP a MQTT na zkušebním zařízení v mobilní či nestabilní bezdrátové síti, ukázal, že AMQP nabízí více možností z hlediska bezpečnosti, zatímco MQTT je energeticky efektivnější.
Bezpečnost
Bezpečnost je další klíčová otázka, která se objevuje při zkoumání tématu internetu věcí a okrajového/oblačného výpočtu. Bezpečnostní mechanismus se obvykle zakládá na TLS v HTTP, MQTT, AMQP a XMPP, nebo DTLS v CoAP, a také podporujícím obě varianty DDS.
TLS a DTLS začínají procesem navazování spojení mezi klientskou a serverovou stranou pro výměnu podporovaných sad šifer a klíčů. Obě strany se dohodnou na sadách, aby zajistily, že další komunikace probíhá v bezpečném kanálu. Rozdíl mezi nimi spočívá v drobných modifikacích, které umožňují DTLS založenému na UDP pracovat v nespolehlivém připojení.
Při Při testování různých implementací TLS a DTLS se ukázalo, že TLS se s úkolem vypořádalo lépe. Útoky na DTLS byly úspěšnější kvůli jeho toleranci k chybám.
Největším problémem těchto protokolů však je, že původně nebyly navrženy pro použití v IoT a nepředpokládaly práci v mlze nebo cloudu. Při dohodě (handshaking) přidávají další provoz s každým navázáním spojení, což vyčerpává výpočetní zdroje. Průměrně došlo k nárůstu o 6,5 % pro TLS a 11 % pro DTLS v režijní zátěži ve srovnání se spojením bez bezpečnostní vrstvy. V bohatých zdrojových prostředích, která se obvykle nacházejí v , to nebude problém, ale v případě spojení mezi IoT a úrovní mlhy se to stává důležitým omezením.
Co si tedy vybrat? Na tuto otázku neexistuje jednoznačná odpověď. MQTT a HTTP se zdají být nejperspektivnějšími protokoly, protože jsou považovány za relativně vyspělé a stabilní řešení pro IoT ve srovnání s jinými protokoly.
Řešení na základě jediného komunikačního protokolu
Praxe jednoho protokolu má mnoho nevýhod. Například protokol, který vyhovuje omezenému prostředí, nemusí fungovat v doméně, která má přísné bezpečnostní požadavky. S tímto na paměti musíme vyloučit téměř všechna možná řešení na bázi jediného protokolu v ekosystému Fog-to-Cloud v IoT, kromě MQTT a REST HTTP.
REST HTTP jako jednoprotokolové řešení
Existuje dobrý příklad interakce mezi požadavky a odpověďmi REST HTTP v oblasti IoT-to-Fog: . Zvířata jsou vybavena nositelnými senzory (IoT-klient, C) a jsou řízena prostřednictvím cloudového výpočtu chytrým zemědělským systémem (Fog-server, S).
V záhlaví metody POST je uveden zdroj ke změně ( /farm /animals), spolu s verzí HTTP a typem obsahu, který je v tomto případě objektem JSON představujícím chovatelskou farmu, kterou má systém řídit (Dulcinea /kráva). Odpověď ze serveru naznačuje, že žádost byla úspěšná, a posílá kód stavu HTTPS 201 (resource created). Metoda GET by měla uvádět pouze požadovaný zdroj v URI (například /farm /animals /1), což vrací JSON reprezentaci zvířete s tímto identifikátorem ze serveru.
Metoda PUT se používá, když je třeba aktualizovat konkrétní záznam zdroje. V tomto případě se v zdroji uvádí URI pro parametr, který se má změnit, a aktuální hodnotu (například když kráva právě pase, /farm/animals/1?state=chod). Nakonec metoda DELETE je používána stejným způsobem jako metoda GET, ale jednoduše odstraní zdroj v důsledku operace.
MQTT jako jednoprotokolové řešení
Vezměme si stejnou inteligentní farmu, ale místo REST HTTP použijeme protokol MQTT. Místní server se nainstalovanou knihovnou Mosquitto funguje jako broker. V tomto příkladu jednoduchý počítač (označovaný jako server farmy) Raspberry Pi slouží jako klient MQTT, implementovaný pomocí instalace knihovny MQTT Paho, plně kompatibilní s brokerem Mosquitto.
Tento klient odpovídá úrovni abstrakce IoT představující zařízení s možnostmi detekce a výpočtů. Zprostředkovatel, na druhé straně, odpovídá vyšší úrovni abstrakce představující výpočetní uzel mlhy, charakterizovaný velkými kapacitami v oblasti zpracování a ukládání dat.
V navrhovaném scénáři 'inteligentní farmy' se Raspberry Pi připojuje k akcelerometru, GPS a teplotním senzorům a publikuje data z těchto senzorů v uzlu mlhy. Jak jistě víte, MQTT chápe témata jako hierarchii. Jeden vydavatel MQTT může publikovat zprávy v určité sadě témat. V našem případě jsou to tři. Pro senzor, který měří teplotu ve stáji pro zvířata, si klient vybírá téma (animalfarm/shed/temperature). Pro senzory, které měří polohu GPS a pohyb zvířat prostřednictvím akcelerometru, klient publikovat aktualizace (animalfarm/animal/GPS) a (animalfarm/animal/movement).
Tyto informace budou předány brokerovi, který je může dočasně uložit do místní databáze pro případ, že by se později objevil jiný zainteresovaný odběratel.
Kromě lokálního serveru, který funguje jako MQTT broker v mlze a kterému Raspberry Pi, fungující jako MQTT klienti, posílají data ze senzorů, může na úrovni cloudu existovat další MQTT broker. V takovém případě může být informace, předávaná lokálnímu brokerovi, dočasně uchovávána v lokální databázi a/nebo posílána do cloudu. Mlhavý MQTT broker je v této situaci využíván k propojení všech dat s cloudovým MQTT brokerem. Při této architektuře může uživatel mobilní aplikace být přihlášen k oběma brokerům.
V případě výpadku spojení s jedním z brokerů (například cloudovým) získá koncový uživatel informace od druhého (mlhavého). To je charakteristická vlastnost kombinovaných systémů mlhy a cloudových výpočtů. Výchozí mobilní aplikace může být nastavena na první připojení k mlhavému MQTT brokeru, a v případě neúspěchu na připojení k MQTT brokeru v cloudu. Toto řešení je pouze jedním z mnoha v systémech IoT-F2C.
Multiprotocolní řešení
Řešení s jedním protokolem jsou populární díky své snazší realizaci. Je však jasné, že v systémech IoT-F2C má smysl kombinovat různé protokoly. Smysl spočívá v tom, že na různých úrovních mohou fungovat různé protokoly. Vezměme například tři abstrakce: úrovně IoT, mlhy a cloudových výpočtů. Zařízení na úrovni IoT jsou obvykle považována za omezená. Pro tento přehled považujme úrovně IoT za nejvíce omezené, cloudové za méně omezené a výpočty mlhy jako „někde uprostřed“. Pak to vychází tak, že mezi IoT a abstrakcemi mlhy zahrnují aktuální protokolová řešení MQTT, CoAP a XMPP. Mezi mlhou a cloudem, na druhou stranu, je AMQP jedním z hlavních používaných protokolů spolu s REST HTTP, který díky své flexibilitě je také používán mezi IoT a vrstvami mlhy.
Hlavním problémem je funkční kompatibilita protokolů a jednoduchost převodu zpráv z jednoho protokolu na druhý. Ideálně, v budoucnu bude architektura systému internetu věcí s cloudovými a mlhavými zdroji nezávislá na používaném komunikačním protokolu a zajistí dobrou interakci různých protokolů.
Vzhledem k tomu, že tomu momentálně tak není, dává smysl spojit protokoly, které nemají významné rozdíly. K tomuto účelu je jedno potenciální řešení založeno na kombinaci dvou protokolů, které se řídí stejným architektonickým stylem, REST HTTP a CoAP. Další navrhované řešení vychází ze spojení dvou protokolů, které nabízejí interakci podle modelu „publikace-předplatné“, MQTT a AMQP. Použití blízkých konceptů (jak MQTT, tak AMQP používají zprostředkovatele, CoAP a HTTP využívají REST) usnadňuje realizaci těchto kombinací a vyžaduje menší úsilí při integraci.
Na obrázku (a) jsou zobrazeny dva modely založené na požadavcích a odpovědích, HTTP a CoAP, a jejich možné umístění v řešení IoT-F2C. Vzhledem k tomu, že HTTP je jedním z nejznámějších a nejpřizpůsobenějších protokolů v současných sítích, je nepravděpodobné, že by byl plně nahrazen jinými protokoly pro výměnu zpráv. Mezi uzly, které představují výkonné zařízení, jež se nachází mezi cloudem a mlhou, je REST HTTP rozumným řešením.
Na druhou stranu, pro zařízení s omezenými výpočetními zdroji, která komunikují mezi úrovněmi mlhy a IoT, je efektivnější používat CoAP. Jednou z velkých výhod CoAP je jeho kompatibilita s HTTP, protože oba protokoly jsou založeny na principech REST.
Na obrázku (b) jsou zobrazeny dva modely interakce „publikace-předplatné“ v jednom scénáři, zahrnující MQTT a AMQP. I když hypoteticky mohou být oba protokoly použity pro komunikaci mezi uzly na každé úrovni abstrakce, jejich umístění by mělo být určeno na základě výkonnosti. MQTT byl navržen jako zjednodušený protokol pro zařízení s omezenými výpočetními zdroji, takže může být použit pro komunikaci mezi IoT a mlhou. AMQP je lépe přizpůsoben pro výkonnější zařízení, která by ho ideálně umístila mezi uzly mlhy a cloudu. Místo MQTT může být v IoT použit protokol XMPP, protože se považuje za lehký. Ale v podobných scénářích se nepoužívá tak široce.
Závěry
Je nepravděpodobné, že by jeden z uvedených protokolů stačil k pokrytí celé komunikace v systému, počínaje zařízeními s omezenými výpočetními zdroji a konče cloudovými servery. Studie ukázala, že dva nejperspektivnější varianty, které vývojáři častěji využívají, jsou MQTT a RESTful HTTP. Tyto dva protokoly jsou nejen nejvíce zralé a stabilní, ale také zahrnují mnoho dobře zdokumentovaných a úspěšných implementací a online zdrojů.
Díky své stabilitě a jednoduché konfiguraci je MQTT protokolem, který časem prokázal svou vynikající výkonnost při použití na úrovni IoT s omezenými zařízeními. V částech systému, kde není problémem omezené připojení a spotřeba baterie, například v některých oblastech mlhy a většině cloud computingů, je RESTful HTTP jednoduchou volbou. CoAP by měl být také zvážen, protože se také rychle vyvíjí jako standard pro zprávy IoT, a je velmi pravděpodobné, že v blízké budoucnosti dosáhne úrovně stability a zralosti srovnatelné s MQTT a HTTP. Ale standard se nyní vyvíjí, což s sebou nese krátkodobé problémy s kompatibilitou.
Co dalšího si můžete přečíst v blogu
→
→
→
→
→
Sledujte náš -kanál, abyste nepřišli o další článek! Píšeme maximálně dvakrát týdně a pouze relevantně.
Zdroj: habr.com
