MQTT (Message Queuing Telemetry Transport) betekent in menselijke termen Message Queuing Telemetry Transport. Enkele jaren geleden, toen de pc-kant van de prevalentie van veel ingenieurs eenvoudigweg geen omslachtige term hoorde, maar met de geleidelijke ontwikkeling van de Internet of Things (IoT) -technologie, verschijnt dit protocol steeds vaker in de ogen van grote ingenieurs. Dit heeft ertoe geleid dat veel ingenieurs alleen de naam kennen, maar niet de betekenis, en veel mensen dachten zelfs dat dit een soort protocol was dat ontwikkeld was met de ontwikkeling van IoT. In feite werd het MQTT-protocol meer dan twintig jaar geleden voor het eerst uitgevonden, en in 1999 schreven Andy Stanford Clark van IBM en Alan Nippe van Cirrus Link de eerste versie van het protocol. Het protocol is sindsdien internationaal gestandaardiseerd als een op publiceren/abonneren-gebaseerd berichtenprotocol onder de ISO-standaard (ISO/IEC PRF 20922.) IBM heeft de MQTT versie 3.1-specificatie in 2013 ingediend bij de Structured Information Standards Facilitation Organization, samen met een handvest om ervoor te zorgen dat slechts een klein aantal wijzigingen in de specificatie kon worden aangebracht, en sindsdien wordt het MQTT-protocol gebruikt sindsdien in een aantal niches. Toen de technische infrastructuur van het IoT eenmaal voltooid was, begon dit eeuwenoude protocol zijn eerste lente te beleven.
Transport- en applicatielagen van het netwerk
Zoals we allemaal weten, kan de snelle ontwikkeling van het Internet of Things tot nu toe de infrastructuur van het communicatienetwerk niet verlaten. Je kunt nu elke hoek van de wereld besturen in het huis van een kamerlichtschakelaar, of om industriële controle uit te voeren, je kunt ook de beweging van een robot op afstand besturen. De volwassenheid van deze technologie is gebaseerd op netwerkcommunicatie als basis. De belangrijkste technologie van de huidige netwerktechnologie is het OSI-model met zeven-lagen. De daadwerkelijke toepassing maakt uiteraard gebruik van het TCP/IP-netwerkmodel met vier-lagen.
TCP/IP vier-laags netwerkmodel van de derde transportlaag is het beroemde TCP/IP-protocol. Deze laag van het hoofddoel van het protocol wordt gebruikt om een computer op het netwerk communicatiegegevens te verzenden naar het opgegeven IP-adres van de andere machine hierboven, bijvoorbeeld een IP-adres "192.168.137.19". Als een machine met IP-adres "192.168.137.19" bijvoorbeeld een binair pakket van 16 bytes naar een machine met IP-adres "192.168.137.10" sturen, dan is het mogelijk om het TCP/IP-protocol te gebruiken om het te verzenden. In plaats daarvan gebruiken we bij het overbrengen van gegevens via TCP gewoonlijk sockets.
Maar wanneer het IP-adres van de "192.168.137.19"-machine gegevens naar de "192.168.137.10"-machine verzendt, is dit pakket TCP-pakketten in de gegevens eigenlijk namens wat de betekenis is van het ontvangende uiteinde van het IP-adres van het ontvangende uiteinde van de "192.168.137.10"-machine. Hoe dit pakket met gegevens moet worden geparseerd, wordt dit probleem overgelaten aan de transportlaag boven de laag van protocollen die moeten worden opgelost, wat de applicatielaagprotocollen zijn. Als uw protocollen de resolutie niet aan het gewone netwerk van computers willen geven, kunt u natuurlijk ook enkele van hun eigen applicatielaagprotocollen gaan ontwikkelen. Het maakt niet uit, het doel van de transportlaag is alleen maar om de gegevens door te geven aan de doelmachine erbovenop.
Ons dagelijks werk, entertainment zal vaak een verscheidenheid aan applicatielaagprotocollen tegenkomen, zoals wanneer u een webpagina opent, wordt de afbeelding in die positie weergegeven, de knop om naar beneden te wijzen is om welke functie te bereiken, dit wordt door het HTML HyperText Transfer Protocol (Engels: HyperTextTransferProtocol, afkorting: HTTP) overeengekomen. Dit zorgt ervoor dat wanneer een pagina op uw website door een apparaat wordt opgevraagd, dat apparaat deze correct kan weergeven. Naast HTTP zijn er nog vele andere protocollen op de applicatielaag, zoals DNS, FTP, enz., en het MQTT-protocol, dat vandaag onze hoofdrol speelt, is daar een van.
Waarom IoT de voorkeur geeft aan MQTT
Waarom blinkt MQTT uit in de IoT-ruimte, met alle geweldige applicatielaagprotocollen die beschikbaar zijn voor onze bestaande applicaties? De keuze voor het MQTT-protocol is niet ongegrond; MQTT is een lichtgewicht, flexibel netwerkprotocol dat ernaar streeft de juiste balans te vinden voor IoT-ontwikkelaars:
Dit lichtgewicht protocol kan worden geïmplementeerd op sterk beperkte apparaathardware en netwerken met beperkte latentie/bandbreedte.
De flexibiliteit maakt het mogelijk om diverse toepassingsscenario's voor IoT-apparaten en -diensten te ondersteunen.
De meeste ontwikkelaars zijn al bekend met HTTP-webservices. Dus waarom zouden we IoT-apparaten niet verbinding laten maken met webservices? Apparaten kunnen hun gegevens verzenden in de vorm van HTTP-verzoeken en updates van het systeem ontvangen in de vorm van HTTP-antwoorden. Dit verzoek- en antwoordmodel heeft enkele ernstige beperkingen:
HTTP is een synchronisatieprotocol. De client moet wachten tot de server reageert. webbrowsers hebben deze vereiste, maar dit gaat ten koste van de schaalbaarheid. In de IoT-ruimte maken een groot aantal apparaten en een netwerk dat waarschijnlijk onbetrouwbaar is of een hoge latentie heeft, synchrone communicatie problematisch. Asynchrone berichtenprotocollen zijn beter geschikt voor IoT-toepassingen. Sensoren verzenden metingen en laten het netwerk de beste route en tijd bepalen om deze naar doelapparaten en -services te sturen.
HTTP is unidirectioneel. De client moet de verbinding tot stand brengen. Bij IoT-toepassingen is het apparaat of de sensor meestal de client, wat betekent dat ze niet passief opdrachten van het netwerk kunnen ontvangen.
HTTP is een één-op-één-protocol. De client doet een verzoek en de server reageert. Het bezorgen van berichten aan alle apparaten in het netwerk is niet alleen moeilijk maar ook duur, wat een veelvoorkomend gebruiksscenario is bij IoT-toepassingen.
HTTP is een zwaargewicht protocol met veel headers en regels. Het is niet geschikt voor beperkte netwerken.
Om deze redenen gebruiken de meeste hoogwaardige, schaalbare systemen- asynchrone berichtbussen voor interne gegevensuitwisseling in plaats van webservices.
Het abonnements-/publicatiemodel
Interessant is dat deze MQTT-protocolserver eigenlijk een veel eenvoudiger ontwerp heeft dan een webserver, omdat deze een efficiënte service wil zijn. het mechanisme waarmee MQTT voornamelijk berichten verzendt en ontvangt, is enigszins vergelijkbaar met de relatie tussen onze openbare website en u, de lezers.
In de echte wereld zijn ik en jij vergelijkbaar met een MQTT-apparaat dat is aangesloten op een uniforme server, je abonneert je op ons uit interesse of een soort genegenheid voor ons openbare nummer, en wanneer ik elke dag een sms-push verstuur, zul je verschijnen in de mobiele telefoon waarop ik het bericht heb gepusht. Dit proces, je krijgt mijn informatie op een manier die bekend staat als de In dit proces wordt de manier waarop je mijn informatie krijgt 'abonnement' genoemd, en het gedrag van mijn berichten op dit openbare nummer is 'publiceren'. En iedereen kan naar mijn artikel gaan, je kunt gerust een bericht voor mij achterlaten, dit gedrag is ieders "publicatie" -gedrag, en ik blijf altijd voorop staan om ieders bericht te zien, dit is een soort "abonnements" -gedrag. In dit proces heeft alle externe informatie niets met ons te maken, we communiceren eenvoudigweg in twee richtingen met de informatiestroom. Het berichtenmechanisme in MQTT is ook gebaseerd op het Publish - Subscribe-model. Het MQTT-berichtbezorgingsmechanisme is ook gebaseerd op het 'Publiceren' - 'Abonneren'-model.
MQTT-specifieke stappen zijn:
Stap 1:Gebruik de eerste om een MQTT-server te verkrijgen en maak vervolgens een nieuw MQTT-communicatieproduct.
Stap 2:Ga vervolgens verbinding maken met deze server. Twee belangrijke parameters om verbinding te maken met de server zijn het hostnummer (domeinnaam of IP-adres) en poortnummer.
Stap 3:Als u een cloudserverplatform van derden- gebruikt, kan het zijn dat u zich moet aanmelden bij dit apparaat met behulp van de product-ID en authenticatie-informatie, die beide te vinden zijn in de backend van Device Cloud.
Zodra deze drie stappen zijn voltooid, kunt u zich abonneren op of berichten plaatsen op de overeenkomstige onderwerpen.
Ik zal een document samenstellen om u te laten zien hoe u een open-toegangsplatform in de cloud van China Mobile-apparaten kunt 'hoeren'.
Deze drie stappen zijn van toepassing op zowel de ontwikkeling van applicatiesoftware als op de ontwikkeling van microcontrollers. Als u bij de ontwikkeling van microcontrollers AT-opdrachten en externe WIFI-modulecommunicatie gebruikt, kan de algemene module worden geleverd met AT + MQTT-opdrachten, wat de beste manier is om de druk op de microcontroller aanzienlijk te verminderen. Of u kunt rechtstreeks toegang krijgen tot de gegevens van de TCP/IP-transportlaag en vervolgens de MQTT parseren, wat vereist dat de gebruiker een diep begrip heeft van het MQTT-protocol om ook zijn eigen Json-gegevens te kunnen parseren. Over het algemeen wordt bij het gebruik van ingebedde apparaten over het algemeen aanbevolen dat we direct de kant-en-klare module met het MQTT-protocol gebruiken; het direct parseren van de AT-opdracht is handiger.
Casestudy:
Verlichting op afstand bedienen en de huidige kamertemperatuur opvragen.
Wat dit geval betreft, het is eigenlijk een van de eenvoudigste toepassingen van MQTT. Allereerst is de ingebouwde besturingskaart in de kamer voornamelijk via WIFI verbonden met de server, die de lichtschakelaar kan bedienen en ook de temperatuur kan verzamelen. Het eindapparaat ver weg is een mobiele telefoon.
Om de communicatie te laten werken, moeten ze eerst verbonden zijn met dezelfde MQTT-server.
De temperatuurinformatie aan de apparaatzijde wordt door het apparaat verzameld, dus het moet de verzamelde gegevens publiceren in het onderwerp "Temperatuur", terwijl de mobiele telefoon de temperatuurinformatie ontvangt, dus het moet zich abonneren op het onderwerp "Temperatuur". Zodra het apparaat de temperatuurinformatie naar het "temperatuuronderwerp" verzendt, wordt het onderwerp door de mobiele telefoon ontvangen.
De lichtbediening aan de kant van het apparaat wordt uitgevoerd door het apparaat, dus het moet zich abonneren op het onderwerp "lichtschakelaar", terwijl de mobiele telefoon de lichtschakelaar bestuurt, dus het moet besturingsinformatie publiceren over dit onderwerp "lichtschakelaar". Zodra de mobiele telefoon een licht-aan-bericht naar het "licht-aan"-onderwerp stuurt, wordt het onderwerp door de terminal ontvangen en vervolgens wordt het licht-aan-commando uitgevoerd.