Rozvoj technologií v oblasti softwaru a hardwaru, vznik nových komunikačních protokolů vedly k rozšíření internetu věcí (IoT). Počet zařízení den ode dne roste a generují obrovské množství dat. Proto existuje potřeba vhodné systémové architektury schopné zpracovávat, ukládat a přenášet tato data.
Nyní se pro tyto účely využívají cloudové služby. Stále populárnější paradigma fog computingu (Fog) však může doplnit cloudová řešení škálováním a optimalizací infrastruktury IoT.
Cloudy jsou schopny pokrýt většinu požadavků IoT. Například zajistit monitoring služeb, rychlé zpracování libovolného množství dat generovaných zařízeními a také jejich vizualizaci. Fog computing je efektivnější při řešení problémů v reálném čase. Poskytují rychlou reakci na požadavky a minimální latenci při zpracování dat. To znamená, že Mlha doplňuje „mraky“ a rozšiřuje své schopnosti.
Hlavní otázka je však jiná: jak by se to všechno mělo ovlivňovat v kontextu IoT? Jaké komunikační protokoly budou nejefektivnější při práci v kombinovaném systému IoT-Fog-Cloud?
I přes zjevnou dominanci HTTP existuje velké množství dalších řešení používaných v systémech IoT, Fog a Cloud. IoT totiž musí kombinovat funkčnost různých senzorů zařízení s bezpečností, kompatibilitou a dalšími požadavky uživatelů.
Ale o referenční architektuře a komunikačním standardu prostě neexistuje jediná představa. Proto je vytvoření nového protokolu nebo úprava stávajícího protokolu pro konkrétní úkoly IoT jedním z nejdůležitějších úkolů, kterým IT komunita čelí.
Jaké protokoly se v současnosti používají a co mohou nabídnout? Pojďme na to přijít. Nejprve si ale proberme principy ekosystému, ve kterém se vzájemně ovlivňují mraky, mlha a internet věcí.
IoT Fog-to-Cloud (F2C) architektura
Pravděpodobně jste si všimli, kolik úsilí je věnováno zkoumání výhod a výhod spojených s chytrou a koordinovanou správou IoT, cloudu a mlhy. Pokud ne, zde jsou tři standardizační iniciativy: , и .
Pokud byly dříve uvažovány pouze 2 úrovně, cloudy a koncová zařízení, pak navrhovaná architektura zavádí novou úroveň – fog computing. V tomto případě lze úroveň mlhy rozdělit do několika podúrovní v závislosti na specifikách zdrojů nebo souboru zásad, které určují použití různých zařízení v těchto podúrovních.
Jak může tato abstrakce vypadat? Zde je typický ekosystém IoT-Fog-Cloud. Zařízení IoT odesílají data na rychlejší servery a výpočetní zařízení k řešení problémů, které vyžadují nízkou latenci. Ve stejném systému jsou cloudy zodpovědné za řešení problémů, které vyžadují velké množství výpočetních zdrojů nebo prostoru pro ukládání dat.
Součástí IoT mohou být i chytré telefony, chytré hodinky a další vychytávky. Taková zařízení však zpravidla používají proprietární komunikační protokoly od velkých vývojářů. Vygenerovaná IoT data jsou přenášena do fog layer přes REST HTTP protokol, který poskytuje flexibilitu a interoperabilitu při vytváření RESTful služeb. To je důležité ve světle potřeby zajistit zpětnou kompatibilitu se stávající výpočetní infrastrukturou běžící na místních počítačích, serverech nebo serverovém clusteru. Místní zdroje, nazývané „mlžné uzly“, filtrují přijatá data a zpracovávají je lokálně nebo je posílají do cloudu k dalším výpočtům.
Cloudy podporují různé komunikační protokoly, nejběžnější jsou AMQP a REST HTTP. Vzhledem k tomu, že HTTP je dobře známý a přizpůsobený pro internet, může vyvstat otázka: „Neměli bychom ho používat pro práci s IoT a mlhou?“ Tento protokol má však problémy s výkonem. Více o tom později.
Obecně existují 2 modely komunikačních protokolů vhodné pro systém, který potřebujeme. Jedná se o požadavek-odpověď a publikovat-předplatit. První model je známější, zejména v architektuře server-klient. Klient požaduje informace od serveru a server požadavek přijme, zpracuje a vrátí zprávu s odpovědí. Na tomto modelu fungují protokoly REST HTTP a CoAP.
Druhý model vznikl z potřeby zajistit asynchronní, distribuované, volné spojení mezi zdroji generujícími data a příjemci těchto dat.
Model předpokládá tři účastníky: vydavatele (zdroj dat), zprostředkovatele (dispečer) a předplatitele (příjemce). Zde klient vystupující jako předplatitel nemusí vyžadovat informace ze serveru. Namísto odesílání požadavků odebírá určité události v systému prostřednictvím brokera, který má na starosti filtrování všech příchozích zpráv a jejich směrování mezi vydavateli a odběrateli. A vydavatel, když dojde k události týkající se určitého tématu, ji zveřejní brokerovi, který odešle data o požadovaném tématu předplatiteli.
Tato architektura je v podstatě založena na událostech. A tento interakční model je zajímavý pro aplikace v IoT, cloudu, mlze díky své schopnosti poskytovat škálovatelnost a zjednodušit propojení mezi různými zařízeními, podporovat dynamickou komunikaci many-to-many a asynchronní komunikaci. Některé z nejznámějších standardizovaných protokolů zasílání zpráv, které používají model publikování a odběru, zahrnují MQTT, AMQP a DDS.
Je zřejmé, že model publikování a odběru má mnoho výhod:
- Vydavatelé a předplatitelé nemusí vědět o své existenci;
- Jeden odběratel může přijímat informace z mnoha různých publikací a jeden vydavatel může posílat data mnoha různým odběratelům (princip mnoho k mnoha);
- Vydavatel a předplatitel nemusí být pro komunikaci současně aktivní, protože broker (fungující jako frontový systém) bude moci ukládat zprávu pro klienty, kteří nejsou aktuálně připojeni k síti.
Model žádost-odpověď má však i své silné stránky. V případech, kdy schopnost serveru zpracovat více požadavků klientů není problémem, má smysl používat osvědčená spolehlivá řešení.
Existují také protokoly, které podporují oba modely. Například XMPP a HTTP 2.0, které podporují možnost „server push“. IETF také vydala CoAP. Ve snaze vyřešit problém se zasíláním 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).
V případě WebSockets, přestože se používá k přenosu dat v reálném čase ze serveru do webového klienta a poskytuje trvalé připojení se současnou obousměrnou komunikací, není určen pro zařízení s omezenými výpočetními zdroji. QUIC si také zaslouží pozornost, protože nový transportní protokol poskytuje mnoho nových příležitostí. Protože ale QUIC ještě není standardizován, je předčasné předvídat jeho možné uplatnění a dopad na řešení IoT. WebSockets a QUIC tedy pamatujeme s ohledem na budoucnost, ale zatím se jimi nebudeme podrobněji zabývat.
Kdo je nejroztomilejší na světě: porovnávání protokolů
Nyní si promluvme o silných a slabých stránkách protokolů. Podíváme-li se dopředu, okamžitě udělejme výhradu, že neexistuje žádný jasný vůdce. Každý protokol má nějaké výhody/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. Mezi existujícími protokoly však neexistuje jasný vítěz, který by prokázal minimální úroveň latence při práci za různých podmínek. Existuje však celá řada výzkumů a srovnání možností protokolů.
Například, srovnání efektivity HTTP a MQTT při práci s IoT ukázalo, že doba odezvy na požadavky pro MQTT je kratší než pro HTTP. A kdy Doba zpáteční cesty (RTT) MQTT a CoAP odhalila, že průměrná RTT CoAP je o 20 % nižší než u MQTT.
Další s RTT pro protokoly MQTT a CoAP byla provedena ve dvou scénářích: místní síť a síť IoT. Ukázalo se, že průměrná RTT je v IoT síti 2-3x vyšší. MQTT s QoS0 vykazovalo nižší výsledek ve srovnání s CoAP a MQTT s QoS1 vykazovalo vyšší RTT kvůli ACK na aplikační a transportní vrstvě. Pro různé úrovně QoS byla latence sítě bez přetížení milisekundy pro MQTT a stovky mikrosekund pro CoAP. Je však třeba připomenout, že při práci na méně spolehlivých sítích bude MQTT spuštěný nad TCP vykazovat úplně jiný výsledek.
doba odezvy pro protokoly AMQP a MQTT zvýšením užitečného zatížení ukázala, že při nízké zátěži je úroveň latence téměř stejná. Při přenosu velkého množství dat však MQTT vykazuje kratší doby odezvy. ještě v jednom CoAP byl srovnáván s HTTP ve scénáři komunikace mezi stroji se zařízeními umístěnými na vozidlech vybavených senzory plynu, senzory počasí, senzory polohy (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ý k použití zpráv HTTP.
Byly provedeny studie, které srovnávaly ne dva, ale tři protokoly. Například, výkon protokolů IoT MQTT, DDS a CoAP ve scénáři lékařské aplikace pomocí síťového emulátoru. DDS překonalo MQTT z hlediska testované latence telemetrie za různých špatných síťových podmínek. CoAP založené na UDP fungovalo dobře pro aplikace, které vyžadovaly rychlou odezvu, ale vzhledem k tomu, že je založen na UDP, docházelo k významným nepředvídatelným ztrátám paketů.
Propustnost
MQTT a CoAP z hlediska účinnosti šířky pásma byly provedeny jako výpočet celkového množství dat přenesených na zprávu. CoAP vykazuje nižší propustnost než MQTT při přenosu malých zpráv. Ale při srovnání účinnosti protokolů z hlediska poměru počtu užitečných informačních bajtů k celkovému počtu přenesených bajtů se CoAP ukázalo jako efektivnější.
na pomocí MQTT, DDS (s TCP jako transportním protokolem) a šířky pásma CoAP bylo zjištěno, že CoAP obecně vykazovalo srovnatelně nižší spotřebu šířky pásma, která se nezvyšovala se zvýšenou ztrátou síťových paketů nebo zvýšenou latencí sítě, na rozdíl od MQTT a DDS, kde došlo zvýšení využití šířky pásma ve zmíněných scénářích. Další scénář zahrnoval velký počet zařízení přenášejících data současně, což je typické v prostředí IoT. Výsledky ukázaly, že pro vyšší využití je lepší použít CoAP.
Při mírném zatížení využívalo CoAP nejmenší šířku pásma, následované MQTT a REST HTTP. Když se však velikost datových částí zvýšila, REST HTTP měl nejlepší výsledky.
Spotřeba energie
Otázka spotřeby energie je vždy velmi důležitá, a to zejména v systému internetu věcí. Li Zatímco MQTT a HTTP spotřebovávají elektřinu, HTTP spotřebovává mnohem více. A CoAP je víc ve srovnání s MQTT, což umožňuje správu 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í napájení.
Experiment, který porovnával možnosti AMQP a MQTT na testovacím prostředí mobilní nebo nestabilní bezdrátové sítě, zjistil, že AMQP nabízí více bezpečnostních funkcí, zatímco MQTT je energeticky účinnější.
zabezpečení
Bezpečnost je další kritickou otázkou, která se objevuje při studiu tématu internetu věcí a fog/cloud computingu. Bezpečnostní mechanismus je obvykle založen na TLS v HTTP, MQTT, AMQP a XMPP nebo DTLS v CoAP a podporuje obě varianty DDS.
TLS a DTLS začínají procesem navázání komunikace mezi klientskou a serverovou stranou za účelem výměny podporovaných šifrovacích sad a klíčů. Obě strany vyjednávají sady, aby zajistily, že další komunikace proběhne na zabezpečeném kanálu. Rozdíl mezi těmito dvěma spočívá v malých úpravách, které umožňují DTLS na bázi UDP pracovat přes nespolehlivé připojení.
na Několik různých implementací TLS a DTLS zjistilo, že TLS odvedlo lepší práci. Útoky na DTLS byly úspěšnější díky jeho odolnosti vůči chybám.
Největším problémem těchto protokolů je však to, že nebyly původně navrženy pro použití v IoT a nebyly určeny pro práci v mlze nebo cloudu. Prostřednictvím handshakingu přidávají další provoz s každým navázáním připojení, což vyčerpává výpočetní zdroje. V průměru došlo k nárůstu režie u TLS o 6,5 % au DTLS o 11 % ve srovnání s komunikacemi bez bezpečnostní vrstvy. V prostředích bohatých na zdroje, která se obvykle nacházejí na úrovni to nebude problém, ale ve spojení mezi IoT a úrovní mlhy se to stává důležitým omezením.
Co si vybrat? Jednoznačná odpověď neexistuje. MQTT a HTTP se zdají být nejslibnějšími protokoly, protože jsou považovány za poměrně vyspělejší a stabilnější řešení IoT ve srovnání s jinými protokoly.
Řešení založená na jednotném komunikačním protokolu
Praxe jednoprotokolového řešení má mnoho nevýhod. Například protokol, který vyhovuje omezenému prostředí, nemusí fungovat v doméně, která má přísné požadavky na zabezpečení. S ohledem na to nám zbývá zahodit téměř všechna možná jednoprotokolová řešení v ekosystému Fog-to-Cloud v IoT, kromě MQTT a REST HTTP.
REST HTTP jako jednoprotokolové řešení
Existuje dobrý příklad toho, jak REST HTTP požadavky a odpovědi interagují v prostoru IoT-to-Fog: . Zvířata jsou vybavena nositelnými senzory (IoT klient, C) a řízena pomocí cloud computingu pomocí chytrého farmářského systému (Fog server, S).
Hlavička metody POST specifikuje zdroj, který se má upravit (/farma/zvířata), a také verzi HTTP a typ obsahu, což je v tomto případě objekt JSON představující zvířecí farmu, kterou má systém spravovat (Dulcinea/kráva). . Odesláním stavového kódu HTTPS 201 (prostředek vytvořen) odezva ze serveru indikuje, že požadavek byl úspěšný. Metoda GET musí v URI specifikovat pouze požadovaný zdroj (například /farm/animals/1), který ze serveru vrátí JSON reprezentaci zvířete s daným ID.
Metoda PUT se používá, když je třeba aktualizovat určitý záznam o prostředku. V tomto případě zdroj specifikuje URI parametru, který se má změnit, a aktuální hodnotu (například indikující, že kráva právě chodí, /farm/zvířata/1? stav=chůze). Nakonec se metoda DELETE používá stejně jako metoda GET, ale v důsledku operace jednoduše odstraní zdroj.
MQTT jako jednoprotokolové řešení
Vezměme stejnou chytrou farmu, ale místo REST HTTP používáme protokol MQTT. Jako broker funguje lokální server s nainstalovanou knihovnou Mosquitto. V tomto příkladu jednoduchý počítač (označovaný jako farmářský server) Raspberry Pi slouží jako klient MQTT, implementovaný prostřednictvím instalace knihovny Paho MQTT, která je plně kompatibilní s brokerem Mosquitto.
Tento klient odpovídá abstrakční vrstvě IoT představující zařízení se snímacími a výpočetními schopnostmi. Mediátor na druhé straně odpovídá vyšší úrovni abstrakce, představuje mlhový výpočetní uzel vyznačující se větší kapacitou zpracování a ukládání.
V navrhovaném scénáři chytré farmy se Raspberry Pi připojuje k akcelerometru, GPS a teplotním senzorům a publikuje data z těchto senzorů do mlhového uzlu. Jak asi víte, MQTT zachází s tématy jako s hierarchií. Jeden vydavatel MQTT může publikovat zprávy na konkrétní sadu témat. V našem případě jsou tři. Pro senzor, který měří teplotu ve stáji pro zvířata, si klient vybere téma (farma/chlév/teplota). U senzorů, které měří GPS polohu a pohyb zvířat prostřednictvím akcelerometru, bude klient zveřejňovat aktualizace (farma zvířat/zvíře/GPS) a (farma zvířat/zvíře/pohyb).
Tyto informace budou předány brokerovi, který je může dočasně uložit do lokální databáze pro případ, že by se později objevil další zájemce.
Kromě lokálního serveru, který v mlze funguje jako MQTT broker a kterému Raspberry Pis jako klienti MQTT posílá data ze senzorů, může existovat další MQTT broker na úrovni cloudu. V tomto případě mohou být informace předané místnímu brokerovi dočasně uloženy v lokální databázi a/nebo odeslány do cloudu. Fog MQTT broker se v této situaci používá ke spojení všech dat s cloudovým MQTT brokerem. S touto architekturou může být uživatel mobilní aplikace přihlášen k oběma brokerům.
Pokud selže připojení k jednomu z brokerů (například cloud), dostane koncový uživatel informace od druhého (fog). To je charakteristický rys kombinovaných systémů mlhy a cloud computingu. Ve výchozím nastavení lze mobilní aplikaci nakonfigurovat tak, aby se nejprve připojila k brokerovi fog MQTT, a pokud to selže, aby se připojila ke cloudovému brokerovi MQTT. Toto řešení je jen jedním z mnoha v systémech IoT-F2C.
Víceprotokolová řešení
Jednoprotokolová řešení jsou oblíbená díky jejich snadnější implementaci. Je ale jasné, že v systémech IoT-F2C má smysl kombinovat různé protokoly. Myšlenka je, že různé protokoly mohou fungovat na různých úrovních. Vezměme si například tři abstrakce: vrstvy IoT, mlhu a cloud computing. Zařízení na úrovni IoT jsou obecně považována za omezená. Pro tento přehled považujme úrovně internetu věcí za nejvíce omezené, cloud za nejméně omezené a fog computing za „někde uprostřed“. Ukazuje se tedy, že mezi IoT a fog abstrakcemi současná protokolová řešení zahrnují MQTT, CoAP a XMPP. Mezi fog a cloud je naproti tomu AMQP jedním z hlavních používaných protokolů spolu s REST HTTP, který se díky své flexibilitě používá i mezi IoT a fog vrstvami.
Hlavním problémem je zde interoperabilita protokolů a snadnost přenosu zpráv z jednoho protokolu do druhého. V ideálním případě bude v budoucnu architektura systému internetu věcí s cloudovými a mlhovými zdroji nezávislá na použitém komunikačním protokolu a zajistí dobrou interoperabilitu mezi různými protokoly.
Protože tomu tak v současnosti není, má smysl kombinovat protokoly, které nemají výrazné rozdíly. Za tímto účelem 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í je založeno na kombinaci dvou protokolů, které nabízejí komunikaci publish-subscribe, MQTT a AMQP. Použití podobných konceptů (jak MQTT, tak AMQP používají brokery, CoAP a HTTP používají REST) usnadňuje implementaci těchto kombinací a vyžaduje menší integrační úsilí.
Obrázek (a) ukazuje dva modely založené na požadavku-odezvě, HTTP a CoAP, a jejich možné umístění v řešení IoT-F2C. Protože HTTP je jedním z nejznámějších a nejrozšířenějších protokolů v moderních sítích, je nepravděpodobné, že bude zcela nahrazen jinými protokoly pro zasílání zpráv. Mezi uzly reprezentujícími výkonná zařízení, která sedí mezi cloudem a mlhou, je REST HTTP chytré řešení.
Na druhou stranu pro zařízení s omezenými výpočetními zdroji, která komunikují mezi vrstvami Fog a IoT, je efektivnější používat CoAP. Jednou z velkých výhod CoAP je ve skutečnosti jeho kompatibilita s HTTP, protože oba protokoly jsou založeny na principech REST.
Obrázek (b) ukazuje dva komunikační modely publikovat-předplatit ve stejném scénáři, včetně MQTT a AMQP. Ačkoli by oba protokoly mohly být hypoteticky použity pro komunikaci mezi uzly na každé vrstvě abstrakce, jejich pozice by měla být určena na základě výkonu. MQTT byl navržen jako odlehčený protokol pro zařízení s omezenými výpočetními zdroji, takže jej lze použít pro komunikaci IoT-Fog. AMQP je vhodnější pro výkonnější zařízení, která by jej ideálně umístila mezi uzly mlhy a cloudu. Místo MQTT lze v IoT použít protokol XMPP, protože je považován za lehký. Ale v takových scénářích není tak široce používán.
Závěry
Je nepravděpodobné, že jeden z diskutovaných protokolů bude dostatečný k pokrytí veškeré komunikace v systému, od zařízení s omezenými výpočetními zdroji až po cloudové servery. Studie zjistila, že dvě nejslibnější možnosti, které vývojáři nejvíce využívají, jsou MQTT a RESTful HTTP. Tyto dva protokoly jsou nejen nejvyspělejší a nejstabilnější, ale zahrnují také mnoho dobře zdokumentovaných a úspěšných implementací a online zdrojů.
Díky své stabilitě a jednoduché konfiguraci je MQTT protokol, který v průběhu času prokázal svůj vynikající výkon při použití na úrovni IoT s omezenými zařízeními. V částech systému, kde omezená komunikace a spotřeba baterie nepředstavují problém, jako jsou některé fog domény a většina cloud computingu, je RESTful HTTP snadnou volbou. CoAP by měl být také vzat v úvahu, protože se také rychle vyvíjí jako standard pro zasílání zpráv IoT a je pravděpodobné, že v blízké budoucnosti dosáhne úrovně stability a vyspělosti podobné MQTT a HTTP. Ale standard se v současné době vyvíjí, což přichází s krátkodobými problémy s kompatibilitou.
Co dalšího si můžete přečíst na blogu?
→
→
→
→
→
Přihlaste se k odběru -kanál, aby vám neunikl další článek! Píšeme maximálně dvakrát týdně a pouze služebně.
Zdroj: www.habr.com