MQTT (Message Queuing Telemetry Transport) w języku ludzkim oznacza transport telemetrii kolejkowania wiadomości. Kilka lat temu, kiedy po stronie komputerów PC dominowało wielu inżynierów, po prostu nie słyszało się okrężnego określenia, ale wraz ze stopniowym rozwojem technologii Internetu Rzeczy (IoT), protokół ten pojawia się coraz częściej w oczach głównych inżynierów. Spowodowało to, że wielu inżynierów zna tylko nazwę, ale nie znaczenie, a wiele osób nawet myślało, że jest to rodzaj protokołu opracowanego wraz z rozwojem IoT. Tak naprawdę protokół MQTT został wynaleziony ponad 20 lat temu, a w 1999 roku Andy Stanford Clark z IBM i Alan Nippe z Cirrus Link napisali pierwszą wersję protokołu. Od tego czasu protokół został ujednolicony na szczeblu międzynarodowym jako protokół przesyłania komunikatów oparty na publikacji/subskrypcji- zgodnie z normą ISO (ISO/IEC PRF 20922). W 2013 r. IBM przedłożył specyfikację MQTT w wersji 3.1 organizacji Structured Information Standards Facilitation Organisation wraz ze statutem zapewniającym możliwość wprowadzenia jedynie niewielkiej liczby zmian w specyfikacji i od tego czasu protokół MQTT jest używany od tego czasu w wielu niszach. Po sfinalizowaniu infrastruktury technicznej IoT ten starożytny protokół zaczął przeżywać swoją pierwszą wiosnę.
Warstwy transportowe i aplikacyjne sieci
Jak wszyscy wiemy, dotychczasowy szybki rozwój Internetu Rzeczy nie może opuścić infrastruktury sieci komunikacyjnych, obecnie można sterować dowolnym zakątkiem świata w domu za pomocą włącznika światła w pomieszczeniu, czy też wykonywać sterowanie przemysłowe, można także zdalnie sterować ruchem robota, dojrzałość tej technologii opiera się na komunikacji sieciowej jako podstawie. Główną technologią obecnie stosowanej technologii sieciowej jest siedmio-model OSI. Rzeczywista aplikacja faktycznie korzysta z czterowarstwowego modelu sieci-TCP/IP.
Czterowarstwowy model sieci-TCP/IP Trzecia warstwa transportowa to słynny protokół TCP/IP. Głównym celem tej warstwy protokołu jest wysyłanie komputera w sieciowej transmisji danych komunikacyjnych na określony adres IP drugiej maszyny powyżej, na przykład adres IP „192.168.137.19”. Na przykład, jeśli maszyna z adresem IP „192.168.137.19” chce wysłać 16-bajtowy pakiet binarny do maszyny o adresie IP „192.168.137.10”, wówczas istnieje możliwość jego przesłania za pomocą protokołu TCP/IP. Zamiast tego, przesyłając dane za pomocą protokołu TCP, powszechnie używamy gniazd.
Ale kiedy adres IP maszyny „192.168.137.19” ma wysłać dane do maszyny „192.168.137.10”, ten pakiet pakietów TCP wewnątrz danych w rzeczywistości odpowiada znaczeniu adresu IP odbiorcy maszyny „192.168.137.10”, jak analizować ten pakiet danych, problem ten pozostawia się warstwie transportowej powyżej warstwy protokoły do rozwiązania, czyli protokoły warstwy aplikacji. Oczywiście jeśli Twoje protokoły nie chcą dawać rozdzielczości zwykłej sieci komputerów, możesz też przejść do opracowania własnych protokołów warstwy aplikacji, nie ma to znaczenia, celem warstwy transportowej jest jedynie przekazanie na nią danych do maszyny docelowej.
W naszej codziennej pracy i rozrywce często spotykamy się z różnymi protokołami warstwy aplikacji, na przykład po otwarciu strony internetowej obraz jest wyświetlany w tej pozycji, a przycisk, który należy skierować w dół, służy do osiągnięcia określonej funkcji, jest to zgodne z protokołem HTML HyperText Transfer Protocol (angielski: HyperTextTransferProtocol, w skrócie: HTTP). Dzięki temu, gdy dowolne urządzenie zażąda strony w Twojej witrynie, będzie mogło ją poprawnie wyświetlić. Oprócz HTTP istnieje wiele innych protokołów warstwy aplikacji, takich jak DNS, FTP itp., a jednym z nich jest protokół MQTT, który jest dziś naszym bohaterem.
Dlaczego IoT faworyzuje MQTT
Dlaczego MQTT świeci w przestrzeni IoT, biorąc pod uwagę wszystkie wspaniałe protokoły warstwy aplikacji dostępne dla naszych istniejących aplikacji? Wybór protokołu MQTT nie jest bezpodstawny; MQTT to lekki, elastyczny protokół sieciowy, który stara się zachować właściwą równowagę dla programistów IoT:
Ten lekki protokół można wdrożyć na sprzęcie o bardzo ograniczonych ograniczeniach i w sieciach o dużych opóźnieniach i ograniczonej przepustowości.
Jego elastyczność umożliwia obsługę różnorodnych scenariuszy zastosowań dla urządzeń i usług IoT.
Większość programistów zna już usługi sieciowe HTTP. Dlaczego więc nie pozwolić urządzeniom IoT łączyć się z usługami internetowymi? Urządzenia mogą wysyłać swoje dane w formie żądań HTTP i otrzymywać aktualizacje z systemu w formie odpowiedzi HTTP. Ten model żądania i odpowiedzi ma kilka poważnych ograniczeń:
HTTP to protokół synchronizacji. Klient musi poczekać, aż serwer odpowie. przeglądarki internetowe mają to wymaganie, ale kosztem skalowalności. W przestrzeni IoT duża liczba urządzeń i sieć, która prawdopodobnie będzie zawodna lub będzie miała duże opóźnienia, sprawiają, że komunikacja synchroniczna jest problematyczna. Asynchroniczne protokoły przesyłania wiadomości lepiej nadają się do zastosowań IoT. Czujniki wysyłają odczyty i pozwalają sieci określić najlepszą trasę i czas dostarczenia ich do docelowych urządzeń i usług.
HTTP jest jednokierunkowy. Klient musi zainicjować połączenie. W zastosowaniach IoT urządzeniem lub czujnikiem jest zwykle klient, co oznacza, że nie może on biernie odbierać poleceń z sieci.
HTTP to protokół „jeden{0}}do-jednego. Klient wysyła żądanie, a serwer odpowiada. Dostarczanie wiadomości do wszystkich urządzeń w sieci jest nie tylko trudne, ale także kosztowne, co jest częstym przypadkiem użycia w aplikacjach IoT.
HTTP to protokół o dużej wadze z wieloma nagłówkami i regułami. Nie nadaje się do sieci o ograniczonych możliwościach.
Z tych powodów większość-wydajnych, skalowalnych systemów korzysta z asynchronicznych szyn komunikatów do wewnętrznej wymiany danych zamiast usług internetowych.
Model subskrybuj/publikuj
Co ciekawe, ten serwer protokołu MQTT jest w rzeczywistości znacznie prostszą konstrukcją niż serwer WWW, ponieważ ma być wydajną usługą. mechanizm, dzięki któremu MQTT głównie wysyła i odbiera wiadomości, jest nieco podobny do relacji pomiędzy naszą publiczną witryną internetową a Wami, czytelnikami.
W prawdziwym świecie ja i ty jesteśmy podobni do tego, jak mamy urządzenie MQTT podłączone do zunifikowanego serwera, subskrybujecie nas z zainteresowania lub jakiegoś uczucia do naszego publicznego numeru, a kiedy każdego dnia wysyłam wiadomość push, pojawiacie się w telefonie komórkowym. Wysłałem wiadomość. Ten proces pozwala uzyskać moje informacje w sposób znany jako W tym procesie sposób, w jaki uzyskujecie moje informacje, nazywa się „subskrypcją”, a zachowanie mojego wysyłania na ten numer publiczny to „publikowanie”. I każdy może przeczytać mój artykuł, możesz śmiało zostawić mi wiadomość, to zachowanie jest zachowaniem wszystkich związanym z „publikowaniem” i zawsze jestem przed pushem, aby zobaczyć wiadomość od wszystkich, jest to rodzaj zachowania „subskrypcyjnego”. W tym procesie wszelkie informacje zewnętrzne nie mają z nami nic wspólnego, po prostu komunikujemy się z przepływem informacji w dwóch kierunkach. Mechanizm przesyłania wiadomości w MQTT również opiera się na modelu Publikuj - Subskrybuj. Mechanizm dostarczania wiadomości MQTT jest również oparty na modelu „Publikuj” - „Subskrybuj”.
Konkretne kroki MQTT to:
Krok 1:Użyj pierwszego, aby uzyskać serwer MQTT, a następnie utwórz nowy produkt komunikacyjny MQTT.
Krok 2:Następnie przejdź do połączenia z tym serwerem, dwa ważne parametry połączenia z serwerem to numer hosta (nazwa domeny lub adres IP) i numer portu.
Krok 3:Jeśli korzystasz z platformy serwerów w chmurze-innej firmy, może być konieczne zalogowanie się na tym urządzeniu przy użyciu identyfikatora produktu i informacji uwierzytelniających, które można znaleźć w zapleczu Device Cloud.
Po wykonaniu tych trzech kroków możesz subskrybować lub publikować wiadomości w odpowiednich tematach.
Przygotuję dokument, który pokaże Ci, jak „wyruchać” platformę otwartego dostępu do chmury na urządzenia China Mobile.
Te trzy kroki dotyczą zarówno tworzenia oprogramowania aplikacyjnego, jak i rozwoju mikrokontrolera. Jeśli podczas opracowywania mikrokontrolera używasz poleceń AT i komunikacji z zewnętrznym modułem WIFI, wówczas moduł ogólny może zawierać polecenia AT + MQTT, co jest najlepszym sposobem na znaczne zmniejszenie nacisku na mikrokontroler. Można też uzyskać bezpośredni dostęp do danych warstwy transportowej protokołu TCP/IP, a następnie przeanalizować protokół MQTT, co wymaga od użytkownika głębokiej wiedzy na temat protokołu MQTT, aby móc analizować także własne dane Json, więc ogólnie rzecz biorąc, w przypadku urządzeń wbudowanych ogólnie zaleca się bezpośrednie użycie gotowego-modułu z protokołem MQTT, bezpośrednie analizowanie polecenia AT jest wygodniejsze.
Studium przypadku:
Zdalne sterowanie oświetleniem i uzyskiwanie aktualnej temperatury w pomieszczeniu.
W tym przypadku jest to właściwie jedno z najprostszych zastosowań MQTT. Po pierwsze, wbudowana w pomieszczeniu tablica sterująca jest połączona głównie z serwerem poprzez sieć WIFI, która może sterować włącznikiem światła, a także mierzyć temperaturę. Dalekim urządzeniem końcowym jest telefon komórkowy.
Aby komunikacja działała, najpierw muszą być połączeni z tym samym serwerem MQTT.
Informacje o temperaturze po stronie urządzenia są zbierane przez urządzenie, więc musi opublikować zebrane dane w temacie „Temperatura”, natomiast telefon komórkowy otrzymuje informację o temperaturze, więc musi zapisać się do tematu „Temperatura”. Gdy urządzenie wyśle informację o temperaturze do „tematu temperatury”, temat zostanie odebrany przez telefon komórkowy.
Sterowanie światłem po stronie urządzenia jest realizowane przez urządzenie, więc musi subskrybować temat „przełącznik światła”, podczas gdy telefon komórkowy steruje włącznikiem światła, więc musi publikować informacje sterujące w tym temacie „przełącznik światła”. Gdy telefon komórkowy wyśle wiadomość o włączeniu światła na temat „zapal światło”, temat zostanie odebrany przez terminal, a następnie zostanie wykonane polecenie włączenia światła.