Utviklingen av teknologier innen programvare og maskinvare, fremveksten av nye kommunikasjonsprotokoller har ført til utvidelsen av tingenes internett (IoT). Antall enheter vokser dag for dag, og de genererer en enorm mengde data. Derfor er det behov for en praktisk systemarkitektur som er i stand til å behandle, lagre og overføre disse dataene.
Nå brukes skytjenester til disse formålene. Imidlertid kan det stadig mer populære tåkedatabehandlingsparadigmet (Fog) komplementere skyløsninger ved å skalere og optimalisere IoT-infrastruktur.
Skyer er i stand til å dekke de fleste IoT-forespørsler. For eksempel for å gi overvåking av tjenester, rask behandling av enhver mengde data generert av enheter, samt visualisering av dem. Tåkedatabehandling er mer effektivt når du løser sanntidsproblemer. De gir rask respons på forespørsler og minimal latens i databehandlingen. Det vil si at Fog kompletterer "skyene" og utvider mulighetene.
Hovedspørsmålet er imidlertid annerledes: hvordan skal alt dette samhandle i sammenheng med IoT? Hvilke kommunikasjonsprotokoller vil være mest effektive når du arbeider i et kombinert IoT-Fog-Cloud-system?
Til tross for den tilsynelatende dominansen til HTTP, er det et stort antall andre løsninger som brukes i IoT, Fog og Cloud-systemer. Dette er fordi IoT må kombinere funksjonaliteten til en rekke enhetssensorer med sikkerhet, kompatibilitet og andre krav til brukere.
Men det er rett og slett ingen enkelt idé om referansearkitekturen og kommunikasjonsstandarden. Derfor er det å lage en ny protokoll eller modifisere en eksisterende for spesifikke IoT-oppgaver en av de viktigste oppgavene IT-fellesskapet står overfor.
Hvilke protokoller er i bruk og hva kan de tilby? La oss finne ut av det. Men først, la oss diskutere prinsippene for økosystemet der skyer, tåke og tingenes internett samhandler.
IoT Fog-to-Cloud (F2C)-arkitektur
Du har sikkert lagt merke til hvor mye innsats som legges ned på å utforske fordelene og fordelene knyttet til smart og koordinert styring av IoT, sky og tåke. Hvis ikke, så er her tre standardiseringsinitiativer: , и .
Hvis tidligere bare 2 nivåer ble vurdert, skyer og sluttenheter, introduserer den foreslåtte arkitekturen et nytt nivå - tåkedatabehandling. I dette tilfellet kan tåkenivået deles inn i flere undernivåer, avhengig av spesifikke ressurser eller et sett med retningslinjer som bestemmer bruken av forskjellige enheter i disse undernivåene.
Hvordan kan denne abstraksjonen se ut? Her er et typisk IoT-Fog-Cloud-økosystem. IoT-enheter sender data til raskere servere og dataenheter for å løse problemer som krever lav ventetid. I samme system er skyer ansvarlige for å løse problemer som krever store mengder dataressurser eller datalagringsplass.
Smarttelefoner, smartklokker og andre dingser kan også være en del av IoT. Men slike enheter bruker som regel proprietære kommunikasjonsprotokoller fra store utviklere. De genererte IoT-dataene overføres til tåkelaget via REST HTTP-protokollen, som gir fleksibilitet og interoperabilitet ved opprettelse av RESTful-tjenester. Dette er viktig i lys av behovet for å sikre bakoverkompatibilitet med eksisterende datainfrastruktur som kjører på lokale datamaskiner, servere eller en serverklynge. Lokale ressurser, kalt "tåkenoder", filtrerer de mottatte dataene og behandler dem lokalt eller sender dem til skyen for videre beregninger.
Skyer støtter forskjellige kommunikasjonsprotokoller, de vanligste er AMQP og REST HTTP. Siden HTTP er godt kjent og skreddersydd for Internett, kan spørsmålet oppstå: "bør vi ikke bruke det til å jobbe med IoT og tåke?" Denne protokollen har imidlertid ytelsesproblemer. Mer om dette senere.
Generelt er det 2 modeller av kommunikasjonsprotokoller som passer for systemet vi trenger. Disse er forespørsel-svar og publiser-abonner. Den første modellen er mer kjent, spesielt innen server-klient-arkitektur. Klienten ber om informasjon fra serveren, og serveren mottar forespørselen, behandler den og returnerer en svarmelding. REST HTTP- og CoAP-protokollene fungerer på denne modellen.
Den andre modellen oppsto fra behovet for å gi asynkron, distribuert, løs kobling mellom kildene som genererer data og mottakerne av disse dataene.
Modellen forutsetter tre deltakere: en publisher (datakilde), en megler (dispatcher) og en abonnent (mottaker). Her trenger ikke klienten som fungerer som abonnent å be om informasjon fra serveren. I stedet for å sende forespørsler, abonnerer den på visse hendelser i systemet gjennom en megler, som er ansvarlig for å filtrere alle innkommende meldinger og dirigere dem mellom utgivere og abonnenter. Og utgiveren, når en hendelse oppstår angående et bestemt emne, publiserer den til megleren, som sender data om det forespurte emnet til abonnenten.
I hovedsak er denne arkitekturen hendelsesbasert. Og denne interaksjonsmodellen er interessant for applikasjoner innen IoT, sky, tåke på grunn av dens evne til å gi skalerbarhet og forenkle sammenkoblingen mellom ulike enheter, støtte dynamisk mange-til-mange-kommunikasjon og asynkron kommunikasjon. Noen av de mest kjente standardiserte meldingsprotokollene som bruker en publiserings-abonner-modell inkluderer MQTT, AMQP og DDS.
Åpenbart har publiserings-abonner-modellen mange fordeler:
- Utgivere og abonnenter trenger ikke å vite om hverandres eksistens;
- Én abonnent kan motta informasjon fra mange forskjellige publikasjoner, og én utgiver kan sende data til mange forskjellige abonnenter (mange-til-mange-prinsippet);
- Utgiver og abonnent trenger ikke å være aktive samtidig for å kommunisere, fordi megleren (som jobber som et køsystem) vil kunne lagre meldingen for klienter som for øyeblikket ikke er koblet til nettverket.
Forespørsel-svar-modellen har imidlertid også sine styrker. I tilfeller der serversidens evne til å håndtere flere klientforespørsler ikke er et problem, er det fornuftig å bruke velprøvde, pålitelige løsninger.
Det finnes også protokoller som støtter begge modellene. For eksempel XMPP og HTTP 2.0, som støtter alternativet "server push". IETF har også gitt ut en CoAP. I et forsøk på å løse meldingsproblemet er det laget flere andre løsninger, for eksempel WebSockets-protokollen eller bruk av HTTP-protokollen over QUIC (Quick UDP Internet Connections).
Når det gjelder WebSockets, selv om den brukes til å overføre data i sanntid fra en server til en webklient og gir vedvarende tilkoblinger med samtidig toveiskommunikasjon, er den ikke beregnet på enheter med begrensede dataressurser. QUIC fortjener også oppmerksomhet, siden den nye transportprotokollen gir mange nye muligheter. Men siden QUIC ennå ikke er standardisert, er det for tidlig å forutsi mulig anvendelse og innvirkning på IoT-løsninger. Så vi har WebSockets og QUIC i tankene med tanke på fremtiden, men vi vil ikke studere det mer detaljert foreløpig.
Hvem er den søteste i verden: sammenligne protokoller
La oss nå snakke om styrker og svakheter ved protokoller. Når vi ser fremover, la oss umiddelbart ta forbehold om at det ikke er én tydelig leder. Hver protokoll har noen fordeler/ulemper.
Respons tid
En av de viktigste egenskapene til kommunikasjonsprotokoller, spesielt i forhold til tingenes internett, er responstid. Men blant de eksisterende protokollene er det ingen klar vinner som demonstrerer minimumsnivået av latens når du arbeider under forskjellige forhold. Men det er en hel haug med forskning og sammenligninger av protokollfunksjoner.
For eksempel, sammenligninger av effektiviteten til HTTP og MQTT ved arbeid med IoT viste at responstiden for forespørsler om MQTT er mindre enn for HTTP. Og når Rundreisetiden (RTT) for MQTT og CoAP avslørte at gjennomsnittlig RTT for CoAP er 20 % mindre enn for MQTT.
Andre med RTT for MQTT- og CoAP-protokollene ble utført i to scenarier: lokalt nettverk og IoT-nettverk. Det viste seg at gjennomsnittlig RTT er 2-3 ganger høyere i et IoT-nettverk. MQTT med QoS0 viste et lavere resultat sammenlignet med CoAP, og MQTT med QoS1 viste en høyere RTT på grunn av ACKs ved applikasjons- og transportlagene. For forskjellige QoS-nivåer var nettverksforsinkelsen uten overbelastning millisekunder for MQTT, og hundrevis av mikrosekunder for CoAP. Det er imidlertid verdt å huske at når du jobber på mindre pålitelige nettverk, vil MQTT som kjører på toppen av TCP vise et helt annet resultat.
responstid for AMQP- og MQTT-protokollene ved å øke nyttelasten viste at med en lett belastning er latensnivået nesten det samme. Men når du overfører store datamengder, viser MQTT kortere responstider. i en til CoAP ble sammenlignet med HTTP i et maskin-til-maskin kommunikasjonsscenario med enheter utplassert på toppen av kjøretøy utstyrt med gasssensorer, værsensorer, plasseringssensorer (GPS) og et mobilnettverksgrensesnitt (GPRS). Tiden det tok å sende en CoAP-melding over mobilnettet var nesten tre ganger kortere enn tiden det tok å bruke HTTP-meldinger.
Det er utført studier som sammenlignet ikke to, men tre protokoller. For eksempel, ytelsen til IoT-protokollene MQTT, DDS og CoAP i et medisinsk applikasjonsscenario ved bruk av en nettverksemulator. DDS overgikk MQTT når det gjelder testet telemetriforsinkelse under en rekke dårlige nettverksforhold. UDP-basert CoAP fungerte bra for applikasjoner som krevde raske responstider, men på grunn av at det var UDP-basert, var det betydelig uforutsigbart pakketap.
båndbredde
MQTT og CoAP når det gjelder båndbreddeeffektivitet ble utført som en beregning av den totale mengden data som ble sendt per melding. CoAP har vist lavere gjennomstrømning enn MQTT ved overføring av små meldinger. Men når man sammenligner effektiviteten til protokoller når det gjelder forholdet mellom antall nyttige informasjonsbytes og det totale antallet overførte byte, viste CoAP seg å være mer effektivt.
ved ved bruk av MQTT, DDS (med TCP som transportprotokoll) og CoAP-båndbredde, ble det funnet at CoAP generelt viste relativt lavere båndbreddeforbruk, som ikke økte med økt nettverkspakketap eller økt nettverksforsinkelse, i motsetning til MQTT og DDS, hvor det var en økning i båndbreddeutnyttelsen i de nevnte scenariene. Et annet scenario involverte et stort antall enheter som overfører data samtidig, noe som er typisk i IoT-miljøer. Resultatene viste at for høyere utnyttelse er det bedre å bruke CoAP.
Under lett belastning brukte CoAP minst båndbredde, etterfulgt av MQTT og REST HTTP. Men når størrelsen på nyttelastene økte, hadde REST HTTP de beste resultatene.
Strømforbruk
Spørsmålet om energiforbruk er alltid av stor betydning, og spesielt i et IoT-system. Hvis Mens MQTT og HTTP bruker strøm, bruker HTTP mye mer. Og CoAP er mer sammenlignet med MQTT, noe som tillater strømstyring. Men i enkle scenarier er MQTT mer egnet for å utveksle informasjon i Internet of Things-nettverk, spesielt hvis det ikke er strømbegrensninger.
Et eksperiment som sammenlignet mulighetene til AMQP og MQTT på et mobilt eller ustabilt trådløst nettverk testbed fant at AMQP tilbyr flere sikkerhetsmuligheter mens MQTT er mer energieffektiv.
Безопасность
Sikkerhet er et annet kritisk problem som tas opp når man studerer temaet tingenes internett og tåke-/skydatabehandling. Sikkerhetsmekanismen er vanligvis basert på TLS i HTTP, MQTT, AMQP og XMPP, eller DTLS i CoAP, og støtter begge DDS-variantene.
TLS og DTLS begynner med prosessen med å etablere kommunikasjon mellom klient- og serversiden for å utveksle støttede chiffersuiter og nøkler. Begge parter forhandler om sett for å sikre at videre kommunikasjon skjer på en sikker kanal. Forskjellen mellom de to ligger i små modifikasjoner som lar UDP-basert DTLS fungere over en upålitelig tilkobling.
ved Flere forskjellige implementeringer av TLS og DTLS fant ut at TLS gjorde en bedre jobb. Angrep på DTLS var mer vellykkede på grunn av feiltoleransen.
Det største problemet med disse protokollene er imidlertid at de ikke opprinnelig var designet for bruk i IoT og ikke var ment å fungere i tåke eller sky. Gjennom handshaking legger de til ekstra trafikk med hver tilkoblingsetablering, noe som tapper dataressurser. I gjennomsnitt er det en økning på 6,5 % for TLS og 11 % for DTLS i overhead sammenlignet med kommunikasjon uten sikkerhetslag. I ressursrike miljøer, som typisk ligger på nivå vil ikke dette være et problem, men i sammenhengen mellom IoT og tåkenivå blir dette en viktig begrensning.
Hva skal man velge? Det finnes ikke noe klart svar. MQTT og HTTP ser ut til å være de mest lovende protokollene da de anses som relativt mer modne og mer stabile IoT-løsninger sammenlignet med andre protokoller.
Løsninger basert på en enhetlig kommunikasjonsprotokoll
Praksisen med en enkeltprotokollløsning har mange ulemper. For eksempel kan det hende at en protokoll som passer til et begrenset miljø ikke fungerer i et domene som har strenge sikkerhetskrav. Med dette i tankene, er vi overlatt til å forkaste nesten alle mulige enkeltprotokollløsninger i Fog-to-Cloud-økosystemet i IoT, bortsett fra MQTT og REST HTTP.
REST HTTP som en enkeltprotokollløsning
Det er et godt eksempel på hvordan REST HTTP-forespørsler og svar samhandler i IoT-to-Fog-området: . Dyrene er utstyrt med bærbare sensorer (IoT-klient, C) og styres via cloud computing av et smart oppdrettssystem (Fog-server, S).
Overskriften til POST-metoden spesifiserer ressursen som skal endres (/gård/dyr) samt HTTP-versjon og innholdstype, som i dette tilfellet er et JSON-objekt som representerer dyrefarmen som systemet skal administrere (Dulcinea/ku) . Svaret fra serveren indikerer at forespørselen var vellykket ved å sende HTTPS-statuskode 201 (ressurs opprettet). GET-metoden må kun spesifisere den forespurte ressursen i URIen (for eksempel /farm/animals/1), som returnerer en JSON-representasjon av dyret med den ID-en fra serveren.
PUT-metoden brukes når en bestemt ressurspost må oppdateres. I dette tilfellet spesifiserer ressursen URI for parameteren som skal endres og gjeldende verdi (for eksempel indikerer at kua går, /farm/dyr/1? tilstand=går). Til slutt brukes DELETE-metoden på samme måte som GET-metoden, men sletter ganske enkelt ressursen som et resultat av operasjonen.
MQTT som en enkeltprotokollløsning
La oss ta den samme smarte gården, men i stedet for REST HTTP bruker vi MQTT-protokollen. En lokal server med Mosquitto-biblioteket installert fungerer som en megler. I dette eksemplet fungerer en enkel datamaskin (referert til som farm-serveren) Raspberry Pi som en MQTT-klient, implementert gjennom en installasjon av Paho MQTT-biblioteket, som er fullt kompatibelt med Mosquitto-megleren.
Denne klienten tilsvarer et IoT-abstraksjonslag som representerer en enhet med sanse- og databehandlingsevner. Formidleren, derimot, tilsvarer et høyere abstraksjonsnivå, og representerer en tåkeberegningsnode preget av større prosesserings- og lagringskapasitet.
I det foreslåtte smartfarm-scenariet kobles Raspberry Pi til akselerometeret, GPS-en og temperatursensorene og publiserer data fra disse sensorene til en tåkenode. Som du sikkert vet, behandler MQTT emner som et hierarki. En enkelt MQTT-utgiver kan publisere meldinger til et spesifikt sett med emner. I vårt tilfelle er det tre av dem. For en sensor som måler temperaturen i et dyrefjøs, velger oppdragsgiver et tema (dyrgård/skur/temperatur). For sensorer som måler GPS-plassering og dyrebevegelser gjennom akselerometeret, vil klienten publisere oppdateringer til (dyrgård/dyr/GPS) og (dyrgård/dyr/bevegelse).
Denne informasjonen vil bli sendt til megleren, som midlertidig kan lagre den i en lokal database i tilfelle en annen interessert abonnent kommer senere.
I tillegg til den lokale serveren, som fungerer som en MQTT-megler i tåken og som Raspberry Pis, som fungerer som MQTT-klienter, sender sensordata til, kan det være en annen MQTT-megler på skynivå. I dette tilfellet kan informasjonen som overføres til den lokale megleren midlertidig lagres i en lokal database og/eller sendes til skyen. Tåke-MQTT-megleren i denne situasjonen brukes til å knytte alle dataene til sky-MQTT-megleren. Med denne arkitekturen kan en mobilapplikasjonsbruker abonnere på begge meglere.
Hvis tilkoblingen til en av meglerne (for eksempel skyen) svikter, vil sluttbrukeren motta informasjon fra den andre (tåke). Dette er et karakteristisk trekk ved kombinerte tåke- og skydatabehandlingssystemer. Som standard kan mobilappen konfigureres til å koble til tåke-MQTT-megleren først, og hvis det mislykkes, koble til sky-MQTT-megleren. Denne løsningen er bare en av mange i IoT-F2C-systemer.
Multiprotokollløsninger
Enkeltprotokollløsninger er populære på grunn av deres enklere implementering. Men det er klart at i IoT-F2C-systemer er det fornuftig å kombinere forskjellige protokoller. Tanken er at ulike protokoller kan operere på ulike nivåer. Ta for eksempel tre abstraksjoner: lagene av IoT, tåke og cloud computing. Enheter på IoT-nivå anses generelt som begrensede. For denne oversikten, la oss vurdere IoT-nivåer som de mest begrensede, sky som minst begrenset og tåkedatabehandling som "et sted i midten." Det viser seg da at mellom IoT og tåkeabstraksjoner inkluderer dagens protokollløsninger MQTT, CoAP og XMPP. Mellom tåke og sky, derimot, er AMQP en av hovedprotokollene som brukes, sammen med REST HTTP, som på grunn av sin fleksibilitet også brukes mellom IoT og tåkelag.
Hovedproblemet her er interoperabiliteten til protokoller og det er enkelt å overføre meldinger fra en protokoll til en annen. Ideelt sett vil i fremtiden arkitekturen til et Internet of Things-system med sky- og tåkeressurser være uavhengig av kommunikasjonsprotokollen som brukes og vil sikre god interoperabilitet mellom ulike protokoller.
Siden dette foreløpig ikke er tilfelle, er det fornuftig å kombinere protokoller som ikke har vesentlige forskjeller. For dette formål er én potensiell løsning basert på en kombinasjon av to protokoller som følger samme arkitektoniske stil, REST HTTP og CoAP. En annen foreslått løsning er basert på en kombinasjon av to protokoller som tilbyr publiser-abonner kommunikasjon, MQTT og AMQP. Ved å bruke lignende konsepter (både MQTT og AMQP bruker meglere, CoAP og HTTP bruker REST) gjør disse kombinasjonene enklere å implementere og krever mindre integrasjonsinnsats.
Figur (a) viser to forespørsel-svar-baserte modeller, HTTP og CoAP, og deres mulige plassering i en IoT-F2C-løsning. Siden HTTP er en av de mest kjente og vedtatte protokollene på moderne nettverk, er det lite sannsynlig at den vil bli fullstendig erstattet av andre meldingsprotokoller. Blant nodene som representerer kraftige enheter som sitter mellom skyen og tåken, er REST HTTP en smart løsning.
På den annen side, for enheter med begrensede dataressurser som kommuniserer mellom tåke- og IoT-lagene, er det mer effektivt å bruke CoAP. En av de store fordelene med CoAP er faktisk kompatibiliteten med HTTP, siden begge protokollene er basert på REST-prinsipper.
Figur (b) viser to publiser-abonner kommunikasjonsmodeller i samme scenario, inkludert MQTT og AMQP. Selv om begge protokollene hypotetisk kan brukes for kommunikasjon mellom noder ved hvert abstraksjonslag, bør deres posisjon bestemmes basert på ytelse. MQTT ble designet som en lettvektsprotokoll for enheter med begrensede dataressurser, slik at den kan brukes til IoT-Fog-kommunikasjon. AMQP er mer egnet for kraftigere enheter, som ideelt sett vil plassere den mellom tåke- og skynoder. I stedet for MQTT kan XMPP-protokollen brukes i IoT da den anses som lett. Men det er ikke så mye brukt i slike scenarier.
Funn
Det er usannsynlig at en av de diskuterte protokollene vil være tilstrekkelig til å dekke all kommunikasjon i et system, fra enheter med begrensede dataressurser til skyservere. Studien fant at de to mest lovende alternativene som utviklere bruker mest er MQTT og RESTful HTTP. Disse to protokollene er ikke bare de mest modne og stabile, men inkluderer også mange veldokumenterte og vellykkede implementeringer og nettressurser.
På grunn av sin stabilitet og enkle konfigurasjon, er MQTT en protokoll som har bevist sin overlegne ytelse over tid når den brukes på IoT-nivå med begrensede enheter. I deler av systemet der begrenset kommunikasjon og batteriforbruk ikke er et problem, for eksempel noen tåkedomener og de fleste cloud computing, er RESTful HTTP et enkelt valg. CoAP bør også tas i betraktning siden den også utvikler seg raskt som en IoT-meldingsstandard, og det er sannsynlig at den vil nå et nivå av stabilitet og modenhet som ligner på MQTT og HTTP i nær fremtid. Men standarden er for tiden under utvikling, som kommer med kortsiktige kompatibilitetsproblemer.
Hva annet kan du lese på bloggen?
→
→
→
→
→
Abonner på vår -kanal slik at du ikke går glipp av neste artikkel! Vi skriver ikke mer enn to ganger i uken og kun på forretningsreise.
Kilde: www.habr.com