MQTT: nyitott hálózati protokoll és jelentősége az IoT-ben

Emlékezz a névre MQTT, mivel ez egy M2M (Machine to Machine) típusú hálózati kommunikációs protokoll, amely eléggé hangzik. Elég népszerűvé válik a dolgok internetének vagy az IoT (Internet of Things) új korszakának köszönhetően az angol rövidítésnek. Ezenkívül nyílt protokoll, amely számos előnyt nyújt.

Valójában az IoT egyik központi pillérévé vált, mivel nagyon jó olyan eszközökön, amelyeknél vannak ilyen átviteli korlátozások. Az MQTT rövidítés származik Üzenetsor Telemetria szállítás, az OASIS és az ISO (ISO / IEC 20922) nyílt szabványa a hálózati kommunikációra, és általában a híres TCP / IP-n fut.

Hálózati protokollok

sok kommunikációs protokollok Ezek olyan szabályok, amelyek lehetővé teszik két vagy több eszköz vagy rendszer közötti kommunikációt. Vagyis protokoll különféle eszközökkel és meghatározott formátumban történő információ továbbítására, függetlenül attól, hogy szoftveres és hardveres (vagy mindkettő) megvalósítja őket.

El estándar A protokoll a kommunikációs jellemzők sokaságát határozza meg. Kihúzható a szinkronizálás, a szemantika, a szintaxis, a csomagformátum stb. Szabályaiból. És az az igazság, hogy nem elhanyagolhatóak, mivel manapság ezeknek a protokolloknak köszönhetően használhatjuk az internetet és más kommunikációs hálózatokat ...

És természetesen nemcsak egy protokoll létezik, hanem sok is. Például, a híres DNS, FTP, MQTT, HTTP és HTTPS, IMAP, LDAP, NTP, DHCP, SSH, Telnet, SNMP, SMTP stb. Míg a szállítási rétegben találhat olyan híreseket, mint a TCP, UDP stb., Valamint az internetes rétegét, például az IPv4 vagy az IPv6 (amely lehetővé tette a lehető legtöbb IP-t és a az IoT), az IPSec stb. és mások a kapcsolati rétegből, például DSL, Ethernet, WiFi, ARP stb.

Az IoT protokollokról

Természetesen vannak speciális kommunikációs protokollok, amelyek alkalmazhatók a Tárgyak internete. Vagyis az előző szakaszt figyelembe véve, ezek egy meghatározott szabvány sorozat lennének, hogy két vagy több IoT eszköz kommunikálhasson és megértsék egymást, és általában M2M, azaz gép-gép közötti kommunikációról van szó. sok IoT eszköz csatlakoztatva van, és szenzorokból vagy más forrásokból származó információkat oszt meg.

Az IoT-eszközök nagy száma miatt ezeknek a protokolloknak meg kell felelniük a sávszélesség, a sebesség stb. (vegye figyelembe, hogy sok eszköz beágyazott és olcsó), ami általában egyes eszközökben található. És ezt a tényt értem skálázhatónak kell lennie, hogy további csatlakoztatott eszközöket hozzá lehessen adni, ha szükséges és anélkül, hogy ez befolyásolná a globális rendszert.

Emellett rendelkezniük kell a alacsony függőség összekapcsolása az eszközök között, így egy eszköz eltávolításakor nem keletkeznek problémák. És természetesen egyidejűleg magas interoperabilitásra törekednek, hogy nagyszámú eszközzel és nagyon változatos rendszerekkel működjön, mivel az IoT világa meglehetősen heterogén.

További hasznos funkciók a megvalósításuk egyszerűsége, a biztonságstb. Ne feledje, hogy az IoT nagy kihívásokat jelent a biztonsági szempontból. Még inkább, ha a csatlakoztatott eszközök közül sokan bizonyos esetekben kritikusak ... például kiskorúak játékai.

Fontos fogalmak

Ennek ellenére el kell mondani, hogy az IoT megoldásai központosított szervert használnak az üzenetek fogadására az összes csatlakoztatott eszközről, amelyek kibocsátják és terjesztik azokat az összes csatlakoztatott IoT eszközre, amely hallgatja. Ez a szerver az úgynevezett router vagy bróker. Valami, ami bizonyos szempontból messze áll a hagyományos kliens-szerver kapcsolattól.

Továbbá, a módszertanok amelyeket az IoT kommunikációs protokolljaiban talál:

• PubSub: A Publish / Susbcribe olyan üzenetküldési minta, amikor egy eszköz (Sub) tájékoztatja a brókert arról, hogy üzenetet akar kapni, míg egy másik eszköz (Pub) üzeneteket tesz közzé a brókernek, hogy terjessze azokat a többi eszközre, amelyek rájuk várnak.
• rRPC: Az útválasztó-átalakító eljáráshívásai a távoli folyamatfuttatás másik mintája. Ebben egy eszköz (Callee) tájékoztatja a brókert, hogy végrehajt egy bizonyos eljárást, és a bróker elosztja azt egy másik eszköznek (Caller), amelyen az említett folyamat végrehajtásra kerül.

Ezen módszerek vagy minták végrehajtásához a üzenetküldő infrastruktúra. Ebben az értelemben kettő különböztethető meg:

• Üzenetsor: üzenetküldési szolgáltatás, ahol egyetlen üzenet várakozási sor jön létre minden ügyfel számára, aki előfizetését kezdeményezi a brókernél. Ez utóbbi addig tárolja az üzeneteket, amíg azokat el nem juttatják az ügyfélhez. Ha az ügyfél vagy a címzett nincs csatlakoztatva, akkor a kapcsolat létrejöttéig fennmarad. Az ilyen típusú szolgáltatások hasonlítanak az azonnali üzenetküldő alkalmazásokhoz, például a Telegra, a WhatsApp, a Messenger stb.
• Üzenetszolgáltatás: ez egy másik szolgáltatás, amelyben a bróker üzeneteket küld a csatlakoztatott címzett ügyfélnek, az üzenet típusa szerint szűrve. Ha az ügyfél vagy a fogadó eszköz nincs csatlakoztatva, akkor az üzenetek elvesznek (bár lehet, hogy van valamilyen naplózási rendszerük).

IoT protokollok

Miután láttuk a fentieket, most nézzük meg közelebbről IoT protokollok amelyek ismertebbek. Az M2M közül a legkiemelkedőbbek a következők:

• AMQP (Advanced Message Queuing Protocol): az üzenetsor PubSub típusú protokollja. Úgy tervezték, hogy jó átjárhatóságot és megbízhatóságot biztosítson. Különösen vállalati alkalmazásokhoz, nagy teljesítményű, nagy késési hálózatokhoz, kritikus stb.
• WAMP (webes alkalmazás üzenetküldési protokoll): ez egy másik nyílt protokoll, amely a PubSub típusú, például az rRPC, és a WebSocketeken fut.
• CoAP (korlátozott alkalmazás protokoll): egy kifejezetten kis kapacitású alkalmazásokhoz tervezett protokoll.
• TOMP (Streaming Text Oriented Messaging Protocol): nagyon egyszerű protokoll és a maximális interoperabilitás elérése. A HTTP a szöveges üzenetek továbbítására szolgál.
• XMPP (extensible Messaging and Presence Protocol): az IoT-ben azonnali üzenetküldő alkalmazásokhoz használt és XML-alapú másik protokoll. Jan ez az ügy is nyitott.
• WMQ (WebSphere Message Queuing): az IBM által kifejlesztett protokoll. Ez a Message Queue típusú, amint a neve is mutatja, és üzenet-orientált.
• MQTT: (lásd a következő szakaszt)

Minden az MQTT-ről

El MQTT protokoll Ez egy Message Queue kommunikációs protokoll, amely egy PubSub mintát követ és M2M típusú, amint azt már említettem. Széles körben használják az IoT-ben, és az interneten használt TCP / IP-veremen alapul.

Az MQTT esetében minden kapcsolatot nyitva tartanak és minden szükséges kommunikációban újra felhasználják. Valami eltér attól, ami más ismert protokollokban történik, hogy minden kommunikáció új kapcsolatra van szükség.

előny

Az MQTT protokoll előnyei meglehetősen nyilvánvalóak az IoT M2M kommunikációja szempontjából. A fentieken túlmenően ez egy protokoll, amely a következőket biztosítja:

• Méretezhetőség, hogy egyre több ügyfelet kössön össze.
• Leválasztás az ügyfelek között, kevesebb függőség érdekében.
• Aszinkronizmus.
• Egyszerűség.
• Könnyűség, hogy ne fogyasszon túl sok erőforrást (bár a TLS / SSL biztonsággal ez megnő).
• Energiatakarékos az akkumulátortól függő vagy a nap 24 órájában működő eszközöknél, ezért nincs szükség nagy sávszélességre (ideális lassú kapcsolatokhoz, mint például néhány vezeték nélküli).
• Biztonság és minőség, a kommunikáció nagyobb megbízhatósága és robusztussága érdekében.

történelem

Az MQTT-t a 90-es években hozták létre, az jegyzőkönyv 1999-ben. Dr. Andy Stanford-Clark, az IBM és Arlen Nipper, a Cirrus Link (korábban Eurotech) alkotta.

La kezdeti ötlet egy sivatagban haladó csővezeték megfigyelésére szolgáló protokoll létrehozása volt a hatékony kommunikációs protokoll (alacsony sávszélesség-fogyasztás), a fény és az alacsony energiafogyasztás. Abban az időben nagyon drága volt, de most olcsó és nyílt protokoll lett belőle.

A kezdeti protokoll javult a megjelenésével új verziók, például az MQTT v3.1 (2013) az OASIS (Szervezet a strukturált információs szabványok előmozdításáért) specifikáció szerint stb. Tudnia kell, hogy kezdetben az IBM saját protokollja volt, de 2010-ben kiadták, és végül az OASIS szabványává vált ...

Hogyan működik az MQTT kapcsolat

Az MQTT protokoll használja egy szűrő, az egyes klienseknek küldött üzenetekhez hierarchikusan rendezett témák vagy témák alapján. Ily módon az ügyfél üzenetet küldhet egy adott témáról. Ily módon mindazok az ügyfelek vagy csatlakoztatott eszközök, amelyek feliratkoznak a témára, üzeneteket kapnak a közvetítőn keresztül.

Ahogy az MQ, az üzenetek a sorban maradnak és nem vesznek el, amíg az ügyfél meg nem kapta ezt az üzenetet.

A kapcsolatok, amint azt is jeleztem, megtörténnek TCP / IP-n keresztül, és a szerver vagy a közvetítő nyilvántartást vezet a csatlakoztatott ügyfelekről. Alapértelmezés szerint az eszközök az 1883-as kommunikációs portokat fogják használni, bár előfordulhat, hogy 8883-as portot is talál, ha SSL / TLS-t használ a nagyobb biztonság érdekében.

A kapcsolat lehetővé tételéhez nemcsak kliensekre, szerverekre és portokra van szükség. Mások is küldött csomagok vagy üzenetek a kommunikáció megvalósításához:

• Hozza létre a kapcsolatot: CONNECT üzenet / csomag, amelyet az ügyfél küldött minden szükséges információval együtt. Ezek az információk tartalmazzák az ügyfél-azonosítót, a felhasználónevet, a jelszót stb. A közvetítő vagy szerver egy CONNACK csomaggal válaszol, amely tájékoztatja az ügyfelet arról, hogy a kapcsolatot elfogadták, elutasították stb.
• Üzenetek küldése és fogadása: ha a kapcsolat létrejött, PUBLISH csomagokat vagy üzeneteket használnak a témával és a brókernek küldött üzenet hasznos terhelésével. Másrészt az érdekelt ügyfél vagy ügyfelek SUBSCRIBE és UNSUSCRIBE csomagokat használnak előfizetésükhöz, illetve előfizetésük visszavonásához. A bróker SUBACK és UNSUBACK csomaggal is válaszol, hogy beszámoljon az ügyfél által kért művelet sikeréről.
• A kapcsolat fenntartása: a kapcsolat nyitott állapotának garantálása érdekében az ügyfelek rendszeresen elküldhetnek egy PINGREQ csomagot, amelyet a szerver egy PINGRESP csomaggal egyeztet.
• Kapcsolat befejezése: amikor egy ügyfél megszakad, egy DISCONNECT csomagot küld az esemény jelentésére.

Azok üzeneteket vagy csomagokat Azokról, amelyekről beszéltem, a felépítés megegyezik a többi hálózati protokoll többi csomagjával:

• Fejléc vagy fix fejléc: egy fix rész, amely 2-5 bájt között foglal helyet. Tartalmaz egy vezérlő kódot, az elküldött üzenet típusának azonosítóját és hosszát. 1-4 bájt közötti értéket használunk a hossz kódolásához, az egyes oktettek első 7 bitjét használva adatként a hosszra és egy további folytonossági bitre annak megállapításához, hogy egynél több bájt alkotja az üzenet hosszát.
• Változó fejléc: nem mindig kötelező, de nem kötelező. Csak bizonyos helyzetekben vagy meghatározott üzenetekben található néhány csomagban.
• Tartalom vagy adatok: a csomagadatok tartalmazzák az elküldendő üzenetet. Lehet néhány kB-tól 256 MB-ig.

Ha érdekel a megismerése a megfelelő kódot hexadecimálisan az elküldött üzenetek típusai:

A kommunikáció minősége és biztonsága

Az MQTT üzeneteinek másik fontos részlete a szolgáltatás minősége vagy QoSés a biztonság. Ettől függ a kommunikációs rendszer robusztus jellege meghibásodások esetén és biztonsága.

Minőségét tekintve meghatározható 3 különböző szint:

• QoS 0 (ismeretlenség)- Az üzenetet csak egyszer küldik el, és meghibásodás esetén nem kézbesítik. Akkor használják, ha nem kritikus.
• QoS 1 (nyugtázás): az üzenet annyiszor kerül elküldésre, amely szükséges az ügyfél kézbesítésének garantálásához. Hátránya, hogy az ügyfél többször is megkapta ugyanazt az üzenetet.
• QoS 2 (biztosított)- A fentihez hasonló, de garantáltan csak egyszer leszállítva. Gyakran használják kritikusabb rendszereknél, ahol nagyobb megbízhatóságra van szükség.

Másrészt, ami a MQTT biztonság, különféle intézkedések alkalmazhatók annak erősségére ebben a tekintetben. Mint már korábban említettem, a felhasználónév és a jelszó hitelesítése, mint sok más protokoll, SSL / TLS segítségével is biztosítható. Bár sok alacsony kapacitású vagy erőforrású IoT-eszköz problémája lehet a munka túlterhelésével, amikor ilyen típusú biztonságos kommunikációt használ ...

Ezért sok IoT eszköz, amely MQTT-t használ, jelszavakat és felhasználókat használ egyszerű szöveg, ami arra késztetheti a hálózati forgalmat, hogy nagyon könnyen megszerezze őket. És ha ez nem elegendő, a bróker konfigurálható névtelen kapcsolatok elfogadására is, ami lehetővé tenné, hogy bármely felhasználó kommunikációt létesítsen, nagyobb kockázattal jár.

Az MQTT használata az Arduinóval

Természetesen lehet használja az MQTT protokollt az Arduinóval és más fejlesztői táblák, valamint a Rapsberry Pi stb. Ehhez biztosítani kell az Arduino táblának a csatlakozást, ha nincs. Továbbá, a könyvtár Arduino kliens az MQTT-hez ez segít ezekben a feladatokban. Ez a könyvtár kompatibilis a következőkkel:

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

Amint az MQTT használatához egyes alkalmazásokban az az igazság, hogy egyszerű. A Fritzing képen emléktábla látható Arduino UNO amelyhez a kapcsolatot az Arduino Ethernet adta, és azt is csatlakoztatták a DHT22 páratartalom és hőmérséklet érzékelőbár bármi más is lehetett volna ...

Ok, ezzel együtt azt a kódot kell generálni Arduino IDE Az Arduino MQTT protokolljával való együttműködés ilyen egyszerű:

• hogy üzeneteket küldeni 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);
}

• hogy üzeneteket fogadni az MQTT szerint csak a lemezre van szüksége Arduino UNO és kapcsolat, Arduino Ethernet vagy bármely más elem segítségével. Ami a kódot illeti, egy példa lenne:

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

További információkért letöltés ingyen Nuestro PDF kézikönyv az Arduino IDE tanfolyammal a programozás megkezdéséhez.