MQTT – co to jest, jak działa i do czego służy w IoT

MQTT to protokół komunikacyjny, który stał się fundamentem współczesnego Internetu Rzeczy. Kryje się za nim precyzyjnie zaprojektowany mechanizm wymiany wiadomości, który sprawdza się wszędzie tam, gdzie liczy się niezawodność, niskie zużycie energii i tysiące urządzeń działających jednocześnie. Ten artykuł wyjaśnia, jak działa MQTT od strony technicznej i dlaczego tak wiele systemów IoT opiera się właśnie na tym protokole.

Najważniejsze informacje z tego artykułu:

• MQTT to standaryzowany przez OASIS protokół komunikacyjny działający w modelu publish/subscribe, gdzie wiadomości przesyłane są za pośrednictwem centralnego pośrednika zwanego brokerem.
• Komunikacja odbywa się przez hierarchiczne tematy (topics), a nie bezpośrednio między urządzeniami, co pozwala na luźne powiązanie nadawcy i odbiorcy.
• Protokół oferuje trzy poziomy niezawodności dostarczania wiadomości – QoS 0, QoS 1 i QoS 2 – których wybór wpływa na zachowanie całego systemu.
• MQTT generuje wielokrotnie mniejszy narzut komunikacyjny niż HTTP, co ma bezpośrednie przełożenie na zużycie energii i opóźnienia w systemach IoT.
• Sam MQTT nie zapewnia bezpieczeństwa – wymaga osobnej konfiguracji szyfrowania TLS oraz kontroli dostępu do tematów przez listy ACL.

Czym jest MQTT i do czego służy ten protokół?

MQTT, czyli Message Queuing Telemetry Transport, to protokół transportu wiadomości oparty na modelu publish/subscribe, standaryzowany przez organizację OASIS. Wbrew temu, co sugeruje nazwa, nie jest systemem kolejkowym ani formatem danych. Definiuje sposób ustanawiania sesji, publikowania komunikatów, subskrybowania filtrów tematów, potwierdzania dostarczenia i obsługi stanu połączenia – a format treści wiadomości pozostawia całkowicie aplikacji.

Protokół powstał z myślą o środowiskach, gdzie zasoby są ograniczone. Niskie zużycie pasma, minimalna objętość nagłówków i asynchroniczny charakter komunikacji sprawiają, że MQTT dobrze działa zarówno na małych mikrokontrolerach, jak i w rozbudowanych instalacjach przemysłowych.

Dane z Eclipse Foundation 2024 IoT & Embedded Developer Survey pokazują skalę adopcji – 56% developerów Industrial IoT wskazuje MQTT jako preferowany protokół komunikacyjny, co oznacza wzrost o 7 punktów procentowych względem roku 2023. W badaniu IoT Analytics połowa ankietowanych firm uznała go za protokół strategiczny dla swoich wdrożeń IIoT.

Gdzie MQTT ma zastosowanie:

• Inteligentny dom – czujniki temperatury, wilgotności, czujniki otwarcia okien i drzwi, sterowanie oświetleniem i ogrzewaniem.
• Przemysłowy Internet Rzeczy (IIoT) – zbieranie danych z maszyn, monitorowanie parametrów produkcji, integracja z systemami SCADA.
• Telemetria pojazdów – przesyłanie danych GPS, diagnostyki i stanu pojazdu do zaplecza.
• Smart city – sieci czujników środowiskowych, monitoring zużycia mediów, inteligentne parkometry.
• Medycyna i opieka zdrowotna – przesyłanie danych z urządzeń pomiarowych pacjentów.
• Rolnictwo – monitoring warunków w szklarniach, automatyczne nawadnianie, czujniki glebowe.

Jak działa model publish/subscribe w MQTT?

Najważniejsza cecha architektury MQTT to brak bezpośredniej komunikacji między urządzeniami. Klient publikujący wiadomość i klient ją odbierający nigdy nie rozmawiają ze sobą wprost – pośrednikiem jest zawsze broker.

Broker to serwer, który:

• utrzymuje połączenia ze wszystkimi klientami,
• przechowuje subskrypcje i dopasowuje do nich przychodzące wiadomości,
• zarządza stanem sesji – nawet gdy klient jest chwilowo offline,
• obsługuje autoryzację i routing wiadomości,
• kolejkuje wiadomości dla klientów niedostępnych w danym momencie (przy odpowiedniej konfiguracji).

Klient może pełnić dwie role – publisher (wydawca) publikuje wiadomości do określonego tematu, a subscriber (subskrybent) odbiera wiadomości z tematów, które go interesują. Jedno urządzenie może jednocześnie publikować i subskrybować różne tematy.

Czym jest topic w MQTT?

Topic, czyli temat, to hierarchiczny ciąg znaków, który pełni rolę adresu wiadomości. Przykładowy temat wygląda tak: budynek/pietro2/sala5/temperatura. Poszczególne poziomy hierarchii oddziela ukośnik, a ich struktura nie jest narzucona przez specyfikację MQTT – to kwestia umowy projektowej.

Subskrybent może używać filtrów z wieloznakami (wildcardami):

• + – zastępuje dokładnie jeden poziom hierarchii, np. budynek/+/sala5/temperatura dopasuje tematy z dowolnym piętrem.
• # – zastępuje dowolną liczbę poziomów, np. budynek/# dopasuje wszystko poniżej.

Warto wiedzieć, że konwencja nazewnictwa tematów ma praktyczne znaczenie dla uprawnień. Hierarchia w stylu device/123/temp zwykle lepiej współpracuje z regułami ACL i filtrowaniem per urządzenie niż odwrócona struktura temp/device/123 – choć obie są technicznie równoważne z punktu widzenia protokołu.

Wskazówka: Wildcard # w subskrypcji administracyjnej może przeciążyć klienta odbiorczego lub ujawnić dane między różnymi grupami użytkowników systemu. W środowiskach produkcyjnych warto blokować globalne subskrypcje z wildcardami na poziomie reguł ACL brokera.

Czym różni się MQTT od HTTP?

To zestawienie, które często pojawia się przy pierwszym kontakcie z protokołem. MQTT i HTTP to protokoły warstwy aplikacji, ale zaprojektowane z zupełnie innymi założeniami.

Dane porównawcze pochodzą z eksperymentalnych badań dla scenariuszy smart city. Różnica w zużyciu energii przy dużej liczbie wiadomości jest pochodną architektury – HTTP zestawia nowe połączenie przy każdym żądaniu i przesyła rozbudowane nagłówki tekstowe, podczas gdy MQTT utrzymuje stałe połączenie TCP i minimalizuje narzut do kilku bajtów.

Przy 10 000 wiadomości MQTT zużywa energii ponad dwa razy mniej niż HTTP, co ma bezpośrednie przełożenie na żywotność baterii w urządzeniach zasilanych autonomicznie.

Jakie poziomy niezawodności dostarczania oferuje MQTT?

MQTT definiuje trzy poziomy Quality of Service (QoS) – parametr, który określa gwarancje dostarczenia wiadomości między konkretną parą nadawca–odbiorca. Ważne: QoS nie jest globalną właściwością kanału ani gwarancją efektu biznesowego. Przepływ publisher–broker i broker–subscriber mogą mieć niezależne poziomy QoS, a dostarczenie do subskrybenta ogranicza niższy z nich.

Trzy poziomy QoS:

• QoS 0 – at most once – wiadomość wysyłana bez potwierdzenia. Może zaginąć. Odpowiedni dla telemetrii, gdzie utrata jednej próbki pomiaru temperatury co jakiś czas nie powoduje problemów.
• QoS 1 – at least once – nadawca czeka na PUBACK, a przy jego braku retransmituje. Subskrybent może otrzymać duplikat, dlatego aplikacja powinna obsługiwać idempotencję.
• QoS 2 – exactly once – czterostopniowa sekwencja pakietów (PUBLISH, PUBREC, PUBREL, PUBCOMP) gwarantuje dostarczenie dokładnie raz na poziomie protokołu MQTT.

QoS 2 nie oznacza jednak dokładnie jednokrotnego efektu w systemie zewnętrznym. Jeśli subskrybent po odebraniu wiadomości zapisuje dane w bazie i przy tym dochodzi do błędu backendu albo restartu aplikacji, operacja może zostać wykonana dwukrotnie. Protokół zarządza transportem, a nie transakcją w zewnętrznym systemie – dlatego przy QoS 2 nadal warto projektować idempotentne operacje i używać identyfikatorów korelacji.

Jest też mniej oczywisty problem z wysokim QoS przy dużej skali. QoS 1 i 2 generują dodatkowe potwierdzenia i wymagają utrzymania stanu po stronie brokera. Przy tysiącach urządzeń na niestabilnym łączu komórkowym wyższy QoS może paradoksalnie obniżyć niezawodność całego systemu – wtedy lepszym rozwiązaniem bywa QoS 0 połączony z częstszym raportowaniem danych.

Jak MQTT zarządza sesją i wiadomościami offline?

MQTT 5.0 rozdziela pojęcia, które we wcześniejszej wersji 3.1.1 były ze sobą powiązane. Clean Start określa, czy połączenie ma zacząć od nowej sesji. Session Expiry Interval osobno definiuje, jak długo broker ma zachować stan sesji po rozłączeniu klienta. Pozwala to precyzyjnie obsłużyć urządzenia, które regularnie tracą łączność, ale powinny zachować subskrypcje i oczekujące wiadomości.

Sesja trwała nie oznacza jednak nieograniczonej retencji wiadomości. MQTT 5.0 wprowadza Message Expiry Interval – czas życia wiadomości oczekującej na klienta offline. To rozwiązanie ma realne znaczenie: stary odczyt temperatury może być bezużyteczny, ale polecenie otwarcia zaworu, które dotrze kilka godzin po wysłaniu, może być niebezpieczne. W wersji 3.1.1 takie wygaszanie trzeba było implementować samodzielnie.

Warto też wiedzieć, że migracja z MQTT 3.1.1 do MQTT 5.0 wymaga ostrożności – Clean Session ze starszej wersji i Clean Start z nowej to pojęcia zbliżone, ale nie identyczne. Pominięcie Session Expiry Interval podczas migracji może zmienić zachowanie kolejkowania wiadomości offline w sposób nieoczekiwany.

Dwa dodatkowe mechanizmy zarządzania stanem:

• Retained Message – broker przechowuje ostatnią wiadomość opublikowaną do danego tematu i przekazuje ją nowemu subskrybentowi zaraz po subskrypcji. Przydatne do przekazania aktualnego stanu urządzenia, ale nie jest historią ani kolejką. Pułapka pojawia się wtedy, gdy urządzenie zostało wymienione lub temat zmienił znaczenie – broker może wtedy rozsyłać nieaktualną konfigurację jako bieżący stan.
• Last Will and Testament (LWT) – wiadomość, którą broker publikuje, gdy klient nieoczekiwanie zerwie połączenie. Ważne ograniczenie: LWT działa tylko przy niepoprawnym zerwaniu sesji. Jeśli klient wyśle pakiet DISCONNECT w sposób prawidłowy, broker nie opublikuje komunikatu o rozłączeniu – co warto uwzględnić przy projektowaniu monitoringu dostępności urządzeń.

Osobny mechanizm to persistent session i ryzyko burzy wiadomości po powrocie klienta. Jeśli urządzenie było offline przez długi czas, broker może dostarczyć tysiące zakolejkowanych wiadomości naraz. Dlatego warto ustawiać limity kolejki i Message Expiry Interval, zamiast zakładać, że subskrybent zawsze poradzi sobie z zaległościami.

Czym MQTT 5.0 różni się od starszej wersji protokołu?

MQTT 5.0 to nie tylko kosmetyczna aktualizacja. Wprowadza mechanizmy, które mają realne przełożenie na diagnostykę, wydajność i możliwości architektoniczne systemu.

Najważniejsze rozszerzenia MQTT 5.0:

• Reason Codes i Reason Strings – broker może precyzyjnie zakomunikować przyczynę odmowy, błędu autoryzacji, przekroczenia limitu lub rozłączenia bez konieczności zamykania całego połączenia przy każdym błędzie. Klient może reagować różnie na błąd trwały, przejściowy i limit zasobów.
• Topic Alias – wielokrotnie przesyłana długa nazwa tematu może być zastąpiona krótkim identyfikatorem liczbowym. Przydatne przy głęboko zagnieżdżonych hierarchiach i małych payloadach. Zakres aliasów jest negocjowany niezależnie między klientem a serwerem.
• Receive Maximum i Maximum Packet Size – mechanizmy ochrony zasobów i kontroli backpressure, a nie tylko dodatki diagnostyczne. Receive Maximum ogranicza liczbę jednocześnie obsługiwanych przepływów QoS 1 i 2.
• Response Topic i Correlation Data – formalizują wzorzec żądanie-odpowiedź. Żądanie zawiera temat, na który ma trafić odpowiedź, oraz dane korelacyjne łączące odpowiedź z konkretnym żądaniem. Nie tworzy to gwarancji timeoutu ani transakcyjności – te reguły pozostają po stronie aplikacji.
• Shared Subscriptions – subskrypcje współdzielone, gdzie broker dostarcza każdą wiadomość tylko do jednego klienta z grupy. Przydatne do poziomego skalowania workerów backendowych.
• Enhanced Authentication – pakiet AUTH umożliwia wieloetapowe mechanizmy challenge-response oparte na SASL, w tym ponowne uwierzytelnienie podczas długiej sesji.

Wskazówka: Persistent session po dłuższej nieobecności klienta może skutkować dostarczeniem tysięcy zakolejkowanych wiadomości naraz. Ustawiaj Message Expiry Interval i limity kolejki w brokerze – szczególnie dla danych telemetrycznych, które tracą ważność po kilku sekundach lub minutach.

Jak wygląda bezpieczeństwo w MQTT?

MQTT nie zapewnia bezpieczeństwa samo z siebie – to kwestia konfiguracji i architektury systemu, a nie właściwość protokołu. Specyfikacja wskazuje potrzebę uwierzytelniania, autoryzacji i bezpiecznego transportu, ale konkretne mechanizmy zależą od implementacji brokera i decyzji projektowych.

Bezpieczeństwo MQTT opiera się na dwóch niezależnych warstwach:

Warstwa transportowa:

• TLS (Transport Layer Security) zapewnia szyfrowanie połączenia, integralność danych i uwierzytelnienie warstwy transportowej. Standardowy port MQTT to 1883 (bez szyfrowania), a MQTTS to 8883 (z TLS).
• MQTT over WebSocket (port 443 lub 8083) bywa używany w sieciach korporacyjnych i przeglądarkach internetowych, ale generuje większy narzut ramek i utrudnia diagnozowanie problemów z proxy.

Warstwa autoryzacji:

• ACL (Access Control List) – reguły po stronie brokera ograniczające, które klienty mogą publikować lub subskrybować konkretne tematy. TLS nie zastępuje ACL – klient z ważnym certyfikatem, ale bez odpowiednich uprawnień, nadal może próbować odczytywać dane, których nie powinien widzieć.
• MQTT 5.0 Enhanced Authentication – pakiet AUTH umożliwia mechanizmy SASL, SCRAM czy OAuth. Token OAuth może służyć jednocześnie do uwierzytelnienia i autoryzacji dostępu do tematów.

Skala realnych wdrożeń pokazuje, jak poważnie traktować bezpieczeństwo. W badaniu obejmującym ponad 425 000 zidentyfikowanych serwerów MQTT udało się nawiązać połączenie z ponad 251 000 – co pokazuje, jak wiele brokerów jest publicznie dostępnych w sieci. Część z nich działa bez uwierzytelniania.

Wskazówka: Samo włączenie TLS nie kończy konfiguracji bezpieczeństwa. Bez poprawnych reguł ACL klient z ważnym certyfikatem może subskrybować tematy wszystkich innych urządzeń w systemie. Konfiguruj uprawnienia per klient i weryfikuj je podczas testów integracyjnych.

Jakie są zalety MQTT i kiedy warto po niego sięgnąć?

MQTT sprawdza się przede wszystkim tam, gdzie wiele urządzeń wysyła dane regularnie, połączenie bywa niestabilne, a zasoby energetyczne i obliczeniowe są ograniczone.

Zalety protokołu:

• Minimalny narzut komunikacyjny – nagłówek MQTT zaczyna się od 2 bajtów, podczas gdy HTTP przesyła setki bajtów samych nagłówków tekstowych.
• Asynchroniczność – urządzenie nie czeka na odpowiedź. Może opublikować dane i przejść do trybu uśpienia.
• Skalowalność – jeden broker obsługuje tysiące jednoczesnych połączeń. Shared subscriptions pozwalają skalować przetwarzanie po stronie odbiorczej.
• Luźne powiązanie nadawcy i odbiorcy – producent danych nie musi wiedzieć, kto i ile systemów odbiera jego wiadomości.
• Konfigurowalna niezawodność – wybór QoS zależy od charakteru danych, a nie od architektury całego systemu.
• Wbudowany mechanizm wykrywania awarii – LWT pozwala zautomatyzować reakcję na utratę połączenia przez urządzenie.

MQTT ma też ograniczenia, o których warto wiedzieć przed podjęciem decyzji projektowej:

• Brak natywnej semantyki danych – protokół nie definiuje formatu payloadu, jednostek ani modelu urządzenia. W środowiskach przemysłowych tę lukę uzupełnia Sparkplug B, dodając wspólny namespace tematów, binarny model danych i zarządzanie stanem urządzeń.
• Brak pełnego odtwarzania historii – retained messages dają ostatni znany stan, ale nie zastępują pełnego logu zdarzeń. Jeśli system wymaga audytu, odtwarzania strumienia i niezależnych pozycji konsumentów, warto rozważyć dedykowane platformy event streamingowe.
• Kolejność wiadomości nie jest gwarantowana globalnie – jest zachowana dla tego samego klienta i połączenia, ale przy klastrach brokerów lub wielu publisherach na różnych poziomach QoS nie należy zakładać globalnej kolejności zdarzeń.

Podsumowanie

MQTT to broker-centryczny protokół publish/subscribe zaprojektowany z myślą o środowiskach, gdzie zasoby są ograniczone, połączenia niestabilne, a urządzeń jest dużo. Jego siłą są minimalny narzut komunikacyjny, asynchroniczność, konfigurowalna niezawodność i naturalne rozdzielenie producentów danych od konsumentów. Protokół nie definiuje formatu payloadu ani semantyki danych, dlatego wymaga dodatkowych konwencji lub specyfikacji – takich jak Sparkplug – gdy w grę wchodzi interoperacyjność przemysłowa. Bezpieczeństwo wymaga osobnej konfiguracji TLS i reguł ACL. Rosnąca adopcja MQTT w środowiskach IIoT potwierdza, że dla wielu scenariuszy telemetrycznych i sterowania maszynowego jest to protokół trudny do zastąpienia.

FAQ

Q: Jaki broker MQTT wybrać do projektu IoT?

A: Popularne opcje to Mosquitto (lekki, open source), EMQX i HiveMQ (skalowalne klastry produkcyjne) oraz Mosca (Node.js). Wybór zależy od liczby klientów, wymagań klastrowania i integracji z systemami zewnętrznymi.

Q: Czy MQTT działa przez internet, czy tylko w sieci lokalnej?

A: MQTT działa przez internet. Wystarczy broker dostępny publicznie i połączenie TCP. Dla bezpieczeństwa należy używać TLS i uwierzytelniania, ponieważ niezabezpieczony broker na porcie 1883 jest widoczny dla każdego.

Q: Jaki jest maksymalny rozmiar wiadomości w MQTT?

A: Specyfikacja MQTT 3.1.1 dopuszcza payload do 256 MB. Wersja 5.0 pozwala negocjować Maximum Packet Size między klientem a brokerem. W praktyce brokerzy i klienci stosują własne, niższe limity.

Q: Czy MQTT wymaga stałego połączenia z internetem po stronie urządzenia?

A: Nie. Przy sesji trwałej broker przechowuje wiadomości dla klienta offline. Po powrocie do sieci klient odbiera zakolejkowane dane, o ile nie przekroczyły Message Expiry Interval i limitu kolejki.

Q: Czy MQTT nadaje się do przesyłania dużych plików lub obrazów?

A: Technicznie jest to możliwe, ale protokół nie jest do tego zoptymalizowany. Przy dużych payloadach lepiej przesłać przez MQTT tylko metadane lub odnośnik do pliku, a sam plik przenieść przez HTTP lub protokół dedykowany do transferu plików.