MQTT: ett öppet nätverksprotokoll och dess betydelse i IoT

Kom ihåg namnet MQTT, eftersom det är ett nätverkskommunikationsprotokoll typ M2M (Machine to Machine) som kommer att låta ganska lite. Det blir ganska populärt tack vare den nya eran av Internet of Things eller IoT (Internet of Things) för dess akronym på engelska. Dessutom är det ett öppet protokoll som ger många fördelar.

I själva verket har det blivit en av de centrala pelarna i IoT, eftersom det är ganska bra på enheter med vissa överföringsbegränsningar som dessa. Förkortningen MQTT kommer från Message Queuing Telemetri Transport, en öppen standard från OASIS och ISO (ISO / IEC 20922) för nätverkskommunikation och som i allmänhet körs på den berömda TCP / IP.

Nätverksprotokoll

mycket kommunikationsprotokoll De är regler som gör att två eller flera enheter eller system kan kommunicera med varandra. Det vill säga det är ett protokoll för att sända information på olika sätt och med ett definierat format, oavsett om det implementeras av programvara och hårdvara (eller båda).

El standard i protokollet definierar en mängd kommunikationsegenskaper. Det kan gå från reglerna för synkronisering, semantik, syntax, paketformat etc. Och sanningen är att de inte är något försumbar, eftersom vi tack vare dessa protokoll idag kan använda Internet och andra kommunikationsnätverk ...

Och naturligtvis finns det inte bara ett protokoll utan många. Till exempel, den kända DNS, FTP, MQTT, HTTP och HTTPS, IMAP, LDAP, NTP, DHCP, SSH, Telnet, SNMP, SMTP, etc., för applikationslagret. I transportskiktet kan du hitta några så kända som TCP, UDP, etc., liksom de för Internet-lagret som IPv4 eller IPv6 (vilket har möjliggjort det största antalet tillgängliga IP-adresser och ankomsten av IoT ), IPSec, etc., och andra från länklagret som DSL, Ethernet, WiFi, ARP, etc.

Om IoT-protokoll

Naturligtvis finns det specifika kommunikationsprotokoll eller som kan tillämpas på IoT. Det vill säga, med tanke på föregående avsnitt skulle de vara en serie definierade standarder så att två eller flera IoT-enheter kan kommunicera och förstå varandra, och de är vanligtvis M2M, det vill säga maskin-till-maskin-kommunikation. många IoT-enheter anslutna och delar information från sensorer eller andra källor.

På grund av det stora antalet IoT-enheter måste dessa protokoll uppfylla kraven utöver begränsningarna för bandbredd, hastighet etc. (notera att många enheter är inbäddade och billiga), vilket vanligtvis finns i vissa enheter. Och jag menar det faktum att måste vara skalbar, för att kunna lägga till fler anslutna enheter vid behov och utan att påverka det globala systemet.

De måste också ha en lågt beroende koppling mellan enheter så att problem inte genereras om en enhet tas bort. Och naturligtvis eftersträvas en hög driftskompatibilitet så att den fungerar med ett stort antal enheter och mycket varierande system, eftersom IoT-världen är ganska heterogen.

Andra användbara funktioner är att det är enkelt att implementera dem, säkerhet, etc. Tänk på att IoT skapar stora utmaningar i säkerhetsaspekten. Ännu mer så när många av de anslutna enheterna tenderar att vara kritiska i vissa fall ... till exempel leksaker för minderåriga.

Viktiga begrepp

Med detta sagt måste det sägas att lösningar för IoT använder en centraliserad server för att ta emot meddelanden från alla anslutna enheter som sänder ut och distribuera dem till alla anslutna IoT-enheter som lyssnar. Den servern är det som kallas router eller mäklare. Något som är långt ifrån det konventionella klient-serverförhållandet på vissa sätt.

Vidare, metoderna som du hittar i dessa kommunikationsprotokoll för IoT är:

• PubSub: Publish / Susbcribe är ett meddelandemönster där en enhet (Sub) informerar mäklaren om att den vill ta emot ett meddelande, medan en annan enhet (Pub) publicerar meddelanden för mäklaren att distribuera till den / de andra enheterna som väntar på dem.
• rRPC: Router Remoder Procedure Calls är ett annat mönster för körning av fjärrprocessen. I den informerar en enhet (Callee) mäklaren om att den kommer att utföra en viss procedur och mäklaren distribuerar den till en annan enhet (Caller) som nämnda process utförs på.

Nu, för att utföra dessa metoder eller mönster, a meddelandeinfrastruktur. Och i den meningen kan man urskilja två:

• Meddelandekö: meddelandetjänst där en enda meddelandekö genereras för alla klienter som initierar ett abonnemang på mäklaren. Den senare kommer att lagra meddelandena tills de levereras till klienten. Om klienten eller mottagaren inte är ansluten behålls den tills den är ansluten. Dessa typer av tjänster är som de som används i snabbmeddelandeprogram som Telegra, WhatsApp, Messenger etc.
• Meddelandetjänst: det är en annan tjänst där mäklaren skickar meddelandena till den anslutna mottagarklienten och filtrerar efter typ av meddelande. Om klienten eller den mottagande enheten kopplas bort försvinner meddelandena (även om det kan ha något loggningssystem).

IoT-protokoll

Efter att ha sett ovanstående, låt oss nu titta närmare IoT-protokoll som är bättre kända. Bland de mest framstående av M2M är:

• AMQP (Advanced Message Queuing Protocol): är ett PubSub-typprotokoll för Message Queue. Konstruerad för att ha bra interoperabilitet och säkerställa tillförlitlighet. Speciellt för företagsapplikationer, högpresterande nätverk med hög latens, kritiska etc.
• WAMP (Web Application Messaging Protocol): det är ett annat öppet protokoll av typen PubSub som rRPC, och det körs på WebSockets.
• CoAP (begränsat applikationsprotokoll): är ett protokoll speciellt utformat för applikationer med låg kapacitet.
• TOMP (Streaming Text Oriented Messaging Protocol): mycket enkelt protokoll och för att uppnå maximal interoperabilitet. HTTP används för att överföra textmeddelanden.
• XMPP (eXtensible Messaging and Presence Protocol): ett annat protokoll som används i IoT för snabbmeddelandeprogram och baserat på XML. Jan detta ärende är också öppet.
• WMQ (WebSphere Message Queuing): protokoll utvecklat av IBM. Det är av typen Message Queue, som namnet antyder, och är meddelandesorienterat.
• MQTT: (se nästa avsnitt)

Allt om MQTT

El MQTT-protokoll Det är ett meddelandekö-kommunikationsprotokoll som följer ett PubSub-mönster och av typen M2M som jag redan har nämnt. Det används ofta i IoT och är baserat på TCP / IP-stacken som används på Internet.

När det gäller MQTT, varje anslutning hålls öppen och det återanvänds i all nödvändig kommunikation. Något annat än vad som händer i andra kända protokoll, att varje kommunikation sker kräver en ny anslutning.

Fördel

Fördelarna med MQTT-protokollet är ganska uppenbara när det gäller M2M-kommunikation för IoT. Förutom allt som sägs ovan är det ett protokoll som ger:

• Skalbarhet, för att ansluta fler och fler kunder.
• Frikoppling mellan klienter, för mindre beroende.
• Asynkronism.
• Enkelhet.
• Lätthet för att inte konsumera för många resurser (även om det med TLS / SSL-säkerhet går upp).
• Energieffektivt för enheter som är beroende av batteri eller fungerar 24/7, det behöver inte stor bandbredd (perfekt för långsamma anslutningar, som vissa trådlösa).
• Säkerhet och kvalitet för ökad tillförlitlighet och robusthet i kommunikationen.

historia

MQTT skapades på 90-talet med en tidig version av protokoll 1999. Det skapades av Dr. Andy Stanford-Clark från IBM och Arlen Nipper från Cirrus Link (tidigare Eurotech).

La första idé var att skapa ett protokoll för att övervaka en rörledning som färdades genom öknen, med ett effektivt kommunikationsprotokoll (låg bandbreddförbrukning), ljus och att en låg energiförbrukning. Vid den tiden var det väldigt dyrt, men nu har det blivit ett billigt och öppet protokoll.

Det ursprungliga protokollet förbättrades med utseendet på nya versioner, såsom MQTT v3.1 (2013) enligt specifikationen OASIS (Organization for the Advancement of Structured Information Standards), etc. Du borde veta att det i början var ett eget IBM-protokoll, men att det skulle släppas 2010, och det blev slutligen en standard i OASIS ...

Hur MQTT-anslutningen fungerar

MQTT-protokollet använder ett filter, för meddelanden som skickas till varje klient, baserat på ämnen eller ämnen som är organiserade hierarkiskt. På detta sätt kan en kund skicka ett meddelande om ett visst ämne. På detta sätt får alla de klienter eller anslutna enheter som prenumererar på ämnet meddelanden via mäklaren.

Liksom MQ, meddelanden förblir i kön och de går inte förlorade förrän klienten har fått det meddelandet.

Anslutningarna, som jag också angav, är gjorda via TCP / IP, och servern eller mäklaren kommer att registrera de anslutna klienterna. Som standard använder enheterna kommunikationsportnummer 1883, även om du också kan stöta på port 8883 om du använder SSL / TLS för extra säkerhet.

För att anslutningen ska vara möjlig behövs inte bara klienter, servrar och portar. Även andra paket eller meddelanden som skickats för att kommunikation ska äga rum:

• Upprätta anslutning: CONNECT meddelande / paket skickat av klienten med all nödvändig information. Denna information inkluderar kund-ID, användarnamn, lösenord etc. Mäklaren eller servern svarar med ett CONNACK-paket som informerar klienten om att anslutningen accepterades, avvisades etc.
• Skicka och ta emot meddelanden: när anslutningen har upprättats används PUBLICERA paket eller meddelanden med ämnet och nyttolasten för meddelandet som skickas till mäklaren. Å andra sidan använder den eller de intresserade klienterna SUBSCRIBE- och UNSUSCRIBE-paket för att prenumerera eller dra tillbaka sitt abonnemang. Mäklaren kommer också att svara med ett SUBACK- och UNSUBACK-paket för att rapportera framgången för den operation som begärts av klienten.
• Underhålla anslutningen: för att garantera att anslutningen förblir öppen kan klienter regelbundet skicka ett PINGREQ-paket som matchas med ett PINGRESP-paket från servern.
• Avsluta anslutningen: när en klient kopplar ifrån skickar den ett DISCONNECT-paket för att rapportera händelsen.

De där meddelanden eller paket De jag har pratat om har samma struktur som andra paket med andra nätverksprotokoll:

• Sidhuvud eller fast huvud: är en fast del som upptar mellan 2-5 byte. Den innehåller en kontrollkod, ID för vilken typ av meddelande som skickas och dess längd. Mellan 1-4 byte används för att koda längden, med de första 7 bitarna i varje oktett som data för längden och en ytterligare bit av kontinuitet för att bestämma att det finns mer än en byte som utgör meddelandets längd.
• Variabel rubrik: är inte alltid obligatoriskt, men valfritt. Det finns bara i vissa paket i vissa situationer eller specifika meddelanden.
• Innehåll eller data: paketdata är det som faktiskt innehåller meddelandet som ska skickas. Det kan vara från några kB upp till en gräns på 256 MB.

Om du är intresserad av att veta motsvarande kod i hexadecimal för de typer av meddelanden som skickas är:

Kommunikationens kvalitet och säkerhet

En annan viktig detalj i meddelandena från MQTT är kvalitet på tjänsten eller QoSoch säkerhet. Kommunikationssystemets robusthet i händelse av fel och dess säkerhet beror på detta.

När det gäller dess kvalitet kan den bestämmas 3 olika nivåer:

• QoS 0 (okunnighet)- Meddelandet skickas bara en gång och i händelse av misslyckande skulle det inte levereras. Den används när den inte är kritisk.
• QoS 1 (bekräfta): meddelandet skickas så många gånger som behövs för att garantera leverans till kunden. Nackdelen är att klienten kan få samma meddelande flera gånger.
• QoS 2 (säker)- Liknar ovan, men garanteras levereras bara en gång. Det används ofta för mer kritiska system där större tillförlitlighet behövs.

Å andra sidan, som för MQTT-säkerhetkan olika åtgärder användas för att säkerställa dess styrka i detta avseende. Som jag redan har nämnt tidigare kan autentisering av användarnamn och lösenord, som många andra protokoll, säkerställas med SSL / TLS. Även om många IoT-enheter med låg kapacitet eller resurser kan ha problem med överbelastningen av arbete när de använder denna typ av säker kommunikation ...

Av denna anledning använder många IoT-enheter som använder MQTT lösenord och användare i plantext, vilket kan få någon att sniffa nätverkstrafik för att få dem mycket enkelt. Och om det inte räcker kan mäklaren också konfigureras för att acceptera anonyma anslutningar, vilket gör det möjligt för alla användare att upprätta kommunikation med större risk.

Använda MQTT med Arduino

Såklart du kan använd MQTT-protokollet med Arduino och andra utvecklingskort, såväl som Rapsberry Pi, etc. För att göra detta måste du förse ditt Arduino-kort med anslutning, om det inte har det. Också biblioteket Arduino-klient för MQTT det hjälper dig i dessa uppgifter. Detta bibliotek är kompatibelt med:

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

Så snart som till koden för att använda MQTT i någon applikation är sanningen att det är enkelt. I Fritzing-bilden kan du se en plack Arduino UNO till vilken anslutning via Arduino Ethernet har lagts till och den har också anslutits en DHT22 luftfuktighets- och temperatursensor, även om det kunde ha varit något annat ...

Ok, med det sagt, för koden du måste generera i Arduino IDE Att arbeta med MQTT-protokollet på Arduino är så enkelt:

• till skicka meddelanden 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);
}

• till ta emot meddelanden av MQTT behöver du bara plattan Arduino UNO och anslutning, med Arduino Ethernet eller något annat element. När det gäller koden skulle ett exempel vara:

#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();
}

För mer information kan du ladda ner gratis vår PDF-handbok med Arduino IDE-kursen för att börja programmera.