A szoftver- és hardvertechnológiák fejlődése, valamint az új kommunikációs protokollok megjelenése a dolgok internetének (IoT) terjedését eredményezte. A készülékek száma napról napra nő, és óriási mennyiségű adatot generálnak. Ezért szükség van egy kényelmes rendszerarchitektúrára, amely képes feldolgozni, tárolni és továbbítani ezeket az adatokat.
Jelenleg ezekhez a célokhoz felhőszolgáltatásokat használnak. Azonban a mind népszerűbbé váló köd számítási paradigmák (Fog) kiegészíthetik a felhős megoldásokat, és optimalizálhatják az IoT infrastruktúráját.
A "felhők" képesek lefedni a legtöbb IoT igényt. Például biztosítani tudják a szolgáltatások monitorozását, a készülékek által generált adatmennyiségek gyors feldolgozását és vizualizációját. A köd számítások viszont hatékonyabbak a real-time feladatok megoldásában. Gyors válaszidőt és minimális késleltetést biztosítanak az adatok feldolgozása során. Vagyis a Fog valóban kiegészíti a "felhőket", bővíti azok lehetőségeit.
A legfontosabb kérdés azonban más: hogyan kell mindennek kölcsönhatásba lépnie az IoT kontextusában? Milyen kommunikációs protokollok lesznek a leghatékonyabbak az IoT-Fog-Cloud integrált rendszer működtetésekor?
Bár a HTTP látszólag dominál, az IoT, Fog és Cloud rendszerekben számos más megoldást is használnak. Ennek oka, hogy az IoT-nak ötvöznie kell a különféle eszközök érzékelőinek funkcionális képességeit a biztonsággal, a kompatibilitással és a felhasználók által támasztott egyéb követelményekkel.
A fő probléma azonban az, hogy nincs egységes elképzelés a referenciaarchitektúráról és a kapcsolati szabványokról. Ezért egy új protokoll létrehozása vagy a meglévő protokollak konkrét IoT feladatokhoz való testreszabása az IT közösség számára az egyik legfontosabb feladat.
Milyen protokollokat használnak jelenleg, és mit kínálnak? Nézzük meg. De először beszéljünk az ökoszisztéma alapelveiről, amelyben a felhők, a köd és a dolgok internetje kölcsönhatásba lép.
IoT Fog-to-Cloud (F2C) architektúra
Bizonyára észrevette, milyen jelentős erőfeszítések folynak az IoT, a felhők és a köd tudatos és összehangolt kezelésének előnyeinek és nyereségeinek tanulmányozására. Ha nem, itt van három kezdeményezés a szabványosítás érdekében: , és .
Ha korábban csak 2 szintet, a felhőt és a végberendezéseket vettük figyelembe, most egy új szintet vezetünk be - a ködös számítást. Ezen a szinten a köd több alszintre osztható, az erőforrások sajátosságaitól vagy azoknak a politikáknak a halmazától függően, amelyek meghatározzák a különböző eszközök használatát ezeken az alszinteken.
Hogyan nézhet ki ez az absztrakció? Íme egy tipikus IoT-Köd-Felhő ökoszisztéma. Az IoT-eszközök adatokat küldenek nagyobb teljesítményű szerverekre és számítási egységekre, hogy megoldják az alacsony késleltetet igénylő feladatokat. Ugyanebben a rendszerben a felhők felelnek a nagy számítási kapacitást vagy adatok tárolására alkalmas helyet igénylő feladatok megoldásáért.
Okostelefonok, okosórák és más kütyük is részei lehetnek az IoT-nak. De ezek az eszközök általában a nagy fejlesztők által készített, szabadalmaztatott kommunikációs protokollokat használják. Az internetes dolgok által generált adatokat a köd szintjére a REST HTTP protokoll segítségével továbbítják, amely rugalmasságot és funkcionális kompatibilitást biztosít a RESTful szolgáltatások létrehozásakor. Ez létfontosságú a meglévő, helyi számítógépeken, szervereken vagy szerverklasztereken működő számítási infrastruktúrákkal való visszamenőleges kompatibilitás biztosítása szempontjából. A helyi erőforrásokat, amelyeket "ködcsomópontoknak" neveznek, a fogadott adatok szűrésére és helyi feldolgozására, vagy további számításhoz való felhőbe való továbbítására használják.
A felhők különböző kommunikációs protokollokat támogatnak, amelyek közül a leggyakrabban az AMQP és a REST HTTP található. Mivel a HTTP közismert és az internetre optimalizált, felmerülhet a kérdés: "Nem lenne-e érdemes azt használni az IoT és a köd működéséhez?" Azonban ennek a protokollnak teljesítménybeli problémái vannak. Erről később.
Összességében 2 olyan kommunikációs protokollmodellt ismerünk, amelyek megfelelnek a szükséges rendszerünknek. Ezek a kérés-válasz és a közzététel-előfizetés modell. Az első modell szélesebb körben ismert, különösen a szerver-kliens architektúrában. A kliens információt kér a szervertől, amely megkapja a kérdést, feldolgozza azt, és visszaküldi a válasz üzenetet. E modellek alapján működnek a REST HTTP és CoAP protokollok.
A második modell a források, amelyek adatokat generálnak, és az adatok fogadói közötti aszinkron, elosztott, laza összeköttetés biztosításának szükségességéből fakadt.
A modell három résztvevőt feltételez: a kiadót (adatforrást), a brókert (irányítót) és az előfizetőt (fogadót). Ebben az esetben az ügyfél, aki előfizetőként működik, nem kérheti az információt a szervertől. A kérés helyett az eseményekre iratkozik fel a rendszerben a bróker segítségével, aki felelős az összes bejövő üzenet szűréséért és azok kiadók és előfizetők közötti irányításáért. Amikor egy esemény történik egy adott témával kapcsolatban, a kiadó azt közzéteszi a brókernek, amely továbbítja az adatokat az előfizetőnek a kért témában.
Alapvetően ez az architektúra eseményeken alapul. Ez az interakciós modell érdekes az IoT, felhő, és ködalkalmazások számára, mivel képes skálázhatóságot biztosítani és egyszerűsíteni a különböző eszközök közötti kapcsolatokat, fenntartani a dinamikus "sok-sok" kapcsolódást és az aszinkron kommunikációt. A legismertebb szabványos üzenetküldési protokollok, amelyek a "kiadás-előfizetés" modellt használják, például az MQTT, AMQP és DDS.
Nyilvánvaló, hogy a "kiadás-előfizetés" modell számos előnnyel jár:
- A kiadóknak és az előfizetőknek nem kell tudniuk egymás létezéséről;
- Egyetlen előfizető információt kaphat számos különböző kiadótól, míg egyetlen kiadó adatokat küldhet számos különböző előfizetőnek ("sok-sok" elv);
- A kiadónak és az előfizetőnek nem szükséges egyszerre aktívnak lennie az adatok cseréjéhez, mivel a bróker (mint sor kezelő rendszer) tárolhatja az üzenetet azoknak a klienseknek, akik jelenleg nincsenek online.
A "kérés-válasz" modellnek azonban megvannak a maga erősségei is. Abban az esetben, amikor a szerveroldali kéréskezelés lehetőségei nem problémát jelentenek több kliens számára, érdemes lehet a már bevált megbízható megoldások használata.
Vannak olyan protokollok is, amelyek mindkét modellt támogatják. Például az XMPP és a HTTP 2.0 támogatja a „server push” lehetőséget. Az IETF kiadott egy CoAP-t is. A kommunikációs problémák megoldásának érdekében számos más megoldást fejlesztettek ki, például a WebSocket protokollt vagy a HTTP protokollt a QUIC (Quick UDP Internet Connections) segítségével.
A WebSocket esetében, bár az valós idejű adatátvitelre használható a szerver és a webkliens között, és folyamatos, kétirányú kommunikációt biztosít, nem olyan eszközökhöz készült, amelyek korlátozott számítási kapacitással rendelkeznek. A QUIC is figyelmet érdemel, mivel az új szállítási protokoll sok új lehetőséget kínál. Azonban mivel a QUIC még nem szabványosított, korai lenne előre jelezni lehetséges alkalmazását és hatását az IoT megoldásokra. Így a WebSocket és a QUIC a jövőre nézve emlékezetünkben marad, de részletesebben egyelőre nem vizsgáljuk.
Ki a legkedvesebb a világon: protokollok összehasonlítása
Most beszéljünk a protokollok erősségeiről és gyengeségeiről. Előre bocsátva, hogy nincs egyértelmű vezető. Minden protokollnak megvannak a maga előnyei és hátrányai.
V válaszidő
A kommunikációs protokollok egyik legfontosabb jellemzője, különösen az IoT esetében, a válaszidő. Azonban a meglévő protokollok között nincs egyértelmű győztes, amely minimális késleltetést mutat különböző körülmények között. Viszont rengeteg kutatás és összehasonlítás létezik a protokollok lehetőségeiről.
Például, Az HTTP és az MQTT hatékonyságának összehasonlítása az IoT-val kapcsolatban azt mutatta, hogy az MQTT-nek a lekérdezések válaszideje kisebb, mint az HTTP esetében. Emellett az MQTT és a CoAP átvételi-átviteli ideje (RTT) azt mutatta, hogy a CoAP átlagos RTT-je 20%-kal alacsonyabb, mint az MQTT-é.
Más Az MQTT és a CoAP RTT-jét két scenárióban vizsgálták: helyi hálózaton és IoT hálózaton. Kiderült, hogy az átlagos RTT 2-3-szorosa volt az IoT hálózatban. Az MQTT QoS0-val alacsonyabb eredményt mutatott a CoAP-hoz képest, míg az MQTT QoS1 magasabb RTT-t mutatott az alkalmazási és szállítási szinteken lévő ACK miatt. A különböző QoS szinteken a nem terhelt hálózaton az MQTT késleltetései milliszekundumok voltak, míg a CoAP esetében száz mikroszekundumok. Fontos azonban megjegyezni, hogy a kevésbé megbízható hálózatokban az MQTT, amely TCP fölött működik, teljesen más eredményt fog mutatni.
Az AMQP és MQTT protokollok válaszidejének vizsgálata során, a terhelés növelésével azt tapasztalták, hogy alacsony terhelés mellett a késleltetés szintje szinte azonos. Azonban nagy adatmennyiségek átvitele esetén az MQTT kevesebb válaszidőt mutatott. Egy másik vizsgálatban A CoAP-ot az HTTP-hoz hasonlították olyan gépek közötti kommunikációs szcenárióban, amelyek járműveken helyezkedtek el, és gázelvezető, időjárás-érzékelő, GPS helymeghatározó és mobilhálózati interfésszel (GPRS) voltak felszerelve. A CoAP üzenet mobilhálózaton történő átviteléhez szükséges idő majdnem háromszor rövidebb volt, mint az HTTP üzenetek alkalmazásához szükséges idő.
Kutatásokat végeztek, amelyekben nem két, hanem három protokollt hasonlítottak össze. Például az IoT-protokollok, mint az MQTT, DDS és CoAP teljesítményét orvosi alkalmazásban, hálózati emulator segítségével. A DDS a mért telemetriai késleltetés szempontjából felülmúlta az MQTT-t különböző gyenge hálózati körülmények között. A UDP alapú CoAP jól működött a gyors válaszidőt igénylő alkalmazások számára, de a UDP alapú működése miatt jelentős, kiszámíthatatlan csomagvesztés történt.
Sávszélesség
Az MQTT és a CoAP hatékonyságának értékelését a csatorna kihasználás szempontjából az üzenetenként átadott adatok összmennyiségének számításával végezték. A CoAP kisebb sávszélességet mutatott, mint az MQTT kis üzenetek átvitele során. Azonban a protokollok hatékonyságának vizsgálatánál, amikor a hasznos információs byte-ok és az átadott byte-ok összmennyisége közötti arányt nézték, a CoAP hatékonyabbnak bizonyult.
Mikor az MQTT, DDS (TCP mint szállító protokoll) és CoAP sávszélesség-használatának vizsgálata során kiderült, hogy a CoAP általában alacsonyabb sávszélesség-fogyasztást mutatott, amely nem növekedett a hálózati csomagvesztés vagy a megnövekedett hálózati késleltetés esetén, ellentétben az MQTT-vel és DDS-sel, ahol a fent említett szcenáriókban a csatorna kihasználásának növekedése figyelhető meg. Egy másik szcenárióban számos eszköz egyidejű adatátvitelét vizsgálták, ami tipikus helyzet az IoT környezetekben. Az eredmények azt mutatták, hogy magasabb terhelés esetén a CoAP használata a jobb választás.
Kis terhelés mellett a CoAP a legalacsonyabb sávszélességet használta, ezt követte az MQTT és a REST HTTP. Azonban, amikor a hasznos terhelések mérete nőtt, a legjobb eredményeket a REST HTTP érte el.
Energiagyság
Az energiafogyasztás kérdése mindig fontos, az IoT rendszerekben pedig különösen. Ha az MQTT és a HTTP energiafogyasztását, akkor a HTTP sokkal több energiát "fogyaszt". Ezzel szemben a CoAP sokkal az MQTT-hez képest, lehetővé téve az energia kezelését. Ugyanakkor egyszerű forgatókönyvekben az MQTT jobban alkalmas információcserére az IoT hálózatokban, különösen, ha nincsenek teljesítménykorlátozások.
A kísérlet, amelyben az AMQP és az MQTT lehetőségeit hasonlították össze egy mobil vagy instabil vezeték nélküli hálózati tesztpulton, azt mutatta, hogy az AMQP nagyobb biztonsági lehetőségeket kínál, míg az MQTT energiahatékonyabb.
Biztonság
A biztonság egy másik rendkívül fontos kérdés, amely a dolgok internetének és a köd-/felhőalapú számítástechnika tanulmányozásakor merül fel. A biztonsági mechanizmusok általában a TLS-ra épülnek a HTTP, MQTT, AMQP és XMPP esetében, vagy DTLS-ra a CoAP-ban, valamint mindkettőt támogató DDS-re.
A TLS és DTLS a kliens- és szerveroldali kapcsolatok létrehozásával kezdődnek, hogy megosszák a támogatott titkosítási készleteket és kulcsokat. Mindkét fél egyesíti a készleteket, hogy biztosítsa, hogy a további kommunikáció biztonságos csatornában történjen. A különbség közöttük apró módosításokban rejlik, amelyek lehetővé teszik a DTLS számára, hogy UDP alapú, megbízhatatlan kapcsolatban működjön.
Mikor több különböző TLS és DTLS megvalósítás ellen azt tapasztaltuk, hogy a TLS jobban teljesített a feladatnál. A DTLS ellen irányuló támadások sikeresebbek voltak, mivel a hiba toleranciája miatt könnyebben támadható.
Mindazonáltal, a legnagyobb probléma ezekkel a protokollokkal az, hogy eredetileg nem voltak tervezve IoT környezetekben való használatra, és nem számítottak a ködben vagy felhőben való működésre. A kézbesített kézfogások (handshaking) révén minden egyes kapcsolat kialakításával többletfeladatokat adnak hozzá, amelyek kimerítik a számítási erőforrásokat. Átlagosan 6,5%-os növekedés figyelhető meg a TLS és 11%-os a DTLS esetében a biztonsági szint nélküli kapcsolathoz képest. Azokban a környezetekben, ahol gazdag erőforrások állnak rendelkezésre, amelyek általában a szinten ez nem jelent problémát, de az IoT és a köd szintje közötti kapcsolat miatt ez fontos korlátozássá válik.
Mit válasszunk? Nincs egyértelmű válasz. Az MQTT és a HTTP tűnnek a legígéretesebb protokolloknak, mivel viszonylag érettebb és stabilabb megoldásoknak számítanak az IoT területén más protokollokhoz képest.
Egyetlen kommunikációs protokollon alapuló megoldások
Az egy protokollos megoldásnak rengeteg hátránya van. Például egy protokoll, amely egy korlátozott környezethez megfelelő, nem biztos, hogy működik egy olyan tartományban, amely szigorú biztonsági követelményekkel bír. Ezt figyelembe véve, szinte minden egy protokollon alapuló megoldást le kell vetnünk a Fog-to-Cloud ökoszisztémában az IoT területén, kivéve az MQTT-t és a REST HTTP-t.
REST HTTP mint egy protokollos megoldás
Jó példa az IoT-to-Fog területeken a REST HTTP kérések és válaszok interakciójára: . Az állatok hordozható érzékelőkkel vannak ellátva (IoT-kliens, C), és egy felhőalapú intelligens gazdálkodási rendszer (Fog-szerver, S) irányítja őket.
A POST módszer headerében a módosítandó erőforrás van megadva (/_farm/_animals), valamint HTTP verzió és tartalomtípus, amely jelen esetben egy JSON objektum, ami a kezelendő állattenyésztési farmot reprezentálja (Dulcinea/_tehén). A szervertől érkező válasz jelzi, hogy a kérés sikeres volt, és HTTPS 201 státusz kódot küld (resource created). A GET módszernek csak a kért erőforrást kell megadnia az URI-ban (például /farm/animals/1), ami visszaadja a szerverről az adott azonosítóval rendelkező állat JSON reprezentációját.
A PUT módszer akkor használatos, amikor egy konkrét erőforrás rekordot kell frissíteni. Ebben az esetben az erőforráshoz a módosítandó paraméter URI-ja és a jelenlegi érték (például ami azt jelzi, hogy a tehén éppen legel, /farm/animals/1?state=walking) van megadva. Végül a DELETE módszert egyenlően használják a GET módszerrel, de csak törli az erőforrást a művelet eredményeként.
MQTT mint egy protokollos megoldás
Vegyük ugyanazt az okosfarmot, de az REST HTTP helyett az MQTT protokollt használjuk. A helyi szerver, amelyen a Mosquitto könyvtár telepítve van, broker szerepet tölt be. Ebben a példában egy egyszerű számítógép (ami a farm szervereként van megjelölve), a Raspberry Pi MQTT kliensként működik, amelyet az MQTT Paho könyvtár telepítésével valósítanak meg, teljes mértékben kompatibilis a Mosquitto brokerrel.
Ez a kliens megfelel az IoT absztrakciós szintjének, amely egy érzékelési és számítási lehetőségekkel rendelkező eszközt képvisel. A közvetítő viszont egy magasabb absztrakciós szintet képvisel, amely egy köd számítási csomópont, amely nagyobb számítási teljesítménnyel és adatkezelési kapacitással jellemezhető.
A javasolt „okosfarm” forgatókönyvben a Raspberry Pi csatlakozik egy gyorsulásmérőhöz, GPS-hez és hőmérséklet-érzékelőkhöz, és az érzékelőkről származó adatokat köd csomópontba publikálja. Ahogy valószínűleg tudja, az MQTT a témákat hierarchiaként kezeli. Egy MQTT kiadó bizonyos témák halmazában publikálhat üzeneteket. A mi esetünkben ezekből három van. Az állatok istállójában mért hőmérsékletet mérő érzékelő esetén a kliens az (animalfarm/shed/temperature) témát választja. A GPS helymeghatározás és az állatok mozgásának mérésére szolgáló érzékelők esetében a kliens frissítéseket tesz közzé (animalfarm/animal/GPS) és (animalfarm/animal/movement).
Ez az információ a brokerhez kerül, amely ideiglenesen tárolhatja azt egy helyi adatbázisban, arra az esetre, ha később egy másik érdeklődő előfizető jelenne meg.
A helyi szerver mellett, amely az MQTT broker szerepét tölti be a ködben, és amelyhez a Raspberry Pi, mint MQTT kliensek, küldik az érzékelőktől származó adatokat, az felhőszinten lehet még egy másik MQTT broker is. Ebben az esetben a helyi brokerhez továbbított információ ideiglenesen tárolható a helyi adatbázisban és/vagy elküldhető a felhőbe. A ködMQTT broker ebben a helyzetben a felhőbeli MQTT brokerhez kötődő összes adat összekapcsolására szolgál. Ilyen architektúrával a mobilalkalmazás felhasználója mindkét brokerre feliratkozhat.
Ha megszakad a kapcsolat az egyik brókerrel (például a felhővel), a végfelhasználó információt kap egy másiktól (a ködből). Ez a ködös és felhő alapú számítástechnikai rendszerek jellemzője. Alapértelmezés szerint a mobilalkalmazás az első kapcsolatot a ködbeli MQTT-brókerrel létesíti, és ha ez nem sikerül, akkor a felhőbeli MQTT-brókerhez csatlakozik. Ez a megoldás csak egy a sok közül az IoT-F2C rendszerekben.
Többprotokollos megoldások
Az egy protokollos megoldások népszerűek, mert könnyebben megvalósíthatók. De nyilvánvaló, hogy az IoT-F2C rendszerekben érdemes különböző protokollokat kombinálni. Az a lényeg, hogy különböző szinteken különböző protokollok működhetnek. Vegyünk például három absztrakciót: IoT, köd és felhőszámítást. Az IoT szinten lévő eszközök általában korlátozottak. E felülvizsgálat során tekintsük az IoT szintet a legkorlátozottabbnak, a felhőt a legkevésbé korlátozottként és a köd számítást pedig „valahol a középen”. Ezért a köd és az IoT absztrakciók között a jelenlegi protokollmegoldások közé tartozik az MQTT, CoAP és XMPP. A köd és a felhő között pedig az AMQP az egyik legfontosabb használt protokoll, együtt a REST HTTP-val, amely a rugalmassága miatt szintén használatos az IoT és a ködszintek között.
A legnagyobb probléma itt a protokollok funkcionális kompatibilitása és az üzenetek egyik protokollból a másikba való egyszerű átkonvertálása. Ideálisan, a jövőben az IoT rendszer architektúrája felhő- és ködforrásokkal független lenne a használt kommunikációs protokolltól, és jó interakciót biztosítana a különböző protokollok között.
Mivel jelenleg ez nem így van, érdemes egyesíteni azokat a protokollokat, amelyek nem jelentenek jelentős eltérést. Ennek érdekében egy potenciális megoldás két, azonos architekturális stílust követő protokoll kombinációjára épül, a REST HTTP-ra és a CoAP-ra. Egy másik javasolt megoldás két, 'közzététel-előfizetés' modellt kínáló protokoll, az MQTT és az AMQP egyesítésén alapul. A közeli koncepciók használata (az MQTT és az AMQP is brókereket, a CoAP és az HTTP pedig REST-t használ), megkönnyíti ezen kombinációk megvalósítását és kevesebb erőfeszítést igényel az integrációhoz.
A ábrán (a) látható két, a kérés-válasz alapú HTTP és CoAP modellek, valamint azok lehetséges elhelyezkedése az IoT-F2C megoldásban. Mivel a HTTP az egyik legismertebb és a modern hálózatokban legjobban alkalmazott protokoll, valószínűtlen, hogy teljesen más üzenetküldő protokollokkal helyettesítenék. Az erőforrásokkal rendelkező eszközök között, amelyek a felhő és a köd között helyezkednek el, a REST HTTP ésszerű megoldás.
Másrészről a korlátozott számítási kapacitással rendelkező eszközöknél, amelyek a köd és az IoT szintek között kommunikálnak, hatékonyabb a CoAP használata. A CoAP egyik nagy előnye valójában a HTTP-val való kompatibilitása, mivel mindkét protokoll a REST elvein alapul.
A ábrán (b) látható két «publikálás-feliratkozás» interakciós modell egy forgatókönyvben, beleértve az MQTT-t és az AMQP-t. Bár hipotetikusan mindkét protokoll használható a csomópontok közötti kommunikációra minden absztrakciós szinten, a pozicionálásukat a teljesítményük alapján kell meghatározni. Az MQTT-t úgy tervezték, mint egy egyszerűsített protokollt a korlátozott számítási kapacitással rendelkező eszközök számára, ezért a köd és az IoT közötti kommunikációra is használható. Az AMQP jobban megfelelő a nagyobb teljesítményű eszközökhöz, amelyeket ideálisan a köd és a felhő csomópontjai közé lehet helyezni. Az IoT-ban az MQTT helyett az XMPP protokollt is lehet használni, mivel könnyűsúlyúnak számít. De nem olyan széles körben használják hasonló forgatókönyvekben.
Következtetések
Valószínűtlen, hogy a vizsgált protokollok egyike elegendő lenne a rendszer összes kommunikációjának lefedésére, a korlátozott számítási kapacitással rendelkező eszközöktől kezdve a felhő szerverekig. A kutatás azt mutatta, hogy a két legígéretesebb lehetőség, amelyet a fejlesztők gyakrabban használnak, az MQTT és a RESTful HTTP. Ezek a protokollok nemcsak a legérettebbek és legstabilabbak, hanem számos jól dokumentált és sikeres megvalósítást és online erőforrást is tartalmaznak.
Stabilitása és egyszerű konfigurációja révén az MQTT olyan protokoll, amely idővel kiváló teljesítményét bizonyította az IoT szintjén korlátozott eszközök használata során. Azokban a rendszer részekben, ahol a korlátozott kapcsolat és az energiafogyasztás nem probléma, például a köd bizonyos területein és a legtöbb felhőalapú számítás területén, a RESTful HTTP egyszerű választás. A CoAP-ot is érdemes figyelembe venni, mivel szintén gyorsan fejlődik az IoT üzenetküldési szabványként, és valószínű, hogy a közeljövőben eléri az MQTT és a HTTP szintjéig stabilitását és érettségét. Azonban a szabvány jelenleg fejlődik, ami rövid távú kompatibilitási problémákkal jár.
Milyen hasznos dolgokat olvashat még a blogban
→
→
→
→
→
Iratkozzon fel az -csatornánkra, hogy ne maradjon le a legújabb cikkünkről! Hetente legfeljebb kétszer írunk és csak hasznos tartalommal.
Forrás: habr.com
