MQTT (Message Queuing Telemetry Transport) tähendab inimlikult öeldes sõnumijärjekorra telemeetriatransporti. Mõned aastad tagasi, kui paljude inseneride levimuse PC pool lihtsalt ei kuulnud ümmargust terminit, kuid asjade Interneti (IoT) tehnoloogia järkjärgulise arenguga ilmub see protokoll suuremate inseneride silmis üha sagedamini. See on põhjustanud selle, et paljud insenerid teavad ainult nime, kuid mitte tähendust, ja paljud inimesed arvasid isegi, et see on omamoodi protokoll, mis on välja töötatud asjade Interneti arendamisel. Tegelikult leiutati MQTT protokoll esimest korda rohkem kui 20 aastat tagasi ning 1999. aastal kirjutasid Andy Stanford Clark IBMist ja Alan Nippe Cirrus Linkist protokolli esimese versiooni. Protokoll on sellest ajast alates rahvusvaheliselt standarditud ISO-standardi (ISO/IEC PRF 20922) alusel avaldamise/tellimise{6}}põhise sõnumsideprotokollina. IBM esitas MQTT versiooni 3.1 spetsifikatsiooni struktureeritud teabe standardite hõlbustamise organisatsioonile 2013. aastal koos hartaga, et tagada, et MQTT-s on võimalik kasutada vaid väikest arvu muudatusi. number niššidest alates sellest ajast. Kui asjade Interneti tehniline infrastruktuur oli valmis, hakkas see iidne protokoll kehtima esimest korda.
Võrgu transpordi- ja rakenduskihid
Nagu me kõik teame, ei saa asjade interneti senine kiire areng sidevõrgu infrastruktuurist lahkuda, nüüd saab kodus valgusti lülitiga juhtida mis tahes maailmanurka või teha tööstuslikku juhtimist ka roboti liikumise kaugjuhtimisega, selle tehnoloogia küpsus on aluseks võrgusuhtlusele. Praeguse võrgutehnoloogia põhitehnoloogia on OSI seitsme-kihi mudel, tegelik rakendus kasutab loomulikult TCP/IP nelja-kihilist võrgumudelit.
Kolmanda transpordikihi TCP / IP nelja-kihi võrgumudel on kuulus TCP / IP-protokoll, seda protokolli põhieesmärgi kihti kasutatakse arvuti võrgus andmeedastuse saatmiseks teise masina ülaltoodud IP-aadressile, näiteks IP-aadress "192.168.137.19 Näiteks kui masin IP-aadressiga "192.3" saadab16. 16-baidine binaarpakett IP-aadressiga "192.168.137.10" masinasse, siis on võimalik selle edastamiseks kasutada TCP/IP protokolli. Selle asemel kasutame TCP-ga andmete edastamisel tavaliselt pistikupesasid.
Aga kui IP-aadress "192.168.137.19" masin andmete saatmiseks "192.168.137.10" masin, see pakett TCP paketid sees andmed on tegelikult nimel, mida tähendab vastuvõtva otsa IP-aadressi vastuvõtva otsa "192.168.137.10" masin on jäetud selle kihi andmete transportimiseks. kiht lahendatavad protokollid, mis on rakenduskihi protokollid. Muidugi, kui teie protokollid ei taha anda tavalisele arvutivõrgule eraldusvõimet, võite minna ka mõnda nende enda rakenduskihi protokolli välja töötama, see pole oluline, transpordikihi eesmärk on lihtsalt edastada andmed selle peal olevale sihtmasinale.
Meie igapäevane töö, meelelahutus puutuvad sageli kokku mitmesuguste rakenduskihtide protokollidega, näiteks kui avate veebilehe, kuvatakse pilt selles asendis, allapoole suunatud nupp on selle funktsiooni saavutamiseks, mis on HTML HyperText Transfer Protocol (inglise: HyperTextTransferProtocol, lühend: HTTP) kokku lepitud. See tagab, et kui mis tahes seade taotleb teie veebisaidi lehte, saab see seade seda õigesti kuvada. Peale HTTP on palju muid rakenduskihi protokolle, nagu DNS, FTP jne, ning MQTT-protokoll, mis on täna meie peategelane, on üks neist.
Miks IoT eelistab MQTT-d?
Kuna meie olemasolevate rakenduste jaoks on saadaval kõik suurepärased rakenduskihi protokollid, siis miks MQTT paistab asjade Interneti-ruumis silma. MQTT protokolli valik ei ole alusetu; MQTT on kerge ja paindlik võrguprotokoll, mis püüab leida asjade Interneti arendajatele õiget tasakaalu:
Seda kerget protokolli saab rakendada rangelt piiratud seadme riistvara ja suure latentsusajaga/piiratud ribalaiusega võrkudes.
Selle paindlikkus võimaldab toetada erinevaid IoT-seadmete ja -teenuste rakendusstsenaariume.
Enamik arendajaid on HTTP veebiteenustega juba tuttav. Miks mitte lasta IoT-seadmetel veebiteenustega ühendust luua? Seadmed saavad saata oma andmeid HTTP-päringute kujul ja saada süsteemilt värskendusi HTTP-vastustena. Sellel päringu ja vastuse mudelil on mõned tõsised piirangud:
HTTP on sünkroonimisprotokoll. Klient peab ootama, kuni server vastab. veebibrauseritel on see nõue, kuid skaleeritavuse hinnaga. IoT-ruumis muudab sünkroonse suhtluse problemaatiliseks suur hulk seadmeid ja võrk, mis on tõenäoliselt ebausaldusväärne või millel on kõrge latentsusaeg. Asünkroonsed sõnumsideprotokollid sobivad paremini asjade Interneti-rakenduste jaoks. Andurid saadavad näidud ja lasevad võrgul määrata parima marsruudi ja aja nende edastamiseks sihtseadmetesse ja -teenustesse.
HTTP on ühesuunaline. Klient peab ühenduse algatama. IoT rakendustes on seade või andur tavaliselt klient, mis tähendab, et nad ei saa võrgust passiivselt käske vastu võtta.
HTTP on üks{0}}ühele{1}}protokoll. Klient teeb päringu ja server vastab. Sõnumite edastamine kõigile võrgus olevatele seadmetele pole mitte ainult keeruline, vaid ka kulukas, mis on asjade Interneti rakendustes tavaline kasutusjuht.
HTTP on raskekaalu protokoll, millel on palju päiseid ja reegleid. See ei sobi piiratud võrkude jaoks.
Nendel põhjustel kasutavad enamik suure jõudlusega{0}}skaleeritavaid süsteeme sisemiseks andmevahetuseks veebiteenuste asemel asünkroonseid sõnumisiine.
Tellimise/avaldamise mudel
Huvitaval kombel on see MQTT-protokolliserver tegelikult palju lihtsama disainiga kui veebiserver, kuna see püüab olla tõhus teenus. mehhanism, mille abil MQTT peamiselt sõnumeid saadab ja vastu võtab, on mõneti sarnane meie avaliku veebisaidi ja teie, lugejate, vahelisele suhtele.
Reaalses maailmas oleme mina ja sina sarnased sellega, et meil on MQTT-seade ühendatud ühtse serveriga, tellite meid huvist või mingisugusest kiindumusest meie avaliku numbri vastu ja kui iga päev saadan tekstisõnumi, näete teid mobiiltelefonis, millele ma sõnumi saatsin, see protsess, saate minu teavet viisil, mida tuntakse nimega "Selles protsessis, viis, kuidas saate minu teabe avalikkust, kutsutakse minu postituse numbrit". "avaldamine". Ja kõik saavad minu artiklile, võite jätta mulle sõnumi, selline käitumine on igaühe "avaldamise" käitumine ja ma hoian alati tõuke ees, et näha kõigi sõnumit, see on omamoodi "tellimuse" käitumine. Selles protsessis ei ole kogu välisteave meiega midagi pistmist, me lihtsalt suhtleme teabevooga kahes suunas. MQTT sõnumsidemehhanism põhineb samuti Publish - Subscribe mudelil. MQTT sõnumiedastusmehhanism põhineb samuti mudelil "Avalda" - "Telli".
MQTT konkreetsed sammud on järgmised:
1. samm:Kasutage esimest MQTT-serveri hankimiseks ja seejärel looge uus MQTT-sidetoode.
2. samm:Seejärel minge selle serveriga ühenduse loomiseks, serveriga ühenduse loomiseks on kaks olulist parameetrit hostinumber (domeeninimi või IP-aadress) ja pordi number.
3. samm:Kui kasutate kolmanda osapoole{0}}pilveserveri platvormi, võib teil olla vaja sellesse seadmesse sisse logida, kasutades toote ID-d ja autentimisteavet, mis mõlemad leiate Device Cloudi taustaprogrammist.
Kui need kolm sammu on tehtud, saate vastavatel teemadel sõnumeid tellida või postitada.
Panen kokku dokumendi, mis näitab teile, kuidas Hiina Mobile'i seadme pilve avatud juurdepääsuplatvormi "hoorata".
Need kolm sammu kehtivad nii rakendustarkvara arendamise kui ka mikrokontrolleri arendamise kohta. Kui kasutada mikrokontrolleri arenduses AT käske ja välist WIFI mooduli suhtlust, siis üldmoodulisse võivad tulla AT + MQTT käsud, mis on parim viis mikrokontrollerile avaldatavat survet oluliselt vähendada. Või saate otse juurde pääseda TCP/IP-transpordikihi andmetele ja seejärel sõeluda MQTT-d, mis nõuab kasutajalt MQTT-protokolli sügavat mõistmist, et sõeluda ka omaenda Json-andmeid, nii et üldiselt soovitatakse manusseadmete kasutamisel kasutada otse MQTT-protokolliga -valmis moodulit, AT-käsu otse sõelumine on mugavam.
Juhtumiuuring:
Valgustite kaugjuhtimine ja hetke ruumitemperatuuri mõõtmine.
Selle juhtumi puhul on see tegelikult üks MQTT lihtsamaid rakendusi. Esiteks on ruumis olev sisseehitatud juhtpaneel peamiselt WIFI kaudu ühendatud serveriga, mis suudab juhtida valguse lülitit ja koguda ka temperatuuri. Kaugel asuv lõppseade on mobiiltelefon.
Side toimimiseks peavad need esmalt olema ühendatud sama MQTT-serveriga.
Seadme poolel oleva temperatuuriteabe kogub seade, nii et see peab avaldama kogutud andmed teemas "Temperatuur", samal ajal kui mobiiltelefon saab temperatuuriteavet, seega tuleb tellida teema "Temperatuur". Kui seade saadab temperatuuriteabe "temperatuuri teemasse", võtab teema mobiiltelefon vastu.
Seadmepoolset valgusjuhtimist teostab seade, nii et see peab tellima teema "valguslüliti", samas kui mobiiltelefon juhib valgustuse lülitit, seega peab see avaldama selle "valguslüliti" teema juhtimisteabe. Kui mobiiltelefon saadab teemale "valgus sisse lülitatud" teate, võtab terminal selle teema vastu ja seejärel käivitatakse märgutuli sisse lülitatud käsk.