Ohjelmistojen ja laitteistojen alan teknologioiden kehitys ja uusien viestintäprotokollien syntyminen ovat johtaneet esineiden internetin (IoT) laajentumiseen. Laitteiden määrä kasvaa päivä päivältä ja ne tuottavat valtavan määrän dataa. Siksi tarvitaan kätevä järjestelmäarkkitehtuuri, joka pystyy käsittelemään, tallentamaan ja lähettämään tätä dataa.
Nyt pilvipalveluita käytetään näihin tarkoituksiin. Kuitenkin yhä suositumpi sumulaskentaparadigma (Sumu) voi täydentää pilviratkaisuja skaalaamalla ja optimoimalla IoT-infrastruktuuria.
Pilvet pystyvät peittämään useimmat IoT-pyynnöt. Esimerkiksi tarjoamaan palveluiden seurantaa, laitteiden tuottaman datamäärän nopeaa käsittelyä sekä niiden visualisointia. Sumulaskenta on tehokkaampaa, kun ratkaistaan reaaliaikaisia ongelmia. Ne tarjoavat nopean vastauksen pyyntöihin ja minimaalisen viiveen tietojenkäsittelyssä. Eli Fog täydentää "pilviä" ja laajentaa sen ominaisuuksia.
Pääkysymys on kuitenkin erilainen: kuinka tämän kaiken pitäisi olla vuorovaikutuksessa IoT:n kontekstissa? Mitkä viestintäprotokollat ovat tehokkaimpia, kun työskentelet yhdistetyssä IoT-Fog-Cloud -järjestelmässä?
Huolimatta HTTP:n näennäisestä vallitsevasta asemasta, IoT-, sumu- ja pilvijärjestelmissä käytetään paljon muita ratkaisuja. Tämä johtuu siitä, että IoT:n on yhdistettävä erilaisten laiteanturien toiminnallisuus käyttäjien tietoturva-, yhteensopivuus- ja muihin vaatimuksiin.
Mutta referenssiarkkitehtuurista ja viestintästandardista ei yksinkertaisesti ole yhtä ideaa. Siksi uuden protokollan luominen tai olemassa olevan protokollan muokkaaminen tiettyjä IoT-tehtäviä varten on yksi IT-yhteisön tärkeimmistä tehtävistä.
Mitä protokollia on tällä hetkellä käytössä ja mitä ne voivat tarjota? Selvitetään se. Mutta ensin keskustellaan ekosysteemin periaatteista, joissa pilvet, sumu ja esineiden internet ovat vuorovaikutuksessa.
IoT Fog-to-Cloud (F2C) -arkkitehtuuri
Olet luultavasti huomannut, kuinka paljon työtä tehdään IoT:n, pilven ja sumun älykkään ja koordinoituun hallintaan liittyvien etujen ja etujen tutkimiseen. Jos ei, tässä on kolme standardointialoitetta: , и .
Jos aiemmin tarkasteltiin vain kahta tasoa, pilvet ja päätelaitteet, niin ehdotettu arkkitehtuuri tuo uuden tason - sumulaskentaa. Tässä tapauksessa sumutaso voidaan jakaa useisiin alatasoihin riippuen resurssien erityispiirteistä tai käytännöistä, jotka määrittävät eri laitteiden käytön näillä alatasoilla.
Miltä tämä abstraktio voi näyttää? Tässä on tyypillinen IoT-Fog-Cloud ekosysteemi. IoT-laitteet lähettävät dataa nopeampiin palvelimiin ja tietokonelaitteisiin pientä viivettä vaativien ongelmien ratkaisemiseksi. Samassa järjestelmässä pilvet vastaavat paljon laskentaresursseja tai tiedon tallennustilaa vaativien ongelmien ratkaisemisesta.
Älypuhelimet, älykellot ja muut vempaimet voivat myös olla osa IoT:tä. Mutta tällaiset laitteet käyttävät yleensä suurten kehittäjien omia viestintäprotokollia. Luotu IoT-data siirretään sumukerrokseen REST HTTP -protokollan kautta, joka tarjoaa joustavuutta ja yhteentoimivuutta RESTful-palveluita luotaessa. Tämä on tärkeää, kun otetaan huomioon tarve varmistaa taaksepäin yhteensopivuus paikallisissa tietokoneissa, palvelimissa tai palvelinklusterissa toimivan olemassa olevan laskentainfrastruktuurin kanssa. Paikalliset resurssit, joita kutsutaan "sumusolmuiksi", suodattavat vastaanotetut tiedot ja käsittelevät sen paikallisesti tai lähettävät ne pilveen lisälaskelmia varten.
Pilvet tukevat erilaisia kommunikaatioprotokollia, joista yleisimmät ovat AMQP ja REST HTTP. Koska HTTP on hyvin tunnettu ja räätälöity Internetiin, voi herätä kysymys: "Eikö meidän pitäisi käyttää sitä IoT:n ja sumun kanssa toimimiseen?" Tällä protokollalla on kuitenkin suorituskykyongelmia. Tästä lisää myöhemmin.
Yleensä on olemassa 2 mallia viestintäprotokollasta, jotka sopivat tarvitsemamme järjestelmään. Nämä ovat pyyntö-vastaus ja julkaisu-tilaus. Ensimmäinen malli tunnetaan laajemmin, erityisesti palvelin-asiakasarkkitehtuurissa. Asiakas pyytää tietoja palvelimelta ja palvelin vastaanottaa pyynnön, käsittelee sen ja palauttaa vastausviestin. REST HTTP- ja CoAP-protokollat toimivat tässä mallissa.
Toinen malli syntyi tarpeesta tarjota asynkroninen, hajautettu, löysä kytkentä dataa tuottavien lähteiden ja tämän tiedon vastaanottajien välille.
Mallissa oletetaan kolme osallistujaa: julkaisija (tietolähde), välittäjä (välittäjä) ja tilaaja (vastaanottaja). Tällöin tilaajana toimivan asiakkaan ei tarvitse pyytää tietoja palvelimelta. Pyyntöjen lähettämisen sijaan se tilaa tietyt tapahtumat järjestelmässä välittäjän kautta, joka vastaa kaikkien saapuvien viestien suodattamisesta ja reitittämisestä julkaisijoiden ja tilaajien välillä. Ja julkaisija, kun tiettyä aihetta koskeva tapahtuma tapahtuu, julkaisee sen välittäjälle, joka lähettää tilaajalle tiedot pyydetystä aiheesta.
Pohjimmiltaan tämä arkkitehtuuri on tapahtumapohjainen. Ja tämä vuorovaikutusmalli on mielenkiintoinen IoT:n, pilven ja sumun sovelluksille, koska se pystyy tarjoamaan skaalautuvuutta ja yksinkertaistamaan eri laitteiden välistä yhteenliittämistä, tukemaan dynaamista monista moneen -viestintää ja asynkronista viestintää. Joitakin tunnetuimpia standardoituja viestintäprotokollia, jotka käyttävät julkaisu-tilausmallia, ovat MQTT, AMQP ja DDS.
Ilmeisesti julkaisu-tilaa -mallilla on paljon etuja:
- Kustantajien ja tilaajien ei tarvitse tietää toistensa olemassaolosta;
- Yksi tilaaja voi vastaanottaa tietoa useista eri julkaisuista ja yksi julkaisija voi lähettää tietoja useille eri tilaajille (monesta moneen -periaate);
- Julkaisijan ja tilaajan ei tarvitse olla samanaikaisesti aktiivisia kommunikoidakseen, koska välittäjä (jonojärjestelmänä toimiva) pystyy tallentamaan viestin asiakkaille, jotka eivät tällä hetkellä ole yhteydessä verkkoon.
Pyyntö-vastaus-mallilla on kuitenkin myös vahvuutensa. Tapauksissa, joissa palvelinpuolen kyky käsitellä useita asiakaspyyntöjä ei ole ongelma, on järkevää käyttää todistettuja ja luotettavia ratkaisuja.
On myös protokollia, jotka tukevat molempia malleja. Esimerkiksi XMPP ja HTTP 2.0, jotka tukevat "server push" -vaihtoehtoa. IETF on myös julkaissut CoAP:n. Viestintäongelman ratkaisemiseksi on luotu useita muita ratkaisuja, kuten WebSockets-protokolla tai HTTP-protokollan käyttö QUIC:n (Quick UDP Internet Connections) kautta.
Vaikka WebSocketsin tapauksessa sitä käytetään tietojen siirtämiseen reaaliajassa palvelimelta verkkoasiakkaalle ja se tarjoaa pysyviä yhteyksiä samanaikaisen kaksisuuntaisen tiedonsiirron kanssa, sitä ei ole tarkoitettu laitteille, joiden laskentaresurssit ovat rajalliset. Myös QUIC ansaitsee huomion, sillä uusi kuljetusprotokolla tarjoaa paljon uusia mahdollisuuksia. Mutta koska QUIC ei ole vielä standardoitu, on ennenaikaista ennustaa sen mahdollista sovellusta ja vaikutusta IoT-ratkaisuihin. Joten pidämme WebSocketsin ja QUICin mielessä tulevaisuutta silmällä pitäen, mutta emme tutki niitä tarkemmin nyt.
Kuka on maailman suloisin: protokollien vertailu
Puhutaan nyt protokollien vahvuuksista ja heikkouksista. Tehkäämme eteenpäin varauma, ettei ole olemassa yhtä selkeää johtajaa. Jokaisella protokollalla on joitain etuja/haittoja.
Vastausaika
Yksi viestintäprotokollien tärkeimmistä ominaisuuksista, erityisesti suhteessa esineiden Internetiin, on vasteaika. Mutta olemassa olevien protokollien joukossa ei ole selkeää voittajaa, joka osoittaisi latenssin vähimmäistason työskennellessäsi erilaisissa olosuhteissa. Mutta on olemassa koko joukko tutkimusta ja protokollaominaisuuksien vertailua.
Esimerkiksi HTTP:n ja MQTT:n tehokkuuden vertailut IoT:n kanssa työskennellessä osoittivat, että MQTT:n pyyntöjen vastausaika on lyhyempi kuin HTTP:n. Ja milloin MQTT:n ja CoAP:n edestakaisen matkan aika (RTT) paljasti, että CoAP:n keskimääräinen RTT on 20 % pienempi kuin MQTT:n.
Muut RTT:llä MQTT- ja CoAP-protokollia varten suoritettiin kahdessa skenaariossa: paikallisverkko ja IoT-verkko. Kävi ilmi, että keskimääräinen RTT on 2-3 kertaa korkeampi IoT-verkossa. MQTT QoS0:lla osoitti alhaisemman tuloksen verrattuna CoAP:iin, ja MQTT QoS1:llä osoitti korkeamman RTT:n sovellus- ja kuljetuskerrosten ACK:iden vuoksi. Eri QoS-tasoilla verkon latenssi ilman ruuhkaa oli millisekunteja MQTT:lle ja satoja mikrosekunteja CoAP:lle. On kuitenkin syytä muistaa, että kun työskentelet vähemmän luotettavissa verkoissa, TCP:n päällä toimiva MQTT näyttää täysin erilaisen tuloksen.
AMQP- ja MQTT-protokollien vasteaika hyötykuormaa lisäämällä osoitti, että kevyellä kuormalla latenssitaso on lähes sama. Mutta siirrettäessä suuria tietomääriä, MQTT osoittaa lyhyempiä vasteaikoja. vielä yhdessä CoAP:ta verrattiin HTTP:hen koneen välisessä tietoliikenneskenaariossa, jossa laitteet asennettiin ajoneuvojen päälle, jotka on varustettu kaasu-, sää-, sijaintiantureilla (GPS) ja mobiiliverkkoliittymällä (GPRS). CoAP-viestin lähettämiseen matkaviestinverkon kautta tarvittava aika oli lähes kolme kertaa lyhyempi kuin HTTP-sanomien käyttöaika.
On tehty tutkimuksia, joissa ei verrattu kahta vaan kolmea protokollaa. Esimerkiksi, IoT-protokollien MQTT, DDS ja CoAP suorituskyky lääketieteellisessä sovelluksessa verkkoemulaattorilla. DDS ylitti MQTT:n testatun telemetrian latenssin suhteen useissa huonoissa verkko-olosuhteissa. UDP-pohjainen CoAP toimi hyvin nopeita vasteaikoja vaativissa sovelluksissa, mutta sen UDP-pohjaisuuden vuoksi tapahtui merkittävää arvaamatonta pakettihäviötä.
kapasiteetti
MQTT ja CoAP kaistanleveyden tehokkuuden kannalta suoritettiin laskelmana viestiä kohden lähetetyn datan kokonaismäärästä. CoAP on osoittanut alhaisempaa suorituskykyä kuin MQTT lähetettäessä pieniä viestejä. Mutta kun verrattiin protokollien tehokkuutta hyödyllisten tietotavujen määrän suhteen siirrettyjen tavujen kokonaismäärään, CoAP osoittautui tehokkaammaksi.
At käyttämällä MQTT:tä, DDS:ää (jossa TCP siirtoprotokollana) ja CoAP-kaistanleveyttä havaittiin, että CoAP osoitti yleensä suhteellisen pienempää kaistanleveyden kulutusta, mikä ei lisääntynyt verkon pakettihäviön lisääntyessä tai verkon latenssin lisääntyessä, toisin kuin MQTT ja DDS, joissa oli kaistanleveyden käytön lisääntyminen mainituissa skenaarioissa. Toinen skenaario koski suuria määriä dataa samanaikaisesti lähettäviä laitteita, mikä on tyypillistä IoT-ympäristöissä. Tulokset osoittivat, että korkeamman käyttöasteen saavuttamiseksi on parempi käyttää CoAP.
Kevyellä kuormituksella CoAP käytti vähiten kaistanleveyttä, jota seurasivat MQTT ja REST HTTP. Kuitenkin, kun hyötykuormien koko kasvoi, REST HTTP sai parhaat tulokset.
Virrankulutus
Energiankulutuskysymys on aina erittäin tärkeä, ja erityisesti IoT-järjestelmässä. Jos Kun MQTT ja HTTP kuluttavat sähköä, HTTP kuluttaa paljon enemmän. Ja CoAP on enemmän verrattuna MQTT:hen, mikä mahdollistaa virranhallinnan. Yksinkertaisissa skenaarioissa MQTT sopii kuitenkin paremmin tiedon vaihtoon esineiden Internet-verkoissa, varsinkin jos tehorajoituksia ei ole.
Kokeessa, jossa verrattiin AMQP:n ja MQTT:n ominaisuuksia mobiilissa tai epävakaassa langattomassa verkossa, havaittiin, että AMQP tarjoaa enemmän suojausominaisuuksia, kun taas MQTT on energiatehokkaampi.
Безопасность
Turvallisuus on toinen kriittinen kysymys, joka nousee esille esineiden Internetiä ja sumu-/pilvitietotekniikkaa tutkittaessa. Suojausmekanismi perustuu tyypillisesti HTTP:n, MQTT:n, AMQP:n ja XMPP:n TLS:ään tai CoAP:n DTLS:ään ja tukee molempia DDS-variantteja.
TLS ja DTLS alkavat viestintäprosessilla asiakas- ja palvelinpuolen välillä tuettujen salauspakettien ja avainten vaihtamiseksi. Molemmat osapuolet neuvottelevat sarjoista varmistaakseen, että jatkoviestintä tapahtuu suojatulla kanavalla. Ero näiden kahden välillä on pienissä muutoksissa, jotka mahdollistavat UDP-pohjaisen DTLS:n toimimisen epäluotettavan yhteyden yli.
At Useat erilaiset TLS- ja DTLS-toteutukset havaitsivat, että TLS toimi paremmin. DTLS-hyökkäykset onnistuivat paremmin sen virhetoleranssin vuoksi.
Suurin ongelma näissä protokollissa on kuitenkin se, että niitä ei alun perin suunniteltu IoT-käyttöön, eikä niitä ole tarkoitettu toimimaan sumussa tai pilvessä. Kättelyn avulla ne lisäävät lisäliikennettä jokaisen yhteyden muodostamisen yhteydessä, mikä kuluttaa laskentaresursseja. Keskimäärin TLS:n ja DTLS:n yleiskustannukset lisääntyvät 6,5 % ja DTLS:n 11 % verrattuna tietoliikenteeseen ilman suojakerrosta. Resurssirikkaissa ympäristöissä, jotka tyypillisesti sijaitsevat tasolla, tämä ei ole ongelma, mutta IoT:n ja sumutason välisessä yhteydessä tästä tulee tärkeä rajoitus.
Mitä valita? Selkeää vastausta ei ole. MQTT ja HTTP näyttävät olevan lupaavimpia protokollia, koska niitä pidetään verrattain kypsempinä ja vakaampina IoT-ratkaisuina verrattuna muihin protokolliin.
Yhtenäiseen viestintäprotokollaan perustuvat ratkaisut
Yhden protokollan ratkaisulla on monia haittoja. Esimerkiksi rajoitettuun ympäristöön sopiva protokolla ei välttämättä toimi toimialueella, jolla on tiukat turvallisuusvaatimukset. Tätä silmällä pitäen meidän on jätettävä pois lähes kaikki mahdolliset yhden protokollan ratkaisut Fog-to-Cloud -ekosysteemissä IoT:ssä, paitsi MQTT ja REST HTTP.
REST HTTP yhden protokollan ratkaisuna
Tässä on hyvä esimerkki siitä, kuinka REST HTTP -pyynnöt ja vastaukset ovat vuorovaikutuksessa IoT-to-Fog -tilassa: . Eläimet on varustettu puetettavilla sensoreilla (IoT-asiakas, C) ja niitä ohjataan pilvitekniikalla älykkäällä viljelyjärjestelmällä (Fog server, S).
POST-menetelmän otsikko määrittää muokattavan resurssin (/farm/animals) sekä HTTP-version ja sisältötyypin, joka tässä tapauksessa on JSON-objekti, joka edustaa järjestelmän hallinnoimaa eläintilaa (Dulcinea/lehmä). . Palvelimen vastaus osoittaa, että pyyntö onnistui lähettämällä HTTPS-tilakoodin 201 (resurssi luotu). GET-menetelmän tulee määrittää vain pyydetty resurssi URI:ssa (esimerkiksi /farm/animals/1), joka palauttaa palvelimelta JSON-esityksen kyseisellä tunnuksella varustetusta eläimestä.
PUT-menetelmää käytetään, kun jokin tietty resurssitietue on päivitettävä. Tässä tapauksessa resurssi määrittää muutettavan parametrin URI:n ja nykyisen arvon (esimerkiksi osoittaen, että lehmä kävelee parhaillaan, /farm/animals/1? state=walking). Lopuksi DELETE-menetelmää käytetään yhtä hyvin kuin GET-menetelmää, mutta se yksinkertaisesti poistaa resurssin toiminnon seurauksena.
MQTT yhden protokollan ratkaisuna
Otetaan sama älyfarmi, mutta REST HTTP:n sijaan käytämme MQTT-protokollaa. Paikallinen palvelin, johon on asennettu Mosquitto-kirjasto, toimii välittäjänä. Tässä esimerkissä yksinkertainen tietokone (kutsutaan maatilapalvelimeksi) Raspberry Pi toimii MQTT-asiakkaana, joka on toteutettu asentamalla Paho MQTT -kirjasto, joka on täysin yhteensopiva Mosquitto-välittäjän kanssa.
Tämä asiakas vastaa IoT-abstraktiokerrosta, joka edustaa laitetta, jossa on tunnistus- ja laskentaominaisuudet. Välittäjä puolestaan vastaa korkeampaa abstraktiotasoa edustaen sumulaskentasolmua, jolle on tunnusomaista suurempi käsittely- ja tallennuskapasiteetti.
Ehdotetussa älykkään maatilan skenaariossa Raspberry Pi muodostaa yhteyden kiihtyvyysanturiin, GPS:ään ja lämpötila-antureihin ja julkaisee tiedot näistä antureista sumusolmuun. Kuten luultavasti tiedät, MQTT käsittelee aiheita hierarkiana. Yksi MQTT-julkaisija voi julkaista viestejä tietyille aiheille. Meidän tapauksessamme niitä on kolme. Navetan lämpötilaa mittaavalle anturille asiakas valitsee teeman (eläintila/vaja/lämpötila). Antureille, jotka mittaavat GPS-sijaintia ja eläinten liikettä kiihtyvyysmittarin kautta, asiakas julkaisee päivitykset (eläinfarm/eläin/GPS) ja (eläinfarm/eläin/liike).
Nämä tiedot välitetään välittäjälle, joka voi tallentaa ne tilapäisesti paikalliseen tietokantaan siltä varalta, että myöhemmin tulee toinen kiinnostunut tilaaja.
Paikallisen palvelimen lisäksi, joka toimii MQTT-välittäjänä sumussa ja jolle MQTT-asiakkaina toimiva Raspberry Pis lähettää anturidataa, pilvitasolla voi olla toinenkin MQTT-välittäjä. Tällöin paikalliselle välittäjälle välitetyt tiedot voidaan tallentaa tilapäisesti paikalliseen tietokantaan ja/tai lähettää pilveen. Sumu MQTT -välittäjää käytetään tässä tilanteessa yhdistämään kaikki tiedot pilvi MQTT-välittäjään. Tämän arkkitehtuurin avulla mobiilisovelluksen käyttäjä voi liittyä molempiin välittäjiin.
Jos yhteys toiseen välittäjään (esimerkiksi pilvi) epäonnistuu, loppukäyttäjä saa tietoa toiselta välittäjältä (sumu). Tämä on tyypillinen ominaisuus yhdistetyille sumu- ja pilvilaskentajärjestelmille. Oletusarvoisesti mobiilisovellus voidaan määrittää muodostamaan yhteys ensin sumu-MQTT-välittäjään ja jos se epäonnistuu, yhdistämään pilvi-MQTT-välittäjään. Tämä ratkaisu on vain yksi monista IoT-F2C-järjestelmistä.
Moniprotokollaratkaisut
Yhden protokollan ratkaisut ovat suosittuja helpomman toteutuksensa vuoksi. Mutta on selvää, että IoT-F2C-järjestelmissä on järkevää yhdistää eri protokollia. Ajatuksena on, että eri protokollat voivat toimia eri tasoilla. Otetaan esimerkiksi kolme abstraktiota: IoT:n kerrokset, sumu ja pilvilaskenta. IoT-tason laitteita pidetään yleensä rajoitetuina. Tarkastellaan tätä yleiskatsausta varten IoT-tasoja kaikkein rajoitetuimpina, pilvipalveluita vähiten rajoittavina ja sumulaskentaa "jossain keskellä". Silloin käy ilmi, että IoT:n ja sumuabstraktion välissä nykyisiä protokollaratkaisuja ovat MQTT, CoAP ja XMPP. Toisaalta sumun ja pilven välissä AMQP on yksi tärkeimmistä käytetyistä protokollista yhdessä REST HTTP:n kanssa, jota joustavuuden vuoksi käytetään myös IoT- ja sumukerrosten välillä.
Suurin ongelma tässä on protokollien yhteentoimivuus ja viestien siirtämisen helppous protokollasta toiseen. Ihannetapauksessa tulevaisuudessa pilvi- ja sumuresursseja sisältävän esineiden internet-järjestelmän arkkitehtuuri on riippumaton käytetystä viestintäprotokollasta ja varmistaa hyvän yhteentoimivuuden eri protokollien välillä.
Koska näin ei ole tällä hetkellä, on järkevää yhdistää protokollia, joissa ei ole merkittäviä eroja. Tätä tarkoitusta varten yksi mahdollinen ratkaisu perustuu kahden samaa arkkitehtuurityyliä noudattavan protokollan yhdistelmään, REST HTTP ja CoAP. Toinen ehdotettu ratkaisu perustuu kahden julkaisu-tilaa-viestintää tarjoavan protokollan, MQTT:n ja AMQP:n, yhdistelmään. Samankaltaisten konseptien käyttäminen (sekä MQTT että AMQP käyttävät välittäjiä, CoAP ja HTTP käyttävät RESTiä) tekee näistä yhdistelmistä helpompia toteuttaa ja vaatii vähemmän integrointiponnisteluja.
Kuvassa (a) on esitetty kaksi pyyntö-vastauspohjaista mallia, HTTP ja CoAP, ja niiden mahdollinen sijoittaminen IoT-F2C-ratkaisuun. Koska HTTP on yksi tunnetuimmista ja käytetyimmistä protokollista nykyaikaisissa verkoissa, on epätodennäköistä, että se korvataan kokonaan muilla viestintäprotokolilla. Pilven ja sumun välissä sijaitsevien tehokkaiden laitteiden joukossa REST HTTP on älykäs ratkaisu.
Toisaalta sumu- ja IoT-kerrosten välillä kommunikoiville laitteille, joilla on rajalliset laskentaresurssit, on tehokkaampaa käyttää CoAP:ta. Yksi CoAP:n suurista eduista on itse asiassa sen yhteensopivuus HTTP:n kanssa, koska molemmat protokollat perustuvat REST-periaatteisiin.
Kuva (b) esittää kaksi julkaisu-tilaa-viestintämallia samassa skenaariossa, mukaan lukien MQTT ja AMQP. Vaikka molempia protokollia voitaisiin hypoteettisesti käyttää solmujen väliseen viestintään kussakin abstraktiokerroksessa, niiden sijainti tulisi määrittää suorituskyvyn perusteella. MQTT on suunniteltu kevyeksi protokollaksi laitteille, joilla on rajalliset laskentaresurssit, joten sitä voidaan käyttää IoT-Fog-viestintään. AMQP sopii paremmin tehokkaampiin laitteisiin, jotka sijoittaisivat sen ihanteellisesti sumu- ja pilvisolmujen väliin. MQTT:n sijaan XMPP-protokollaa voidaan käyttää IoT:ssä, koska sitä pidetään kevyenä. Mutta sitä ei käytetä niin laajasti tällaisissa skenaarioissa.
Tulokset
On epätodennäköistä, että yksi käsitellyistä protokollista riittää kattamaan kaiken järjestelmän viestinnän laitteista, joilla on rajalliset laskentaresurssit, pilvipalvelimiin. Tutkimuksessa havaittiin, että kaksi lupaavinta vaihtoehtoa, joita kehittäjät käyttävät eniten, ovat MQTT ja RESTful HTTP. Nämä kaksi protokollaa eivät ole vain kypsimmät ja vakaimpia, vaan sisältävät myös monia hyvin dokumentoituja ja onnistuneita toteutuksia ja verkkoresursseja.
Vakauden ja yksinkertaisen konfiguroinnin ansiosta MQTT on protokolla, joka on osoittanut ylivoimaisen suorituskyvyn ajan myötä, kun sitä käytetään IoT-tasolla rajoitetuilla laitteilla. Järjestelmän osissa, joissa rajoitettu viestintä ja akun kulutus eivät ole ongelma, kuten joissakin sumutoimialueissa ja useimmissa pilvipalveluissa, RESTful HTTP on helppo valinta. CoAP on myös otettava huomioon, sillä se kehittyy myös nopeasti IoT-viestintästandardina ja on todennäköistä, että se saavuttaa lähitulevaisuudessa MQTT:tä ja HTTP:tä vastaavan vakauden ja kypsyystason. Mutta standardia kehitetään parhaillaan, mikä sisältää lyhytaikaisia yhteensopivuusongelmia.
Mitä muuta voit lukea blogista?
→
→
→
→
→
Tilaa meidän -kanava, jotta et missaa seuraavaa artikkelia! Kirjoitamme korkeintaan kaksi kertaa viikossa ja vain työasioissa.
Lähde: will.com