Запомни името MQTT, тъй като това е протокол за мрежова комуникация тип M2M (Machine to Machine), който ще звучи доста. Той става доста популярен благодарение на новата ера на Интернет на нещата или IoT (Internet of Things) за неговото съкращение на английски език. В допълнение, това е отворен протокол, който дава много предимства.
Всъщност той се превърна в един от централните стълбове на IoT, тъй като е доста добър за устройства с някои ограничения на предаването като тези. Съкращението 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 устройства да могат да комуникират и да се разбират помежду си, и те обикновено са M2M, т.е. комуникация между машини. много IoT устройства са свързани и споделят информация от сензори или други източници.
Поради големия брой IoT устройства, тези протоколи трябва да отговарят на изисквания извън ограниченията на честотната лента, скоростта и т.н. (имайте предвид, че много устройства са вградени и евтини), което обикновено е в някои устройства. И имам предвид факта, че трябва да е мащабируема, за да можете да добавяте още свързани устройства, ако е необходимо и без да се засяга глобалната система.
Освен това те трябва да имат ниска зависимост свързване между устройства, така че да не се генерират проблеми, ако дадено устройство бъде премахнато. И разбира се, в същото време се търси висока оперативна съвместимост, така че да работи с голям брой устройства и много разнообразни системи, тъй като светът на IoT е доста разнороден.
Други полезни функции биха били лекотата на изпълнението им, сигурносттаи т.н. Имайте предвид, че IoT създава големи предизвикателства в аспекта на сигурността. Още повече, когато много от свързаните устройства обикновено са критични в определени случаи ... например играчки за непълнолетни.
Важни понятия
Въпреки това трябва да се каже, че решенията за IoT използват централизиран сървър, за да получават съобщенията от всички свързани устройства, които излъчват и ги разпространяват до всички свързани IoT устройства, които слушат. Този сървър е това, което е известно като рутер или брокер. Нещо, което е далеч от конвенционалната връзка клиент-сървър в някои отношения.
Освен това, методологиите които можете да намерите в тези комуникационни протоколи за IoT са:
- PubSub: Publish / Susbcribe е модел за съобщения, при който устройство (Sub) информира брокера, че иска да получи съобщение, докато друго устройство (Pub) публикува съобщения, които брокерът да разпространява на другите устройства, които ги чакат.
- rRPC: Процедурни повиквания за преустройство на рутер е друг модел на дистанционно изпълнение на процес. В него устройство (Callee) информира брокера, че ще извърши определена процедура и брокерът го разпределя на друго устройство (Caller), на което се изпълнява споменатият процес.
Сега, за да извършите тези методологии или модели, a инфраструктура за съобщения. И в този смисъл могат да се разграничат две:
- Опашка за съобщения: услуга за съобщения, при която се генерира една опашка от съобщения за всички клиенти, които инициират абонамент за брокера. Последният ще съхранява съобщенията, съхранявани, докато не бъдат доставени на клиента. Ако клиентът или получателят не са свързани, те се поддържат, докато не бъдат свързани. Тези видове услуги са като тези, използвани в приложения за незабавни съобщения като Telegra, WhatsApp, Messenger и т.н.
- Услуга за съобщения: това е друга услуга, при която брокерът изпраща съобщенията до свързания клиент-получател, филтрирайки по вида на съобщението. Ако клиентът или приемащото устройство са прекъснати, съобщенията се губят (въпреки че може да има някаква система за регистриране).
IoT протоколи
След като видяхме горното, сега нека разгледаме по-отблизо IoT протоколи които са по-известни. Сред най-изявените от M2M са:
- AMQP (Разширен протокол за опашка на съобщения): е протокол от тип PubSub на опашката за съобщения. Проектиран да има добра оперативна съвместимост и да гарантира надеждност. Специално за корпоративни приложения, висока производителност, мрежи с голяма латентност, критични и др.
- WAMP (протокол за съобщения в уеб приложения): е друг отворен протокол от тип PubSub като rRPC и работи на WebSockets.
- CoAP (протокол с ограничено приложение): е протокол, специално разработен за приложения с малък капацитет.
- TOMP (протокол за текстово ориентирано съобщение): много опростен протокол и за постигане на максимална оперативна съвместимост. HTTP се използва за предаване на текстови съобщения.
- XMPP (разширяем протокол за съобщения и присъствие): друг протокол, използван в IoT за приложения за незабавни съобщения и базиран на XML. Ян това дело също е открито.
- WMQ (опашка за съобщения WebSphere): протокол, разработен от IBM. Той е от типа Queue Message, както подсказва името му, и е ориентиран към съобщенията.
- MQTT: (вижте следващия раздел)
Всичко за MQTT
El MQTT протокол Това е комуникационен протокол за опашка на съобщения, който следва PubSub модел и от типа M2M, както вече споменах. Той се използва широко в IoT и се основава на TCP / IP стека, използван в Интернет.
В случая на MQTT, всяка връзка се поддържа отворена и се използва повторно във всяка необходима комуникация. Нещо различно от това, което се случва в други известни протоколи, че всяко осъществяване на комуникация изисква нова връзка.
Предимство
Предимствата на протокола MQTT са очевидни по отношение на M2M комуникациите за IoT. В допълнение към всичко казано по-горе, това е протокол, който осигурява:
- Мащабируемост, за да свързвате все повече и повече клиенти.
- Отделяне между клиенти, за по-малко зависимост.
- Асинхронност.
- Простота.
- Лекота, за да не се консумират твърде много ресурси (въпреки че с TLS / SSL сигурност тя се покачва).
- Енергийно ефективен за устройства, които зависят от батерията или работят 24/7, не се нуждае от голяма честотна лента (идеално за бавни връзки, като например някои безжични).
- Сигурност и качество, за по-голяма надеждност и стабилност в комуникациите.
история
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, който ще информира клиента, че връзката е приета, отхвърлена и т.н.
- Изпращайте и получавайте съобщения: след като се установи връзката, се използват PUBLISH пакети или съобщения с темата и полезния товар на съобщението, изпратено до брокера. От друга страна, заинтересованият клиент или клиенти използват пакети SUBSCRIBE и UNSUSCRIBE, за да се абонират или да оттеглят абонамента си съответно. Брокерът ще отговори също с пакети SUBACK и UNSUBACK, за да докладва успеха на операцията, поискана от клиента.
- Поддържане на връзката: за да се гарантира, че връзката остава отворена, клиентите могат периодично да изпращат пакет PINGREQ, който ще бъде съчетан с пакет PINGRESP от сървъра.
- Крайна връзка: когато клиент прекъсне връзката си, той изпраща пакет DISCONNECT, за да докладва за това събитие.
Тези съобщения или пакети Тези, за които говорих, имат структура, същата като другите пакети на други мрежови протоколи:
- Хедър или фиксиран хедър: е фиксирана част, която заема между 2-5 байта. Той съдържа контролен код, ID на вида на изпратеното съобщение и неговата дължина. За кодиране на дължината се използват между 1-4 байта, като се използват първите 7 бита от всеки октет като данни за дължината и допълнителен бит непрекъснатост, за да се определи, че има повече от един байт, който съставлява дължината на съобщението.
- Променлива заглавка: не винаги е задължително, но по избор. Той се съдържа само в някои пакети в определени ситуации или специфични съобщения.
- Съдържание или данни: пакетните данни са това, което всъщност съдържа съобщението за изпращане. Тя може да бъде от няколко kB до 256 MB ограничение.
Ако се интересувате да знаете съответният код в шестнадесетичен знак за видовете изпратени съобщения са:
съобщение | Код |
---|---|
СОЦИАЛНИ ВРЪЗКИ | 0x10 |
СВЪРЗВАНЕ | 0x20 |
ПУБЛИКУВАНЕ | 0x30 |
ПАКЕТ | 0x40 |
pubrec | 0x50 |
ПУБРЕЛ | 0x60 |
pubcomp | 0x70 |
АБОНИРАЙТЕ СЕ | 0x80 |
СУБАК | 0x90 |
НЕОБМЕЗАТЕЛНО | 0xA0 |
ОТКЛОНЯВАНЕ | 0xB0 |
PINGREQ | 0xC = |
PINGRESP | 0xD0 |
Изключете | 0xE0 |
Качество и сигурност на комуникациите
Друга важна подробност за съобщенията от 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 ръководство с курса Arduino IDE за започване на програмиране.