Protokoly aplikační vrstvy, jako je HyperText Transfer Protocol (HTTP), se primárně používají pro komunikaci na klientech založených na prohlížeči, kteří obvykle běží na relativně výkonných zařízeních, jako jsou smartphony, které používají komunikační kanály s relativně velkou šířkou pásma (např. LTE). Na druhou stranu, IoT protokoly jsou sada pravidel vhodných pro IoT aplikace, aby zajistily, že data odeslaná z IoT zařízení budou čtena a pochopena jiným zařízením. Protokoly IoT také musí zajistit optimální zabezpečení vyměňovaných informací mezi připojenými zařízeními. V závislosti na zařízeních IoT a jejich aplikacích existují různé protokoly IoT na aplikační vrstvě. Aplikační vrstva je vlastně rozhraní mezi uživatelem a zařízením IoT. Konkrétní případ použití IoT může vyžadovat specifický datový komunikační protokol aplikační vrstvy a komunikační zásobník zaměřený na IoT.

Existuje mnoho protokolů IoT, které si můžete vybrat pro různé aplikace a požadavky. Některé z těchto protokolů jsou například speciálně navrženy tak, aby splňovaly požadavky na rychlé a spolehlivé obchodní transakce, nebo některé další jsou optimalizovány tak, aby splňovaly požadavky na sběr dat, jako jsou aktualizace senzorů v omezených sítích. Některé další IoT protokoly jsou vhodné pro aplikace, kde je potřeba Instant Messaging (IM) a online detekce přítomnosti [5]. Každý z těchto protokolů má své výhody a nevýhody při řešení různých scénářů IoT. Proto je důležité porozumět charakteristikám různých IoT protokolů, abyste si mohli vybrat nejlepší protokol pro váš případ použití.

Tři široce akceptované a klíčové IoT protokoly zahrnují Message Queue Telemetry Transport (MQTT), Constrained Application Protocol (CoAP) a Advanced Message Queuing Protocol (AMQP). Nejprve podrobně představíme každý z těchto tří protokolů a poté představíme obecné srovnání mezi nimi, abychom získali přehled o silných stránkách a omezeních každého protokolu.

Protokol MQTT (Message Queue Telemetry Transport).

MQTT je lehký a škálovatelný protokol pro zasílání zpráv IoT pro publikování a předplatné, který lze snadno implementovat pro přenos dat prostřednictvím centrálního serveru zvaného broker. Tento protokol se primárně používá pro omezené sítě, které poskytují připojení ke vzdáleným místům, a je ideální pro malá zařízení, která vyžadují efektivní šířku pásma a využití baterie, jako jsou automobilové senzory, detektory kouře, chytré hodinky a aplikace pro zasílání textových zpráv. Ve srovnání s HTTP je MQTT rychlejší, má menší režii a spotřebu energie. Dalším rozdílem oproti HTTP je to, že v MQTT klient nemusí stahovat informace, které potřebuje, ale pokud jsou k odeslání nová data, server (broker) pošle informace klientovi.

V MQTT lze snadno přidávat nová zařízení, aniž byste se dotkli stávající infrastruktury (více vydavatelů a více předplatitelů). Protože nová zařízení komunikují pouze s brokerem, nemusí být kompatibilní s ostatními zařízeními.

Obrázek 4.1. Protokol MQTT pro mobilní IoT

Broker se chová jako pošta. Namísto zařízení, odesílání zpráv na jiné zařízení nebo jejich získávání z jiného zařízení přímo (peer-to-peer), klient (vydavatel) odesílá zprávy na poštu (zprostředkovatele) a poté je přeposílá všem, kteří zprávu potřebují (odběratelům). Rozdíl je v tom, že MQTT používá místo adres předmět nazvaný „téma“, tj. každý, kdo potřebuje kopii této zprávy, se přihlásí k odběru tohoto tématu. Téma je jednoduchý řetězec, který může mít více úrovní hierarchie, které jsou odděleny lomítkem (např. senzory/teplota). Všimněte si, že témata rozlišují malá a velká písmena.

V MQTT jsou IoT zařízení propojena prostřednictvím zprostředkovatele, což znamená, že mezi klienty neexistuje žádné přímé spojení a zprostředkovatel předává zprávy mezi klienty. Na rozdíl od většiny komunikačních protokolů není toto předávání zpráv omezeno na model jedna ku jedné. Zpráva používá téma pro jednoznačnou identifikaci a není zacílena do jednoho zařízení. Je tedy možné mít mnoho zařízení přihlášených ke stejnému tématu, což může realizovat model one-to-many. Podobně může více zařízení typu many-to-many publikovat stejné téma a mít jednoho nebo více odběratelů. Zprostředkovatel zpracovává všechny tyto scénáře pomocí témat ke správě zpráv.

MQTT je obousměrný komunikační protokol, kde každý klient může produkovat a spotřebovávat data publikováním zpráv a přihlášením k odběru témat. Velkou výhodou této obousměrné komunikace je, že IoT zařízení mohou odesílat data ze senzorů a zároveň přijímat konfigurační informace a řídicí příkazy.

A. Připojení MQTT

MQTT používá tři úrovně kvality služeb (QoS), aby byla zajištěna spolehlivost zpráv. Tabulka 4.1 ukazuje tyto tři úrovně QoS včetně požáru a zapomenutí (Úroveň 0), potvrzeného doručení (Úroveň 1) a Zajištěného doručení (Úroveň 2).

MQTT vyžaduje spolehlivé, bezztrátové a v pořádku doručování paketů, a proto se jedná o protokol založený na TCP/IP, kde je třeba před přenosem dat navázat TCP spojení. MQTT je třífázová handshake komunikace, která musí nejprve navázat TCP spojení. Za druhé je navázáno spojení MQTT a data jsou publikována. Nakonec je TCP spojení ukončeno.

Obrázek 4.2. Potřesení rukou mezi vydavatelem a zprostředkovatelem MQTT

Navázání TCP spojení

K navázání TCP spojení se používá třícestný handshake. Nejprve klient odešle  požadavek SYN , aby naznačil, že chce komunikovat se serverem (brokerem), který je vždy v režimu naslouchání. Poté je tento požadavek serverem potvrzen odesláním paketu [SYN, ACK], aby klient věděl, že server přijal paket požadavku na připojení a je připraven vyměňovat si informace s klientem. Nakonec klient odešle  ACK , aby si server uvědomil, že klient obdržel potvrzení žádosti o připojení a je připraven přenášet data se serverem.  

Navázání připojení MQTT a publikování dat

Existují různé procesy handshake vydavatele MQTT pro různé úrovně QoS. U úrovně QoS 0 po úspěšném navázání připojení TCP vydavatel odešle paket požadavku na připojení na server (zprostředkovatele). Jakmile server obdrží paket požadavku na připojení, odešle potvrzovací paket vydavateli, aby ukázal, že je broker připraven ke komunikaci. Poté vydavatel začne publikovat zprávu. Nakonec se vydavatel odpojí od serveru odesláním paketu požadavku na odpojení.

Ukončení TCP spojení

Poté, co server přijme paket požadavku na odpojení, odešle klientovi dva pakety. Jeden paket ACK pro potvrzení přijetí paketu s požadavkem na odpojení a druhý paket [FIN, ACK] pro sdělení klientovi, že broker chce také ukončit spojení. Posledním paketem v této fázi je potvrzení zaslané klientem.

B. Zabezpečení protokolu MQTT

Většina zařízení IoT postrádá potřebné síťové zdroje pro bezpečnou správu jejich připojení. Centrální broker v architektuře MQTT zvyšuje bezpečnost oddělením zařízení a aplikací. V této architektuře se všechna zařízení musí autentizovat proti centrálnímu bezpečnostnímu umístění (broker) a vyžaduje se, aby byl pro brokera otevřen pouze jeden port (zabezpečený port 8883). MQTT poskytuje toto zabezpečení pomocí šifrování Transport Layer Security (TLS) a připojení chráněných uživatelským jménem/heslem. Navíc každý klient nezná IP adresy a domény jiných zařízení. Tyto bezpečnostní mechanismy jsou nakonfigurovány na zprostředkovateli MQTT a klient pak bude muset splnit bezpečnostní požadavky. To je důvod, proč by měly být schopnosti klienta MQTT brány v úvahu při plánování a implementaci bezpečnostních opatření na brokera.

Existují tři způsoby, jak může broker ověřit identitu klienta MQTT:

• ID klientů: Všichni klienti MQTT musí poskytnout ID klienta, které se používá k propojení tématu MQTT s klientem a připojením TCP, když se klient přihlásí k odběru tématu.
• Uživatelská jména a hesla: Před navázáním připojení může zprostředkovatel MQTT vyžadovat od klienta platné uživatelské jméno a heslo. Všimněte si, že tato kombinace uživatelského jména a hesla není šifrovaná ani zabezpečená a je jednoduše přenášena jako prostý text.
• Klientské certifikáty: Tuto nejbezpečnější metodu ověřování klientů je obvykle velmi obtížné implementovat, protože certifikáty je třeba nasadit a spravovat na mnoha klientech. Tato metoda autentizace by mohla být vhodná pro malý počet klientů s přísně vysokými požadavky na zabezpečení.

C. Zabezpečení transportní vrstvy (TLS)

Technologie TLS nebo jak je běžněji známá technologie Secure Socket Layer (SSL) je součástí protokolu TCP/IP (nikoli MQTT) a poskytuje šifrovaný kanál pro ochranu všech částí zpráv MQTT včetně užitečného zatížení. Tuto technologii musí podporovat i klient a nemusí být dostupná na levných a jednoduchých zařízeních IoT. Všimněte si, že data lze šifrovat end-to-end na aplikační vrstvě bez konfigurace zprostředkovatele. Hesla však nelze chránit, protože není zapojen zprostředkovatel.

D. Broker MQTT

Hostování brokera MQTT

Existují dvě hlavní možnosti, jak hostit brokera MQTT. Zprostředkovatel MQTT může být hostován na lokálně nainstalovaném nebo cloudovém serveru. V prvním případě je MQTT broker nainstalován na hardware serveru. V závislosti na požadavcích každého brokera si lze vybrat z mnoha free a open source MQTT brokerů. Tabulka níže ukazuje některé z těchto dostupných brokerů.

Mnoho společností, jako je Google, Amazon, Microsoft a IBM, poskytuje cloudové servery/brokery MQTT. Například Google Cloud IoT Core poskytuje protokol MQTT prostřednictvím spuštění spravovaného brokera, který se propojuje s portem „mqtt.googleapis.com:8883“. Všimněte si, že port 8883 je standardním portem TCP vyhrazeným pro zabezpečené připojení MQTT.

Spolehlivost brokera MQTT

V MQTT je broker centrálním bodem komunikace mezi všemi zařízeními, což vyvolává obavy z jediného zdroje selhání. Pro zvýšení spolehlivosti komunikace většina zprostředkovatelského softwaru a klientů podporuje automatické předání záložnímu/redundantnímu zprostředkovateli, pokud selže primární server. Software lze také nastavit tak, aby sdílel zátěž klientů na více serverech na citaci, v cloudu nebo na kombinaci obou.

Certifikáty stavu klienta

V MQTT je zatížení sítě sníženo tím, že klient odesílá data pouze tehdy, když dojde ke změně hodnot. Zprostředkovatel uchovává zveřejněné zprávy a rozesílá je novým předplatitelským klientům. Makléři MQTT si mohou být vědomi stavu svých klientů a sdělovat tento stav ostatním klientům pomocí rodných a úmrtních listů a funkce Last Will and Testament (LWT). Klienti MQTT mohou zaregistrovat zprávu LWT, která bude zaslána zprostředkovatelem, pokud se náhle odpojí. Tyto zprávy lze použít k informování účastníků o odpojení zařízení. Když se publikační klient připojí k brokerovi, vydá mu rodný list spolu s jeho LWT nákladem. Zprostředkovatel upozorní každého předplatitele na stejné téma jako publikační klient, kdykoli je publikující klient offline nebo online. Aby bylo zajištěno, že zastaralá data nebudou doručena předplatitelskému klientovi, pokud je publikování klient offline, poskytne zprostředkovatel předplatitelskému klientovi užitečné zatížení LWT. Toho je dosaženo pomocí předem nakonfigurovaného „časovače udržování života“ nebo „kontroly srdečního tepu“ mezi makléřem a vydavatelskými klienty. Výsledkem je, že předplatitelští klienti vždy vědí, zda je publikující klient online nebo kdy přešel do režimu offline a jaká byla poslední známá hodnota.

4.3 Protokol CoAP (Constrained Application Protocol)

Constrained Application Protocol (CoAP) je protokol aplikační vrstvy vyvinutý organizací Internet Engineering Task Force (IETF) jako extrémně lehký zásobník komunikačních protokolů vhodný pro zařízení s omezenými zdroji. CoAP lze implementovat pomocí protokolu UDP (User Datagram Protocol) a je určen pro zařízení s omezenou kapacitou pro připojení v rámci komunikace mezi stroji a strojem (LWM2M). LWM2M umožňuje vzdálenou správu a ovládání zařízení IoT pomocí zjednodušeného modelu spravovaných objektů a poskytuje rozhraní pro bezpečné monitorování a správu zařízení. CoAP používá metody GET, PUT, POST a DELETE a kódy odpovědí podobné, ale ne přesně jako HTTP. Proto je snadné mapovat provoz CoAP ze zařízení na logiku rozhraní API (Representational State Transfer-ful) (RESTful). RESTful API je API, které využívá HTTP požadavky na GET, PUT, POST a DELETE data. API pro webovou stránku je kód, který umožňuje dvěma softwarovým programům vyměňovat si mezi nimi informace.

CoAP používá model prostředků mapovaný na identifikátor URI (Universal Resource Identifier) ​​namísto témat MQTT. Mezi tématy CoAP URI a MQTT však existuje podobnost. Například senzorová zařízení publikující informace o svých senzorech na server by mohla být popsána následujícím způsobem:

Publikování senzoru CoAP na server CoAP

URI: coap://devices/sensors/temperature

Publikování klienta MQTT do fronty senzorů na zprostředkovateli

téma: "/devices/sensors/temperature"

Zjednodušeně lze fungování CoAP shrnout následovně. Paket UDP je přenášen za účelem vyžádání dat z druhého koncového bodu (GET na adrese URL zařízení). Poté je zpět odeslán paket odpovědí obsahující požadované informace (např. hodnota teploty senzoru). Všimněte si, že paket dat lze také odeslat do zařízení – POST na jeho URL.

Protokoly CoAP a HTTP mají mnoho podobných funkcí s tím rozdílem, že CoAP je optimalizován pro IoT a konkrétněji pro M2M. CoAP má nízkou režii a je velmi jednoduché analyzovat. Má funkce proxy a mezipaměti a vyměňuje zprávy asynchronně.

Jak je znázorněno na obrázku CoAP se skládá ze dvou různých vrstev: vrstva zpráv, která je nejnižší vrstvou a zabývá se UDP, a vrstva žádost/odpověď, která spravuje interakce žádost/odpověď.

Obrázek 4.3. Modely zasílání zpráv CoAP a MQTT

A. Vrstva zpráv CoAP

Vrstva zpráv je umístěna nad UDP a zabývá se výměnou zpráv mezi zařízeními IoT a internetem. Duplicitní zprávy jsou detekovány pomocí jedinečných ID přiřazených každé zprávě. CoAP poskytuje svůj vlastní mechanismus spolehlivosti pomocí zpráv s potvrzením a zpráv, které nelze potvrdit.

Potvrditelná zpráva (CON)

Potvrditelná zpráva (CON) je spolehlivá zpráva, kde klient stále odesílá zprávu pomocí výchozího časového limitu a mechanismu zpětného vypínání mezi opakovanými přenosy, dokud není ze serveru přijata potvrzovací zpráva (ACK) se stejným ID. Zprávy ACK mohou přenášet užitečná data užitečného zatížení a samy o sobě nepotřebují samostatné ACK.

Obrázek 4.4. Potvrditelná zpráva

V případě, že má server problém se zpracováním zprávy CON (např. když server nemůže poskytnout ani chybovou odpověď), odpoví namísto signálu ACK zprávou RST (reset message).

Obrázek 4.5. zpráva RST

Nepotvrditelné zprávy (NON)

Při výměně nekritických zpráv lze použít nespolehlivé NON zprávy, kdy server nepotvrdí příchod zpráv. Přestože zprávy NON nejsou potvrzeny, jsou jim přiřazena ID zpráv, aby bylo možné detekovat duplicitní zprávy.

Obrázek 4.6. Nepotvrditelná zpráva

CoAP na rozdíl od MQTT neposkytuje explicitní model úrovně QoS. Potvrditelné/nepotvrditelné typy zpráv však mohou být mapovány na sémantiku MQTT QoS. Tabulka 4.3 ukazuje mapování CoAP a MQTT QoS.

Tabulka4.3. CoAP a MQTT QoS mapování

B. Vrstva požadavků/odpovědí CoAP

Tato vrstva může odeslat požadavek pomocí zprávy CON nebo NON. Ve scénáři, kde je požadavek odeslán pomocí zprávy CON, server odpoví na zprávu ACK obsahující odpověď nebo chybový kód za předpokladu, že může odpovědět okamžitě. V takovém komunikačním schématu jsou požadavek a odpověď spárovány pomocí tokenu (tento token se liší od ID zprávy).

Obrázek 4.7. Požadavek/odpověď pomocí zpráv CON, když je odpověď serveru k dispozici okamžitě

V případě, že server nemůže okamžitě odpovědět, odešle jako odpověď ACK zprávu bez obsahu (prázdná odpověď). Jakmile je odpověď připravena, je klientovi odeslána nová zpráva CON obsahující odpověď. Po obdržení odpovědi to klient potvrdí. Všimněte si, že odpověď serveru bude také zprávou NON, pokud je požadavek zaslaný klientem také zprávou NON.

Obrázek 4.8. Požadavek/odpověď pomocí zpráv CON, když odpověď serveru není k dispozici okamžitě

C. Multicast Group Communications

CoAP podporuje skupinovou komunikaci (one-to-many nebo multicast), která umožňuje odeslání jednoho požadavku mnoha zařízením.

D. Pozorovatelé

Pozorovatelé snižují potřebu neustálého dotazování tím, že umožňují klientovi přijímat aktualizace na základě stavu subjektu. Jinými slovy, stav inteligentního objektu závisí na stavech ostatních zařízení, ke kterým je připojen. Příkladem pozorovatelů v akci je, když motor reaguje na senzor měřící rychlost otáčení generátoru a podle toho upravuje jeho rychlost. Stav klienta pozorovatele se neustále aktualizuje, dokud buď není potvrzena zpráva CON, nebo dokud klient neodešle explicitní zprávu o odstranění, nebo dokud nevyprší platnost posledního upozornění.

E. Zabezpečení CoAP

Stejně jako HTTP je i CoAP standardně protokol s prostým textem, což znamená, že pro zabezpečení komunikace je vyžadován další šifrovaný protokol jako obal. V CoAP je šifrování dat prováděno Datagram Transport Layer Security (DTLS) přes UDP pro zabezpečení a ochranu informací.

4.4 Advanced Message Queuing Protocol (AMQP)

AMQP je odlehčený protokol aplikační vrstvy optimalizovaný pro vyšší zabezpečení a spolehlivost, snadnější poskytování a interoperabilitu. Protokol AMQP podporuje architektury publikování/odběru (jako je MQTT) i žádost/odpověď (jako je CoAP). AMQP je protokol orientovaný na připojení (klient a broker musí před přenosem dat navázat spojení), protože jako přenosový protokol používá TCP. AMQP je považován za spolehlivý protokol se dvěma úrovněmi QoS pro doručování zpráv, včetně formátu unsettle (podobný MQTT QoS 0) a formátu settle (spolehlivý podobný MQTT QoS 1).

4.5 Srovnávací analýza protokolů IoT

Jak bylo vidět v předchozích podkapitolách, každý protokol IoT má svůj vlastní model přenosu dat. Například při porovnání dvou protokolů IoT, o kterých jsme hovořili dříve v této kapitole, MQTT a CoAP používají modely publikování/přihlášení a požadavky/odpověď. V MQTT se používá centrální zprostředkovatel k předávání přijatých zpráv od vydavatele odběratelům (MQTT může podporovat více vydavatelů a odběratelů pro stejné téma). Na druhou stranu, podobně jako HTTP, je CoAP v podstatě protokol one-to-one. MQTT je protokol orientovaný na události (klient zveřejní téma vždy, když dojde k aktualizaci), zatímco CoAP je vhodnější pro přenos stavu zařízení. Hlavní rozdíl mezi CoAP a MQTT vyplývá z požadavku MQTT, aby běžel na spolehlivém, bezztrátovém, uspořádaném, byte-streamovém doručovacím transportu, který efektivně nařizuje zásobník TCP/IP. CoAP na druhé straně běží nad UDP a poskytuje svůj vlastní mechanismus spolehlivosti pomocí potvrzovatelných a nepotvrditelných typů zpráv. Celkově provoz MQTT/TCP vyžaduje přibližně 10x více transakcí a datová režie je přibližně 100x vyšší ve srovnání s provozem CoAP/UDP pro 5bajtové užitečné zatížení. Charakteristiky protokolů IoT jsou shrnuty v tabulce 4.4 [7].

Tabulka 4.4. Charakteristika protokolů IoT

V závislosti na požadavcích na zasílání zpráv v případech použití IoT lze vybrat různé protokoly zasílání zpráv. To je důvod, proč je důležité porozumět síle a omezením každého protokolu, aby bylo možné určit jejich nejvhodnější aplikace. Tabulka 4.5 uvádí hodnocení a relativní analýzu čtyř široce přijímaných a používaných protokolů internetu věcí, o nichž se pojednává v této kapitole. Toto relativní srovnání z hlediska velikosti zprávy, spotřeby energie, šířky pásma, spolehlivosti, zabezpečení a interoperability atd. pomáhá získat vhled do výhod a nevýhod každého protokolu [7].

Při zvažování výběru MQTT a CoAP je třeba vzít v úvahu následující doporučení:

• Pro přenos dat IP přes sítě NB-IoT je preferován protokol CoAP.
• CoAP může poskytnout o 224 až 1 157 procent vyšší efektivitu užitečného zatížení ve srovnání s MQTT na bázi TCP/IP. Nabízí tedy vynikající přenosový výkon pro kapacitu sítě i řešení IoT.
• MQTT přes sítě NB-IoT se nedoporučuje kvůli velmi vysoké režii a zvýšenému počtu datových transakcí.
• MQTT je vhodné pro relativně dlouhotrvající připojení MQTT/TCP/IP, která přenášejí relativně velké objemy dat (např. telematické aplikace). U řešení IoT, která vyžadují přenos MQTT, je třeba zvážit jiné typy rádiových technologií, jako je LTE.

Tabulka4.5. Aplikační protokoly IoT: srovnávací analýza

@misc{bccampusChapterData,
	author = {},
	title = {{C}hapter 4: {D}ata {C}ommunication {P}rotocols for {I}o{T} \– {C}ellular {I}nternet of {T}hings for {P}ractitioners --- pressbooks.bccampus.ca},
	howpublished = {\url{https://pressbooks.bccampus.ca/cellulariot/chapter/chapter-4/}},
	year = {},
	note = {[Accessed 28-02-2025]},
}