Udviklingen af teknologier inden for software og hardware, fremkomsten af nye kommunikationsprotokoller har ført til udvidelsen af Internet of Things (IoT). Antallet af enheder vokser dag for dag, og de genererer en enorm mængde data. Derfor er der behov for en bekvem systemarkitektur, der er i stand til at behandle, lagre og transmittere disse data.
Nu bruges cloud-tjenester til disse formål. Det stadig mere populære fog computing-paradigme (Fog) kan dog supplere cloud-løsninger ved at skalere og optimere IoT-infrastruktur.
Skyer er i stand til at dække de fleste IoT-anmodninger. For eksempel at levere overvågning af tjenester, hurtig behandling af enhver mængde data, der genereres af enheder, samt deres visualisering. Tågeberegning er mere effektiv, når man løser problemer i realtid. De giver hurtig respons på anmodninger og minimal latens i databehandlingen. Det vil sige, at Fog komplementerer "skyerne" og udvider dens muligheder.
Men hovedspørgsmålet er anderledes: hvordan skal alt dette interagere i forbindelse med IoT? Hvilke kommunikationsprotokoller vil være mest effektive, når du arbejder i et kombineret IoT-Fog-Cloud-system?
På trods af HTTPs tilsyneladende dominans er der en lang række andre løsninger, der bruges i IoT-, Fog- og Cloud-systemer. Dette skyldes, at IoT skal kombinere funktionaliteten af en række enhedssensorer med brugernes sikkerhed, kompatibilitet og andre krav.
Men der er simpelthen ikke en enkelt idé om referencearkitekturen og kommunikationsstandarden. Derfor er oprettelse af en ny protokol eller ændring af en eksisterende protokol til specifikke IoT-opgaver en af de vigtigste opgaver, som IT-samfundet står over for.
Hvilke protokoller er i brug i øjeblikket, og hvad kan de tilbyde? Lad os finde ud af det. Men lad os først diskutere principperne for økosystemet, hvor skyer, tåge og tingenes internet interagerer.
IoT Fog-to-Cloud (F2C) arkitektur
Du har sikkert lagt mærke til, hvor mange kræfter der bliver lagt i at udforske fordele og fordele forbundet med smart og koordineret styring af IoT, sky og tåge. Hvis ikke, så er her tre standardiseringsinitiativer: , и .
Hvis tidligere kun 2 niveauer blev overvejet, skyer og slutenheder, introducerer den foreslåede arkitektur et nyt niveau - tågeberegning. I dette tilfælde kan tågeniveauet opdeles i flere underniveauer, afhængigt af ressourcespecifikationerne eller et sæt 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 hurtigere servere og computerenheder for at løse problemer, der kræver lav latenstid. I det samme system er skyer ansvarlige for at løse problemer, der kræver en stor mængde computerressourcer eller datalagerplads.
Smartphones, smarture og andre gadgets kan også være en del af IoT. Men sådanne enheder bruger som regel proprietære kommunikationsprotokoller fra store udviklere. De genererede IoT-data overføres til tågelaget via REST HTTP-protokollen, som giver fleksibilitet og interoperabilitet ved oprettelse af RESTful-tjenester. Dette er vigtigt i lyset af behovet for at sikre bagudkompatibilitet med eksisterende computerinfrastruktur, der kører på lokale computere, servere eller en serverklynge. Lokale ressourcer, kaldet "tåge noder", filtrerer de modtagne data og behandler dem lokalt eller sender dem til skyen for yderligere beregninger.
Skyer understøtter forskellige kommunikationsprotokoller, de mest almindelige er AMQP og REST HTTP. Da HTTP er velkendt og skræddersyet til internettet, kan spørgsmålet opstå: "skal vi ikke bruge det til at arbejde med IoT og tåge?" Denne protokol har dog præstationsproblemer. Mere om dette senere.
Generelt er der 2 modeller af kommunikationsprotokoller, der passer til det system, vi har brug for. Disse er anmodning-svar og udgiv-abonner. Den første model er mere kendt, især inden for server-klient-arkitektur. Klienten anmoder om information fra serveren, og serveren modtager anmodningen, behandler den og returnerer en svarmeddelelse. REST HTTP- og CoAP-protokollerne fungerer på denne model.
Den anden model opstod fra behovet for at tilvejebringe asynkron, distribueret, løs kobling mellem de kilder, der genererer data, og modtagerne af disse data.
Modellen forudsætter tre deltagere: en udgiver (datakilde), en mægler (dispatcher) og en abonnent (modtager). Her skal klienten, der fungerer som abonnent, ikke anmode om information fra serveren. I stedet for at sende anmodninger, abonnerer den på visse hændelser i systemet gennem en mægler, som er ansvarlig for at filtrere alle indgående beskeder og dirigere dem mellem udgivere og abonnenter. Og udgiveren, når der opstår en begivenhed vedrørende et bestemt emne, udgiver den til mægleren, som sender data om det anmodede emne til abonnenten.
I det væsentlige er denne arkitektur begivenhedsbaseret. Og denne interaktionsmodel er interessant for applikationer inden for IoT, cloud, tåge på grund af dens evne til at give skalerbarhed og forenkle sammenkoblingen mellem forskellige enheder, understøtte dynamisk mange-til-mange-kommunikation og asynkron kommunikation. Nogle af de mest kendte standardiserede meddelelsesprotokoller, der bruger en publicerings-abonnement-model, inkluderer MQTT, AMQP og DDS.
Det er klart, at public-subscribe-modellen har en masse fordele:
- Udgivere og abonnenter behøver ikke at kende til hinandens eksistens;
- Én abonnent kan modtage information fra mange forskellige publikationer, og én udgiver kan sende data til mange forskellige abonnenter (mange-til-mange-princippet);
- Udgiver og abonnent behøver ikke at være aktive på samme tid for at kommunikere, fordi mægleren (der fungerer som et køsystem) vil være i stand til at gemme beskeden for klienter, der ikke i øjeblikket er tilsluttet netværket.
Anmodning-svar-modellen har dog også sine styrker. I tilfælde, hvor serversidens evne til at håndtere flere klientanmodninger ikke er et problem, giver det mening at bruge gennemprøvede, pålidelige løsninger.
Der er også protokoller, der understøtter begge modeller. For eksempel XMPP og HTTP 2.0, som understøtter "server push" muligheden. IETF har også udgivet en CoAP. I et forsøg på at løse meddelelsesproblemet er der lavet flere andre løsninger, såsom WebSockets-protokollen eller brugen af HTTP-protokollen over QUIC (Quick UDP Internet Connections).
I tilfælde af WebSockets, selvom det bruges til at overføre data i realtid fra en server til en webklient og giver vedvarende forbindelser med samtidig tovejskommunikation, er det ikke beregnet til enheder med begrænsede computerressourcer. QUIC fortjener også opmærksomhed, da den nye transportprotokol giver en masse nye muligheder. Men da QUIC endnu ikke er standardiseret, er det for tidligt at forudsige dets mulige anvendelse og indvirkning på IoT-løsninger. Så vi holder WebSockets og QUIC i tankerne med henblik på fremtiden, men vi vil ikke studere det mere detaljeret for nu.
Hvem er den sødeste i verden: Sammenligning af protokoller
Lad os nu tale om styrker og svagheder ved protokoller. Når vi ser fremad, så lad os straks tage forbehold for, at der ikke er én klar leder. Hver protokol har nogle fordele/ulemper.
Responstid
En af de vigtigste egenskaber ved kommunikationsprotokoller, især i forhold til Internet of Things, er responstid. Men blandt de eksisterende protokoller er der ingen klar vinder, der demonstrerer minimumsniveauet af latenstid, når man arbejder under forskellige forhold. Men der er en hel masse forskning og sammenligninger af protokolfunktioner.
For eksempel, sammenligninger af effektiviteten af HTTP og MQTT ved arbejde med IoT viste, at responstiden for anmodninger om MQTT er mindre end for HTTP. Og når Rundrejsetiden (RTT) for MQTT og CoAP afslørede, at den gennemsnitlige RTT for CoAP er 20 % mindre end for MQTT.
Andet med RTT for MQTT- og CoAP-protokollerne blev udført i to scenarier: lokalt netværk og IoT-netværk. Det viste sig, at den gennemsnitlige RTT er 2-3 gange højere i et IoT-netværk. MQTT med QoS0 viste et lavere resultat sammenlignet med CoAP, og MQTT med QoS1 viste en højere RTT på grund af ACK'er ved applikations- og transportlagene. For forskellige QoS-niveauer var netværkslatens uden overbelastning millisekunder for MQTT og hundredvis af mikrosekunder for CoAP. Det er dog værd at huske på, at når man arbejder på mindre pålidelige netværk, vil MQTT, der kører oven på TCP, vise et helt andet resultat.
responstid for AMQP- og MQTT-protokollerne ved at øge nyttelasten viste, at med en let belastning er latensniveauet næsten det samme. Men når der overføres store mængder data, viser MQTT kortere svartider. i en mere CoAP blev sammenlignet med HTTP i et maskine-til-maskine kommunikationsscenarie med enheder installeret oven på køretøjer udstyret med gassensorer, vejrsensorer, lokationssensorer (GPS) og en mobilnetværksgrænseflade (GPRS). Den tid, det krævede at sende en CoAP-meddelelse over mobilnetværket, var næsten tre gange kortere end den tid, det krævede at bruge HTTP-meddelelser.
Der er udført undersøgelser, der sammenlignede ikke to, men tre protokoller. For eksempel, ydeevne af IoT-protokoller MQTT, DDS og CoAP i et medicinsk applikationsscenarie ved hjælp af en netværksemulator. DDS overgik MQTT med hensyn til testet telemetri-latens under en række dårlige netværksforhold. UDP-baseret CoAP fungerede godt for applikationer, der krævede hurtige svartider, men da det var UDP-baseret, var der betydeligt uforudsigeligt pakketab.
gennemløb
MQTT og CoAP med hensyn til båndbreddeeffektivitet blev udført som en beregning af den samlede mængde data transmitteret pr. besked. CoAP har vist lavere gennemløb end MQTT ved transmission af små beskeder. Men når man sammenligner effektiviteten af protokoller med hensyn til forholdet mellem antallet af nyttige informationsbytes og det samlede antal overførte bytes, viste CoAP sig at være mere effektiv.
på ved brug af MQTT, DDS (med TCP som transportprotokol) og CoAP-båndbredde, viste det sig, at CoAP generelt viste et relativt lavere båndbreddeforbrug, som ikke steg med øget netværkspakketab eller øget netværksforsinkelse, i modsætning til MQTT og DDS, hvor der var en stigning i båndbreddeudnyttelsen i de nævnte scenarier. Et andet scenarie involverede et stort antal enheder, der transmitterede data samtidigt, hvilket er typisk i IoT-miljøer. Resultaterne viste, at for højere udnyttelse er det bedre at bruge CoAP.
Under let belastning brugte CoAP den mindste båndbredde, efterfulgt af MQTT og REST HTTP. Men når størrelsen af nyttelasterne steg, havde REST HTTP de bedste resultater.
Strømforbrug
Spørgsmålet om energiforbrug er altid af stor betydning, og især i et IoT-system. Hvis Mens MQTT og HTTP forbruger elektricitet, forbruger HTTP meget mere. Og CoAP er mere sammenlignet med MQTT, hvilket tillader strømstyring. Men i simple scenarier er MQTT mere velegnet til at udveksle information i Internet of Things-netværk, især hvis der ikke er strømbegrænsninger.
Et eksperiment, der sammenlignede mulighederne for AMQP og MQTT på et mobilt eller ustabilt trådløst netværk testbed fandt, at AMQP tilbyder flere sikkerhedsmuligheder, mens MQTT er mere energieffektiv.
Безопасность
Sikkerhed er et andet kritisk spørgsmål, der rejses, når man studerer emnet Internet of Things og tåge/cloud computing. Sikkerhedsmekanismen er typisk baseret på TLS i HTTP, MQTT, AMQP og XMPP eller DTLS i CoAP og understøtter begge DDS-varianter.
TLS og DTLS begynder med processen med at etablere kommunikation mellem klient- og serversiden for at udveksle understøttede krypteringspakker og nøgler. Begge parter forhandler sæt for at sikre, at yderligere kommunikation sker på en sikker kanal. Forskellen mellem de to ligger i små modifikationer, der tillader UDP-baseret DTLS at arbejde over en upålidelig forbindelse.
på Flere forskellige implementeringer af TLS og DTLS fandt ud af, at TLS gjorde et bedre stykke arbejde. Angreb på DTLS var mere vellykkede på grund af dets fejltolerance.
Det største problem med disse protokoller er dog, at de ikke oprindeligt var designet til brug i IoT og ikke var beregnet til at fungere i tågen eller skyen. Gennem håndtryk tilføjer de ekstra trafik med hver forbindelses etablering, hvilket dræner computerressourcer. I gennemsnit er der en stigning på 6,5 % for TLS og 11 % for DTLS i overhead sammenlignet med kommunikation uden sikkerhedslag. I ressourcerige miljøer, som typisk er placeret på niveau vil dette ikke være et problem, men i sammenhængen mellem IoT og tågeniveau bliver dette en vigtig begrænsning.
Hvad skal man vælge? Der er ikke noget klart svar. MQTT og HTTP ser ud til at være de mest lovende protokoller, da de anses for at være forholdsvis mere modne og mere stabile IoT-løsninger sammenlignet med andre protokoller.
Løsninger baseret på en samlet kommunikationsprotokol
Udøvelsen af en enkeltprotokolløsning har mange ulemper. For eksempel fungerer en protokol, der passer til et begrænset miljø, muligvis ikke i et domæne, der har strenge sikkerhedskrav. Med dette i tankerne er vi overladt til at kassere næsten alle mulige enkeltprotokolløsninger i Fog-to-Cloud-økosystemet i IoT, undtagen MQTT og REST HTTP.
REST HTTP som en enkeltprotokolløsning
Der er et godt eksempel på, hvordan REST HTTP-anmodninger og -svar interagerer i IoT-to-Fog-rummet: . Dyrene er udstyret med bærbare sensorer (IoT-klient, C) og styres via cloud computing af et smart farming-system (Fog-server, S).
POST-metodens overskrift specificerer den ressource, der skal ændres (/farm/dyr) samt HTTP-versionen og indholdstypen, som i dette tilfælde er et JSON-objekt, der repræsenterer den dyrefarm, som systemet skal administrere (Dulcinea/ko) . Svaret fra serveren indikerer, at anmodningen lykkedes ved at sende HTTPS-statuskode 201 (ressource oprettet). GET-metoden må kun angive den anmodede ressource i URI'en (for eksempel /farm/dyr/1), som returnerer en JSON-repræsentation af dyret med det pågældende ID fra serveren.
PUT-metoden bruges, når en bestemt ressourcepost skal opdateres. I dette tilfælde specificerer ressourcen URI'en for parameteren, der skal ændres, og den aktuelle værdi (f.eks. angiver, at koen i øjeblikket går, /farm/dyr/1? tilstand=går). Endelig bruges DELETE-metoden på samme måde som GET-metoden, men sletter blot ressourcen som et resultat af operationen.
MQTT som en enkelt-protokol løsning
Lad os tage den samme smarte farm, men i stedet for REST HTTP bruger vi MQTT-protokollen. En lokal server med Mosquitto-biblioteket installeret fungerer som en mægler. I dette eksempel fungerer en simpel computer (benævnt farm-serveren) Raspberry Pi som en MQTT-klient, implementeret gennem en installation af Paho MQTT-biblioteket, som er fuldt kompatibelt med Mosquitto-mægleren.
Denne klient svarer til et IoT-abstraktionslag, der repræsenterer en enhed med sansnings- og computerfunktioner. Mediatoren svarer på den anden side til et højere abstraktionsniveau, der repræsenterer en tågeberegningsknude karakteriseret ved større behandlings- og lagerkapacitet.
I det foreslåede smart farm-scenarie forbinder Raspberry Pi til accelerometer, GPS og temperatursensorer og udgiver data fra disse sensorer til en tåge node. Som du sikkert ved, behandler MQTT emner som et hierarki. En enkelt MQTT-udgiver kan udgive beskeder til et bestemt sæt emner. I vores tilfælde er der tre af dem. For en sensor, der måler temperaturen i en dyrestald, vælger klienten et tema (dyregård/stald/temperatur). For sensorer, der måler GPS-placering og dyrebevægelser gennem accelerometeret, vil klienten offentliggøre opdateringer til (dyrfarm/dyr/GPS) og (dyrgård/dyr/bevægelse).
Disse oplysninger vil blive videregivet til mægleren, som midlertidigt kan gemme dem i en lokal database, hvis der senere kommer en anden interesseret abonnent.
Ud over den lokale server, der fungerer som en MQTT-mægler i tågen, og som Raspberry Pis, der fungerer som MQTT-klienter, sender sensordata, kan der være en anden MQTT-mægler på skyniveau. I dette tilfælde kan de oplysninger, der sendes til den lokale mægler midlertidigt gemmes i en lokal database og/eller sendes til skyen. Tåge-MQTT-mægleren i denne situation bruges til at knytte alle data til cloud-MQTT-mægleren. Med denne arkitektur kan en mobilapplikationsbruger abonnere på begge mæglere.
Hvis forbindelsen til en af mæglerne (for eksempel skyen) mislykkes, vil slutbrugeren modtage information fra den anden (tåge). Dette er et karakteristisk træk ved kombinerede tåge- og cloud computing-systemer. Som standard kan mobilappen konfigureres til først at oprette forbindelse til tåge-MQTT-mægleren, og hvis det mislykkes, oprette forbindelse til cloud-MQTT-mægleren. Denne løsning er blot en af mange i IoT-F2C-systemer.
Multi-protokol løsninger
Enkeltprotokolløsninger er populære på grund af deres nemmere implementering. Men det er klart, at det i IoT-F2C-systemer giver mening at kombinere forskellige protokoller. Tanken er, at forskellige protokoller kan fungere på forskellige niveauer. Tag for eksempel tre abstraktioner: lagene af IoT, tåge og cloud computing. Enheder på IoT-niveau anses generelt for at være begrænsede. For at få dette overblik, lad os betragte IoT-niveauer som de mest begrænsede, cloud de mindst begrænsede og tågedatabehandling som "et sted i midten." Det viser sig da, at mellem IoT og tågeabstraktioner inkluderer nuværende protokolløsninger MQTT, CoAP og XMPP. Mellem tåge og sky er AMQP derimod en af de vigtigste protokoller, der bruges sammen med REST HTTP, som på grund af sin fleksibilitet også bruges mellem IoT og tågelag.
Hovedproblemet her er interoperabiliteten af protokoller og letheden ved at overføre meddelelser fra en protokol til en anden. Ideelt set vil arkitekturen i et Internet of Things-system med cloud- og tågressourcer være uafhængig af den anvendte kommunikationsprotokol og sikre god interoperabilitet mellem forskellige protokoller.
Da dette ikke er tilfældet i øjeblikket, giver det mening at kombinere protokoller, der ikke har væsentlige forskelle. Til dette formål er én potentiel løsning baseret på en kombination af to protokoller, der følger den samme arkitektoniske stil, REST HTTP og CoAP. En anden foreslået løsning er baseret på en kombination af to protokoller, der tilbyder public-subscribe kommunikation, MQTT og AMQP. Brug af lignende koncepter (både MQTT og AMQP bruger mæglere, CoAP og HTTP bruger REST) gør disse kombinationer nemmere at implementere og kræver mindre integrationsindsats.
Figur (a) viser to request-response-baserede modeller, HTTP og CoAP, og deres mulige placering i en IoT-F2C-løsning. Da HTTP er en af de mest kendte og anvendte protokoller på moderne netværk, er det usandsynligt, at det vil blive fuldstændig erstattet af andre meddelelsesprotokoller. Blandt de noder, der repræsenterer kraftfulde enheder, der sidder mellem skyen og tågen, er REST HTTP en smart løsning.
På den anden side, for enheder med begrænsede computerressourcer, der kommunikerer mellem tåge- og IoT-lagene, er det mere effektivt at bruge CoAP. En af de store fordele ved CoAP er faktisk dens kompatibilitet med HTTP, da begge protokoller er baseret på REST principper.
Figur (b) viser to public-subscribe-kommunikationsmodeller i samme scenarie, inklusive MQTT og AMQP. Selvom begge protokoller hypotetisk kunne bruges til kommunikation mellem noder ved hvert abstraktionslag, bør deres position bestemmes baseret på ydeevne. MQTT er designet som en letvægtsprotokol til enheder med begrænsede computerressourcer, så den kan bruges til IoT-Fog kommunikation. AMQP er mere velegnet til mere kraftfulde enheder, som ideelt set ville placere den mellem tåge og skyknuder. I stedet for MQTT kan XMPP-protokollen bruges i IoT, da den anses for let. Men det er ikke så udbredt i sådanne scenarier.
Fund
Det er usandsynligt, at en af de diskuterede protokoller vil være tilstrækkelig til at dække al kommunikation i et system, lige fra enheder med begrænsede computerressourcer til skyservere. Undersøgelsen viste, at de to mest lovende muligheder, som udviklere bruger mest, er MQTT og RESTful HTTP. Disse to protokoller er ikke kun de mest modne og stabile, men inkluderer også mange veldokumenterede og vellykkede implementeringer og online ressourcer.
På grund af dens stabilitet og enkle konfiguration er MQTT en protokol, der har bevist sin overlegne ydeevne over tid, når den bruges på IoT-niveau med begrænsede enheder. I dele af systemet, hvor begrænset kommunikation og batteriforbrug ikke er et problem, såsom nogle tågedomæner og de fleste cloud computing, er RESTful HTTP et nemt valg. CoAP bør også tages i betragtning, da det også udvikler sig hurtigt som en IoT-meddelelsesstandard, og det er sandsynligt, at det vil nå et niveau af stabilitet og modenhed svarende til MQTT og HTTP i den nærmeste fremtid. Men standarden er i øjeblikket under udvikling, hvilket kommer med kortsigtede kompatibilitetsproblemer.
Hvad kan du ellers læse på bloggen?
→
→
→
→
→
Abonner på vores -kanal, for ikke at gå glip af næste artikel! Vi skriver ikke mere end to gange om ugen og kun på forretningsrejse.
Kilde: www.habr.com