Utvecklingen av teknologier inom området mjukvara och hårdvara, framväxten av nya kommunikationsprotokoll har lett till expansionen av Internet of Things (IoT). Antalet enheter växer dag för dag och de genererar en enorm mängd data. Därför finns det ett behov av en bekväm systemarkitektur som kan bearbeta, lagra och sända dessa data.
Nu används molntjänster för dessa ändamål. Det alltmer populära paradigmet för dimma (Fog) kan dock komplettera molnlösningar genom att skala och optimera IoT-infrastruktur.
Moln kan täcka de flesta IoT-förfrågningar. Till exempel för att tillhandahålla övervakning av tjänster, snabb bearbetning av vilken mängd data som helst som genereras av enheter, samt deras visualisering. Dimdatorer är effektivare när man löser problem i realtid. De ger snabbt svar på förfrågningar och minimal latens vid databehandling. Det vill säga, Fog kompletterar "molnen" och utökar dess möjligheter.
Men huvudfrågan är en annan: hur ska allt detta interagera i IoT-sammanhang? Vilka kommunikationsprotokoll kommer att vara mest effektiva när man arbetar i ett kombinerat IoT-Fog-Cloud-system?
Trots HTTPs uppenbara dominans finns det ett stort antal andra lösningar som används i IoT-, Fog- och Cloud-system. Detta beror på att IoT måste kombinera funktionaliteten hos en mängd olika enhetssensorer med användarnas säkerhet, kompatibilitet och andra krav.
Men det finns helt enkelt ingen enskild idé om referensarkitekturen och kommunikationsstandarden. Därför är att skapa ett nytt protokoll eller modifiera ett befintligt för specifika IoT-uppgifter en av de viktigaste uppgifterna som IT-gemenskapen står inför.
Vilka protokoll används för närvarande och vad kan de erbjuda? Låt oss ta reda på det. Men låt oss först diskutera principerna för ekosystemet där moln, dimma och sakernas internet samverkar.
IoT Fog-to-Cloud (F2C) arkitektur
Du har säkert märkt hur mycket ansträngning som läggs på att utforska fördelarna och fördelarna med smart och samordnad hantering av IoT, moln och dimma. Om inte, så är här tre standardiseringsinitiativ: , и .
Om tidigare bara 2 nivåer övervägdes, moln och slutenheter, introducerar den föreslagna arkitekturen en ny nivå - dimberäkning. I det här fallet kan dimnivån delas in i flera undernivåer, beroende på specifika resurser eller en uppsättning policyer som bestämmer användningen av olika enheter i dessa undernivåer.
Hur kan denna abstraktion se ut? Här är ett typiskt IoT-Fog-Cloud-ekosystem. IoT-enheter skickar data till snabbare servrar och datorenheter för att lösa problem som kräver låg latens. I samma system är molnen ansvariga för att lösa problem som kräver en stor mängd datorresurser eller datalagringsutrymme.
Smartphones, smarta klockor och andra prylar kan också vara en del av IoT. Men sådana enheter använder som regel proprietära kommunikationsprotokoll från stora utvecklare. Den genererade IoT-datan överförs till dimlagret via REST HTTP-protokollet, vilket ger flexibilitet och interoperabilitet när man skapar RESTful-tjänster. Detta är viktigt mot bakgrund av behovet av att säkerställa bakåtkompatibilitet med befintlig datorinfrastruktur som körs på lokala datorer, servrar eller ett serverkluster. Lokala resurser, kallade "fognoder", filtrerar mottagen data och bearbetar den lokalt eller skickar den till molnet för ytterligare beräkningar.
Moln stödjer olika kommunikationsprotokoll, de vanligaste är AMQP och REST HTTP. Eftersom HTTP är välkänt och skräddarsytt för Internet kan frågan uppstå: "ska vi inte använda det för att arbeta med IoT och dimma?" Det här protokollet har dock prestandaproblem. Mer om detta senare.
I allmänhet finns det 2 modeller av kommunikationsprotokoll som är lämpliga för det system vi behöver. Dessa är begäran-svar och publicera-prenumerera. Den första modellen är mer allmänt känd, särskilt inom server-klientarkitektur. Klienten begär information från servern och servern tar emot begäran, bearbetar den och returnerar ett svarsmeddelande. REST HTTP- och CoAP-protokollen fungerar på denna modell.
Den andra modellen uppstod från behovet av att tillhandahålla asynkron, distribuerad, lös koppling mellan de källor som genererar data och mottagarna av dessa data.
Modellen förutsätter tre deltagare: en utgivare (datakälla), en mäklare (dispatcher) och en abonnent (mottagare). Här behöver inte klienten som agerar som abonnent begära information från servern. Istället för att skicka förfrågningar, prenumererar den på vissa händelser i systemet genom en mäklare, som ansvarar för att filtrera alla inkommande meddelanden och dirigera dem mellan publicister och prenumeranter. Och utgivaren, när en händelse inträffar angående ett visst ämne, publicerar det till mäklaren, som skickar data om det begärda ämnet till abonnenten.
I huvudsak är denna arkitektur händelsebaserad. Och denna interaktionsmodell är intressant för applikationer inom IoT, moln, dimma på grund av dess förmåga att ge skalbarhet och förenkla sammankopplingen mellan olika enheter, stödja dynamisk många-till-många-kommunikation och asynkron kommunikation. Några av de mest välkända standardiserade meddelandeprotokollen som använder en publicera-prenumerationsmodell inkluderar MQTT, AMQP och DDS.
Uppenbarligen har publiceringsprenumerationsmodellen många fördelar:
- Publishers och prenumeranter behöver inte veta om varandras existens;
- En prenumerant kan ta emot information från många olika publikationer och en utgivare kan skicka data till många olika prenumeranter (många-till-många-principen);
- Utgivaren och abonnenten behöver inte vara aktiva samtidigt för att kommunicera, eftersom mäklaren (som arbetar som ett kösystem) kommer att kunna lagra meddelandet för klienter som för närvarande inte är anslutna till nätverket.
Begäransvarsmodellen har dock också sina styrkor. I de fall där serversidans förmåga att hantera flera klientförfrågningar inte är ett problem, är det vettigt att använda beprövade, pålitliga lösningar.
Det finns även protokoll som stöder båda modellerna. Till exempel XMPP och HTTP 2.0, som stöder alternativet "server push". IETF har också släppt en CoAP. I ett försök att lösa meddelandeproblemet har flera andra lösningar skapats, såsom WebSockets-protokollet eller användningen av HTTP-protokollet över QUIC (Quick UDP Internet Connections).
I fallet med WebSockets, även om det används för att överföra data i realtid från en server till en webbklient och tillhandahåller beständiga anslutningar med samtidig dubbelriktad kommunikation, är det inte avsett för enheter med begränsade datorresurser. QUIC förtjänar också uppmärksamhet, eftersom det nya transportprotokollet ger många nya möjligheter. Men eftersom QUIC ännu inte är standardiserat är det för tidigt att förutsäga dess möjliga tillämpning och inverkan på IoT-lösningar. Så vi har WebSockets och QUIC i åtanke med sikte på framtiden, men vi kommer inte att studera det mer i detalj just nu.
Vem är sötast i världen: jämföra protokoll
Låt oss nu prata om styrkorna och svagheterna med protokoll. När vi ser framåt, låt oss omedelbart reservera oss för att det inte finns någon tydlig ledare. Varje protokoll har vissa fördelar/nackdelar.
Svarstid
En av de viktigaste egenskaperna hos kommunikationsprotokoll, särskilt i relation till Internet of Things, är svarstid. Men bland de befintliga protokollen finns det ingen tydlig vinnare som visar den lägsta latensnivån när man arbetar under olika förhållanden. Men det finns en hel massa forskning och jämförelser av protokollförmågor.
Till exempel, jämförelser av effektiviteten hos HTTP och MQTT när man arbetar med IoT visade att svarstiden för förfrågningar om MQTT är mindre än för HTTP. Och när RTT-tiden (RTT) för MQTT och CoAP visade att den genomsnittliga RTT för CoAP är 20 % mindre än för MQTT.
Andra med RTT för MQTT- och CoAP-protokollen genomfördes i två scenarier: lokalt nätverk och IoT-nätverk. Det visade sig att den genomsnittliga RTT är 2-3 gånger högre i ett IoT-nätverk. MQTT med QoS0 visade ett lägre resultat jämfört med CoAP, och MQTT med QoS1 visade en högre RTT på grund av ACKs vid applikations- och transportskikten. För olika QoS-nivåer var nätverkslatens utan överbelastning millisekunder för MQTT och hundratals mikrosekunder för CoAP. Det är dock värt att komma ihåg att när man arbetar på mindre pålitliga nätverk kommer MQTT som körs ovanpå TCP att visa ett helt annat resultat.
svarstid för AMQP- och MQTT-protokollen genom att öka nyttolasten visade att med en lätt belastning är latensnivån nästan densamma. Men vid överföring av stora mängder data visar MQTT kortare svarstider. i en till CoAP jämfördes med HTTP i ett maskin-till-maskin kommunikationsscenario med enheter utplacerade ovanpå fordon utrustade med gassensorer, vädersensorer, positionssensorer (GPS) och ett mobilt nätverksgränssnitt (GPRS). Tiden som krävdes för att sända ett CoAP-meddelande över mobilnätet var nästan tre gånger kortare än tiden som krävdes för att använda HTTP-meddelanden.
Studier har genomförts som jämfört inte två, utan tre protokoll. Till exempel, prestanda för IoT-protokoll MQTT, DDS och CoAP i ett medicinskt tillämpningsscenario med hjälp av en nätverksemulator. DDS överträffade MQTT när det gäller testad telemetrifördröjning under en mängd dåliga nätverksförhållanden. UDP-baserad CoAP fungerade bra för applikationer som krävde snabba svarstider, men eftersom det var UDP-baserat blev det betydande oförutsägbara paketförluster.
Bandbredd
MQTT och CoAP när det gäller bandbreddseffektivitet utfördes som en beräkning av den totala mängden data som överfördes per meddelande. CoAP har visat lägre genomströmning än MQTT vid överföring av små meddelanden. Men när man jämför effektiviteten hos protokoll när det gäller förhållandet mellan antalet användbara informationsbytes och det totala antalet överförda bytes, visade sig CoAP vara mer effektivt.
vid med MQTT, DDS (med TCP som transportprotokoll) och CoAP-bandbredd, visade det sig att CoAP generellt visade en jämförelsevis lägre bandbreddsförbrukning, som inte ökade med ökad nätverkspaketförlust eller ökad nätverkslatens, till skillnad från MQTT och DDS, där det fanns en ökning av bandbreddsutnyttjandet i de nämnda scenarierna. Ett annat scenario involverade ett stort antal enheter som överförde data samtidigt, vilket är typiskt i IoT-miljöer. Resultaten visade att för högre utnyttjande är det bättre att använda CoAP.
Under lätt belastning använde CoAP minst bandbredd, följt av MQTT och REST HTTP. Men när storleken på nyttolasten ökade hade REST HTTP de bästa resultaten.
Strömförbrukning
Frågan om energiförbrukning är alltid av stor vikt, och speciellt i ett IoT-system. Om Medan MQTT och HTTP förbrukar el, förbrukar HTTP mycket mer. Och CoAP är mer jämfört med MQTT, vilket möjliggör energihantering. Men i enkla scenarier är MQTT mer lämpad för att utbyta information i Internet of Things-nätverk, speciellt om det inte finns några strömbegränsningar.
Ett experiment som jämförde kapaciteten hos AMQP och MQTT på ett mobilt eller instabilt trådlöst nätverk testbädd fann att AMQP erbjuder fler säkerhetsfunktioner medan MQTT är mer energieffektiv.
Безопасность
Säkerhet är en annan viktig fråga som tas upp när man studerar ämnet Internet of Things och dimma/molnberäkningar. Säkerhetsmekanismen är vanligtvis baserad på TLS i HTTP, MQTT, AMQP och XMPP, eller DTLS i CoAP, och stöder båda DDS-varianterna.
TLS och DTLS börjar med processen att etablera kommunikation mellan klient- och serversidan för att utbyta krypteringssviter och nycklar som stöds. Båda parter förhandlar om uppsättningar för att säkerställa att ytterligare kommunikation sker på en säker kanal. Skillnaden mellan de två ligger i små modifieringar som gör att UDP-baserad DTLS kan fungera över en opålitlig anslutning.
vid Flera olika implementeringar av TLS och DTLS fann att TLS gjorde ett bättre jobb. Attacker på DTLS var mer framgångsrika på grund av dess feltolerans.
Det största problemet med dessa protokoll är dock att de inte ursprungligen var designade för användning i IoT och inte var avsedda att fungera i dimman eller molnet. Genom handskakning lägger de till ytterligare trafik med varje anslutningsetablering, vilket dränerar datorresurser. I genomsnitt är det en ökning med 6,5 % för TLS och 11 % för DTLS i overhead jämfört med kommunikation utan säkerhetslager. I resursrika miljöer, som vanligtvis ligger på nivå kommer detta inte att vara ett problem, men i sambandet mellan IoT och dimnivå blir detta en viktig begränsning.
Vad ska man välja? Det finns inget tydligt svar. MQTT och HTTP verkar vara de mest lovande protokollen eftersom de anses vara jämförelsevis mer mogna och mer stabila IoT-lösningar jämfört med andra protokoll.
Lösningar baserade på ett enhetligt kommunikationsprotokoll
Utövandet av en enkelprotokollslösning har många nackdelar. Till exempel kanske ett protokoll som passar en begränsad miljö inte fungerar i en domän som har strikta säkerhetskrav. Med detta i åtanke är vi kvar att förkasta nästan alla möjliga enprotokolllösningar i Fog-to-Cloud-ekosystemet i IoT, förutom MQTT och REST HTTP.
REST HTTP som en lösning med ett protokoll
Det finns ett bra exempel på hur REST HTTP-förfrågningar och svar interagerar i IoT-to-Fog-utrymmet: . Djuren är utrustade med bärbara sensorer (IoT-klient, C) och styrs via cloud computing av ett smart odlingssystem (Fog-server, S).
Rubriken för POST-metoden anger resursen som ska modifieras (/farm/djur) samt HTTP-versionen och innehållstypen, vilket i det här fallet är ett JSON-objekt som representerar djurfarmen som systemet ska hantera (Dulcinea/ko) . Svaret från servern indikerar att begäran lyckades genom att skicka HTTPS-statuskod 201 (resurs skapad). GET-metoden måste endast ange den begärda resursen i URI:n (till exempel /farm/animals/1), som returnerar en JSON-representation av djuret med det ID:t från servern.
PUT-metoden används när någon specifik resurspost behöver uppdateras. I det här fallet anger resursen URI för parametern som ska ändras och det aktuella värdet (till exempel anger att kon går, /farm/djur/1? tillstånd=går). Slutligen används DELETE-metoden på samma sätt som GET-metoden, men tar helt enkelt bort resursen som ett resultat av operationen.
MQTT som en lösning med ett protokoll
Låt oss ta samma smarta farm, men istället för REST HTTP använder vi MQTT-protokollet. En lokal server med Mosquitto-biblioteket installerat fungerar som en mäklare. I det här exemplet fungerar en enkel dator (kallad farm-server) Raspberry Pi som en MQTT-klient, implementerad genom en installation av Paho MQTT-biblioteket, som är helt kompatibelt med Mosquitto-mäklaren.
Den här klienten motsvarar ett IoT-abstraktionslager som representerar en enhet med avkännings- och beräkningsmöjligheter. Mediatorn, å andra sidan, motsvarar en högre abstraktionsnivå, som representerar en fogberäkningsnod som kännetecknas av större bearbetnings- och lagringskapacitet.
I det föreslagna smarta gårdsscenariot ansluter Raspberry Pi till accelerometern, GPS och temperatursensorer och publicerar data från dessa sensorer till en dimnod. Som du säkert vet, behandlar MQTT ämnen som en hierarki. En enda MQTT-utgivare kan publicera meddelanden till en specifik uppsättning ämnen. I vårt fall är det tre av dem. För en sensor som mäter temperaturen i en djurlada väljer kunden ett tema (djurgård/skjul/temperatur). För sensorer som mäter GPS-position och djurrörelser genom accelerometern kommer klienten att publicera uppdateringar till (djurgård/djur/GPS) och (djurgård/djur/rörelse).
Denna information kommer att skickas till mäklaren, som tillfälligt kan lagra den i en lokal databas ifall en annan intresserad abonnent skulle komma senare.
Förutom den lokala servern, som fungerar som en MQTT-mäklare i dimman och till vilken Raspberry Pis, som fungerar som MQTT-klienter, skickar sensordata, kan det finnas ytterligare en MQTT-mäklare på molnnivå. I det här fallet kan informationen som överförs till den lokala mäklaren tillfälligt lagras i en lokal databas och/eller skickas till molnet. Dim-MQTT-mäklaren i denna situation används för att associera all data med moln-MQTT-mäklaren. Med denna arkitektur kan en mobilapplikationsanvändare prenumerera på båda mäklarna.
Om anslutningen till en av mäklarna (till exempel molnet) misslyckas kommer slutanvändaren att få information från den andra (dimma). Detta är en karakteristisk egenskap hos kombinerade dimma och molnberäkningssystem. Som standard kan mobilappen konfigureras för att ansluta till fog MQTT-mäklaren först, och om det misslyckas, för att ansluta till moln-MQTT-mäklaren. Denna lösning är bara en av många i IoT-F2C-system.
Multiprotokolllösningar
Enkelprotokolllösningar är populära på grund av deras enklare implementering. Men det är tydligt att i IoT-F2C-system är det vettigt att kombinera olika protokoll. Tanken är att olika protokoll kan fungera på olika nivåer. Ta till exempel tre abstraktioner: lagren av IoT, dimma och cloud computing. Enheter på IoT-nivå anses generellt vara begränsade. För den här översikten, låt oss betrakta IoT-nivåer som de mest begränsade, moln som minst begränsade och dimma som "någonstans i mitten". Det visar sig då att mellan IoT och dimabstraktioner inkluderar nuvarande protokolllösningar MQTT, CoAP och XMPP. Mellan dimma och moln å andra sidan är AMQP ett av huvudprotokollen som används, tillsammans med REST HTTP, som på grund av sin flexibilitet även används mellan IoT och dimlager.
Huvudproblemet här är interoperabiliteten mellan protokoll och enkelheten att överföra meddelanden från ett protokoll till ett annat. Helst kommer arkitekturen för ett Internet of Things-system med moln- och dimresurser i framtiden att vara oberoende av vilket kommunikationsprotokoll som används och kommer att säkerställa god interoperabilitet mellan olika protokoll.
Eftersom detta inte är fallet för närvarande är det vettigt att kombinera protokoll som inte har betydande skillnader. För detta ändamål är en potentiell lösning baserad på en kombination av två protokoll som följer samma arkitektoniska stil, REST HTTP och CoAP. En annan föreslagen lösning är baserad på en kombination av två protokoll som erbjuder publicerings-prenumerationskommunikation, MQTT och AMQP. Att använda liknande koncept (både MQTT och AMQP använder mäklare, CoAP och HTTP använder REST) gör dessa kombinationer lättare att implementera och kräver mindre integrationsansträngning.
Figur (a) visar två förfrågningssvar-baserade modeller, HTTP och CoAP, och deras möjliga placering i en IoT-F2C-lösning. Eftersom HTTP är ett av de mest välkända och använda protokollen i moderna nätverk är det osannolikt att det helt kommer att ersättas av andra meddelandeprotokoll. Bland noderna som representerar kraftfulla enheter som sitter mellan molnet och dimman är REST HTTP en smart lösning.
Å andra sidan, för enheter med begränsade datorresurser som kommunicerar mellan Fog- och IoT-lagren är det mer effektivt att använda CoAP. En av de stora fördelarna med CoAP är faktiskt dess kompatibilitet med HTTP, eftersom båda protokollen är baserade på REST-principer.
Figur (b) visar två publicera-prenumerera kommunikationsmodeller i samma scenario, inklusive MQTT och AMQP. Även om båda protokollen hypotetiskt skulle kunna användas för kommunikation mellan noder vid varje abstraktionslager, bör deras position bestämmas baserat på prestanda. MQTT designades som ett lättviktsprotokoll för enheter med begränsade datorresurser, så det kan användas för IoT-Fog-kommunikation. AMQP är mer lämplig för mer kraftfulla enheter, som idealiskt skulle placera den mellan dimma och molnnoder. Istället för MQTT kan XMPP-protokollet användas i IoT eftersom det anses vara lätt. Men det används inte så flitigt i sådana scenarier.
Resultat
Det är osannolikt att ett av de diskuterade protokollen kommer att räcka för att täcka all kommunikation i ett system, från enheter med begränsade datorresurser till molnservrar. Studien fann att de två mest lovande alternativen som utvecklare använder mest är MQTT och RESTful HTTP. Dessa två protokoll är inte bara de mest mogna och stabila, utan inkluderar också många väldokumenterade och framgångsrika implementeringar och onlineresurser.
På grund av dess stabilitet och enkla konfiguration är MQTT ett protokoll som har bevisat sin överlägsna prestanda över tid när det används på IoT-nivå med begränsade enheter. I delar av systemet där begränsad kommunikation och batteriförbrukning inte är ett problem, som vissa dimdomäner och de flesta molntjänster, är RESTful HTTP ett enkelt val. CoAP bör också beaktas eftersom det också snabbt utvecklas som en IoT-meddelandestandard och det är troligt att det kommer att nå en nivå av stabilitet och mognad som liknar MQTT och HTTP inom en snar framtid. Men standarden håller på att utvecklas, vilket kommer med kortsiktiga kompatibilitetsproblem.
Vad mer kan du läsa på bloggen?
→
→
→
→
→
Prenumerera på vår -kanal så att du inte missar nästa artikel! Vi skriver inte mer än två gånger i veckan och endast i affärer.
Källa: will.com