Rozvoj technológií v oblasti softvéru a hardvéru, vznik nových komunikačných protokolov viedli k rozšíreniu internetu vecí (IoT). Počet zariadení každým dňom rastie a generujú obrovské množstvo dát. Preto existuje potreba vhodnej systémovej architektúry schopnej spracovávať, ukladať a prenášať tieto dáta.
Teraz sa na tieto účely používajú cloudové služby. Čoraz populárnejšia paradigma fog computingu (Fog) však môže dopĺňať cloudové riešenia škálovaním a optimalizáciou infraštruktúry internetu vecí.
Cloudy sú schopné pokryť väčšinu požiadaviek internetu vecí. Napríklad zabezpečiť monitoring služieb, rýchle spracovanie ľubovoľného množstva dát generovaných zariadeniami, ako aj ich vizualizáciu. Fog computing je efektívnejší pri riešení problémov v reálnom čase. Poskytujú rýchlu reakciu na požiadavky a minimálnu latenciu pri spracovaní údajov. To znamená, že hmla dopĺňa „oblaky“ a rozširuje svoje schopnosti.
Hlavná otázka je však iná: ako by to všetko malo spolupôsobiť v kontexte internetu vecí? Aké komunikačné protokoly budú najúčinnejšie pri práci v kombinovanom systéme IoT-Fog-Cloud?
Napriek zjavnej dominancii HTTP existuje veľké množstvo iných riešení používaných v systémoch IoT, Fog a Cloud. IoT totiž musí spájať funkčnosť rôznych senzorov zariadení s bezpečnosťou, kompatibilitou a ďalšími požiadavkami používateľov.
Ale jednoducho neexistuje jediná predstava o referenčnej architektúre a komunikačnom štandarde. Preto je vytvorenie nového protokolu alebo úprava existujúceho protokolu pre konkrétne úlohy internetu vecí jednou z najdôležitejších úloh, ktorým čelí IT komunita.
Aké protokoly sa v súčasnosti používajú a čo môžu ponúknuť? Poďme na to. Najprv si však preberme princípy ekosystému, v ktorom sa oblaky, hmla a internet vecí vzájomne ovplyvňujú.
Architektúra IoT Fog-to-Cloud (F2C).
Pravdepodobne ste si všimli, koľko úsilia sa vynakladá na skúmanie výhod a výhod spojených s inteligentnou a koordinovanou správou internetu vecí, cloudu a hmly. Ak nie, tu sú tri štandardizačné iniciatívy: , и .
Ak sa predtým zvažovali iba 2 úrovne, oblaky a koncové zariadenia, potom navrhovaná architektúra predstavuje novú úroveň – fog computing. V tomto prípade môže byť úroveň hmly rozdelená do niekoľkých podúrovní v závislosti od špecifík zdrojov alebo súboru politík, ktoré určujú použitie rôznych zariadení v týchto podúrovniach.
Ako môže vyzerať táto abstrakcia? Tu je typický IoT-Fog-Cloud ekosystém. Zariadenia internetu vecí odosielajú údaje na rýchlejšie servery a výpočtové zariadenia, aby riešili problémy, ktoré si vyžadujú nízku latenciu. V tom istom systéme sú cloudy zodpovedné za riešenie problémov, ktoré si vyžadujú veľké množstvo výpočtových zdrojov alebo priestoru na ukladanie dát.
Súčasťou internetu vecí môžu byť aj smartfóny, smart hodinky a ďalšie vychytávky. Takéto zariadenia však spravidla používajú proprietárne komunikačné protokoly od veľkých vývojárov. Vygenerované IoT dáta sú prenášané do fog vrstvy cez REST HTTP protokol, ktorý poskytuje flexibilitu a interoperabilitu pri vytváraní RESTful služieb. Je to dôležité vzhľadom na potrebu zabezpečiť spätnú kompatibilitu s existujúcou výpočtovou infraštruktúrou spustenou na lokálnych počítačoch, serveroch alebo serverovom klastri. Miestne zdroje, nazývané „hmlové uzly“, filtrujú prijaté údaje a spracovávajú ich lokálne alebo ich posielajú do cloudu na ďalšie výpočty.
Cloudy podporujú rôzne komunikačné protokoly, najčastejšie AMQP a REST HTTP. Keďže HTTP je dobre známy a prispôsobený pre internet, môže vzniknúť otázka: „Nemali by sme ho použiť na prácu s IoT a hmlou?“ Tento protokol má však problémy s výkonom. Viac o tom neskôr.
Vo všeobecnosti existujú 2 modely komunikačných protokolov vhodné pre systém, ktorý potrebujeme. Sú to požiadavka-odpoveď a zverejnenie-prihlásenie na odber. Prvý model je všeobecne známy, najmä v architektúre server-klient. Klient požaduje informácie od servera a server prijme požiadavku, spracuje ju a vráti správu s odpoveďou. Na tomto modeli fungujú protokoly REST HTTP a CoAP.
Druhý model vznikol z potreby zabezpečiť asynchrónne, distribuované, voľné prepojenie medzi zdrojmi generujúcimi dáta a príjemcami týchto dát.
Model predpokladá troch účastníkov: vydavateľ (zdroj údajov), sprostredkovateľ (dispečer) a predplatiteľ (prijímač). Tu klient vystupujúci ako predplatiteľ nemusí žiadať informácie zo servera. Namiesto odosielania požiadaviek sa prihlási na odber určitých udalostí v systéme prostredníctvom brokera, ktorý má na starosti filtrovanie všetkých prichádzajúcich správ a ich smerovanie medzi vydavateľmi a predplatiteľmi. A vydavateľ, keď nastane udalosť týkajúca sa určitej témy, zverejní ju sprostredkovateľovi, ktorý odošle údaje o požadovanej téme predplatiteľovi.
Táto architektúra je v podstate založená na udalostiach. A tento interakčný model je zaujímavý pre aplikácie v IoT, cloude, fog kvôli svojej schopnosti poskytovať škálovateľnosť a zjednodušiť prepojenie medzi rôznymi zariadeniami, podporovať dynamickú komunikáciu many-to-many a asynchrónnu komunikáciu. Niektoré z najznámejších štandardizovaných protokolov zasielania správ, ktoré používajú model zverejnenia a predplatenia, zahŕňajú MQTT, AMQP a DDS.
Je zrejmé, že model zverejnenia a predplatenia má veľa výhod:
- Vydavatelia a predplatitelia nemusia vedieť o svojej existencii;
- Jeden predplatiteľ môže dostávať informácie z mnohých rôznych publikácií a jeden vydavateľ môže posielať údaje mnohým rôznym predplatiteľom (princíp mnoho k mnohým);
- Vydavateľ a predplatiteľ nemusia byť pri komunikácii súčasne aktívni, pretože broker (fungujúci ako čakací systém) bude môcť uložiť správu pre klientov, ktorí nie sú práve pripojení k sieti.
Model žiadosť – odpoveď má však aj svoje silné stránky. V prípadoch, keď schopnosť servera spracovať viacero požiadaviek klientov nie je problémom, má zmysel používať overené spoľahlivé riešenia.
Existujú aj protokoly, ktoré podporujú oba modely. Napríklad XMPP a HTTP 2.0, ktoré podporujú možnosť „server push“. IETF tiež vydala CoAP. V snahe vyriešiť problém so zasielaním správ bolo vytvorených niekoľko ďalších riešení, ako napríklad protokol WebSockets alebo použitie protokolu HTTP cez QUIC (Quick UDP Internet Connections).
V prípade WebSockets, hoci sa používa na prenos údajov v reálnom čase zo servera na webového klienta a poskytuje trvalé spojenia so súčasnou obojsmernou komunikáciou, nie je určený pre zariadenia s obmedzenými výpočtovými zdrojmi. Pozornosť si zaslúži aj QUIC, keďže nový transportný protokol poskytuje množstvo nových príležitostí. Ale keďže QUIC ešte nie je štandardizovaný, je predčasné predpovedať jeho možnú aplikáciu a dopad na riešenia IoT. WebSockets a QUIC teda berieme do úvahy s ohľadom na budúcnosť, ale nateraz ich nebudeme podrobnejšie študovať.
Kto je najroztomilejší na svete: porovnávanie protokolov
Teraz si povedzme o silných a slabých stránkach protokolov. Pri pohľade do budúcnosti si okamžite urobme výhradu, že neexistuje jeden jasný vodca. Každý protokol má určité výhody/nevýhody.
Čas odozvy
Jednou z najdôležitejších charakteristík komunikačných protokolov, najmä vo vzťahu k internetu vecí, je doba odozvy. Medzi existujúcimi protokolmi však neexistuje jasný víťaz, ktorý by preukázal minimálnu úroveň latencie pri práci v rôznych podmienkach. Existuje však množstvo výskumov a porovnaní možností protokolov.
Napríklad, porovnania efektívnosti HTTP a MQTT pri práci s IoT ukázali, že čas odozvy na požiadavky pre MQTT je kratší ako pre HTTP. A kedy Čas spiatočnej cesty (RTT) MQTT a CoAP odhalil, že priemerný RTT CoAP je o 20 % menší ako čas MQTT.
Ďalšie s RTT pre protokoly MQTT a CoAP sa uskutočnilo v dvoch scenároch: lokálna sieť a sieť IoT. Ukázalo sa, že priemerné RTT je v sieti IoT 2-3 krát vyššie. MQTT s QoS0 vykázal nižší výsledok v porovnaní s CoAP a MQTT s QoS1 vykázal vyššiu RTT v dôsledku ACK na aplikačnej a transportnej vrstve. Pre rôzne úrovne QoS bola latencia siete bez preťaženia milisekúnd pre MQTT a stovky mikrosekúnd pre CoAP. Je však potrebné pripomenúť, že pri práci na menej spoľahlivých sieťach bude MQTT bežiaci nad TCP vykazovať úplne iný výsledok.
čas odozvy pre protokoly AMQP a MQTT zvýšením užitočného zaťaženia ukázal, že pri malom zaťažení je úroveň latencie takmer rovnaká. Pri prenose veľkého množstva údajov však MQTT vykazuje kratšie časy odozvy. ešte v jednom CoAP sa porovnávalo s HTTP v scenári komunikácie medzi strojmi so zariadeniami nasadenými na vozidlách vybavených senzormi plynu, senzormi počasia, senzormi polohy (GPS) a rozhraním mobilnej siete (GPRS). Čas potrebný na prenos správy CoAP cez mobilnú sieť bol takmer trikrát kratší ako čas potrebný na použitie správ HTTP.
Boli vykonané štúdie, ktoré neporovnávali dva, ale tri protokoly. Napríklad, výkon protokolov internetu vecí MQTT, DDS a CoAP v scenári medicínskej aplikácie pomocou sieťového emulátora. DDS prekonalo MQTT z hľadiska testovanej latencie telemetrie v rôznych zlých podmienkach siete. CoAP založené na UDP fungovalo dobre pre aplikácie, ktoré vyžadovali rýchle časy odozvy, avšak vzhľadom na to, že je založený na UDP, dochádzalo k značnej nepredvídateľnej strate paketov.
kapacita
MQTT a CoAP z hľadiska efektívnosti šírky pásma boli vykonané ako výpočet celkového množstva dát prenesených na správu. CoAP ukázal nižšiu priepustnosť ako MQTT pri prenose malých správ. Ale pri porovnaní účinnosti protokolov z hľadiska pomeru počtu užitočných informačných bajtov k celkovému počtu prenesených bajtov sa ukázalo, že CoAP je efektívnejší.
Na pri použití MQTT, DDS (s TCP ako transportným protokolom) a šírky pásma CoAP sa zistilo, že CoAP vo všeobecnosti vykazovalo porovnateľne nižšiu spotrebu šírky pásma, ktorá sa nezvýšila so zvýšenou stratou sieťových paketov alebo zvýšenou latenciou siete, na rozdiel od MQTT a DDS, kde došlo zvýšenie využitia šírky pásma v uvedených scenároch. Ďalší scenár zahŕňal veľký počet zariadení prenášajúcich dáta súčasne, čo je typické v prostrediach internetu vecí. Výsledky ukázali, že pre vyššie využitie je lepšie použiť CoAP.
Pri miernom zaťažení CoAP využívalo najmenšiu šírku pásma, nasledované MQTT a REST HTTP. Keď sa však veľkosť užitočných dát zvýšila, najlepšie výsledky mal REST HTTP.
Spotreba energie
Otázka spotreby energie je vždy veľmi dôležitá, a to najmä v systéme internetu vecí. Ak Zatiaľ čo MQTT a HTTP spotrebúvajú elektrinu, HTTP spotrebúva oveľa viac. A CoAP je viac v porovnaní s MQTT, čo umožňuje správu napájania. V jednoduchých scenároch je však MQTT vhodnejšie na výmenu informácií v sieťach internetu vecí, najmä ak neexistujú žiadne obmedzenia napájania.
Experiment, ktorý porovnával možnosti AMQP a MQTT na testovacej platforme mobilnej alebo nestabilnej bezdrôtovej siete, zistil, že AMQP ponúka viac bezpečnostných možností, zatiaľ čo MQTT je energeticky efektívnejší.
zabezpečenia
Bezpečnosť je ďalšou kritickou otázkou, ktorá sa objavila pri štúdiu témy internetu vecí a fog/cloud computingu. Bezpečnostný mechanizmus je zvyčajne založený na TLS v HTTP, MQTT, AMQP a XMPP alebo DTLS v CoAP a podporuje oba varianty DDS.
TLS a DTLS začínajú procesom nadviazania komunikácie medzi klientskou a serverovou stranou na výmenu podporovaných šifrovacích balíkov a kľúčov. Obe strany vyjednávajú súbory, aby sa zabezpečilo, že ďalšia komunikácia prebieha na zabezpečenom kanáli. Rozdiel medzi nimi spočíva v malých úpravách, ktoré umožňujú DTLS na báze UDP pracovať cez nespoľahlivé pripojenie.
Na Niekoľko rôznych implementácií TLS a DTLS zistilo, že TLS odviedlo lepšiu prácu. Útoky na DTLS boli úspešnejšie vďaka svojej tolerancii chýb.
Najväčším problémom týchto protokolov je však to, že neboli pôvodne navrhnuté na použitie v IoT a neboli určené na prácu v hmle alebo cloude. Prostredníctvom handshakingu pridávajú ďalšiu prevádzku s každým nadviazaním spojenia, čo vyčerpáva výpočtové zdroje. V priemere došlo k nárastu réžie o 6,5 % pre TLS a 11 % pre DTLS v porovnaní s komunikáciou bez bezpečnostnej vrstvy. V prostrediach bohatých na zdroje, ktoré sa zvyčajne nachádzajú na úrovni to nebude problém, ale v spojení medzi IoT a úrovňou hmly sa to stáva dôležitým obmedzením.
Čo si vybrať? Jednoznačná odpoveď neexistuje. MQTT a HTTP sa zdajú byť najsľubnejšími protokolmi, pretože sa považujú za pomerne vyspelejšie a stabilnejšie riešenia internetu vecí v porovnaní s inými protokolmi.
Riešenia založené na jednotnom komunikačnom protokole
Prax jednoprotokolového riešenia má mnoho nevýhod. Napríklad protokol, ktorý vyhovuje obmedzenému prostrediu, nemusí fungovať v doméne, ktorá má prísne bezpečnostné požiadavky. S ohľadom na túto skutočnosť musíme zahodiť takmer všetky možné riešenia s jedným protokolom v ekosystéme Fog-to-Cloud v IoT, okrem MQTT a REST HTTP.
REST HTTP ako jednoprotokolové riešenie
Existuje dobrý príklad toho, ako REST HTTP požiadavky a odpovede interagujú v priestore IoT-to-Fog: . Zvieratá sú vybavené nositeľnými senzormi (IoT klient, C) a ovládané prostredníctvom cloud computingu pomocou systému inteligentného hospodárenia (Fog server, S).
Hlavička metódy POST špecifikuje zdroj na úpravu (/farma/zvieratá), ako aj verziu HTTP a typ obsahu, čo je v tomto prípade objekt JSON predstavujúci zvieraciu farmu, ktorú má systém spravovať (Dulcinea/krava). . Odpoveď zo servera signalizuje, že požiadavka bola úspešná odoslaním stavového kódu HTTPS 201 (vytvorený zdroj). Metóda GET musí špecifikovať iba požadovaný zdroj v URI (napríklad /farm/zvieratá/1), ktorý zo servera vráti JSON reprezentáciu zvieraťa s daným ID.
Metóda PUT sa používa, keď je potrebné aktualizovať nejaký špecifický záznam o zdroji. V tomto prípade zdroj špecifikuje URI pre parameter, ktorý sa má zmeniť, a aktuálnu hodnotu (napríklad indikujúcu, že krava práve kráča, /farma/zvieratá/1? stav=prechádzka). Nakoniec, metóda DELETE sa používa rovnako ako metóda GET, ale jednoducho vymaže zdroj ako výsledok operácie.
MQTT ako jednoprotokolové riešenie
Zoberme si rovnakú inteligentnú farmu, ale namiesto REST HTTP používame protokol MQTT. Lokálny server s nainštalovanou knižnicou Mosquitto funguje ako maklér. V tomto príklade jednoduchý počítač (označovaný ako farmársky server) Raspberry Pi slúži ako klient MQTT, implementovaný prostredníctvom inštalácie knižnice Paho MQTT, ktorá je plne kompatibilná s brokerom Mosquitto.
Tento klient zodpovedá abstrakcii IoT, ktorá predstavuje zariadenie so snímacími a výpočtovými schopnosťami. Sprostredkovateľ na druhej strane zodpovedá vyššej úrovni abstrakcie, ktorá predstavuje hmlový výpočtový uzol charakterizovaný väčšou kapacitou spracovania a ukladania.
V navrhovanom scenári inteligentnej farmy sa Raspberry Pi pripája k akcelerometru, GPS a teplotným senzorom a zverejňuje dáta z týchto senzorov do hmlového uzla. Ako asi viete, MQTT zaobchádza s témami ako s hierarchiou. Jeden vydavateľ MQTT môže publikovať správy na určitú množinu tém. V našom prípade sú tri. Pre senzor, ktorý meria teplotu v maštali, si klient vyberie tému (farma/chovňa/teplota). Pre senzory, ktoré merajú GPS polohu a pohyb zvierat cez akcelerometer, klient zverejní aktualizácie (farma zvierat/zviera/GPS) a (farma/zviera/pohyb).
Tieto informácie budú odovzdané sprostredkovateľovi, ktorý ich môže dočasne uložiť v lokálnej databáze pre prípad, že by sa neskôr objavil ďalší záujemca.
Okrem lokálneho servera, ktorý v hmle funguje ako MQTT broker a ktorému Raspberry Pis ako MQTT klienti posiela dáta zo senzorov, môže existovať ďalší MQTT broker na úrovni cloudu. V tomto prípade môžu byť informácie prenášané miestnemu brokerovi dočasne uložené v lokálnej databáze a/alebo odoslané do cloudu. Fog MQTT broker sa v tejto situácii používa na priradenie všetkých údajov k cloudovému MQTT brokerovi. S touto architektúrou môže byť používateľ mobilnej aplikácie predplatený obom brokerom.
Ak spojenie s jedným z brokerov (napríklad cloud) zlyhá, koncový používateľ dostane informácie od druhého (hmla). Toto je charakteristický znak kombinovaných systémov hmly a cloud computingu. V predvolenom nastavení môže byť mobilná aplikácia nakonfigurovaná tak, aby sa najprv pripojila k maklérovi fog MQTT, a ak to zlyhá, aby sa pripojila ku cloudovému maklérovi MQTT. Toto riešenie je len jedným z mnohých v systémoch IoT-F2C.
Viacprotokolové riešenia
Jednoprotokolové riešenia sú obľúbené vďaka ich jednoduchšej implementácii. Je ale jasné, že v systémoch IoT-F2C má zmysel kombinovať rôzne protokoly. Ide o to, že rôzne protokoly môžu fungovať na rôznych úrovniach. Vezmite si napríklad tri abstrakcie: vrstvy internetu vecí, hmlu a cloud computing. Zariadenia na úrovni internetu vecí sa vo všeobecnosti považujú za obmedzené. Pre tento prehľad považujme úrovne internetu vecí za najviac obmedzené, cloud za najmenej obmedzené a výpočtovú hmlu za „niekde uprostred“. Potom sa ukazuje, že medzi IoT a hmlou abstrakciou súčasné protokolové riešenia zahŕňajú MQTT, CoAP a XMPP. Na druhej strane medzi hmlou a cloudom je AMQP jedným z hlavných používaných protokolov spolu s REST HTTP, ktorý sa vďaka svojej flexibilite používa aj medzi IoT a fog vrstvami.
Hlavným problémom je tu interoperabilita protokolov a jednoduchosť prenosu správ z jedného protokolu do druhého. V ideálnom prípade bude v budúcnosti architektúra systému internetu vecí s cloudovými a fog zdrojmi nezávislá od použitého komunikačného protokolu a zabezpečí dobrú interoperabilitu medzi rôznymi protokolmi.
Keďže to v súčasnosti neplatí, má zmysel kombinovať protokoly, ktoré nemajú výrazné rozdiely. Na tento účel je jedno potenciálne riešenie založené na kombinácii dvoch protokolov, ktoré sledujú rovnaký architektonický štýl, REST HTTP a CoAP. Ďalšie navrhované riešenie je založené na kombinácii dvoch protokolov, ktoré ponúkajú komunikáciu publikovať a predplatiť, MQTT a AMQP. Použitie podobných konceptov (MQTT aj AMQP používajú brokerov, CoAP a HTTP používajú REST) uľahčuje implementáciu týchto kombinácií a vyžaduje menšie integračné úsilie.
Obrázok (a) zobrazuje dva modely založené na požiadavke a odozve, HTTP a CoAP, a ich možné umiestnenie v riešení IoT-F2C. Keďže HTTP je jedným z najznámejších a najrozšírenejších protokolov v moderných sieťach, je nepravdepodobné, že bude úplne nahradený inými protokolmi na odosielanie správ. Medzi uzlami reprezentujúcimi výkonné zariadenia, ktoré sa nachádzajú medzi cloudom a hmlou, je REST HTTP inteligentným riešením.
Na druhej strane, pre zariadenia s obmedzenými výpočtovými zdrojmi, ktoré komunikujú medzi vrstvami Fog a IoT, je efektívnejšie využívať CoAP. Jednou z veľkých výhod CoAP je vlastne jeho kompatibilita s HTTP, keďže oba protokoly sú založené na princípoch REST.
Obrázok (b) zobrazuje dva komunikačné modely zverejnenia a predplatenia v rovnakom scenári, vrátane MQTT a AMQP. Aj keď by sa oba protokoly mohli hypoteticky použiť na komunikáciu medzi uzlami na každej abstrakcii, ich poloha by sa mala určiť na základe výkonu. MQTT bol navrhnutý ako ľahký protokol pre zariadenia s obmedzenými výpočtovými zdrojmi, takže ho možno použiť na komunikáciu IoT-Fog. AMQP je vhodnejší pre výkonnejšie zariadenia, ktoré by ho ideálne umiestnili medzi hmlové a cloudové uzly. Namiesto MQTT je možné v IoT použiť protokol XMPP, pretože sa považuje za ľahký. Ale v takýchto scenároch nie je tak široko používaný.
Závery
Je nepravdepodobné, že jeden z diskutovaných protokolov bude postačovať na pokrytie všetkej komunikácie v systéme, od zariadení s obmedzenými výpočtovými zdrojmi až po cloudové servery. Štúdia zistila, že dve najsľubnejšie možnosti, ktoré vývojári využívajú najviac, sú MQTT a RESTful HTTP. Tieto dva protokoly sú nielen najvyspelejšie a najstabilnejšie, ale zahŕňajú aj veľa dobre zdokumentovaných a úspešných implementácií a online zdrojov.
Vďaka svojej stabilite a jednoduchej konfigurácii je MQTT protokol, ktorý časom preukázal svoj vynikajúci výkon pri použití na úrovni internetu vecí s obmedzenými zariadeniami. V častiach systému, kde nie je problém s obmedzenou komunikáciou a spotrebou batérie, ako sú niektoré hmlové domény a väčšina cloud computingu, je RESTful HTTP jednoduchou voľbou. Do úvahy by sa malo brať aj CoAP, pretože sa tiež rýchlo vyvíja ako štandard pre odosielanie správ internetu vecí a je pravdepodobné, že v blízkej budúcnosti dosiahne úroveň stability a zrelosti podobnú MQTT a HTTP. Ale štandard sa v súčasnosti vyvíja, čo prináša krátkodobé problémy s kompatibilitou.
Čo si ešte môžete prečítať na blogu?
→
→
→
→
→
Prihláste sa na odber -kanál, aby ste nezmeškali ďalší článok! Píšeme si maximálne dvakrát do týždňa a len služobne.
Zdroj: hab.com