Základný rozdiel je v modeli spojenia
Pri HTTPS je každá správa samostatná požiadavka. Zariadenie otvorí spojenie, odošle dáta, dostane odpoveď a odpojí sa. Nie je tu trvalá relácia. Každá požiadavka nesie vlastné overenie, zvyčajne bearer token v hlavičke Authorization, aj smerovanie v podobe URL cesty.
Pri MQTT zariadenie otvorí spojenie raz a udržiava ho. Overenie prebehne pri pripájaní, s tokenom v MQTT prihlasovacích údajoch alebo query parametri zabezpečeného WebSocketu, a platí počas celej relácie. Zariadenie publikuje správy do tém a odoberá ich cez to isté trvalé spojenie. Nejde o cyklus požiadavka–odpoveď, ale o publikovanie a odber.
Znie to ako drobný rozdiel protokolov. V praxi mení pohľad na tri veci: ako zariadenia posielajú dáta, ako ich platforma oslovuje a ako riešite oprávnenia jednotlivých zariadení.
Overovanie funguje inak, než čakáte
Pri HTTPS sa overuje každá požiadavka. Každá správa obsahuje token zariadenia ako bearer token v hlavičke. API ho overí pri každom volaní. Ak token odvoláte, ďalšia požiadavka zlyhá. Jasné a okamžité.
Pri MQTT sa overuje spojenie. Zariadenie sa autentifikuje raz pri vytváraní relácie. V praxi to znamená vlastný autorizátor, v AWS IoT Core funkciu Lambda, ktorý overí token a vráti dokument s pravidlami oprávnení. Tie platia počas celej relácie.
Odvolanie prístupu nie je také okamžité. Ak zneplatníte token, existujúce MQTT relácie overené pred odvolaním zostanú živé až do odpojenia. Ak potrebujete okamžité odvolanie, musíte mať mechanizmus núteného odpojenia konkrétneho zariadenia. V čisto HTTPS architektúre tento návrhový problém nevzniká.
Názvy tém určujú, kam správy putujú
HTTPS smeruje podľa URL, MQTT podľa témy. Bežný IoT vzor dáva každému zariadeniu vlastný menný priestor: devices/{deviceUid}. Zariadenie tam publikuje telemetriu a odoberá prichádzajúce správy – zmeny konfigurácie, metadáta firmvéru a príkazy.
Oprávnenia sú viazané na tému. Zariadenie môže publikovať len do devices/{its-own-uid} a odoberať tú istú tému. Vynucuje to politika autorizátora pri pripojení. Pokus publikovať do témy iného zariadenia sa odmietne. Získate tak izoláciu jednotlivých zariadení bez potreby samostatných prístupových údajov alebo endpointov.
Ak poznáte návrh REST zdrojov, predstavte si témy ako paralelný adresovací systém. Rozdiel je v obojsmernosti. Rovnaký priestor, do ktorého zariadenie publikuje, používa platforma na jeho oslovenie. Neexistuje samostatný endpoint pre push upozornenia. Téma je komunikačný kanál.
Kam sa ktorý protokol hodí v praxi
V reálnej platforme vyzerá rozdelenie zvyčajne takto:
HTTPS rieši registráciu a prípravu zariadení. Registrácia prebieha pred nasadením, zvyčajne pri výrobe. Jednorazové volanie s údajmi výrobcu, nie zariadenia, vytvorí identitu, priradí typ a verziu firmvéru a vráti token zariadenia. Je to klasický postup požiadavka–odpoveď. MQTT tu nič nepridáva.
MQTT rieši priebežnú telemetriu. Po nasadení sa zariadenie so svojím tokenom pripojí cez MQTT a začne publikovať. Pravidelné stavy, merania senzorov, GPS súradnice, diagnostika. Vysoká frekvencia, malá réžia, trvalé spojenie. Platforma prijíma správy vstupnou vrstvou a posúva ich na spracovanie.
MQTT rieši komunikáciu z platformy do zariadenia. Tu MQTT ukazuje svoju hodnotu. Metadáta aktualizácií firmvéru, zmeny konfigurácie – frekvencia hlásení, limity senzorov, aktívny či pasívny režim – aj diagnostické príkazy tečú z platformy do zariadenia tým istým spojením. Zariadenie odoberá svoju tému a zmeny dostáva hneď po publikovaní. Bez opakovaného dopytovania a čakania.
HTTPS zostáva dostupné ako náhradná cesta. Niektoré zariadenia, siete a použitia fungujú lepšie s HTTPS. Zariadenia za firemnými firewallmi blokujúcimi MQTT porty. Zriedkavo komunikujúce zariadenia, kde trvalé spojenie plytvá zdrojmi. Jednorazové API volania na stiahnutie firmvéru. Dobre navrhnutá vstupná vrstva prijme oba protokoly a zjednotí ich do rovnakého spracovania.
Čo vám ušetrí čas
Formát dát má byť pri oboch protokoloch rovnaký. JSON s rovnakými povinnými metadátami: typ udalosti, časová pečiatka a UID zariadenia. Spracovacej vrstve má byť jedno, či správa prišla cez HTTPS alebo MQTT. Ak vytvoríte formáty dát podľa protokolu, zdvojnásobíte logiku parsovania a výrazne rozšírite testovanie.
Na kvalite časových pečiatok záleží viac, než si myslíte. Doručenie MQTT aspoň raz znamená, že vznikajú duplicity. Správy môžu prísť aj v inom poradí, najmä po obnovení siete a odoslaní lokálnej vyrovnávacej pamäte. Úložisko stavu potrebuje pravidlá aktuálnosti: stav prepíšte len vtedy, keď je časová pečiatka správy novšia než uložená. Inak nepozorovane prepíšete čerstvé dáta starými.
S verziovanými dátovými formátmi počítajte od začiatku. Firmvér mení odosielané dáta. Verzia 2.1 môže obsahovať polia, ktoré vo verzii 1.8 nie sú. Spracovanie musí zvládať viac verzií súčasne. Platí to pri oboch protokoloch, no pri MQTT je to naliehavejšie: aktualizácie sa šíria rýchlejšie, pretože ich platforma posiela priamo, a flotila má zmiešané verzie kratšie, ale častejšie.
Testujte v skutočných sieťových podmienkach. MQTT cez mobilnú sieť s latenciou 300 ms a občasnými výpadkami sa správa inak než v lokálnej sieti. Udržiavanie spojenia, odstupy opätovného pripájania, ukladanie správ pri výpadku a obnova relácie môžu vo vývoji fungovať dokonale a v teréne zlyhať. Ak zariadenia používajú mobilnú sieť, testujte na mobilnej sieti.
Článok vychádza z produkčnej IoT komunikačnej platformy pre terénne zariadenia vrátane sledovačov majetku, telematických jednotiek a priemyselného monitoringu. Opísané vzory sme overili na zariadeniach s mobilným, Wi-Fi aj ethernetovým pripojením.
