U sviluppu di e tecnulugia in u campu di u software è u hardware, l'emergenza di novi protokolli di cumunicazione anu purtatu à l'espansione di l'Internet of Things (IoT). U numeru di i dispusitivi cresce ghjornu per ghjornu è generanu una quantità enorme di dati. Dunque, ci hè bisognu di una architettura di sistema cunvene capace di trasfurmà, almacenà è trasmette sta dati.
Avà i servizii di nuvola sò usati per questi scopi. Tuttavia, u paradigma di nebbia computing sempre più populari (Fog) pò cumplementà e soluzioni di nuvola scalendu è ottimizendu l'infrastruttura IoT.
I nuvuli sò capaci di copre a maiò parte di e dumande IoT. Per esempiu, per furnisce u monitoraghju di i servizii, trasfurmazioni veloci di ogni quantità di dati generati da i dispositi, è ancu a so visualizazione. L'informatica di nebbia hè più efficace per risolve i prublemi in tempu reale. Forniscenu una risposta rapida à e dumande è una latenza minima in u trattamentu di dati. Questu hè, Fog cumplementa i "nuvuli" è espansione e so capacità.
Tuttavia, a quistione principale hè diversa: cumu si deve interagisce tuttu questu in u cuntestu di l'IoT? Chì protokolli di cumunicazione seranu più efficaci quandu travaglià in un sistema cumminatu IoT-Fog-Cloud?
Malgradu l'apparente dominanza di HTTP, ci sò un gran numaru d'altri suluzioni utilizati in sistemi IoT, Fog è Cloud. Questu hè chì l'IoT deve cumminà a funziunalità di una varietà di sensori di u dispositivu cù a sicurità, a cumpatibilità è altre esigenze di l'utilizatori.
Ma ùn ci hè solu una idea unica nantu à l'architettura di riferimentu è u standard di cumunicazione. Per quessa, a creazione di un novu protokollu o mudificà un esistenti per e funzioni IoT specifiche hè unu di i travaglii più impurtanti chì affruntà a cumunità IT.
Chì protokolli sò attualmente in usu è chì ponu offre? Scupritemu. Ma prima, discutemu i principii di l'ecosistema in quale nuvole, nebbia è Internet di e cose interagiscenu.
Architettura IoT Fog-to-Cloud (F2C).
Avete prubabilmente nutatu quantu sforzu hè fattu per esplorà i vantaghji è i benefici assuciati à una gestione intelligente è coordinata di l'IoT, u nuvulu è a nebbia. Se no, allora quì sò trè iniziative di standardizazione: , и .
Se prima sò stati cunsiderati solu 2 livelli, nuvole è dispositivi finali, allora l'architettura pruposta introduce un novu livellu - l'informatica di nebbia. In questu casu, u nivellu di nebbia pò esse divisu in parechji sublevels, secondu a specificità di risorse o un inseme di pulitiche chì determinanu l'usu di diversi dispusitivi in questi sublevels.
Chì puderia esse sta astrazione? Eccu un tipicu ecosistema IoT-Fog-Cloud. I dispositi IoT mandanu dati à i servitori più veloci è i dispositi di l'informatica per risolve i prublemi chì necessitanu una latenza bassa. In u listessu sistema, i nuvuli sò rispunsevuli di risolve i prublemi chì necessitanu una grande quantità di risorse informatiche o spaziu di almacenamiento di dati.
Smartphones, smart watches è altri gadgets ponu ancu esse parti di l'IoT. Ma tali dispusitivi, in regula, utilizanu protokolli di cumunicazione privati di grandi sviluppatori. I dati IoT generati sò trasferiti à a capa di nebbia via u protocolu REST HTTP, chì furnisce flessibilità è interoperabilità quandu creanu servizii RESTful. Questu hè impurtante in vista di a necessità di assicurà a cumpatibilità inversa cù l'infrastruttura di l'informatica esistente in esecuzione nantu à l'urdinatori lucali, i servitori o un cluster di servitori. I risorsi lucali, chjamati "nodi di nebbia", filtranu i dati ricevuti è processanu in u locu o mandanu à u nuvulu per più calculi.
Nuvole supportanu diversi protokolli di cumunicazione, i più cumuni sò AMQP è REST HTTP. Siccomu HTTP hè ben cunnisciutu è adattatu per Internet, a quistione pò esse: "Ùn duvemu micca aduprà per travaglià cù IoT è nebbia?" Tuttavia, stu protocolu hà prublemi di rendiment. Più nantu à questu dopu.
In generale, ci sò 2 mudelli di protokolli di cumunicazione adattati per u sistema chì avemu bisognu. Quessi sò dumanda-risposta è publicazione-subscribe. U primu mudellu hè più cunnisciutu, in particulare in l'architettura di u servitore-cliente. U cliente dumanda infurmazione da u servitore, è u servitore riceve a dumanda, u processa è torna un missaghju di risposta. I protokolli REST HTTP è CoAP operanu nantu à stu mudellu.
U sicondu mudellu hè natu da a necessità di furnisce un accoppiamentu asincronu, distribuitu, scioltu trà e fonti chì generanu dati è i destinatari di sti dati.
U mudellu assume trè participanti: un editore (fonte di dati), un broker (dispatcher) è un abbonatu (ricevitore). Quì, u cliente chì agisce cum'è abbonatu ùn deve micca dumandà infurmazione da u servitore. Invece d'invià e dumande, sottumette à certi avvenimenti in u sistema per mezu di un broker, chì hè rispunsevuli di filtrà tutti i messagi entranti è di indirizzà trà editori è abbonati. È l'editore, quandu un avvenimentu accade in un certu tema, u publica à u broker, chì manda dati nantu à u tema dumandatu à l'abbonatu.
Essenzialmente, questa architettura hè basatu annantu à l'avvenimenti. E stu mudellu d'interazzione hè interessante per l'applicazioni in IoT, nuvola, nebbia per via di a so capacità di furnisce scalabilità è simplificà l'interconnessione trà e diverse dispusitivi, supportanu a cumunicazione dinamica assai à parechji è a cumunicazione asincrona. Unipochi di i protokolli di messageria standardizati più cunnisciuti chì utilizanu un mudellu di pubblicazione-abbonamentu includenu MQTT, AMQP è DDS.
Ovviamente, u mudellu di pubblicazione-abbonamentu hà assai vantaghji:
- L'editori è l'abbonati ùn anu micca bisognu di sapè l'esistenza di l'altri;
- Un abbonatu pò riceve infurmazioni da parechje publicazioni diffirenti, è un editore pò mandà dati à parechji abbonati diffirenti (principiu di parechji à parechji);
- L'editore è l'abbonatu ùn anu micca esse attivu à u stessu tempu per cumunicà, perchè u broker (travagliu cum'è un sistema di fila) puderà almacenà u messagiu per i clienti chì ùn sò micca attualmente cunnessi à a reta.
Tuttavia, u mudellu di dumanda-risposta hà ancu i so punti di forza. In i casi induve a capacità di u latu di u servitore per trattà parechje richieste di u cliente ùn hè micca un prublema, hè sensu di utilizà suluzioni pruvati è affidabili.
Ci sò ancu protokolli chì supportanu i dui mudelli. Per esempiu, XMPP è HTTP 2.0, chì supportanu l'opzione "server push". L'IETF hà ancu publicatu un CoAP. In un tentativu di risolve u prublema di messageria, parechje altre soluzioni sò state create, cum'è u protokollu WebSockets o l'usu di u protocolu HTTP per QUIC (Quick UDP Internet Connections).
In u casu di WebSockets, ancu s'ellu hè utilizatu per trasfiriri dati in tempu reale da un servitore à un cliente web è furnisce cunnessione persistenti cù cumunicazione bidirezionale simultanea, ùn hè micca pensatu per i dispositi cù risorse informatiche limitate. QUIC meriteghja ancu attenzione, postu chì u novu protocolu di trasportu furnisce assai novi opportunità. Ma postu chì QUIC ùn hè ancu standardizatu, hè prematuru predichendu a so applicazione possibbili è l'impattu nantu à e soluzioni IoT. Allora mantenemu WebSockets è QUIC in mente cun un ochju à u futuru, ma ùn l'avemu micca studiatu in più detail per avà.
Quale hè u più cutest in u mondu: paragunà i protokolli
Avà parlemu di i punti di forza è di debule di i protokolli. Fighjendu avanti, facemu subitu una riservazione chì ùn ci hè nimu capu chjaru. Ogni protokollu hà qualchi vantaghji / svantaghji.
U tempu di risposta
Una di e caratteristiche più impurtanti di i protokolli di cumunicazione, in particulare in relazione à l'Internet di e Cose, hè u tempu di risposta. Ma trà i protokolli esistenti, ùn ci hè micca un vincitore chjaru chì dimustra u livellu minimu di latenza quandu travaglia in diverse cundizioni. Ma ci hè una mansa di ricerca è paraguni di capacità di protokollu.
Per esempiu, paraguni di l'efficacezza di HTTP è MQTT quandu u travagliu cù l'IoT hà dimustratu chì u tempu di risposta per e dumande per MQTT hè menu cà per HTTP. È quandu U tempu di andata (RTT) di MQTT è CoAP hà revelatu chì u RTT mediu di CoAP hè 20% menu di quellu di MQTT.
Altru cù RTT per i protokolli MQTT è CoAP hè statu realizatu in dui scenarii: rete locale è rete IoT. Hè risultatu chì a media RTT hè 2-3 volte più altu in una reta IoT. MQTT cù QoS0 hà dimustratu un risultatu più bassu cumparatu cù CoAP, è MQTT cù QoS1 hà dimustratu un RTT più altu per via di ACK à l'applicazione è i strati di trasportu. Per diversi livelli di QoS, a latenza di a rete senza congestione era millisecondi per MQTT, è centinaie di microsecondi per CoAP. Tuttavia, vale a pena ricurdà chì quandu si travaglia nantu à e rete menu affidabili, MQTT chì corre nantu à TCP mostrarà un risultatu completamente diversu.
U tempu di risposta per i protokolli AMQP è MQTT aumentendu a carica utile hà dimustratu chì cù una carica ligera u livellu di latenza hè quasi u listessu. Ma quandu si trasferisce una grande quantità di dati, MQTT mostra tempi di risposta più brevi. in unu di più CoAP hè statu paragunatu à HTTP in un scenariu di cumunicazione machine-to-machine cù i dispositi disposti nantu à i veiculi equipati di sensori di gas, sensori di u clima, sensori di locu (GPS) è una interfaccia di rete mobile (GPRS). U tempu necessariu per trasmette un missaghju CoAP nantu à a reta mobile era quasi trè volte più cortu di u tempu necessariu per utilizà missaghji HTTP.
Studi sò stati fatti chì paragunanu micca dui, ma trè protokolli. Per esempiu, prestazioni di i protokolli IoT MQTT, DDS è CoAP in un scenariu di applicazione medica utilizendu un emulatore di rete. DDS superò MQTT in termini di latenza di telemetria testata in una varietà di cundizioni di rete poveri. U CoAP basatu in UDP hà travagliatu bè per l'applicazioni chì necessitavanu tempi di risposta veloci, però, per via di esse basatu in UDP, ci era una perdita di pacchetti imprevisible significativa.
Banda larga
MQTT è CoAP in quantu à l'efficienza di larghezza di banda hè stata realizata cum'è un calculu di a quantità totale di dati trasmessi per messagiu. CoAP hà dimustratu un rendimentu più bassu cà MQTT quandu trasmette picculi missaghji. Ma quandu paragunate l'efficienza di i protokolli in quantu à u rapportu di u numeru di bytes d'informazioni utili à u numeru tutale di bytes trasferiti, CoAP hè diventatu più efficace.
à utilizendu MQTT, DDS (cù TCP cum'è u protokollu di trasportu) è a larghezza di banda CoAP, hè stata trovata chì CoAP generalmente mostrava un cunsumu di larghezza di banda comparativamente più bassu, chì ùn aumentava micca cù a perdita di pacchetti di rete o una latenza di rete aumentata, à u cuntrariu di MQTT è DDS, induve ci era un aumentu di l'utilizazione di larghezza di banda in i scenarii citati. Un altru scenariu implicava un gran numaru di dispusitivi chì trasmettenu dati simultaneamente, chì hè tipicu in ambienti IoT. I risultati anu dimustratu chì per un usu più altu hè megliu aduprà CoAP.
Sottu carica ligera, CoAP hà utilizatu u minimu larghezza di banda, seguita da MQTT è REST HTTP. In ogni casu, quandu a dimensione di e carichi utili aumentanu, REST HTTP hà avutu i migliori risultati.
U cunsumu
U prublema di u cunsumu d'energia hè sempre di grande impurtanza, è soprattuttu in un sistema IoT. Se Mentre MQTT è HTTP cunsuma l'electricità, HTTP cunsuma assai più. E CoAP hè più paragunatu à MQTT, chì permette a gestione di l'energia. In ogni casu, in scenarii simplici, MQTT hè più adattatu per scambià infurmazioni in rete Internet di e cose, soprattuttu s'ellu ùn ci hè micca restrizioni di putere.
Un esperimentu chì paragunò e capacità di AMQP è MQTT in un testbed di rete wireless mobile o inestabile hà truvatu chì AMQP offre più capacità di sicurezza mentre MQTT hè più efficiente energeticamente.
Seguretat
A sicurezza hè un altru prublema criticu suscitatu quandu si studia u tema di l'Internet di e Cose è a nebbia / cloud computing. U mecanismu di sicurità hè tipicamente basatu nantu à TLS in HTTP, MQTT, AMQP è XMPP, o DTLS in CoAP, è sustene e duie varianti DDS.
TLS è DTLS cumincianu cù u prucessu di stabilisce a cumunicazione trà i lati di u cliente è di u servitore per scambià suite è chjave di cifru supportati. I dui partiti negocianu setti per assicurà chì più cumunicazione si faci nantu à un canale sicuru. A diffarenza trà i dui si trova in picculi mudificazioni chì permettenu à DTLS basatu in UDP di travaglià nantu à una cunnessione inaffidabile.
à Diversi implementazioni diffirenti di TLS è DTLS anu truvatu chì TLS hà fattu un travagliu megliu. L'attacchi à DTLS anu più successu per via di a so toleranza à l'errore.
In ogni casu, u prublema più grande cù questi protokolli hè chì ùn sò micca stati urigginariamenti pensati per l'usu in IoT è ùn sò micca destinati à travaglià in a nebbia o nuvola. Attraversu handshaking, aghjunghjenu trafficu supplementu cù ogni stabilimentu di cunnessione, chì drena risorse di computing. In media, ci hè un aumentu di 6,5% per TLS è 11% per DTLS in overhead paragunatu à e cumunicazioni senza una capa di sicurezza. In ambienti ricchi di risorse, chì sò tipicamente situati nantu livellu, stu ùn sarà un prublema, ma in a cunnessione trà IoT è livellu nebbia, sta diventa una limitazione impurtante.
Cosa à sceglie? Ùn ci hè una risposta chjara. MQTT è HTTP parenu esse i protokolli più promettenti postu chì sò cunsiderate solu suluzione IoT comparativamente più mature è più stabile cumparatu cù altri protokolli.
Soluzioni basate nantu à un protocolu di cumunicazione unificatu
A pratica di una suluzione unicu protocolu hà assai disadvantages. Per esempiu, un protokollu chì si adatta à un ambiente ristrettu ùn pò micca travaglià in un duminiu chì hà stretti requisiti di sicurezza. Cù questu in mente, avemu da scaccià quasi tutte e pussibuli suluzioni unicu protokollu in l'ecosistema Fog-to-Cloud in IoT, eccettu MQTT è REST HTTP.
REST HTTP cum'è una suluzione unicu protocolu
Ci hè un bon esempiu di cumu e dumande HTTP REST è risposte interagiscenu in u spaziu IoT-to-Fog: . L'animali sò dotati di sensori wearable (client IoT, C) è cuntrullati via cloud computing da un sistema di agricultura intelligente (server Fog, S).
L'intestazione di u metudu POST specifica a risorsa per mudificà (/farm/animals) è ancu a versione HTTP è u tipu di cuntenutu, chì in questu casu hè un oggettu JSON chì rapprisenta a splutazioni d'animali chì u sistema hè di gestisce (Dulcinea/vacca) . A risposta da u servitore indica chì a dumanda hè stata successu mandendu u codice di statutu HTTPS 201 (risorsa creata). U metudu GET deve specificà solu a risorsa dumandata in l'URI (per esempiu, /farm/animals/1), chì torna una rapprisintazioni JSON di l'animali cù quellu ID da u servitore.
U metudu PUT hè utilizatu quandu qualchì registru di risorse specifiche deve esse aghjurnatu. In questu casu, a risorsa specifica l'URI per u paràmetru per esse cambiatu è u valore attuale (per esempiu, indicà chì a vacca hè in marchja, /farm/animals/1? state=walking). Infine, u metudu DELETE hè utilizatu ugualmente à u metudu GET, ma simpricimenti sguassate a risorsa com'è u risultatu di l'operazione.
MQTT cum'è una suluzione unicu protocolu
Pigliemu a stessa splutazioni intelligente, ma invece di REST HTTP usemu u protocolu MQTT. Un servitore lucale cù a biblioteca Mosquitto installata agisce cum'è un broker. In questu esempiu, un urdinatore simplice (riferitu cum'è u servitore agriculu) Raspberry Pi serve cum'è un cliente MQTT, implementatu attraversu una stallazione di a biblioteca Paho MQTT, chì hè cumplettamente cumpatibile cù u broker Mosquitto.
Stu cliente currisponde à una strata di astrazione IoT chì rapprisenta un dispositivu cù capacità di sensazione è di calculu. U mediatore, invece, currisponde à un livellu più altu di astrazione, chì rapprisenta un nodu di computing di nebbia carattarizatu da una più grande capacità di trasfurmazioni è di almacenamiento.
In u scenariu di a splutazioni intelligente pruposta, u Raspberry Pi si cunnetta à l'accelerometru, GPS è sensori di temperatura è publica dati da questi sensori à un node di nebbia. Cum'è probabilmente sapete, MQTT tratta i temi cum'è una gerarchia. Un solu editore MQTT pò publicà missaghji à un settore specificu di temi. In u nostru casu, ci sò trè. Per un sensoru chì misura a temperatura in una stalla d'animali, u cliente sceglie un tema (animalfarm/shed/temperature). Per i sensori chì misuranu u locu GPS è u muvimentu di l'animali attraversu l'accelerometru, u cliente publicarà l'aghjurnamenti à (animalfarm/animal/GPS) è (animalfarm/animal/movement).
Questa informazione serà trasmessa à u broker, chì pò temporaneamente almacenà in una basa di dati lucale in casu chì un altru abbonatu interessatu vene dopu.
In più di u servitore lucale, chì agisce cum'è un broker MQTT in a nebbia è à quale Raspberry Pis, cum'è clienti MQTT, manda dati di sensori, pò esse un altru broker MQTT à u nivellu di nuvola. In questu casu, l'infurmazioni trasmessi à u broker lucale pò esse temporaneamente guardatu in una basa di dati lucali è / o mandati à u nuvulu. U broker MQTT di nebbia in questa situazione hè utilizatu per associà tutte e dati cù u broker MQTT nuvola. Cù sta architettura, un utilizatore di l'applicazione mobile pò esse abbonatu à i dui brokers.
Se a cunnessione à unu di i brokers (per esempiu, nuvola) falla, l'utilizatore finale riceverà infurmazioni da l'altru (nebbia). Questa hè una caratteristica di i sistemi cumminati di nebbia è cloud computing. Per automaticamente, l'app mobile pò esse cunfigurata per cunnette à u broker MQTT di nebbia prima, è se falla, per cunnette à u broker MQTT nuvola. Questa suluzione hè solu una di parechje in sistemi IoT-F2C.
Soluzioni multiprotocolu
Soluzioni di protokollu unicu sò populari per via di a so implementazione più faciule. Ma hè chjaru chì in i sistemi IoT-F2C hè sensu di cumminà diversi protokolli. L'idea hè chì diversi protokolli ponu operare à diversi livelli. Pigliate, per esempiu, trè astrazioni: i strati di IoT, nebbia è cloud computing. I dispositi à u livellu IoT sò generalmente cunsiderati limitati. Per questa panoramica, cunsideremu i livelli IoT cum'è i più limitati, nuvola u menu limitatu, è l'informatica di nebbia cum'è "in un locu à mezu". Risulta allora chì trà l'IoT è l'astrazioni di nebbia, e soluzioni attuali di protokollu includenu MQTT, CoAP è XMPP. Trà nebbia è nuvola, invece, AMQP hè unu di i protokolli principali utilizati, cù REST HTTP, chì per via di a so flessibilità hè ancu utilizatu trà IoT è strati di nebbia.
U prublema principali quì hè l'interoperabilità di i protokolli è a facilità di trasferimentu di missaghji da un protokollu à l'altru. Ideale, in u futuru, l'architettura di un sistema di Internet di e cose cù risorse di nuvola è nebbia serà indipendente da u protocolu di cumunicazione utilizatu è assicurerà una bona interoperabilità trà i diversi protokolli.
Siccomu questu ùn hè micca attualmente u casu, hè sensu di cumminà protokolli chì ùn anu micca differenze significative. Per questu scopu, una suluzione potenziale hè basata nantu à una cumminazione di dui protokolli chì seguitanu u listessu stile architettonicu, REST HTTP è CoAP. Un'altra suluzione pruposta hè basatu annantu à una cumminazione di dui protokolli chì offrenu cumunicazione publicazione-abbonamenti, MQTT è AMQP. Utilizà cuncetti simili (sia MQTT è AMQP usanu brokers, CoAP è HTTP usanu REST) rende queste cumminazioni più faciule da implementà è richiede menu sforzu di integrazione.
A figura (a) mostra dui mudelli basati nantu à a dumanda di risposta, HTTP è CoAP, è a so pussibile piazzamentu in una soluzione IoT-F2C. Siccomu HTTP hè unu di i protokolli più cunnisciuti è aduttati nantu à e rete muderne, hè improbabile chì serà sustituitu cumpletamente da altri protokolli di messageria. Trà i nodi chì rapprisentanu i dispositi putenti chì si trovanu trà u nuvulu è a nebbia, REST HTTP hè una suluzione intelligente.
Per d 'altra banda, per i dispositi cù risorse informatiche limitate chì cumunicanu trà i strati Fog è IoT, hè più efficaci à utilizà CoAP. Unu di i grandi vantaghji di CoAP hè in realtà a so cumpatibilità cù HTTP, postu chì i dui protokolli sò basati nantu à i principii REST.
A figura (b) mostra dui mudelli di cumunicazione publicazione-abbonamenti in u stessu scenariu, cumprese MQTT è AMQP. Ancu se i dui protokolli puderanu esse ipoteticamente utilizati per a cumunicazione trà i nodi in ogni strata di astrazione, a so pusizione deve esse determinata in basa di u rendiment. MQTT hè statu cuncepitu cum'è un protokollu ligeru per i dispositi cù risorse informatiche limitate, cusì pò esse usatu per a cumunicazione IoT-Fog. AMQP hè più adattatu per i dispositi più putenti, chì idealmente u pusissinu trà i nodi di nebbia è di nuvola. Invece di MQTT, u protocolu XMPP pò esse usatu in IoT postu chì hè cunsideratu ligeru. Ma ùn hè micca cusì largamente utilizatu in tali scenarii.
scuperti
Hè improbabile chì unu di i protokolli discututi serà abbastanza per copre tutte e cumunicazioni in un sistema, da i dispositi cù risorse informatiche limitate à i servitori di nuvola. U studiu hà truvatu chì e duie opzioni più promettenti chì i sviluppatori usanu più sò MQTT è RESTful HTTP. Questi dui protokolli ùn sò micca solu i più maturi è stabili, ma includenu ancu assai implementazioni ben documentate è riescite è risorse in linea.
A causa di a so stabilità è a so cunfigurazione simplice, MQTT hè un protokollu chì hà dimustratu a so prestazione superiore cù u tempu quandu s'utilice à u livellu IoT cù i dispositi limitati. In parti di u sistema induve a cumunicazione limitata è u cunsumu di bateria ùn sò micca un prublema, cum'è certi domini di nebbia è a maiò parte di l'informatica in nuvola, RESTful HTTP hè una scelta faciule. CoAP deve ancu esse cunsideratu cum'è hè ancu in evoluzione rapida cum'è un standard di messageria IoT è hè prubabile chì ghjunghje à un livellu di stabilità è maturità simili à MQTT è HTTP in un futuru vicinu. Ma u standard hè attualmente in evoluzione, chì vene cun prublemi di cumpatibilità à cortu termine.
Chì altru pudete leghje nantu à u blog?
→
→
→
→
→
Abbonate à u nostru -canale, per ùn mancà u prossimu articulu ! Scrivemu micca più di duie volte à settimana è solu nantu à l'affari.
Source: www.habr.com