Kiedy i dlaczego korzystać z protokołu MQTT?


34

Opracowuję urządzenie do pomiaru temperatury, wilgotności i masy. Obecnie używa HTTPS do przesyłania danych na zdalny serwer. Teraz wiem, że istnieje protokół o nazwie MQTT, który jest uważany za „protokół Internetu rzeczy”.

W jakim przypadku i dlaczego powinienem przejść z HTTPS na MQTT?

Odpowiedzi:


32

MQTT to „komunikator” między urządzeniami:

  • urządzenie mierzy w czasie T temperaturę X stopni
  • łączy się (samo lub za pośrednictwem koncentratora zwave) z brokerem MQTT
  • tworzy wiadomość z tematem /domotics/myplace/mydevice/temperature
  • w wiadomości, którą po prostu umieszcza X(jako „ładunek”)

Gdzie indziej w twoim domu:

  • twój Raspberry Pi jest podłączony do brokera MQTT (może to być sama instancja MQTT)
  • subskrybuje ten temat, /domotics/+/+/temperatureaby otrzymywać WSZYSTKIE informacje o temperaturze ze wszystkich urządzeń korzystających z tego formatu tematu. Zobacz specyfikację MQTT, aby uzyskać więcej informacji na temat symboli wieloznacznych MQTT ( +i #).
  • otrzyma wiadomość z ładunkiem Xi zrobi co chce!

Gdzie indziej w twoim domu:

  • Twój komputer jest podłączony do brokera MQTT i subskrybuje ten temat, /domotics/myplace/mydevice/#aby uzyskać WSZYSTKIE informacje z urządzenia i zalogować je
  • otrzyma wiadomość z ładunkiem Xi zrobi co chce!

MQTT jest bardzo przydatny, aby uniknąć umieszczania usług i gniazd sieciowych wokół serwerów. Node-RED używa MQTT, a Domoticz można skonfigurować do pobierania ini ustawiania outsygnałów.

Osobiście używam MQTT w moim domu do wyłączania komputerów: /house/computers/mycomputerładunek:0


Dobrze, że nie muszę zawracać sobie głowy gniazdami i innymi usługami internetowymi.
Bence Kaulics,

Czy możesz skomentować aspekty bezpieczeństwa? Czy tekst jest zwykły?
Mawg

1
Inna odpowiedź mówi, że MQTT obsługuje TLS; iot.stackexchange.com/a/69/39
Goufalite,

20

MQ Telemetry Transport Protocol znany jako MQTT jest przeznaczony dla urządzeń, które pracują na małej mocy i niskiej przepustowości. Jest to lekki protokół przesyłania / publikowania, który oznacza, że ​​każde inne urządzenie może subskrybować określony temat.

HTTP / HTTPS został zaprojektowany jako protokół żądanie-odpowiedź dla obliczeń klient-serwer, który nigdy nie zawraca sobie głowy zużyciem energii i ma duże obciążenie danych.

Użyj MQTT, jeśli:

  • Urządzenie, którego używasz, działa na ogniwie bateryjnym i nie chcesz go wymieniać co x liczba dni (MQTT jest zoptymalizowany pod kątem zużycia baterii, podczas gdy HTTP / S nie jest)
  • Potrzebujesz szybszej odpowiedzi
  • Potrzebujesz mechanizmu pub / sub (jeśli chcesz przekazywać wiadomości do wielu klientów)
  • Konieczność niezawodnego przesyłania danych przy różnych poziomach QoS

Czy MQTT oferuje tyle samo bezpieczeństwa co HTTPS?

MQTT korzysta z protokołu TCP jako protokołu transportowego, co oznacza, że ​​domyślnie połączenie nie korzysta z szyfrowanej komunikacji. Aby zaszyfrować całą komunikację MQTT, większość brokerów MQTT - takich jak HiveMQ - pozwala na użycie TLS zamiast zwykłego TCP.

Ref: HiveMQ


1
Czy MQTT oferuje tyle samo bezpieczeństwa co HTTPS?
Bence Kaulics,

2
Może korzystać z SSL / TLS, więc powinien być tak bezpieczny jak HTTPS.
Ghanima,

1
Dokładnie jak powiedział @Ghanima, zaktualizowałem odpowiedź w artykule referencyjnym, aby sprawdzić, co mówi o zabezpieczeniu MQTT.
bravokeyl,

11

Wydaje się, że MQTT (telemetria transportu w kolejce wiadomości) dobrze nadaje się do proponowanej aplikacji.

Jest lekki zarówno pod względem przepustowości (najmniejszy rozmiar pakietu z nagłówkiem zaledwie 2 bajtów), jak i śladu kodu klienta (dzięki czemu może działać na cienkich klientach, takich jak ESP8266, typowy klient IoT). Zmniejszone przesyłane dane są korzystne dla dłuższej żywotności baterii dla klientów korzystających z sieci poza siecią, takich jak czujniki.

MQTT oferuje również proste metody ( czasowniki ), które dobrze pasują do zadań IoT, takie jak trwałe subskrypcje, które odzyskują połączenia po nieoczekiwanym rozłączeniu klienta. W porównaniu do HTTP / HTTPS łatwiej jest również wyodrębnić dane z pakietu (nie jest potrzebny analizator składni).


5

Tutaj napisałem artykuł, który pokazuje i ewolucję systemu komunikacji, którą mieliśmy w naszym projekcie. Chodzi o mikrousługi, ale można uznać dowolny czujnik za mikrousługę, której zadaniem jest gromadzenie i publikowanie wszelkiego rodzaju danych telemetrycznych.

Dlatego najważniejszym wnioskiem jest to, że lepiej jest użyć MQTT, gdy trzeba gdzieś wysłać wydarzenie i nic nie wiadomo o odbiorcy. I znacznie lepiej jest używać HTTP (zwykle REST), jeśli wiesz coś o odbiorcy i potrzebujesz odpowiedzi - np. W przypadku komend z jakiegokolwiek innego powodu.

Z punktu widzenia ruchu, procesora, pamięci i zużycia energii MQTT i HTTP są w zasadzie takie same.


2

Jeśli chodzi o twoją wycenę, MQTT jest „protokołem Internetu rzeczy”:

Tak, istnieje duża liczba programistów używających tego protokołu (patrz IoT Developer Survey 2018), ale CoAP (jest dostosowany do IoT HTTP na podstawie UDP) stanowi alternatywę dla HTTP w przypadku, gdy chcesz użyć lekkiej funkcji Request / Response w Twoje zgłoszenie.

Z drugiej strony MQTT zapewnia wbudowaną logikę publikowania / subskrybowania, co czyni go doskonałym do skalowania (można użyć większej liczby bram dla większej liczby urządzeń). Istnieje również alternatywa UDP (jak CoAP na HTTP), która nazywa się MQTT-SN (MQTT dla sieci czujników). Zapewnia to nawet mniejszy narzut niż CoAP, ale nie wykorzystuje R / R.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.