MQTT (Message Queuing Telemetry Transport) v človeškem smislu pomeni Message Queuing Telemetry Transport. Pred nekaj leti, ko je računalniška stran razširjenosti številnih inženirjev preprosto ni slišala za krožni izraz, s postopnim razvojem tehnologije interneta stvari (IoT) pa se ta protokol vse pogosteje pojavlja v očeh večjih inženirjev. Zaradi tega mnogi inženirji poznajo samo ime, ne pa tudi pomena, in mnogi ljudje so celo mislili, da je to nekakšen protokol, razvit z razvojem IoT. Pravzaprav je bil protokol MQTT prvič izumljen pred več kot 20 leti, leta 1999 pa sta Andy Stanford Clark iz IBM-a in Alan Nippe iz Cirrus Link napisala prvo različico protokola. Protokol je bil od takrat mednarodno standardiziran kot sporočilni protokol, ki temelji na objavi/naročnini-, v skladu s standardom ISO (ISO/IEC PRF 20922). IBM je leta 2013 predložil specifikacijo MQTT različice 3.1 Organizaciji za spodbujanje strukturiranih informacijskih standardov, skupaj z listino, ki zagotavlja, da je v specifikacijo mogoče narediti le majhno število sprememb, in od takrat je protokol MQTT bil od takrat uporablja v številnih nišah. Ko je bila tehnična infrastruktura IoT dokončana, je ta starodavni protokol začel doživljati svojo prvo pomlad.
Transportna in aplikacijska plast omrežja
Kot vsi vemo, hiter razvoj interneta stvari doslej ne more zapustiti komunikacijske omrežne infrastrukture, zdaj lahko nadzorujete kateri koli kotiček sveta v domu s stikalom za sobno luč ali za industrijski nadzor, lahko tudi daljinsko upravljate gibanje robota, zrelost te tehnologije temelji na omrežni komunikaciji kot osnovi. Glavna tehnologija trenutne omrežne tehnologije je sedem-plastni model OSI, seveda pa dejanska aplikacija dejansko uporablja štiri-plastni omrežni model TCP/IP.
TCP/IP štiri-slojni omrežni model tretje transportne plasti je slavni protokol TCP/IP, ta plast glavnega namena protokola se uporablja za pošiljanje prenosa podatkov računalniku v omrežni komunikaciji na navedeni naslov IP drugega stroja zgoraj, na primer naslov IP "192.168.137.19. Na primer, če želi stroj z naslovom IP "192.168.137.19" za pošiljanje 16-bajtnega binarnega paketa na stroj z naslovom IP "192.168.137.10", potem je mogoče za prenos uporabiti protokol TCP/IP. Namesto tega pri prenosu podatkov s pomočjo TCP običajno uporabljamo vtičnice.
Ko pa naslov IP stroja "192.168.137.19" pošlje podatke stroju "192.168.137.10", je ta paket TCP paketov znotraj podatkov dejansko v imenu tega, kar pomeni naslov IP prejemnega konca stroja "192.168.137.10", kako razčleniti ta paket podatkov, je ta težava prepuščena transportu. plast nad plast protokolov, ki jih je treba rešiti, to je protokoli aplikacijske plasti. Seveda, če vaši protokoli ne želijo dati navadnemu omrežju računalnikov na ločljivost, lahko tudi razvijete nekaj lastnih protokolov aplikacijskega sloja, ni pomembno, namen transportnega sloja je le prenos podatkov do ciljnega stroja na vrhu.
Naše vsakodnevno delo, zabava bo pogosto naletela na različne protokole aplikacijskega sloja, na primer, ko odprete spletno stran, je slika prikazana v tem položaju, gumb, ki kaže navzdol, je za doseganje katere funkcije, to je dogovorjeno s protokolom za prenos hiperbesedila HTML (angleško: HyperTextTransferProtocol, okrajšava: HTTP). To zagotavlja, da lahko katera koli naprava pravilno prikaže stran na vašem spletnem mestu, ko jo zahteva. Poleg HTTP obstaja veliko drugih protokolov aplikacijskega sloja, kot so DNS, FTP itd., in protokol MQTT, ki je danes naš protagonist, je eden izmed njih.
Zakaj IoT daje prednost MQTT
Zakaj MQTT blesti v prostoru IoT z vsemi odličnimi protokoli aplikacijskega sloja, ki so na voljo za naše obstoječe aplikacije. Izbira protokola MQTT ni neutemeljena; MQTT je lahek, prilagodljiv omrežni protokol, ki si prizadeva najti pravo ravnovesje za IoT razvijalce:
Ta lahki protokol je mogoče implementirati na močno omejeno strojno opremo naprave in v omrežjih z visoko zakasnitvijo/pasovno širino.
Njegova prilagodljivost omogoča podporo različnim scenarijem uporabe za naprave in storitve IoT.
Večina razvijalcev že pozna spletne storitve HTTP. Zakaj torej ne bi napravam interneta stvari omogočili povezovanja s spletnimi storitvami? Naprave lahko pošiljajo svoje podatke v obliki zahtev HTTP in prejemajo posodobitve iz sistema v obliki odzivov HTTP. Ta model zahtev in odgovorov ima nekaj resnih omejitev:
HTTP je sinhronizacijski protokol. Odjemalec mora počakati, da se strežnik odzove. spletni brskalniki imajo to zahtevo, vendar za ceno razširljivosti. V prostoru IoT veliko število naprav in omrežje, ki je verjetno nezanesljivo ali ima visoko zakasnitev, otežuje sinhrono komunikacijo. Protokoli za asinhrono sporočanje so bolj primerni za aplikacije IoT. Senzorji pošiljajo odčitke in omrežju omogočajo, da določi najboljšo pot in čas za njihovo dostavo ciljnim napravam in storitvam.
HTTP je enosmeren. Odjemalec mora vzpostaviti povezavo. V aplikacijah IoT je naprava ali senzor običajno odjemalec, kar pomeni, da ne more pasivno sprejemati ukazov iz omrežja.
HTTP je protokol ena-proti-ena. Odjemalec naredi zahtevo in strežnik odgovori. Dostava sporočil vsem napravam v omrežju ni le težka, ampak tudi draga, kar je običajna uporaba v aplikacijah IoT.
HTTP je zahteven protokol s številnimi glavami in pravili. Ni primeren za omejena omrežja.
Zaradi teh razlogov večina visoko{0}}zmogljivih, razširljivih sistemov uporablja asinhrona sporočilna vodila za interno izmenjavo podatkov namesto spletnih storitev.
Model naroči/objavi
Zanimivo je, da je ta strežnik protokola MQTT dejansko veliko enostavnejša zasnova kot spletni strežnik, saj želi biti učinkovita storitev. mehanizem, s katerim MQTT primarno pošilja in prejema sporočila, je nekoliko podoben odnosu med našo javno spletno stranjo in vami, bralci.
V resničnem svetu sva jaz in ti podobna napravi MQTT, priključeni na poenoten strežnik, naročiš se na nas zaradi zanimanja ali neke vrste naklonjenosti naši javni številki in ko vsak dan pošljem potisno besedilo, se boš pojavil v mobilnem telefonu, ki sem ga potisnil, ta postopek, moje podatke dobiš na način, znan kot V tem postopku se način, kako dobiš moje podatke, imenuje "naročnina", in obnašanje moje objave na tej javni številki je "objavljanje". In vsi lahko vidijo moj članek, lahko mi pustite sporočilo, to vedenje je "objavno" vedenje vseh in vedno imam pred potiskom, da vidim sporočilo vseh, to je neke vrste "naročniško" vedenje. V tem procesu vse zunanje informacije nimajo nobene zveze z nami, preprosto komuniciramo s tokom informacij v dveh smereh. Mehanizem sporočanja v MQTT prav tako temelji na modelu Objavi - Naroči se. Mehanizem dostave sporočil MQTT prav tako temelji na modelu »Objavi« - »Naroči se«.
Posebni koraki MQTT so:
1. korak:Uporabite prvo za pridobitev strežnika MQTT in nato ustvarite nov komunikacijski izdelek MQTT.
2. korak:Nato se povežite s tem strežnikom, dva pomembna parametra za povezavo s strežnikom sta številka gostitelja (ime domene ali naslov IP) in številka vrat.
3. korak:Če uporabljate strežniško platformo v oblaku-drugega ponudnika, se boste morda morali prijaviti v to napravo z ID-jem izdelka in informacijami za preverjanje pristnosti, ki ju lahko najdete v zaledju Device Cloud.
Ko naredite te tri korake, se lahko naročite ali objavite sporočila na ustrezne teme.
Sestavil bom dokument, ki vam bo pokazal, kako "prevarati" platformo odprtega dostopa v oblaku naprave China Mobile.
Ti trije koraki veljajo tako za razvoj aplikacijske programske opreme kot za razvoj mikrokontrolerjev. Če pri razvoju mikrokrmilnika uporabljate ukaze AT in zunanjo komunikacijo modula WIFI, lahko splošni modul vsebuje ukaze AT + MQTT, kar je najboljši način za močno zmanjšanje pritiska na mikrokrmilnik. Lahko pa neposredno dostopate do podatkov transportnega sloja TCP/IP in nato razčlenite MQTT, kar od uporabnika zahteva globoko razumevanje protokola MQTT, da lahko razčleni tudi lastne podatke Json, tako da je na splošno pri vdelanih napravah na splošno priporočljivo, da neposredno uporabimo pripravljen{3}}modul s protokolom MQTT, neposredno razčlenjevanje ukaza AT je bolj priročno.
Študija primera:
Daljinsko upravljanje luči in pridobivanje trenutne sobne temperature.
V tem primeru gre dejansko za eno najpreprostejših aplikacij MQTT. Prvič, vgrajena nadzorna plošča v sobi je v glavnem povezana s strežnikom prek WIFI, ki lahko nadzoruje stikalo za luči in tudi zbira temperaturo. Končna naprava daleč stran je mobilni telefon.
Da bo komunikacija delovala, morata biti najprej povezana z istim strežnikom MQTT.
Podatke o temperaturi na strani naprave zbira naprava, zato mora zbrane podatke objaviti v temi "Temperatura", medtem ko mobilni telefon dobi informacijo o temperaturi, zato se mora prijaviti na temo "Temperatura". Ko naprava pošlje informacijo o temperaturi v "temperaturno temo", bo temo prejel mobilni telefon.
Nadzor luči na strani naprave izvaja naprava, zato se mora naročiti na temo "stikalo za luči", medtem ko mobilni telefon nadzoruje stikalo za luči, zato mora objaviti informacije o nadzoru v tej temi "stikalo za luči". Ko mobilni telefon pošlje sporočilo o luči na temo "lučka za vklop", bo temo prejel terminal, nato pa se izvede ukaz za vklop lučke.