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:
MQTT to „komunikator” między urządzeniami:
/domotics/myplace/mydevice/temperatureX(jako „ładunek”)Gdzie indziej w twoim domu:
/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 #).Xi zrobi co chce!Gdzie indziej w twoim domu:
/domotics/myplace/mydevice/#aby uzyskać WSZYSTKIE informacje z urządzenia i zalogować jeXi 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
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:
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
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).
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.
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.