MQTT: адкрыты сеткавы пратакол і яго значэнне ў IoT

Запомніце імя MQTT, паколькі гэта пратакол сеткавай сувязі тыпу M2M (Machine to Machine), які будзе гучаць зусім няшмат. Ён становіцца даволі папулярным дзякуючы новай эры Інтэрнэту рэчаў альбо IoT (Internet of Things) за яго абрэвіятуру на англійскай мове. Акрамя таго, гэта адкрыты пратакол, які дае мноства пераваг.

На самай справе, гэта стала адным з цэнтральных слупоў Інтэрнэту рэчаў, так як гэта вельмі добра на прыладах з некаторымі абмежаваннямі перадачы, падобнымі гэтым. Скарачэнне MQTT паходзіць ад Чарга паведамленняў тэлеметрычнай транспарту, адкрыты стандарт OASIS і ISO (ISO / IEC 20922) для сеткавых камунікацый, які звычайна працуе на знакамітым TCP / IP.

Сеткавыя пратаколы

Л пратаколы сувязі Яны ўяўляюць сабой правілы, якія дазваляюць двум і больш прыладам ці сістэмам мець зносіны паміж сабой. Гэта значыць, што гэта пратакол перадачы інфармацыі рознымі спосабамі і ў вызначаным фармаце, рэалізаваным з дапамогай праграмнага і апаратнага забеспячэння (альбо абодвух).

El стандартны пратакола вызначае мноства характарыстык сувязі. Гэта можа ісці ад правілаў сінхранізацыі, семантыкі, сінтаксісу, фармату пакета і г.д. І праўда, яны нікчэмна малыя, бо дзякуючы гэтым пратаколам сёння мы можам карыстацца Інтэрнэтам і іншымі сеткамі сувязі ...

І, вядома, існуе не толькі адзін пратакол, але і мноства. Напрыклад, знакаміты DNS, FTP, MQTT, HTTP і HTTPS, IMAP, LDAP, NTP, DHCP, SSH, Telnet, SNMP, SMTP і г.д., для прыкладнога ўзроўню. У той час як у транспартным узроўні вы можаце знайсці такія вядомыя, як TCP, UDP і г.д., а таксама Інтэрнэт-узроўні, такія як IPv4 або IPv6 (той, які зрабіў магчымым найбольшую колькасць даступных IP-адрасоў і прыбыццё IoT), IPSec і г.д., і іншыя з узроўню сувязі, такія як DSL, Ethernet, WiFi, ARP і г.д.

Аб пратаколах IoT

Зразумела, ёсць канкрэтныя пратаколы сувязі альбо якія можна прымяніць да IoT. Гэта значыць, улічваючы папярэдні раздзел, яны ўяўляюць сабой шэраг вызначаных стандартаў, каб два і больш прылад IoT маглі ўзаемадзейнічаць і разумець адзін аднаго, і гэта звычайна M2M, гэта значыць сувязь машына-машына. шмат прылад IoT падключана і абменьваецца інфармацыяй з датчыкаў або іншых крыніц.

З-за вялікай колькасці прылад IoT гэтыя пратаколы павінны адпавядаць патрабаванням, якія выходзяць за межы прапускной здольнасці, хуткасці і г.д. (звярніце ўвагу, што многія прылады ўбудаваныя і танныя), што звычайна ёсць у некаторых прыладах. І я маю на ўвазе той факт, што павінна быць маштабуецца, каб мець магчымасць дадаваць больш падлучаных прылад пры неабходнасці і не ўплываючы на ​​глабальную сістэму.

Акрамя таго, яны павінны мець нізкая залежнасць сувязь паміж прыладамі, каб пры выдаленні прылады не ўзнікала праблем. І, вядома, у той жа час высокая сумяшчальнасць шукаецца, каб яна працавала з вялікай колькасцю прылад і вельмі разнастайнымі сістэмамі, паколькі свет IoT даволі неаднародны.

Іншымі карыснымі магчымасцямі будзе прастата іх рэалізацыі, бяспекаі г.д. Майце на ўвазе, што IoT стварае вялікія праблемы ў аспекце бяспекі. Тым больш, калі ў некаторых выпадках многія з падлучаных прылад звычайна крытычныя ... напрыклад, цацкі для непаўналетніх.

Важныя паняцці

Пры гэтым трэба сказаць, што рашэнні для IoT выкарыстоўваюць цэнтралізаваны сервер для атрымання паведамленняў ад усіх падлучаных прылад, якія выпраменьваюць і распаўсюджваюць іх на ўсіх падлучаных прыладах IoT, якія праслухоўваюць. Гэты сервер - гэта тое, што вядома маршрутызатар або брокер. Нешта, што ў нейкім сэнсе далёка ад звычайных адносін кліент-сервер.

Акрамя таго, метадалогіі якія вы можаце знайсці ў гэтых пратаколах сувязі для IoT:

• PubSub: Publish / Susbcribe - гэта шаблон абмену паведамленнямі, пры якім прылада (Sub) паведамляе брокеру, што хоча атрымаць паведамленне, у той час як іншае прылада (Pub) публікуе паведамленні для брокера для распаўсюджвання на іншыя прылады, якія чакаюць іх.
• rRPC: Званкі працэдуры перабудовы маршрутызатара - яшчэ адна мадэль аддаленага выканання працэсу. У ім прылада (Callee) паведамляе брокеру, што ён выканае пэўную працэдуру, і брокер распаўсюджвае яго на іншае прылада (абанент), на якім згаданы працэс выконваецца.

Цяпер, каб выканаць гэтыя метадалогіі ці заканамернасці, а інфраструктура абмену паведамленнямі. І ў гэтым сэнсе можна вылучыць два:

• Чарга паведамленняў: служба абмену паведамленнямі, дзе для ўсіх кліентаў, якія ініцыююць падпіску на брокера, ствараецца адзіная чарга паведамленняў. Апошнія будуць захоўваць паведамленні, якія захоўваюцца, пакуль яны не будуць дастаўлены кліенту. Калі кліент або атрымальнік не падлучаны, ён падтрымліваецца да падключэння. Гэтыя тыпы паслуг падобныя на тыя, якія выкарыстоўваюцца ў праграмах імгненных паведамленняў, такіх як Telegra, WhatsApp, Messenger і г.д.
• Служба паведамленняў: гэта яшчэ адна паслуга, пры якой брокер адпраўляе паведамленні падлучанаму кліенту-атрымальніку, фільтруючы па тыпу паведамлення. Калі кліент або прымальная прылада адключаны, паведамленні губляюцца (хаця ў яго можа быць нейкая сістэма рэгістрацыі).

Пратаколы IoT

Убачыўшы вышэйсказанае, зараз прыгледзімся бліжэй Пратаколы IoT якія больш вядомыя. Сярод найбольш вядомых M2M:

• AMQP (пашыраны пратакол чаргі паведамленняў): гэта пратакол тыпу PubSub у чарзе паведамленняў. Распрацаваны для добрай сумяшчальнасці і забеспячэння надзейнасці. Асабліва для карпаратыўных прыкладанняў, высокай прадукцыйнасці, сетак з вялікай затрымкай, крытычных і г.д.
• WAMP (пратакол абмену паведамленнямі вэб-прыкладанняў): гэта яшчэ адзін адкрыты пратакол тыпу PubSub, напрыклад rRPC, і ён працуе на WebSockets.
• CoAP (абмежаваны пратакол прымянення): гэта пратакол, спецыяльна распрацаваны для прыкладанняў малой ёмістасці.
• TOMP (пратакол абмену тэкставымі паведамленнямі): вельмі просты пратакол і для дасягнення максімальнай сумяшчальнасці. HTTP выкарыстоўваецца для перадачы тэкставых паведамленняў.
• XMPP (пашыраны пратакол абмену паведамленнямі і прысутнасцю): яшчэ адзін пратакол, які выкарыстоўваецца ў IoT для прыкладанняў імгненных паведамленняў і заснаваны на XML. Ян гэтая справа таксама адкрытая.
• WMQ (чарга паведамленняў WebSphere): пратакол, распрацаваны IBM. Як вынікае з яго назвы, ён мае тып "Чарга паведамленняў" і арыентаваны на паведамленні.
• MQTT: (гл. наступны раздзел)

Усё пра MQTT

El Пратакол MQTT Гэта пратакол сувязі ў чарзе паведамленняў, які ідзе па шаблоне PubSub і тыпу M2M, як я ўжо згадваў. Ён шырока выкарыстоўваецца ў IoT і заснаваны на стэку TCP / IP, які выкарыстоўваецца ў Інтэрнэце.

У выпадку MQTT, кожнае злучэнне застаецца адкрытым і ён выкарыстоўваецца паўторна ў любой неабходнай камунікацыі. Штосьці іншае, чым тое, што адбываецца ў іншых вядомых пратаколах, - гэта тое, што кожная сувязь мае патрэбу ў новай сувязі.

Перавага

Перавагі пратакола MQTT цалкам відавочныя з пункту гледжання сувязі M2M для IoT. У дадатак да ўсяго сказанага вышэй, гэта пратакол, які прадугледжвае:

• Маштабаванасць, каб падключыць усё больш і больш кліентаў.
• Раз'яднанне паміж кліентамі для меншай залежнасці.
• Асінхранізм.
• Прастата.
• Лёгкасць, каб не спажываць занадта шмат рэсурсаў (хаця з бяспекай TLS / SSL гэта павялічваецца).
• Энергазберагальны для прылад, якія залежаць ад батарэі або працуюць кругласутачна, без патрэбы ў вялікай прапускной здольнасці (ідэальна падыходзіць для павольных злучэнняў, як некаторыя бесправадныя).
• Бяспека і якасць для большай надзейнасці і надзейнасці сувязі.

Гісторыя

MQTT быў створаны ў 90-х гадах з ранняй версіяй пратакол у 1999 годзе. Яго стварылі доктар Эндзі Стэнфард-Кларк з IBM і Арлен Ніппер з Cirrus Link (былая кампанія Eurotech).

La пачатковая ідэя заключалася ў стварэнні пратакола для маніторынгу трубаправода, які праходзіў праз пустыню, з эфектыўным пратаколам сувязі (нізкае спажыванне прапускной здольнасці), святлом і нізкім спажываннем энергіі. У той час гэта было вельмі дорага, але цяпер гэта стала танным і адкрытым пратаколам.

Першапачатковы пратакол быў удасканалены са з'яўленнем новыя версіі, такія як MQTT v3.1 (2013) у адпаведнасці са спецыфікацыяй OASIS (Арганізацыя па ўдасканаленні стандартных інфармацыйных стандартаў) і г.д. Вы павінны ведаць, што напачатку гэта быў уласны пратакол ад IBM, але ён выйдзе ў 2010 годзе, і ў выніку ён стане стандартам у OASIS ...

Як працуе злучэнне MQTT

Пратакол MQTT выкарыстоўвае фільтр, для паведамленняў, якія адпраўляюцца кожнаму кліенту на аснове тэм або тэм, якія арганізаваны іерархічна. Такім чынам, кліент можа размясціць паведамленне на пэўную тэму. Такім чынам, усе тыя кліенты або падлучаныя прылады, якія падпісаліся на тэму, будуць атрымліваць паведамленні праз брокера.

Як і MQ, паведамленні застануцца ў чарзе і яны не губляюцца, пакуль кліент не атрымае гэтага паведамлення.

Злучэнні, як я таксама адзначыў, устаноўлены праз TCP / IP, а сервер або брокер будзе весці ўлік падлучаных кліентаў. Па змаўчанні прылады будуць выкарыстоўваць парты сувязі 1883, хаця вы таксама можаце знайсці порт 8883, калі вы выкарыстоўваеце SSL / TLS для дадатковай бяспекі.

Каб злучэнне стала магчымым, патрэбныя не толькі кліенты, серверы і парты. Таксама іншыя адпраўленыя пакеты альбо паведамленні для сувязі:

• Усталюйце сувязь: Паведамленне / пакет CONNECT, адпраўлены кліентам, з усёй неабходнай інфармацыяй. Гэтая інфармацыя ўключае ідэнтыфікатар кліента, імя карыстальніка, пароль і г.д. Брокер або сервер адказвае пакетам CONNACK, які паведаміць кліенту аб тым, што злучэнне прынята, адхілена і г.д.
• Адпраўка і прыём паведамленняў: пасля ўстанаўлення злучэння для публікацыі пакетаў альбо паведамленняў выкарыстоўваецца тэма і карысная нагрузка паведамлення, адпраўленага брокеру. З іншага боку, зацікаўлены кліент альбо кліенты выкарыстоўваюць пакеты SUBSCRIBE і UNSUSCRIBE, каб падпісацца альбо зняць падпіску адпаведна. Брокер таксама адкажа пакетам SUBACK і UNSUBACK, каб паведаміць пра паспяховасць аперацыі, запытанай кліентам.
• Падтрыманне сувязі: каб гарантаваць, што злучэнне застаецца адкрытым, кліенты могуць перыядычна адпраўляць пакет PINGREQ, які будзе супадаць з пакетам PINGRESP з сервера.
• Канец злучэння: калі кліент адключаецца, ён адпраўляе пакет DISCONNECT, каб паведаміць пра гэтую падзею.

Тыя паведамленні або пакеты Тыя, пра якія я ўжо казаў, маюць структуру, аналагічную іншым пакетам іншых сеткавых пратаколаў:

• Загаловак альбо фіксаваны загаловак: з'яўляецца фіксаванай часткай, якая займае ад 2-5 байт. Ён змяшчае кантрольны код, ідэнтыфікатар тыпу адпраўленага паведамлення і яго даўжыню. Для кадавання даўжыні выкарыстоўваецца ад 1 да 4 байтаў, выкарыстоўваючы першыя 7 бітаў кожнага актэта ў якасці дадзеных аб даўжыні і дадатковы біт бесперапыннасці, каб вызначыць, што больш чым адзін байт складае даўжыню паведамлення.
• Зменны загаловак: не заўсёды з'яўляецца абавязковым, але неабавязковым. Ён змяшчаецца толькі ў некаторых пакетах у пэўных сітуацыях альбо ў пэўных паведамленнях.
• Змест альбо дадзеныя: пакетныя дадзеныя - гэта тое, што на самой справе ўтрымлівае паведамленне, якое трэба адправіць. Гэта можа быць ад некалькіх кБ да 256 МБ.

Калі вам цікава даведацца адпаведны код у шаснаццатковым выглядзе для тыпаў адпраўленых паведамленняў:

Якасць і бяспека сувязі

Яшчэ адна важная дэталь паведамленняў MQTT - якасць абслугоўвання альбо QoSі бяспека. Ад гэтага будзе залежаць надзейнасць сістэмы сувязі ў выпадку збояў і яе бяспека.

Адносна яго якасці яго можна вызначыць 3 розных узроўняў:

• QoS 0 (невядома)- Паведамленне адпраўляецца толькі адзін раз, і ў выпадку збою яно не будзе дастаўлена. Ён выкарыстоўваецца, калі гэта не крытычна.
• QoS 1 (пацвердзіць): паведамленне будзе адпраўлена столькі разоў, колькі неабходна, каб гарантаваць дастаўку кліенту. Недахопам з'яўляецца тое, што кліент мог атрымліваць адно і тое ж паведамленне некалькі разоў.
• QoS 2 (гарантавана)- Падобна вышэй, але гарантавана дастаўляецца толькі адзін раз. Ён часта выкарыстоўваецца для больш важных сістэм, дзе неабходна большая надзейнасць.

З іншага боку, што тычыцца Бяспека MQTT, могуць быць выкарыстаны розныя меры для забеспячэння яго трываласці ў гэтым плане. Як я ўжо згадваў раней, аўтэнтыфікацыя імя карыстальніка і пароля, як і многіх іншых пратаколаў, можа быць забяспечана з дапамогай SSL / TLS. Хаця ў многіх прылад IoT з невялікай ёмістасцю альбо рэсурсамі могуць узнікнуць праблемы з перагрузкай працы пры выкарыстанні гэтага тыпу бяспечнай сувязі ...

Па гэтай прычыне многія прылады IoT, якія выкарыстоўваюць MQTT, выкарыстоўваюць паролі і карыстальнікаў у тэкст плоскасці, што можа прымусіць кагосьці нюхаць сеткавы трафік, каб атрымаць яго вельмі лёгка. І калі гэтага недастаткова, брокер таксама можа быць настроены прымаць ананімныя злучэння, якія дазваляюць любому карыстальніку наладжваць сувязь, звязаную з большай рызыкай.

Выкарыстанне MQTT з Arduino

Вядома, можна выкарыстоўваць пратакол MQTT з Arduino і іншыя дошкі распрацоўкі, а таксама Rapsberry Pi і г.д. Для гэтага неабходна забяспечыць плату Arduino магчымасцю падключэння, калі яна адсутнічае. Таксама бібліятэка Кліент Arduino для MQTT гэта дапаможа вам у гэтых задачах. Гэтая бібліятэка сумяшчальная з:

• ArduinoYUN
• Ардуіна Wi-Fi (шчыт)
• Arduino Ethernet (шчыт)
• Модуль ESP8266
• Intel Galileo / Edison
• Raspberry Pi
• ...

Як толькі да кода, каб выкарыстоўваць MQTT у некаторых прыкладаннях праўда ў тым, што гэта проста. На малюнку Fritzing вы можаце ўбачыць налёт Arduino UNO да якіх дададзена сувязь з дапамогай Arduino Ethernet, і яна таксама была падлучана датчык вільготнасці і тэмпературы DHT22, хаця магло быць і іншае ...

Добра, з улікам сказанага, для кода, які вы павінны стварыць Ардуіна IDE Працаваць з пратаколам MQTT на Arduino так проста:

• да адпраўляць паведамленні 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);
}

• да атрымліваць паведамленні па MQTT вам патрэбна толькі таблічка Arduino UNO і сувязь з Arduino Ethernet альбо любым іншым элементам. Што тычыцца кода, прыкладам можа быць:

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

Для атрымання дадатковай інфармацыі вы можаце спампаваць бясплатна нашы PDF кіраўніцтва з курсам IDE Arduino, каб пачаць праграмаваць.