Udviklingen af teknologi inden for software og hardware samt fremkomsten af nye kommunikationsprotokoller har ført til en udvidelse af Internet of Things (IoT). Antallet af enheder stiger dag for dag, og de genererer enorme mængder data. Derfor opstår behovet for en praktisk systemarkitektur, der kan behandle, opbevare og overføre disse data.
I øjeblikket anvendes cloud-tjenester til dette formål. Den stadig mere populære paradigm af fog computing kan dog supplere cloud-løsninger ved at skalere og optimere IoT-infrastrukturen.
"Clouds" kan dække de fleste IoT-anmodninger. For eksempel kan de sikre overvågning af tjenester, hurtig behandling af alle datamængder genereret af enheder samt deres visualisering. Fog computing er mere effektiv i løsningen af real-time opgaver. Den sikrer hurtig respons på forespørgsler og minimal forsinkelse i datahåndtering. Det vil sige, at Fog supplerer "clouds" og udvider deres kapabiliteter.
Det vigtigste spørgsmål er dog: hvordan skal alt dette interagere i konteksten af IoT? Hvilke kommunikationsprotokoller vil være de mest effektive i arbejdet med et integreret IoT-Fog-Cloud system?
På trods af den tilsyneladende dominans af HTTP anvendes der mange andre løsninger i IoT-, Fog- og Cloud-systemer. Dette skyldes, at IoT skal kombinere funktionelle muligheder fra forskellige enhedssensorer med sikkerhed, kompatibilitet og andre krav fra brugerne.
Der er dog ikke et entydigt koncept for en referencearkitektur og kommunikationsstandard. Derfor er skabelsen af en ny protokol eller tilpasningen af en eksisterende protokol til specifikke IoT-opgaver en af de vigtigste opgaver, der står over for IT-samfundet.
Hvilke protokoller anvendes i dag, og hvad kan de tilbyde? Lad os finde ud af det. Men først lad os diskutere principperne for økosystemet, hvor cloud, fog og Internet of Things interagerer.
IoT Fog-to-Cloud (F2C) Arkitektur
Du har sikkert bemærket, hvor store bestræbelser der gøres for at undersøge fordelene og fordelene ved rationel og koordineret styring af IoT, clouds og fog. Hvis ikke, så her er tre initiativer til standardisering: , og .
Hvis man tidligere kun har overvejet to niveauer, cloud og endepunkter, introducerer den foreslåede arkitektur et nyt niveau - tågecomputing. Tågeniveauet kan opdeles i flere underniveauer afhængigt af ressourcernes specifik såsom politikker, der bestemmer brugen af forskellige enheder i disse underniveauer.
Hvordan kan denne abstraktion se ud? Her er et typisk IoT-Fog-Cloud økosystem. IoT-enheder sender data til mere potente servere og beregningsenheder for at løse opgaver, der kræver lav latens. I dette system er skyen ansvarlig for at løse opgaver, der kræver store mængder beregningsressourcer eller lagringsplads.
Smartphones, smartwatches og andre gadgets kan også være en del af IoT. Men sådanne enheder bruger typisk proprietære kommunikationsprotokoller fra store udviklere. De genererede IoT-data sendes til tågeniveauet via REST HTTP-protokollen, som sikrer fleksibilitet og funktionel kompatibilitet ved oprettelse af RESTful-tjenester. Dette er vigtigt i lyset af behovet for at sikre bagudkompatibilitet med eksisterende beregningsinfrastruktur, der fungerer på lokale computere, servere eller serverklynger. Lokale ressourcer, der kaldes 'tågeknuder', filtrerer de modtagne data og behandler dem lokalt eller videresender dem til skyen for videre beregning.
Skyerne understøtter forskellige kommunikationsprotokoller, hvoraf de mest almindelige er AMQP og REST HTTP. Da HTTP er velkendt og designet til internettet, kan man stille spørgsmålet: "Skal vi ikke bruge det til at arbejde med IoT og tågen?". Men denne protokol har præstationsproblemer. Mere om dette senere.
Generelt findes der to modeller for kommunikationsprotokoller, der passer til vores system. Det er anmodning-svar og publicering-abonnement. Den første model er mere velkendt, især i server-klient-arkitektur. Klienten anmoder om information fra serveren, som så modtager anmodningen, behandler den og returnerer et svar. REST HTTP og CoAP-protokollerne fungerer efter denne model.
Den anden model opstod ud fra behovet for at sikre asynkron, distribueret, svag forbindelse mellem kilder, der genererer data, og modtagerne af disse data.
Modellen involverer tre deltagere: udgiver (datakilde), mægler (dispatcher) og abonnent (modtager). Her skal klienten, der fungerer som abonnent, ikke anmode om information fra serveren. I stedet for at sende anmodninger abonnerer han på bestemte begivenheder i systemet via mægleren, som er ansvarlig for filtrering af alle indgående meddelelser og deres routning mellem udgivere og abonnenter. Og når der sker en begivenhed, der vedrører et bestemt emne, publicerer udgiveren det til mægleren, som sender oplysningerne til abonnenten om det ønskede emne.
I bund og grund er denne arkitektur baseret på begivenheder. Og denne interaktionsmodel er interessant for applikationer inden for IoT, cloud, fog på grund af dens evne til at sikre skalerbarhed og forenkle forbindelsen mellem forskellige enheder, understøtte dynamisk 'mange-til-mange' kommunikation og asynkron kommunikation. Blandt de mest kendte standardiserede meddelelsesprotokoller, der anvender 'publish-subscribe'-modellen, er MQTT, AMQP og DDS.
Det er åbenlyst, at 'publish-subscribe'-modellen har mange fordele:
- Udgiverne og abonnenterne har ikke brug for at vide om hinandens eksistens;
- En abonnent kan modtage information fra mange forskellige udgivelser, mens en udgiver kan sende data til mange forskellige abonnenter (princip om 'mange-til-mange');
- Udgiver og abonnent behøver ikke at være aktive samtidig for at udveksle data, fordi mægleren (der fungerer som et køsystem) kan opbevare meddelelser til kunder, der i øjeblikket ikke er online.
Men 'request-response'-modellen har også sine styrker. I de tilfælde, hvor serverens kapaciteter til at håndtere anmodninger fra flere kunder ikke er et problem, giver det mening at anvende de allerede afprøvede pålidelige løsninger.
Der er også protokoller, der understøtter begge modeller. For eksempel XMPP og HTTP 2.0, som understøtter muligheden for „server push“. IETF har også frigivet CoAP. I et forsøg på at løse problemet med meddelelser er der blevet skabt flere andre løsninger, såsom WebSockets-protokollen eller brugen af HTTP-protokollen via QUIC (Quick UDP Internet Connections).
Når det gælder WebSockets, selvom de bruges til at overføre data i realtid fra server til webklient og sikrer vedholdende forbindelser med samtidig tovejs kommunikation, er de ikke beregnet til enheder med begrænsede beregningsressourcer. QUIC fortjener også opmærksomhed, da den nye transportprotokol giver masser af nye muligheder. Men da QUIC endnu ikke er standardiseret, ville det være for tidligt at forudsige dens mulige anvendelse og indflydelse på IoT-løsninger. Så vi gemmer WebSockets og QUIC i hukommelsen med udsigt til fremtiden, men vi vil ikke undersøge dem nærmere for nu.
Hvem er sødere på jorden: vi sammenligner protokoller
Lad os nu tale om styrker og svagheder ved protokollerne. For at komme direkte til sagen, er der ikke én tydelig leder. Hver protokol har sine fordele og ulemper.
Reaktionstid
En af de vigtigste egenskaber ved kommunikationsprotokoller, især i forhold til Internet of Things, er reaktionstiden. Men blandt de eksisterende protokoller er der ingen ubestridt vinder, der viser det minimale niveau af forsinkelse under forskellige forhold. Derimod findes der et væld af undersøgelser og sammenligninger af protokollernes muligheder.
For eksempel, Sammenligninger af ydeevnen mellem HTTP og MQTT i forbindelse med IoT har vist, at reaktionstiden for anmodninger i MQTT er mindre end i HTTP. Og under af transmissionstid (RTT) for MQTT og CoAP viste det sig, at den gennemsnitlige RTT for CoAP er 20% mindre end for MQTT.
Andet RTT for the MQTT and CoAP protocols was tested in two scenarios: a local network and an IoT network. It turned out that the average RTT is 2-3 times higher in the IoT network. MQTT with QoS0 showed lower results compared to CoAP, while MQTT with QoS1 demonstrated a higher RTT due to ACK at the application and transport layers. For different QoS levels, the delays in a non-congested network for MQTT were in milliseconds, while for CoAP - in hundreds of microseconds. However, it is worth remembering that in less reliable networks, MQTT, operating over TCP, will show a completely different result.
The response times of the AMQP and MQTT protocols through increased payloads showed that under light load, the level of latency is almost the same. But when transmitting large amounts of data, MQTT demonstrates lower response times. In another CoAP was compared with HTTP in a machine-to-machine communication scenario involving devices deployed on vehicles equipped with gas sensors, weather sensors, GPS, and mobile network interface (GPRS). The time required to transmit a CoAP message over the mobile network was almost three times shorter than the time needed for HTTP messages.
Research was conducted comparing not two, but three protocols. For example, the performance of IoT protocols MQTT, DDS, and CoAP in a medical application scenario using a network emulator. DDS outperformed MQTT in terms of the latency experienced for telemetry under various poor network conditions. CoAP based on UDP performed well for applications requiring quick responses; however, due to its UDP foundation, there was significant unpredictable packet loss.
Båndbredde
MQTT and CoAP were evaluated in terms of bandwidth efficiency by calculating the total amount of data transmitted per message. CoAP showed lower bandwidth than MQTT when transmitting small messages. However, when comparing the protocols' efficiency in terms of the ratio of useful information bytes to the total bytes transmitted, CoAP proved to be more efficient.
Ved Ved brugen af båndbredden i MQTT, DDS (med TCP som transportprotokol) og CoAP, viste det sig, at CoAP generelt havde et relativt lavere båndbreddeforbrug, som ikke steg ved øget netværkspakke tab eller øget netværkslatens, i modsætning til MQTT og DDS, hvor der blev observeret en stigning i båndbreddeforbruget under de nævnte scenarier. I et andet scenarie blev et stort antal enheder taget i brug til at sende data samtidigt, hvilket er en typisk situation i IoT-miljøer. Resultaterne viste, at CoAP var bedre til højere belastning.
Ved lav belastning brugte CoAP mindst båndbredde, efterfulgt af MQTT og REST HTTP. Dog, når størrelsen af payloads steg, viste REST HTTP de bedste resultater.
Energiforbrug
Spørgsmålet om energiforbrug er altid vigtigt, og det er især relevant i IoT-systemer. Hvis energiforbruget for MQTT og HTTP, så "sluger" HTTP betydeligt mere. CoAP er mere sammenlignet med MQTT, hvilket muliggør bedre energistyring. I enkle scenarier er MQTT dog bedre til informationsudveksling i IoT-netværk, især når der ikke er strenge kapacitetsbegrænsninger.
Eksperimentet, hvor vi sammenlignede funktionerne af AMQP og MQTT på et testbed i et mobilt eller ustabilt trådløst netværk, viste, at AMQP tilbyder flere muligheder med hensyn til sikkerhed, mens MQTT er mere energieffektivt.
Sikkerhed
Sikkerhed er et andet vigtigt emne, der brings op, når man undersøger emnet for IoT og fog/cloud computing. Sikkerhedsmekanismen er normalt baseret på TLS i HTTP, MQTT, AMQP og XMPP, eller DTLS i CoAP, samt understøtter begge dele i DDS.
TLS og DTLS starter med en kommunikationsetableringsproces mellem klient- og serverparten for at udveksle understøttede cipher suites og nøgler. Begge parter aftaler disse sæt for at sikre, at den fremtidige kommunikation foregår i en sikker kanal. Forskellen mellem dem ligger i små modifikationer, der gør DTLS baseret på UDP i stand til at fungere over usikre forbindelser.
Ved Flere forskellige implementeringer af TLS og DTLS har vist, at TLS klarer opgaven bedre. Angreb på DTLS var mere succesfulde på grund af dets tolerance over for fejl.
Men det største problem med disse protokoller er, at de oprindeligt ikke var designet til brug i IoT og ikke tog højde for drift i tåge eller skyen. Gennem en aftalt håndtryk tilføjer de ekstra trafik ved hver forbindelse, hvilket udtømmer beregningsressourcerne. I gennemsnit er der en stigning på 6,5% for TLS og 11% for DTLS i overhead sammenlignet med kommunikation uden sikkerhedsniveau. I ressourcerige miljøer, der normalt er placeret på vil dette ikke være et problem, men i forbindelsen mellem IoT og tågeniveauet bliver det en væsentlig begrænsning.
Hvad skal man så vælge? Der er ikke noget entydigt svar. MQTT og HTTP synes at være de mest lovende protokoller, da de anses for at være relativt mere modne og stabile løsninger for IoT i forhold til andre protokoller.
Løsninger baseret på en enkelt kommunikationsprotokol
Praksis for en protokol-løsning har mange ulemper. For eksempel kan en protokol, der opfylder et begrænset miljø, ikke fungere i et domæne med strenge sikkerhedskrav. Med dette in mente skal vi forkaste næsten alle mulige løsninger baseret på én protokol i Fog-to-Cloud-økosystemet i IoT, undtagen MQTT og REST HTTP.
REST HTTP som en protokol-løsning
Der er et godt eksempel på interaktionen mellem forespørgsler og svar i REST HTTP i IoT-to-Fog: . Dyr udstyres med bærbare sensorer (IoT-klient, C) og styres gennem cloud computing af det intelligente landbrugssystem (Fog-server, S).
I overskriften for POST-metoden angives ressourcen, der skal ændres (\/farm\/animals), samt HTTP-versionen og indholdstypen, som i dette tilfælde er et JSON-objekt, der repræsenterer landbruget, som systemet skal styre (Dulcinea\/ko). Serverens svar angiver, at anmodningen var succesfuld ved at sende en HTTPS-statuskode 201 (ressource oprettet). GET-metoden skal kun angive den anmodede ressource i URI'en (f.eks. \/farm\/animals\/1), som returnerer JSON-repræsentationen af dyret med dette ID fra serveren.
PUT-metoden anvendes, når det er nødvendigt at opdatere en bestemt post i ressourcen. I dette tilfælde angives URI'en for parameteren, der skal ændres, samt den aktuelle værdi (for eksempel angiver det, at en ko i øjeblikket græsser, /farm/animals/1?state=græsser). Endelig anvendes DELETE-metoden på samme måde som GET-metoden, men den sletter blot ressourcen som et resultat af operationen.
MQTT som en enkeltprotokolløsning
Lad os tage den samme smarte farm, men i stedet for REST HTTP bruger vi MQTT-protokollen. En lokal server med den installerede Mosquitto-bibliotek fungerer som broker. I dette eksempel fungerer en simpel computer (benævnt farmserveren) Raspberry Pi som en MQTT-klient, implementeret ved hjælp af installationen af MQTT Paho-biblioteket, som er helt kompatibel med Mosquitto-brokeren.
Denne klient svarer til et IoT-abstraktionsniveau, der repræsenterer en enhed med opdagelses- og beregningsmuligheder. Middelmanden derimod svarer til et højere abstraktionsniveau, der repræsenterer en beregningsknude i tågen, kendetegnet ved større kapaciteter til behandling og lagring af data.
I det foreslåede scenarie for 'smart farm' tilsluttes Raspberry Pi til en accelerometer, GPS og temperaturfølere og publicerer data fra disse sensorer i tågenoden. Som du sikkert ved, betragter MQTT emner som en hierarki. En MQTT-udgiver kan publicere meddelelser i et bestemt sæt emner. I vores tilfælde er der tre. For sensoren, der måler temperaturen i dyrenes skur, vælger klienten emnet (animalfarm/shed/temperature). For sensorer, der måler GPS-positionen og dyrenes bevægelse via accelerometeret, publicerer klienten opdateringer (animalfarm/animal/GPS) og (animalfarm/animal/movement).
Disse oplysninger vil blive sendt til brokeren, som midlertidigt kan gemme dem i en lokal database, hvis der senere opstår en anden interesseret abonnent.
Udover en lokal server, der fungerer som en MQTT-broker i tågen, og som Raspberry Pi, der fungerer som MQTT-klienter, sender data fra sensorer til, kan der også være en anden MQTT-broker på cloud-niveau. I dette tilfælde kan oplysningerne, der sendes til den lokale broker, midlertidigt gemmes i en lokal database og/eller sendes til skyen. Den tågehåndterede MQTT-broker bruges i denne situation til at binde alle data til den cloud-baserede MQTT-broker. I en sådan arkitektur kan brugeren af mobilapplikationen abonnere på begge brokere.
I tilfælde af forbindelsesfejl med en af brokerne (for eksempel cloud-broker), vil slutbrugeren modtage oplysninger fra den anden (tågebroker). Dette er et karakteristisk træk ved kombinerede systemer med tåge og cloud computing. Som standard kan mobilapplikationen konfigureres til først at oprette forbindelse til den tågehåndterede MQTT-broker, og i tilfælde af fejl til at oprette forbindelse til MQTT-brokeren i skyen. Denne løsning er blot en af mange i IoT-F2C-systemer.
Multiprotokol-løsninger
Løsninger med én protokol er populære, fordi de er lettere at implementere. Men det er indlysende, at det i IoT-F2C-systemer giver mening at kombinere forskellige protokoller. Ideen er, at forskellige protokoller kan fungere på forskellige niveauer. Lad os tage tre abstraktioner: IoT-niveauet, tågeniveauet og cloud computing-niveauet. Enheder på IoT-niveauet betragtes normalt som begrænsede. For denne gennemgang lad os betragte IoT-niveauet som mest begrænset, cloud-niveauet som mindst begrænset og tågeberegning som 'et sted imellem'. Det viser sig, at de aktuelle protokolløsninger mellem IoT og tågeabstraktionerne inkluderer MQTT, CoAP og XMPP. Mellem tågen og cloud-enheden er AMQP en af de primære anvendte protokoller sammen med REST HTTP, der takket være sin fleksibilitet også bruges mellem IoT og tågelagene.
Det primære problem her er den funktionelle kompatibilitet af protokoller og enkelheden ved at oversætte beskeder fra én protokol til en anden. Ideelt set bør fremtidens arkitektur for Internet of Things med cloud- og tågeressourcer være uafhængig af den anvendte kommunikationsprotokol og sikre god interaktion mellem forskellige protokoller.
Da der er betydelige ligheder mellem de to protokoller, giver det mening at kombinere dem, uden at de adskiller sig væsentligt. I denne forbindelse er en potentielt løsning baseret på en kombination af to protokoller, der følger den samme arkitekturstil, REST HTTP og CoAP. En anden foreslået løsning er baseret på en kombination af to protokoller, der tilbyder interaktion efter "publish-subscribe" modellen, MQTT og AMQP. Brugen af nærliggende koncepter (både MQTT og AMQP anvender mæglere, mens CoAP og HTTP anvender REST) forenkler implementeringen af disse kombinationer og kræver mindre integrationsindsats.
Figur (a) viser to anmodnings-svar modeller, HTTP og CoAP, og deres potentielle placering i IoT-F2C løsningen. Da HTTP er et af de mest kendte og tilpassede protokoller i moderne netværk, er det usandsynligt, at det bliver helt erstattet af andre beskedprotokoller. Blandt noder, der repræsenterer kraftfulde enheder, der befinder sig mellem skyen og tågen, er REST HTTP en fornuftig løsning.
På den anden side, for enheder med begrænsede beregningsressourcer, der forbinder mellem tågeniveauerne og IoT, er det mere effektivt at anvende CoAP. En af de store fordele ved CoAP er faktisk dens kompatibilitet med HTTP, da begge protokoller er baseret på REST-principperne.
Figur (b) viser to "publish-subscribe" interaktionsmodeller i et scenario, herunder MQTT og AMQP. Selvom begge protokoller hypotetisk kan bruges til kommunikation mellem noder på hvert abstractionsniveau, bør deres placering bestemmes baseret på ydeevnen. MQTT blev designet som en forenklet protokol til enheder med begrænsede beregningsressourcer, og kan derfor anvendes til kommunikation mellem IoT og tågen. AMQP er mere velegnet til kraftigere enheder, som ideelt set ville placere den mellem tågen og skyens noder. I stedet for MQTT kan XMPP-protokollen anvendes i IoT, da den betragtes som letvægts. Men den anvendes ikke så bredt i sådanne scenarier.
Konklusioner
Det er usandsynligt, at én af de betragtede protokoller vil være tilstrækkelig til at dække al kommunikationen i systemet, fra enheder med begrænsede computerressourcer til cloud-servere. Undersøgelser har vist, at de to mest lovende muligheder, som udviklere oftest bruger, er MQTT og RESTful HTTP. Disse to protokoller er ikke kun de mest modne og stabile, men inkluderer også mange veldokumenterede og succesfulde implementeringer samt online ressourcer.
Takket være sin stabilitet og enkle konfiguration er MQTT en protokol, der med tiden har bevist sin fremragende ydeevne ved brug på IoT-niveau med begrænsede enheder. I systemområder, hvor begrænset forbindelse og batteriforbrug ikke er et problem, som i nogle fog-løsninger og de fleste cloud computing-scenarier, er RESTful HTTP et simpelt valg. CoAP bør også overvejes, da det hurtigt udvikler sig som standard for IoT-kommunikation, og det er meget sandsynligt, at det i den nærmeste fremtid vil nå et niveau af stabilitet og modenhed, der ligner MQTT og HTTP. Men standarden er i øjeblikket under udvikling, hvilket medfører kortsigtede kompatibilitetsproblemer.
Hvad mere nyttigt kan man læse i bloggen
→
→
→
→
→
Tilmeld dig vores -kanalen for ikke at misse den næste artikel! Vi skriver højst to gange om ugen og kun om relevante emner.
Kilde: habr.com
