Internet Of Things (IOT) – cz. 3

Autor:
Zespół Innokrea

Data publikacji: 2024-01-18

Kategorie: Informacje

Dzisiaj zajmiemy się znowu bardziej techniczną stroną urządzeń IOT i porozmawiamy dokładniej o protokołach warstwy aplikacji. Jakie są dostępne technologie, jakie konkretne paczki programistyczne można zastosować oraz co czym różnią się od siebie poszczególne protokoły charakterystyczne dla IOT? O tym już dzisiaj. Zapraszamy do lektury!

IOT – Warstwa aplikacji

W ostatnim artykule rozmawialiśmy od podejściu warstwowym w sieciach komputerowych i o tym jak właściwie działa na poziomie sieciowym system IOT. Dzisiaj zaczniemy od tego co dla programistów jest najistotniejsze z perspektywy sieciowca, czyli o warstwie aplikacji i protokołach takich jak MQTT czy COAP.

Rysunek 1: Protokoły używane w IOT, TCP/IP model, źródło: fb.com/IoTResearch

Jeśli chcielibyśmy się zapoznać jak wyglądają trendy w domenie protokołów aplikacji IOT możemy skorzystać z porównywarki Google Trends, która wskazuje jakie technologie są najczęściej wyszukiwane.

Rysunek 2 – wykres Google Trends

https://trends.google.com/trends/explore?date=today%205-y&q=MQTT,COAP,XMPP,AMQP

Warto zobaczyć jak wyglądają trendy poszczególnych technologii, ponieważ występują pewne różnice w rozkładzie zainteresowania szczególnie w takich krajach jak Chiny czy USA. Globalnie jednak, można zauważyć znaczącą przewagę rozwiązania MQTT, które postaramy się zaprezentować poniżej.

MQTT IN IOT – czym jest i jaka jest jego historia?

MQTT (ang. MQ Telemetry Transport) jest lekkim protokołem, który powstał w 1999 roku i działa w modelu publish/subscribe. Służy do kolejkowania wiadomości i jest szeroko stosowanym rozwiązaniem w urządzeniach IOT. Standard MQTT definiuje dwa rodzaje obiektów w sieci – klienta oraz broker wiadomości. W 2012 roku powstał jeden z popularniejszych open-source brokerów – Mosquitto 1.0. W 2013 natomiast powstało szeroko stosowane rozwiązanie cloudowe HiveMQ. W roku 2014 natomiast została wydana aktualizacja do standardu MQTT w wersji 3.1.1, a następnie w 2018 MQTT 5.

Rysunek 3 – historia MQTT, źródło hivemq.com

Charakterystyka MQTT

MQTT posiada wiele charakterystyk zarówno upodabniających jak i odróżniających go od innych protokołów warstwy aplikacji jak np. HTTP. Można wśród nich wymienić:

- Połączeniowość realizowana poprzez TCP – MQTT jest zbudowany w oparciu o protokół TCP, co sprawia, że mamy pewność, że każda wysłana wiadomość dotrze do urządzenia do którego powinna dojść. Ostatnio pojawiła się także implementacja oparta o protokół transportowy QUIC, który łączy w sobie pewność dostarczenia TCP oraz szybkość UDP (MQTT over Quic).
- Pewna komunikacja przez niepewne medium – MQTT zapewnia pewną komunikację nawet przez niepewne medium jakim może być dowolny protokół warstwy dostępu do sieci modelu TCP/IP (Wifi, LTE, Ethernet). Kiedy klient straci połączenie np. ze względu na warunki atmosferyczne to wiadomości oznaczone odpowiednimi znacznikami QOS zostaną zcachowane i wysłane kiedy klient odzyska połączenie z brokerem.
- Bezpieczeństwo – Tutaj MQTT jest podobne do innych protokołów jak np. HTTP, które pozwalają uzyskać bezpieczeństwo poprzez implementacji warstwy wspierającej TLS. Jeśli chodzi o aspekty bezpieczeństwa to MQTT może być przesyłane poprzez Tunnel TLS (MQTT over TLS), co oznacza także wsparcie dla certyfikatów, mutual-authentication. MQTT pozwala także na uwierzytelnienie w oparciu o login i hasło, jak przy zwykłej aplikacji webowej.
- Data-agnostic – Jeśli chodzi o możliwości dotyczące przesyłania danych to są one nieograniczone jeśli chodzi o typ, to znaczy, że możemy przesłać dowolne dane np. json czy XML. Takie podejście nazywa się data-agnostic protocol.
- Skalowalność – Podejście publish-subscribe w modelu komunikacyjnym MQTT jest skalowalne a sam broker może być dostarczony w formie klastra. Dzieje się tak np. w HiveMQ, które jest cloudowym brokerem. Jest to dobre ponieważ w tym modelu komunikacyjnym broker jest elementem krytycznym tzw. SPOF (Single Point Of Failure)

IOT – Połączenie MQTT

Połączenie pomiędzy klientem i brokerem zaczyna się od ustanowienia połączenia TCP (jeśli nie używamy QUIC’a) a następnie wymiany pakietów charakterystycznych dla MQTT.

Rysunek 4 – pakiety MQTT używane do zarządzania połączeniem między klientem i brokerem, źródło: Ravi Kishore Kodali, researchgate.net

Jak widać na powyższym rysunku MQTT wykorzystuje kilka typów wiadomości do komunikacji, które postaramy się krótko opisać:

CONNECT – jest początkową wiadomością, którą klient MQTT wysyła do brokera w celu nawiązania połączenia. Zawiera ona istotne informacje wersja protokołu, identyfikator klienta, flaga dotycząca czystej sesji, ustalony interwał keep-alive, dane uwierzytelniające użytkownika, inne istotne parametry połączenia. Ta wiadomość inicjuje sesję MQTT, co pozwala klientowi na subskrybowanie konkretnych tematów, publikowanie wiadomości i aktywną interakcję z brokerem.

Rysunek 5: Zawartość wiadomości CONNECT, źródło: hivemq.com

„lastWIll” w protokole MQTT to funkcja pozwalająca klientowi określić wiadomość, którą broker opublikuje na określonym temacie w przypadku niespodziewanej utraty połączenia klienta. Klient definiuje temat, na którym ma być opublikowana ostatnia wola, oraz samą treść wiadomości.

Parametry związane z „lastWill” obejmują:

Temat – Określany przez klienta temat, na którym zostanie opublikowana wiadomość
Jakość Usług (QoS) -Poziom QoS (0, 1, lub 2) dla publikacji na temacie.
Flaga Retain – Jeśli ustawiona na „true,” wiadomość będzie przechowywana przez brokera po publikacji na temacie.
Treść Wiadomości – Wiadomość, którą klient chce opublikować w przypadku utraty połączenia.
CONNACK – Wiadomość CONNACK to odpowiedź brokera na wiadomość CONNECT od klienta, która informuje klienta, czy połączenie zostało przyjęte lub odrzucone. W przypadku odmowy połączenia, CONNACK może również zawierać kod błędu wskazujący przyczynę.
PINGREQ – Wiadomość, którą klient wysyła, aby zainicjować sprawdzenie „keep-alive” z brokerem. Służy jako mechanizm do potwierdzania, czy połączenie jest wciąż aktywne i odpowiada. Jeśli broker nie otrzyma odpowiedzi w postaci wiadomości PINGRESP w określonym interwale keep-alive, może przerwać połączenie.
PINGRESP – Wiadomość PINGRESP to odpowiedź brokera na PINGREQ od klienta, która potwierdza żądanie klienta dotyczące kontroli aktywności i potwierdza, że połączenie pozostaje aktywne. PINGREQ i PINGRESP są przydatne do wykrywania i obsługi utraconych połączeń oraz zapewnienia synchronizacji między klientami a brokerem.
DISCONNECT – Wiadomość DISCONNECT to wiadomość inicjowana przez klienta, służąca do bezpiecznego zakończenia sesji MQTT. Pozwala klientowi poinformować brokera o swojej intencji rozłączenia i umożliwia zakończenie sesji w kontrolowany sposób, zapewniając jednocześnie uwolnienie zasobów i unikając gwałtownego rozłączenia.
PUBLISH – Wiadomość PUBLISH jest używana przez klienta MQTT do opublikowania wiadomości na określonym temacie u brokera MQTT. Zawiera ona nazwę tematu oraz treść wiadomości. Wiadomości PUBLISH mogą być wysyłane z różnymi poziomami Jakości Usług (QoS): 0 (Najwyżej raz), 1 (Przynajmniej raz) lub 2 (Dokładnie raz), w zależności od pożądanych gwarancji dostarczenia wiadomości. Treść wiadomości może zawierać różnego rodzaju dane, takie jak odczyty z czujników, aktualizacje statusu lub inne informacje, które klienci chcą udostępniać.
SUBSCRIBE – Wiadomość SUBSCRIBE jest używana przez klienta MQTT do subskrybowania jednego lub wielu tematów i odbierania wiadomości opublikowanych na tych tematach. Klient określa tematy, do których chce się zasubskrybować, oraz poziom QoS dla każdego tematu. Broker odpowiada wiadomością SUBACK, potwierdzając subskrypcje klienta. Po zasubskrybowaniu klient otrzymuje wiadomości opublikowane na subskrybowanych tematach przez innych klientów.

Istnieje także wiele innych rodzajów wiadomości MQTT takich jak: PUBACK, PUBREC, PUBREL, PUBCOMP, UNSUBSCRIBE, UNSUBACK.

Podsumowanie

Mamy nadzieję, że dzisiejszy wpis był czymś ciekawym szczególnie dla ludzi technicznych. Dotknęliśmy różnych aspektów technologii zarówno związanych z programowaniem jak i sieciami komputerowymi. Jeśli jesteście zainteresowani, to zapraszamy za tydzień, gdzie nadal pozostajemy w temacie IOT.