MQTT (Message Queuing Telemetry Transport), u ljudskim terminima, znači Message Queuing Telemetry Transport. Prije nekoliko godina, kada je PC strana rasprostranjenosti mnogih inženjera jednostavno nije čula zaobilazan izraz, ali s postupnim razvojem tehnologije Interneta stvari (IoT), ovaj se protokol sve češće pojavljuje u očima velikih inženjera. To je uzrokovalo da mnogi inženjeri znaju samo ime, ali ne i značenje, a mnogi su čak mislili da je ovo vrsta protokola razvijena s razvojem IoT-a. Zapravo, MQTT protokol je prvi put izumljen prije više od 20 godina, a 1999. Andy Stanford Clark iz IBM-a i Alan Nippe iz Cirrus Linka napisali su prvu verziju protokola. Protokol je od tada međunarodno standardiziran kao protokol za razmjenu poruka temeljen na objavljivanju/pretplati-prema ISO standardu (ISO/IEC PRF 20922.) IBM je 2013. predao specifikaciju MQTT verzije 3.1 Structured Information Standards Facilitation Organization, zajedno s poveljom kako bi se osiguralo da se u specifikaciju može napraviti samo mali broj promjena, a od tada je MQTT protokol korišteno u brojnim nišama od tada. Nakon što je tehnička infrastruktura IoT-a dovršena, ovaj drevni protokol počeo je imati svoje prvo proljeće.
Prijenosni i aplikacijski slojevi mreže
Kao što svi znamo, brzi razvoj Interneta stvari do sada ne može napustiti komunikacijsku mrežnu infrastrukturu, sada možete kontrolirati bilo koji kutak svijeta u domu pomoću prekidača za sobno svjetlo ili obavljati industrijsku kontrolu, također možete daljinski upravljati kretanjem robota, zrelost ove tehnologije temelji se na mrežnoj komunikaciji kao osnovi. Glavna tehnologija trenutne mrežne tehnologije je OSI sedmo-slojni model, naravno, stvarna aplikacija zapravo koristi TCP/IP četvero-slojni mrežni model.
TCP/IP četvero-slojni mrežni model trećeg prijenosnog sloja je poznati TCP/IP protokol, ovaj sloj glavne svrhe protokola koristi se za slanje prijenosa podataka računala na mrežnu komunikaciju na navedenu IP adresu drugog stroja iznad, na primjer, IP adresu "192.168.137.19 Na primjer, ako stroj s IP adresom "192.168.137.19" želi poslati 16-bajtni binarni paket na stroj s IP adresom "192.168.137.10", tada je moguće koristiti TCP/IP protokol za njegov prijenos. Umjesto toga, kada prenosimo podatke pomoću TCP-a, obično koristimo utičnice.
Ali kada IP adresa "192.168.137.19" stroja šalje podatke na "192.168.137.10" stroj, ovaj paket TCP paketa unutar podataka zapravo je u ime onoga što znači primateljska IP adresa primateljskog kraja "192.168.137.10" stroja kako raščlaniti ovaj paket podataka, ovaj problem je prepušten transportu sloj iznad sloja protokole za rješavanje, a to su protokoli aplikacijskog sloja. Naravno, ako vaši protokoli ne žele dati običnu mrežu računala na rezoluciju, također možete krenuti u razvoj nekih vlastitih protokola aplikacijskog sloja, nije važno, svrha transportnog sloja je samo proslijediti podatke ciljnom stroju iznad njega.
Naš svakodnevni rad, zabava često će se susresti s raznim protokolima aplikacijskog sloja, kao što je kada otvorite web stranicu, slika se prikazuje u tom položaju, gumb za usmjeravanje prema dolje je postići koju funkciju, to je HTML HyperText Transfer Protocol (engleski: HyperTextTransferProtocol, skraćenica: HTTP) dogovoren. To osigurava da kada stranicu na vašoj web stranici zatraži bilo koji uređaj, taj uređaj može pravilno prikazati. Osim HTTP-a, postoje mnogi drugi protokoli aplikacijskog sloja kao što su DNS, FTP itd., a MQTT protokol, koji je danas naš protagonist, jedan je od njih.
Zašto IoT favorizira MQTT
Uz sve izvrsne protokole aplikacijskog sloja dostupne za naše postojeće aplikacije, zašto MQTT blista u IoT prostoru. Izbor MQTT protokola nije neutemeljen; MQTT je lagani, fleksibilni mrežni protokol koji nastoji postići pravu ravnotežu za IoT programere:
Ovaj lagani protokol može se implementirati na hardver uređaja koji je jako ograničen i mreže s velikom latencijom/propusnošću.
Njegova fleksibilnost omogućuje podršku različitim scenarijima primjene za IoT uređaje i usluge.
Većina programera već je upoznata s HTTP web uslugama. Pa zašto ne dopustiti IoT uređajima da se povežu s web uslugama? Uređaji mogu slati svoje podatke u obliku HTTP zahtjeva i primati ažuriranja od sustava u obliku HTTP odgovora. Ovaj model zahtjeva i odgovora ima neka ozbiljna ograničenja:
HTTP je protokol sinkronizacije. Klijent treba pričekati da poslužitelj odgovori. web preglednici imaju ovaj zahtjev, ali po cijenu skalabilnosti. U IoT prostoru veliki broj uređaja i mreža koja je vjerojatno nepouzdana ili ima visoku latenciju čine sinkronu komunikaciju problematičnom. Asinkroni protokoli za razmjenu poruka prikladniji su za IoT aplikacije. Senzori šalju očitanja i dopuštaju mreži da odredi najbolju rutu i vrijeme za njihovu isporuku ciljanim uređajima i uslugama.
HTTP je jednosmjeran. Klijent mora inicirati vezu. U IoT aplikacijama uređaj ili senzor obično je klijent, što znači da ne mogu pasivno primati naredbe s mreže.
HTTP je protokol jedan-na-jedan. Klijent postavlja zahtjev, a poslužitelj odgovara. Isporuka poruka svim uređajima na mreži nije samo teška, već i skupa, što je čest slučaj u IoT aplikacijama.
HTTP je težak protokol s mnogo zaglavlja i pravila. Nije prikladan za ograničene mreže.
Iz tih razloga, većina visoko{0}}učinkovitih skalabilnih sustava koristi asinkrone sabirnice poruka za internu razmjenu podataka umjesto web usluga.
Model pretplate/objave
Zanimljivo je da je ovaj poslužitelj protokola MQTT zapravo puno jednostavnijeg dizajna od web poslužitelja, budući da nastoji biti učinkovita usluga. mehanizam kojim MQTT prvenstveno šalje i prima poruke donekle je sličan odnosu između naše javne web stranice i vas, čitatelja.
U stvarnom svijetu, ja i ti smo slični kao da imate MQTT uređaj spojen na objedinjeni poslužitelj, pretplaćujete se na nas iz interesa ili neke vrste naklonosti prema našem javnom broju, a kada svaki dan pošaljem tekstualni push, pojavit ćete se na mobitelu Na koji sam poslao poruku, ovaj proces, dobivate moje podatke na način poznat kao U ovom procesu, način na koji dobivate moje podatke naziva se "pretplata", a ponašanje mog objavljivanja na ovom javnom broju je "izdavaštvo". I svatko može pristupiti mom članku, slobodno mi ostavite poruku, ovo je ponašanje svačijeg "objavljivanja", a ja uvijek držim ispred sebe da vidim svačiju poruku, ovo je vrsta ponašanja "pretplate". U ovom procesu sve vanjske informacije nemaju nikakve veze s nama, mi jednostavno komuniciramo s protokom informacija u dva smjera. Mehanizam slanja poruka u MQTT-u također se temelji na modelu Objavi - Pretplati se. Mehanizam isporuke MQTT poruka također se temelji na modelu "Objavi" - "Pretplati se".
Posebni koraci za MQTT su:
Korak 1:Koristite prvi za dobivanje MQTT poslužitelja, a zatim kreirajte novi MQTT komunikacijski proizvod.
Korak 2:Zatim se povežite s ovim poslužiteljem, dva važna parametra za povezivanje s poslužiteljem su broj hosta (naziv domene ili IP adresa) i broj porta.
Korak 3:Ako upotrebljavate platformu poslužitelja u oblaku treće-strane, možda će se od vas tražiti da se prijavite na ovaj uređaj pomoću ID-a proizvoda i podataka za provjeru autentičnosti, a oba se mogu pronaći u pozadini Device Clouda.
Nakon što napravite ova tri koraka, možete se pretplatiti ili objavljivati poruke na odgovarajućim temama.
Sastavit ću dokument da vam pokažem kako "izluditi" platformu otvorenog pristupa oblaku uređaja China Mobile.
Ova tri koraka odnose se i na razvoj aplikacijskog softvera i na razvoj mikrokontrolera. U razvoju mikrokontrolera, ako koristite AT naredbe i komunikaciju vanjskog WIFI modula, tada opći modul može doći s AT + MQTT naredbama, što je najbolji način da se uvelike smanji pritisak na mikrokontroler. Ili možete izravno pristupiti podacima TCP/IP transportnog sloja, a zatim raščlaniti MQTT, što od korisnika zahtijeva duboko razumijevanje MQTT protokola kako bi raščlanio i vlastite Json podatke, tako da općenito kada radimo s ugrađenim uređajima, općenito se preporučuje da izravno koristimo gotov-modul s MQTT protokolom, prikladnije je izravno raščlanjivanje AT naredbe.
Studija slučaja:
Daljinsko upravljanje svjetlima i dobivanje trenutne sobne temperature.
Što se tiče ovog slučaja, to je zapravo jedna od najjednostavnijih primjena MQTT-a. Prije svega, ugrađena kontrolna ploča u sobi uglavnom je povezana s poslužiteljem putem WIFI-ja, koji može kontrolirati prekidač za svjetlo i također prikupljati temperaturu. Krajnji uređaj daleko je mobitel.
Kako bi komunikacija funkcionirala, prvo moraju biti spojeni na isti MQTT poslužitelj.
Podatke o temperaturi sa strane uređaja prikuplja sam uređaj, pa treba prikupljene podatke objaviti u temi "Temperatura", dok mobitel dobiva informaciju o temperaturi, pa se mora pretplatiti na temu "Temperatura". Nakon što uređaj pošalje informaciju o temperaturi u "temperaturnu temu", mobitel će je primiti.
Kontrolu svjetla na strani uređaja izvršava uređaj, pa se treba pretplatiti na temu "prekidač za svjetlo", dok mobitel upravlja prekidačem za svjetlo, pa mora objaviti informacije o upravljanju u ovoj temi "prekidač za svjetlo". Nakon što mobilni telefon pošalje poruku o upaljenom svjetlu na temu "upaljeno svjetlo", terminal će primiti temu, a zatim će se izvršiti naredba za upaljeno svjetlo.