MQTT: en åpen nettverksprotokoll og dens betydning i IoT

Husk navnet MQTT, siden det er en nettverkskommunikasjonsprotokoll type M2M (Machine to Machine) som kommer til å høres ganske mye ut. Det blir ganske populært takket være den nye epoken med tingenes internett eller IoT (tingenes internett) for forkortelsen på engelsk. I tillegg er det en åpen protokoll, som gir mange fordeler.

Faktisk har det blitt en av de sentrale pilarene i IoT, da det er ganske bra på enheter med noen overføringsbegrensninger som disse. Forkortelsen MQTT kommer fra Message Queuing Telemetri Transport, en åpen standard fra OASIS og ISO (ISO / IEC 20922) for nettverkskommunikasjon og som vanligvis kjører på den berømte TCP / IP.

Nettverksprotokoller

den kommunikasjonsprotokoller De er regler som tillater to eller flere enheter eller systemer å kommunisere med hverandre. Det vil si at det er en protokoll for å overføre informasjon på forskjellige måter og med et definert format, enten implementert av programvare og maskinvare (eller begge deler).

El standard i protokollen definerer et mangfold av kommunikasjonsegenskaper. Det kan gå fra reglene for synkronisering, semantikk, syntaks, pakkeformat, etc. Og sannheten er at de ikke er noe ubetydelige, siden takket være disse protokollene i dag kan vi bruke Internett og andre kommunikasjonsnettverk ...

Og selvfølgelig er det ikke bare en protokoll, men mange. For eksempel, de berømte DNS, FTP, MQTT, HTTP og HTTPS, IMAP, LDAP, NTP, DHCP, SSH, Telnet, SNMP, SMTP, etc., for applikasjonslaget. Mens du er i transportsjiktet, kan du finne noen så berømte som TCP, UDP, etc., så vel som de fra Internett-laget som IPv4 eller IPv6 (den som har muliggjort det største antallet tilgjengelige IP-er og ankomsten av IoT), IPSec, etc., og andre fra koblingslaget som DSL, Ethernet, WiFi, ARP, etc.

Om IoT-protokoller

Selvfølgelig er det spesifikke kommunikasjonsprotokoller eller som kan brukes på IOT. Det vil si, med tanke på den forrige delen, ville de være en serie definerte standarder slik at to eller flere IoT-enheter kan kommunisere og forstå hverandre, og de er vanligvis M2M, det vil si maskin-til-maskin-kommunikasjon. mange IoT-enheter tilkoblet og deler informasjon fra sensorer eller andre kilder.

På grunn av det store antallet IoT-enheter, må disse protokollene oppfylle kravene utover begrensningene for båndbredde, hastighet osv. (merk at mange enheter er innebygd og billig), som vanligvis er i noen enheter. Og jeg mener det må være skalerbar, for å kunne legge til flere tilkoblede enheter om nødvendig og uten å påvirke det globale systemet.

De må også ha en lav avhengighet kobling mellom enheter, slik at problemer ikke genereres hvis en enhet fjernes. Og selvfølgelig søkes det høy interoperabilitet slik at det fungerer med et stort antall enheter og svært varierte systemer, siden IoT-verdenen er ganske heterogen.

Andre nyttige funksjoner vil være enkel å implementere dem, sikkerheten, etc. Husk at IoT skaper store utfordringer i sikkerhetsaspektet. Enda mer når mange av de tilkoblede enhetene vanligvis er kritiske i visse tilfeller ... for eksempel leker for mindreårige.

Viktige begreper

Når det er sagt, må det sies at løsninger for IoT bruker en sentralisert server for å motta meldingene fra alle tilkoblede enheter som sender ut og distribuere dem til alle tilkoblede IoT-enheter som lytter. Denne serveren er det som er kjent som ruter eller megler. Noe som på noen måter er langt fra det konvensjonelle klient-server-forholdet.

Videre metodene som du finner i disse kommunikasjonsprotokollene for IoT er:

• PubSub: Publish / Susbcribe er et meldingsmønster der en enhet (Sub) informerer megleren om at den ønsker å motta en melding, mens en annen enhet (Pub) publiserer meldinger som megleren skal distribuere til den / de andre enhetene som venter på dem.
• rRPC: Router Remoder Procedure Calls er et annet mønster for ekstern prosessutførelse. I den informerer en enhet (Callee) megleren om at den vil utføre en bestemt prosedyre, og megleren distribuerer den til en annen enhet (Caller) som nevnte prosess utføres på.

Nå, for å utføre disse metodene eller mønstrene, a meldingsinfrastruktur. Og i denne forstand kan man skille mellom to:

• Meldingskø: meldingstjeneste der det genereres en enkelt meldingskø for alle klienter som starter et abonnement på megleren. Sistnevnte vil lagre meldingene til de blir levert til klienten. Hvis klienten eller mottakeren ikke er tilkoblet, opprettholdes den til den er tilkoblet. Disse tjenestene er som de som brukes i direktemeldingsapper som Telegra, WhatsApp, Messenger, etc.
• Meldingstjeneste: det er en annen tjeneste der megleren sender meldingene til den tilkoblede mottakerklienten, filtrert etter typen melding. Hvis klienten eller mottakerenheten er koblet fra, går meldingene tapt (selv om det kan ha noe loggesystem).

IoT-protokoller

Etter å ha sett ovennevnte, la oss nå se nærmere på IoT-protokoller som er bedre kjent. Blant de mest fremtredende av M2M er:

• AMQP (Advanced Message Queuing Protocol): er en PubSub-type protokoll for Message Queue. Designet for å ha god interoperabilitet og sikre pålitelighet. Spesielt for bedriftsapplikasjoner, høy ytelse, nettverk med høy latens, kritiske osv.
• WAMP (Web Application Messaging Protocol): det er en annen åpen protokoll av typen PubSub som rRPC, og den kjører på WebSockets.
• CoAP (begrenset applikasjonsprotokoll): er en protokoll spesielt designet for applikasjoner med lav kapasitet.
• TOMP (Streaming Text Oriented Messaging Protocol): veldig enkel protokoll og for å oppnå maksimal interoperabilitet. HTTP brukes til å overføre tekstmeldinger.
• XMPP (eXtensible Messaging and Presence Protocol): en annen protokoll som brukes i IoT for direktemeldingsapper og basert på XML. Jan denne saken er også åpen.
• WMQ (WebSphere Message Queuing): protokoll utviklet av IBM. Det er av typen Message Queue, som navnet antyder, og er meldingsorientert.
• MQTT: (se neste avsnitt)

Alt om MQTT

El MQTT-protokoll Det er en Message Queue-kommunikasjonsprotokoll, som følger et PubSub-mønster, og av M2M-typen, som jeg allerede har nevnt. Den brukes mye i IoT, og er basert på TCP / IP-stakken som brukes på Internett.

I tilfelle MQTT, hver forbindelse holdes åpen og det blir gjenbrukt i all nødvendig kommunikasjon. Noe annerledes enn hva som skjer i andre kjente protokoller, at hver kommunikasjon foregår krever en ny forbindelse.

Advantage

Fordelene med MQTT-protokollen er ganske tydelige når det gjelder M2M-kommunikasjon for IoT. I tillegg til alt sagt ovenfor, er det en protokoll som gir:

• Skalerbarhet, for å koble flere og flere kunder.
• Koble fra klienter for mindre avhengighet.
• Asynkronisme.
• Enkelhet.
• Letthet for ikke å forbruke for mange ressurser (selv om det med TLS / SSL-sikkerhet øker).
• Energieffektiv for enheter som er avhengige av batteri eller fungerer 24/7, den trenger ikke stor båndbredde (ideell for langsomme tilkoblinger, for eksempel noen trådløse).
• Sikkerhet og kvalitet, for større pålitelighet og robusthet i kommunikasjonen.

historie

MQTT ble opprettet på 90-tallet, med en tidlig versjon av protokoll i 1999. Den ble opprettet av Dr. Andy Stanford-Clark fra IBM og Arlen Nipper fra Cirrus Link (tidligere Eurotech).

La første ideen skulle lage en protokoll for å overvåke en rørledning som reiste gjennom ørkenen, med en effektiv kommunikasjonsprotokoll (lavt båndbreddeforbruk), lys og at et lavt energiforbruk. Den gang var det veldig dyrt, men nå har det blitt en billig og åpen protokoll.

Den opprinnelige protokollen ble forbedret med utseendet til nye versjoner, slik som MQTT v3.1 (2013) under OASIS (Organization for the Advancement of Structured Information Standards) spesifikasjon, etc. Du burde vite at det i begynnelsen var en proprietær protokoll fra IBM, men at den ville bli utgitt i 2010, og den endte med å bli en standard i OASIS ...

Hvordan MQTT-tilkoblingen fungerer

MQTT-protokollen bruker et filter, for meldingene som sendes til hver klient, basert på emner eller emner som er organisert hierarkisk. På denne måten kan en kunde legge ut en melding om et bestemt emne. På denne måten vil alle de klientene eller tilkoblede enhetene som abonnerer på emnet motta meldinger via megleren.

Som det er MQ, meldinger blir værende i køen og de går ikke tapt før klienten har mottatt den meldingen.

Forbindelsene, som jeg også antydet, er laget via TCP / IP, og serveren eller megleren vil føre oversikt over de tilkoblede klientene. Som standard bruker enhetene kommunikasjonsporter nummer 1883, selv om du også kan finne en port 8883 hvis du bruker SSL / TLS for ekstra sikkerhet.

For at tilkoblingen skal være mulig, trenger ikke bare klienter, servere og porter. Også andre pakker eller meldinger sendt for at kommunikasjon skal finne sted:

• Opprett forbindelse: CONNECT melding / pakke sendt av klienten med all nødvendig informasjon. Denne informasjonen inkluderer kunde-ID, brukernavn, passord, etc. Megleren eller serveren svarer med en CONNACK-pakke som vil informere klienten om at forbindelsen ble akseptert, avvist osv.
• Send og motta meldinger: når forbindelsen er opprettet, brukes PUBLISKE pakker eller meldinger med emnet og nyttelasten til meldingen sendt til megleren. På den annen side bruker den eller de interesserte klientene SUBSCRIBE- og UNSUSCRIBE-pakker for å abonnere eller trekke abonnementet. Megleren vil også svare med henholdsvis en SUBACK- og UNSUBACK-pakke for å rapportere suksessen til operasjonen som kunden ba om.
• Opprettholde forbindelsen: for å garantere at forbindelsen forblir åpen, kan klienter med jevne mellomrom sende en PINGREQ-pakke som vil bli matchet med en PINGRESP-pakke fra serveren.
• Avslutt tilkoblingen: når en klient kobler fra, sender den en DISCONNECT-pakke for å rapportere hendelsen.

de meldinger eller pakker De jeg har snakket om har en struktur den samme som andre pakker med andre nettverksprotokoller:

• Topptekst eller fast topptekst: er en fast del som opptar mellom 2-5 byte. Den inneholder en kontrollkode, ID for sendte meldinger og lengden. Mellom 1-4 byte brukes til å kode lengden, ved å bruke de første 7 bitene i hver oktett som data for lengden og en ekstra bit av kontinuitet for å bestemme at det er mer enn en byte som utgjør lengden på meldingen.
• Variabel topptekst: er ikke alltid obligatorisk, men valgfritt. Den er bare inneholdt i noen pakker i visse situasjoner eller spesifikke meldinger.
• Innhold eller data: pakkedataene er det som faktisk inneholder meldingen som skal sendes. Det kan være fra noen kB opp til en 256 MB grense.

Hvis du er interessert i å vite den tilsvarende koden i heksadesimal for de typer meldingene som sendes, er:

Kvalitet og sikkerhet for kommunikasjon

En annen viktig detalj i meldingene fra MQTT er kvalitet på tjenesten eller QoS, og sikkerhet. Kommunikasjonssystemets robusthet i tilfelle feil og dets sikkerhet vil avhenge av dette.

Når det gjelder kvaliteten, kan den bestemmes 3 forskjellige nivåer:

• QoS 0 (ikke-kunnskap)- Meldingen sendes bare en gang, og i tilfelle feil vil den ikke bli levert. Den brukes når den ikke er kritisk.
• QoS 1 (erkjenn): meldingen vil bli sendt så mange ganger som nødvendig for å garantere levering til kunden. Ulempen er at klienten kunne motta den samme meldingen flere ganger.
• QoS 2 (forsikret)- I likhet med ovenstående, men garantert å bli levert bare en gang. Det brukes ofte til mer kritiske systemer der større pålitelighet er nødvendig.

På den annen side, som for MQTT sikkerhet, kan forskjellige tiltak brukes for å sikre styrken i denne forbindelse. Som jeg allerede har nevnt før, kan autentisering av brukernavn og passord, som mange andre protokoller, sikres ved hjelp av SSL / TLS. Selv om mange IoT-enheter med lav kapasitet, eller ressurser, kan ha problemer med overbelastning av arbeid når du bruker denne typen sikker kommunikasjon ...

Av denne grunn bruker mange IoT-enheter som bruker MQTT passord og brukere i flytekst, som kan få noen til å snuse nettverkstrafikk for å få dem veldig enkelt. Og hvis det ikke er nok, kan megleren også konfigureres til å godta anonyme forbindelser, som vil tillate enhver bruker å etablere kommunikasjon, med større risiko.

Bruker MQTT med Arduino

Selvfølgelig kan du bruk MQTT-protokollen med Arduino og andre utviklingstavler, samt Rapsberry Pi, etc. For å gjøre dette må du forsyne Arduino-kortet med tilkobling, hvis det ikke har det. Også biblioteket Arduino-klient for MQTT det vil hjelpe deg i disse oppgavene. Dette biblioteket er kompatibelt med:

• ArduinoYUN
• Arduino WiFi (skjold)
• Arduino Ethernet (skjold)
• ESP8266-modul
• Intel Galileo / Edison
• Raspberry Pi
• ...

Så snart til koden for å bruke MQTT i noen applikasjoner er sannheten at det er enkelt. På Fritzing-bildet kan du se en plakett Arduino UNO til hvilken tilkobling er lagt til av Arduino Ethernet, og den har også blitt koblet til en DHT22 fuktighets- og temperaturføler, selv om det kunne ha vært noe annet ...

Ok, når det er sagt, for koden du må generere i Arduino IDE For å jobbe med MQTT-protokollen på Arduino, er det så enkelt:

• Til sende meldinger MQTT

#include <SPI.h>
#include <Ethernet.h>
#include <PubSubClient.h>
#include <DHT.h>

#define DHTPIN 2
#define DHTTYPE DHT22

// Direccion MAC del adaptador Ethernet
byte mac[] = { 0xCE, 0xAB, 0x0E, 0x3F, 0xFE, 0xD4 };

// IP del servidor (broker)
IPAddress mqtt_server(192, 168, 1, 4);

// Topic o tema con el que se trabaja
const char* topicName = "test";

DHT dht(DHTPIN, DHTTYPE);
EthernetClient ethClient;
PubSubClient client(ethClient);

void setup()
{
  Serial.begin(9600);
  if (Ethernet.begin(mac) == 0) {
    Serial.println("Fallo en Ethernet usando DHCP");
  }
// Puerto 1883 de comunicación
  client.setServer(mqtt_server, 1883);
  dht.begin();
}

void loop()
{
  if (!client.connected()) {
    Serial.print("Conectando ...\n");
    client.connect("Cliente Arduino");
  }
  else {
    // Envío de informacion del sensor de temperatura y humedad
    float temp = dht.readTemperature();
    char buffer[10];
    dtostrf(temp,0, 0, buffer);
    client.publish(topicName, buffer);
  }
  // Tiempo entre envíos en ms (cada 10 segundos)
  delay(10000);
}

• Til motta meldinger av MQTT trenger du bare platen Arduino UNO og tilkobling, med Arduino Ethernet eller et hvilket som helst annet element. Når det gjelder koden, vil et eksempel være:

#include <SPI.h>
#include <Ethernet.h>
#include <PubSubClient.h>

// Direccion MAC del adaptador Ethernet
byte mac[] = { 0xCE, 0xAB, 0x0E, 0x3F, 0xFE, 0xD4 };

// IP del servidor (broker)
IPAddress mqtt_server(192, 168, 1, 4);

// Topic o tema con el que trabajr
const char* topicName = "test";

EthernetClient ethClient;
PubSubClient client(ethClient);

void callback(char* topic, byte* payload, unsigned int length) {
  Serial.print("El mensaje ha llegado [");
  Serial.print(topic);
  Serial.print("] ");
  int i=0;
  for (i=0;i<length;i++) {
    Serial.print((char)payload[i]);
  }
  Serial.println();
}

void setup()
{
  Serial.begin(9600);
  if (Ethernet.begin(mac) == 0) {
    Serial.println("Fallo en Ethernet al usar configuración DHCP");
  }
  client.setServer(mqtt_server, 1883);
  client.setCallback(callback)
}

void loop()
{
  if (!client.connected()) {
      Serial.print("Conectando ...");
      if (client.connect("rece_arduino")) {
        Serial.println("conectado");
        client.subscribe(topicName);
      } else {
        delay(10000);
      }
  }
  // Cliente a la escucha
  client.loop();
}

For mer informasjon kan du last ned gratis vår PDF-håndbok med Arduino IDE-kurset for å starte programmeringen.