MQTT: відкритий мережевий протокол та його значення в IoT

Запам'ятай ім'я MQTT, оскільки це протокол мережевого зв'язку типу M2M (Machine to Machine), який буде звучати зовсім небагато. Він стає досить популярним завдяки новій ері Інтернету речей або IoT (Internet of Things) за його скорочення англійською мовою. Крім того, це відкритий протокол, який дає безліч переваг.

Насправді, це стало одним із центральних стовпів IoT, оскільки непогано працює на пристроях з деякими обмеженнями передачі, подібними до цих. Скорочення MQTT походить від Телеметричний транспорт, відкритий стандарт OASIS та ISO (ISO / IEC 20922) для мережевих комунікацій, який, як правило, працює на знаменитому TCP / IP.

Мережеві протоколи

L протоколи зв'язку Вони є правилами, які дозволяють комунікації між собою двох або більше пристроїв або систем. Тобто це протокол для передачі інформації різними способами та у визначеному форматі, незалежно від того, реалізований програмним чи апаратним забезпеченням (або тим і іншим).

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 досить неоднорідний.

Іншими корисними функціями буде простота їх реалізації, la seguridadтощо Майте на увазі, що IoT створює великі виклики в аспекті безпеки. Навіть більше, коли багато з підключених пристроїв, як правило, критичні в певних випадках ... наприклад, іграшки для неповнолітніх.

Важливі поняття

При цьому слід сказати, що рішення для IoT використовують централізований сервер для отримання повідомлень від усіх підключених пристроїв, які випромінюють та розподіляють їх між усіма підключеними пристроями IoT, які слухають. Цей сервер - це те, що відоме як маршрутизатор або брокер. Щось, що в чомусь далеке від звичайних відносин клієнт-сервер.

Крім того, методології що ви можете знайти в цих протоколах зв'язку для IoT:

• PubSub: Publish / Susbcribe - це шаблон обміну повідомленнями, коли пристрій (Sub) повідомляє брокеру, що хоче отримати повідомлення, тоді як інший пристрій (Pub) публікує повідомлення, які брокер має розповсюджувати на інші пристрої, які очікують їх.
• rRPC: Процедура виклику процедур переробки маршрутизатора - ще одна модель віддаленого виконання процесу. У ньому пристрій (Callee) повідомляє брокеру, що він виконає певну процедуру, і брокер розподіляє його на інший пристрій (Caller), на якому згаданий процес виконується.

Тепер, щоб виконати ці методології або схеми, a інфраструктура обміну повідомленнями. І в цьому сенсі можна виділити два:

• Черга повідомлень: служба обміну повідомленнями, де генерується одна черга повідомлень для всіх клієнтів, які ініціюють підписку на брокера. Останній зберігатиме повідомлення, що зберігаються, доки вони не будуть доставлені клієнту. Якщо клієнт або одержувач не підключені, вони зберігаються до з’єднання. Ці типи послуг схожі на послуги, що використовуються в програмах обміну миттєвими повідомленнями, таких як Telegra, WhatsApp, Messenger тощо.
• Служба повідомлень: це ще одна послуга, в якій брокер надсилає повідомлення підключеному клієнту-одержувачу, фільтруючи за типом повідомлення. Якщо клієнт або пристрій відключено, повідомлення втрачаються (хоча він може мати якусь систему реєстрації).

Протоколи IoT

Побачивши вищесказане, тепер давайте розглянемо уважніше Протоколи IoT які більш відомі. Серед найбільш відомих з М2М:

• AMQP (розширений протокол черги повідомлень): є протоколом PubSub типу черги повідомлень. Розроблений для забезпечення хорошої сумісності та забезпечення надійності. Особливо для корпоративних програм, високої продуктивності, мереж із великою затримкою, критичних тощо.
• WAMP (протокол обміну повідомленнями веб-додатків): це ще один відкритий протокол типу PubSub, такий як rRPC, і він працює на WebSockets.
• CoAP (Протокол обмежених додатків): це протокол, спеціально розроблений для додатків низької ємності.
• TOMP (протокол обміну текстовими повідомленнями): дуже простий протокол і для досягнення максимальної сумісності. HTTP використовується для передачі текстових повідомлень.
• XMPP (розширюваний протокол обміну повідомленнями та присутності): ще один протокол, який використовується в IoT для програм обміну миттєвими повідомленнями і базується на XML. Ян ця справа також відкрита.
• WMQ (черга повідомлень WebSphere): протокол, розроблений IBM. Це тип черги повідомлень, як випливає з назви, і орієнтований на повідомлення.
• MQTT: (див. наступний розділ)

Все про MQTT

El Протокол MQTT Це протокол зв'язку черги повідомлень, який слідує за шаблоном PubSub і типу M2M, як я вже згадував. Він широко використовується в Інтернеті речей і базується на стеці 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.

Щоб з'єднання було можливим, потрібні не тільки клієнти, сервери та порти. Також інші відправлені пакунки або повідомлення для спілкування:

• Встановіть зв’язок: ЗВ'ЯЗАТИ повідомлення / пакет, надіслані клієнтом, з усією необхідною інформацією. Ця інформація включає ідентифікатор клієнта, ім’я користувача, пароль тощо. Брокер або сервер відповідає пакетом 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
• Arduino WiFi (щит)
• Arduino Ethernet (щит)
• Модуль ESP8266
• Intel Galileo / Edison
• Raspberry Pi
• ...

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

Гаразд, з урахуванням цього, для коду, який ви повинні генерувати Arduino 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();
}

Для отримання додаткової інформації ви можете завантажити безкоштовно Nuestro Посібник у форматі PDF з курсом IDE Arduino для початку програмування.