Az MQTT (Message Queuing Telemetry Transport) emberi értelemben azt jelenti, hogy Message Queuing Telemetry Transport. Néhány évvel ezelőtt, amikor sok mérnök elterjedtségének PC-oldala egyszerűen nem hallott egy körfogót, de a dolgok internete (IoT) technológia fokozatos fejlődésével ez a protokoll egyre gyakrabban jelenik meg a nagy mérnökök szemében. Emiatt sok mérnök csak a nevet tudja, de a jelentését nem, és sokan azt is gondolták, hogy ez egyfajta protokoll, amelyet az IoT fejlődésével fejlesztettek ki. Valójában az MQTT protokollt először több mint 20 évvel ezelőtt találták fel, és 1999-ben Andy Stanford Clark az IBM-től és Alan Nippe a Cirrus Linktől megírta a protokoll első verzióját. A protokollt azóta nemzetközileg szabványosították közzététel/előfizetés{6}}alapú üzenetküldő protokollként az ISO szabvány (ISO/IEC PRF 20922) szerint. Az IBM 2013-ban benyújtotta az MQTT 3.1-es verzió specifikációját a Structurated Information Standards Facilitation Organisation számára, valamint egy chartát, amely biztosítja, hogy az MQTT-ben csak kis számú módosítást lehessen alkalmazni. számos rést azóta. Az IoT technikai infrastruktúrájának véglegesítése után ez az ősi protokoll elkezdte az első tavaszt.
A hálózat szállítási és alkalmazási rétegei
Mint mindannyian tudjuk, a Dolgok Internetének rohamos fejlődése eddig nem hagyhatja el a kommunikációs hálózati infrastruktúrát, a világ bármely sarkát ma már egy szobai villanykapcsoló otthonában vezérelheti, vagy ipari vezérléshez egy robot mozgását is távirányíthatja, ennek a technológiának a kiforrottsága a hálózati kommunikáción alapul. A jelenlegi hálózati technológia fő technológiája az OSI hét-rétegű modellje, természetesen a tényleges alkalmazás a TCP/IP négy-rétegű hálózati modelljét használja.
A harmadik szállítási réteg TCP / IP négy-rétegű hálózati modellje a híres TCP / IP protokoll, a protokoll fő céljának ez a rétege arra szolgál, hogy számítógépet küldjön a hálózati kommunikációs adatátvitelre a másik gép fent megadott IP-címére, például "192.168.137.19" IP-címre. Például, ha egy gép a16 IP-címmel "8.13s7" akar küldeni. 16 bájtos bináris csomagot egy "192.168.137.10" IP-című gépre, akkor lehetőség van a TCP/IP protokoll használatával továbbítani. Ehelyett a TCP használatával történő adatátvitel során általában socketeket használunk.
De amikor a "192.168.137.19" gép IP-címe adatokat küld a "192.168.137.10" gépre, akkor ez a TCP-csomag az adatokon belül valójában annak a nevében szól, hogy mit jelent a "192.168.137.10" fogadó végének IP-címének fogadó végének a jelentése, hogy a fenti csomagot hogyan kell feldolgozni a fenti adatátviteli problémát, rétege protokollokat kell megoldani, ami az alkalmazási réteg protokollja. Természetesen, ha a protokollok nem akarják megadni a szokásos számítógéphálózatot a felbontáson, akkor elmehetsz saját alkalmazási rétegbeli protokollok fejlesztésére is, nem számít, a szállítási réteg célja csak az, hogy az adatokat továbbítsa a célgépnek a tetején.
Mindennapi munkánkban, szórakozásunkban gyakran találkozhatunk különféle alkalmazási réteg protokollokkal, például amikor megnyit egy weboldalt, a kép abban a pozícióban jelenik meg, a lefelé mutató gombbal milyen funkciót kell elérni, ez a HTML HyperText Transfer Protocol (angolul: HyperTextTransferProtocol, rövidítés: HTTP) megegyezik. Ez biztosítja, hogy amikor bármely eszköz lekér egy oldalt a webhelyén, az adott eszköz megfelelően tudja azt megjeleníteni. A HTTP-n kívül sok más alkalmazási rétegbeli protokoll létezik, mint például a DNS, FTP stb., és ezek közé tartozik az MQTT protokoll, amely ma a főszereplőnk.
Miért támogatja az IoT az MQTT-t?
A meglévő alkalmazásaink számára elérhető összes nagyszerű alkalmazási réteg protokoll mellett miért tűnik ki az MQTT az IoT-térben. Az MQTT protokoll választása nem alaptalan; Az MQTT egy könnyű, rugalmas hálózati protokoll, amely arra törekszik, hogy megtalálja a megfelelő egyensúlyt az IoT-fejlesztők számára:
Ez a könnyű protokoll megvalósítható erősen korlátozott eszközhardveren és nagy késleltetésű/korlátozott sávszélességű hálózatokon.
Rugalmassága lehetővé teszi az IoT-eszközök és -szolgáltatások különféle alkalmazási forgatókönyveinek támogatását.
A legtöbb fejlesztő már ismeri a HTTP webszolgáltatásokat. Miért ne engedné tehát, hogy az IoT-eszközök kapcsolódjanak a webszolgáltatásokhoz? Az eszközök HTTP-kérések formájában küldhetik el adataikat, és HTTP-válaszok formájában kaphatnak frissítéseket a rendszertől. Ennek a kérés és válasz modellnek komoly korlátai vannak:
A HTTP egy szinkronizálási protokoll. Az ügyfélnek meg kell várnia a szerver válaszát. a webböngészőknek megvan ez a követelménye, de a méretezhetőség árán. Az IoT-térben a nagyszámú eszköz és egy olyan hálózat, amely valószínűleg megbízhatatlan vagy magas késleltetésű, problémássá teszi a szinkron kommunikációt. Az aszinkron üzenetküldési protokollok jobban megfelelnek az IoT-alkalmazásoknak. Az érzékelők leolvasásokat küldenek, és lehetővé teszik a hálózat számára, hogy meghatározza a legjobb útvonalat és időt, hogy eljuttassa azokat a céleszközökhöz és szolgáltatásokhoz.
A HTTP egyirányú. Az ügyfélnek kell kezdeményeznie a kapcsolatot. Az IoT-alkalmazásokban az eszköz vagy az érzékelő általában a kliens, ami azt jelenti, hogy nem tudnak passzívan fogadni parancsokat a hálózatról.
A HTTP egy-az-egyhez protokoll. A kliens kérést küld, és a szerver válaszol. Az üzenetek eljuttatása a hálózat összes eszközére nemcsak nehéz, hanem költséges is, ami gyakori eset az IoT-alkalmazásokban.
A HTTP egy nehézsúlyú protokoll, sok fejléccel és szabállyal. Nem alkalmas korlátozott hálózatokhoz.
Ezen okok miatt a legtöbb nagy{0}}teljesítményű, méretezhető rendszer aszinkron üzenetbuszt használ a belső adatcserére a webszolgáltatások helyett.
Az előfizetés/közzététel modell
Érdekes módon ez az MQTT protokollszerver valójában sokkal egyszerűbb kialakítású, mint egy webszerver, mivel hatékony szolgáltatásra törekszik. az a mechanizmus, amellyel az MQTT elsősorban üzeneteket küld és fogad, némileg hasonló a nyilvános weboldalunk és Ön, az olvasók közötti kapcsolathoz.
A való világban én és te olyanok vagyunk, mintha egy MQTT eszközt csatlakoztatnánk egy egységes szerverre, érdeklődésből vagy a nyilvános számunk iránti szeretetből iratkozik fel ránk, és amikor minden nap küldök egy sms-t, akkor megjelenik a mobiltelefonon, amelyre az üzenetet küldtem, ez a folyamat, az információimat a következő néven ismerik: Ebben a folyamatban, ahogyan az adataimat megkapja, a viselkedésem a bejegyzésem a következő "kiadás". A cikkemhez pedig mindenki hozzátehet, nyugodtan hagyhat üzenetet nekem, ez a viselkedés mindenki "közzétételi" viselkedése, én pedig mindig egy lökés előtt tartok, hogy lássam mindenki üzenetét, ez egyfajta "előfizetéses" viselkedés. Ebben a folyamatban az összes külső információnak semmi köze hozzánk, egyszerűen csak két irányban kommunikálunk az információáramlással. Az MQTT üzenetküldési mechanizmusa is a Publish - Subscribe modellen alapul. Az MQTT üzenetkézbesítési mechanizmusa szintén a „Közzététel” - „Feliratkozás” modellen alapul.
Az MQTT specifikus lépései a következők:
1. lépés:Használja az elsőt egy MQTT szerver beszerzéséhez, majd hozzon létre egy új MQTT kommunikációs terméket.
2. lépés:Ezután lépjen a kiszolgálóhoz való csatlakozáshoz. A szerverhez való csatlakozás két fontos paramétere a gazdagép száma (tartománynév vagy IP-cím) és a portszám.
3. lépés:Ha harmadik féltől származó{0}}felhőalapú szerverplatformot használ, előfordulhat, hogy be kell jelentkeznie erre az eszközre a termékazonosítóval és a hitelesítési adatokkal, amelyek a Device Cloud háttérrendszerében találhatók.
Ha ez a három lépés megtörtént, feliratkozhat vagy üzeneteket küldhet a megfelelő témákhoz.
Összeállítok egy dokumentumot, amely megmutatja, hogyan lehet "kitermelni" a China Mobile eszközök felhő nyílt hozzáférésű platformját.
Ez a három lépés az alkalmazásszoftver-fejlesztésre és a mikrokontroller-fejlesztésre egyaránt vonatkozik. A mikrokontroller fejlesztésben, ha AT parancsokat és külső WIFI modul kommunikációt használunk, akkor az általános modul AT + MQTT parancsokkal jöhet, ami a legjobb módszer a mikrokontrollerre nehezedő nyomás nagymértékű csökkentésére. Vagy közvetlenül elérheti a TCP/IP szállítási réteg adatait, majd elemzi az MQTT-t, ami megköveteli a felhasználótól, hogy mélyen ismerje az MQTT protokollt, hogy saját Json-adatait is elemezze, ezért általában a beágyazott eszközök használatakor általában ajánlott közvetlenül az MQTT protokollal kész -modult használni, így az AT parancs közvetlen elemzése kényelmesebb.
Esettanulmány:
A világítás távvezérlése és az aktuális szobahőmérséklet lekérése.
Ebben az esetben tulajdonképpen az MQTT egyik legegyszerűbb alkalmazása. Először is, a helyiségben lévő beágyazott vezérlőpanel WIFI-n keresztül elsősorban a szerverhez csatlakozik, amely a villanykapcsolót vezérelheti és a hőmérsékletet is gyűjtheti. A távoli végkészülék egy mobiltelefon.
Ahhoz, hogy a kommunikáció továbbra is működjön, először ugyanahhoz az MQTT szerverhez kell kapcsolódniuk.
A készülék oldali hőmérsékleti információkat a készülék gyűjti, így az összegyűjtött adatokat a "Hőmérséklet" témakörbe kell közzétennie, míg a mobiltelefon megkapja a hőmérsékleti információkat, így elő kell fizetnie a "Hőmérséklet" témára. Miután a készülék elküldi a hőmérsékleti információkat a "hőmérséklet témának", a témát megkapja a mobiltelefon.
A készülékoldali világításvezérlést a készülék hajtja végre, ezért elő kell fizetni a "villanykapcsoló" témára, míg a mobiltelefon a villanykapcsolót vezérli, tehát ehhez a "villanykapcsoló" témához kell vezérlési információkat közzétennie. Amint a mobiltelefon jelzőfényt küld a "light on" témának, a témát a terminál fogadja, majd végrehajtja a lámpa bekapcsolva parancsot.