Lo sviluppo delle tecnologie nel campo del software e dell'hardware, l'emergere di nuovi protocolli di comunicazione ha portato all'espansione dell'Internet delle Cose (IoT). Il numero di dispositivi cresce giorno dopo giorno e generano enormi volumi di dati. Pertanto, si presenta la necessità di un'architettura di sistema conveniente in grado di elaborare, memorizzare e trasmettere questi dati.
Attualmente, per questi scopi si utilizzano servizi cloud. Tuttavia, la crescente popolarità della nuova paradigma del calcolo fog (Fog) è in grado di completare le soluzioni cloud, scalando e ottimizzando l'infrastruttura IoT.
"Le nuvole" sono in grado di soddisfare la maggior parte delle richieste IoT. Ad esempio, possono garantire il monitoraggio dei servizi, l'elaborazione rapida di qualsiasi volume di dati generati dai dispositivi, nonché la loro visualizzazione. Il calcolo fog, invece, è più efficace nella risoluzione di compiti in tempo reale. Garantisce una risposta rapida alle richieste e una latenza minima nell'elaborazione dei dati. Cioè, Fog completa proprio "le nuvole", ampliandone le capacità.
Tuttavia, la domanda principale è un'altra: come dovrebbero interagire tutte queste componenti nel contesto dell'IoT? Quali protocolli di comunicazione saranno più efficaci nel funzionamento del sistema integrato IoT-Fog-Cloud?
Nonostante il presunto dominio di HTTP, in sistemi IoT, Fog e Cloud vengono utilizzate numerose altre soluzioni. Questo è spiegato dal fatto che IoT deve combinare le capacità funzionali dei vari sensori dei dispositivi con la sicurezza, la compatibilità e altri requisiti posti dagli utenti.
Eppure, non esiste una visione univoca di un'architettura di riferimento e di uno standard di comunicazione. Dunque, la creazione di un nuovo protocollo o l'adattamento di uno esistente per compiti specifici dell'IoT rappresenta uno dei compiti più importanti che l'IT community deve affrontare.
Quali protocolli vengono utilizzati attualmente e cosa possono offrire? Cerchiamo di capirlo. Ma prima discutiamo i principi dell'ecosistema in cui interagiscono cloud, fog e internet delle cose.
Architettura IoT Fog-to-Cloud (F2C)
Avrete sicuramente notato quanti sforzi significativi vengono impiegati per studiare i vantaggi e i benefici associati a una gestione razionale e coordinata di IoT, cloud e fog. Se non lo avete fatto, ecco tre iniziative per la standardizzazione: , e .
Se prima si consideravano solo 2 livelli, nuvole e dispositivi finali, l'architettura proposta introduce un nuovo livello: il calcolo fog. In questo, il livello di nebbia può essere suddiviso in diversi sottolivelli, a seconda della specificità delle risorse o dell'insieme di politiche che definiscono l'uso di diversi dispositivi in questi sottolivelli.
Come può apparire questa astrazione? Ecco un tipico ecosistema IoT-Fog-Cloud. I dispositivi IoT inviano dati a server e dispositivi di calcolo più potenti per risolvere problemi che richiedono un basso livello di latenza. In questo sistema, le nuvole sono responsabili della soluzione di compiti che richiedono un alto volume di risorse di calcolo o spazio di archiviazione.
Smartphone, smartwatch e altri gadget possono essere parte dell'IoT. Tuttavia, tali dispositivi generalmente utilizzano protocolli di comunicazione proprietari di grandi sviluppatori. I dati generati dall'internet delle cose vengono trasmessi al livello di nebbia tramite il protocollo REST HTTP, che garantisce flessibilità e interoperabilità nella creazione di servizi RESTful. Questo è importante alla luce della necessità di garantire la retrocompatibilità con l'infrastruttura di calcolo esistente, operante su computer locali, server o cluster di server. Le risorse locali, chiamate "nodi di nebbia", filtrano i dati ricevuti e li elaborano localmente o li inoltrano al cloud per ulteriori elaborazioni.
Le nuvole supportano diversi protocolli di comunicazione, tra cui AMQP e REST HTTP, i più comuni. Poiché HTTP è ampiamente noto e progettato per il web, può sorgere la domanda: "perché non usarlo per lavorare con IoT e nebbia?". Tuttavia, questo protocollo ha problemi di prestazioni, di cui parleremo dopo.
In generale, esistono 2 modelli di protocolli di comunicazione adatti al nostro sistema. Questo è il modello richiesta-risposta e quello pubblicazione-sottoscrizione. Il primo modello è maggiormente noto, soprattutto nell'architettura client-server. Il client richiede informazioni al server, il quale riceve la richiesta, la elabora e restituisce un messaggio di risposta. Questo modello è utilizzato dai protocolli REST HTTP e CoAP.
Il secondo modello è emerso dalla necessità di garantire una connessione asincrona, distribuita e debole tra le fonti che generano dati e i destinatari di tali dati.
Il modello prevede tre partecipanti: l'editore (fonte dei dati), il broker (dispatcher) e l'abbonato (destinatario). Qui il client, che funge da abbonato, non deve richiedere informazioni al server. Invece di inviare richieste, si iscrive a determinati eventi nel sistema tramite il broker, responsabile della filtrazione di tutti i messaggi in arrivo e del loro instradamento tra editori e abbonati. Quando si verifica un evento relativo a un tema specifico, l'editore lo pubblica al broker, che invia i dati all'abbonato sul tema richiesto.
In sostanza, questa architettura si basa sugli eventi. E un tale modello di interazione è interessante per le applicazioni in IoT, cloud e fog computing, grazie alla sua capacità di garantire scalabilità e semplificare le interazioni tra vari dispositivi, supportando una connessione dinamica "molti a molti" e una comunicazione asincrona. Tra i protocolli di messaggistica standardizzati più conosciuti che utilizzano il modello "pubblicazione-sottoscrizione", possiamo citare MQTT, AMQP e DDS.
È evidente che il modello "pubblicazione-sottoscrizione" presenta numerosi vantaggi:
- Gli editori e gli abbonati non devono conoscere l'esistenza l'uno dell'altro;
- Un abbonato può ricevere informazioni da molteplici pubblicazioni diverse e un editore può inviare dati a molti abbonati diversi (principio "molti a molti");
- Editore e abbonato non devono essere attivi contemporaneamente per scambiare dati, poiché il broker (che funge da sistema di code) può memorizzare il messaggio per i clienti che non sono attualmente connessi alla rete.
Tuttavia, anche il modello "richiesta-risposta" ha i suoi punti di forza. Nei casi in cui le capacità lato server per gestire le richieste di più clienti non siano un problema, ha senso utilizzare soluzioni consolidate e affidabili.
Ci sono anche protocolli che supportano entrambi i modelli. Ad esempio, XMPP e HTTP 2.0, che supportano l'opzione «server push». L'IETF ha inoltre rilasciato CoAP. Nel tentativo di affrontare il problema dello scambio di messaggi, sono state create diverse altre soluzioni, come il protocollo WebSockets o l'uso del protocollo HTTP tramite QUIC (Quick UDP Internet Connections).
Nel caso di WebSockets, sebbene venga utilizzato per trasmettere dati in tempo reale dal server al web client e garantisca connessioni permanenti con una comunicazione bidirezionale simultanea, non è progettato per dispositivi con risorse computazionali limitate. Anche QUIC merita attenzione, poiché il nuovo protocollo di trasporto offre molte nuove opportunità. Ma dato che QUIC non è ancora standardizzato, è prematuro prevedere il suo possibile utilizzo e impatto sulle soluzioni nel settore IoT. Pertanto, lasciamo WebSockets e QUIC nella memoria con uno sguardo verso il futuro, ma per ora non li approfondiremo.
Chi è il più gentile del mondo: confrontiamo i protocolli
Ora parliamo dei punti di forza e di debolezza dei protocolli. Anticipiamo subito che non c'è un chiaro leader. Ci sono vantaggi/svantaggi per ogni protocollo.
Tempo di risposta
Una delle caratteristiche più importanti dei protocolli di comunicazione, soprattutto in relazione all'Internet delle cose, è il tempo di risposta. Tuttavia, tra i protocolli esistenti non c'è un vincitore assoluto che dimostri il livello minimo di latenza in diverse condizioni. Ci sono però molti studi e confronti delle capacità dei protocolli.
Ad esempio, Confronti sull'efficienza di HTTP e MQTT nel lavoro con l'IoT hanno mostrato che il tempo di risposta per le richieste di MQTT è inferiore rispetto a quello di HTTP. E durante del tempo di round trip (RTT) di MQTT e CoAP è emerso che l'RTT medio di CoAP è inferiore del 20% rispetto a quello di MQTT.
Altro L'RTT dei protocolli MQTT e CoAP è stato testato in due scenari: rete locale e rete IoT. Si è scoperto che l'RTT medio è da 2 a 3 volte più alto nella rete IoT. MQTT con QoS0 ha mostrato risultati più bassi rispetto a CoAP, mentre MQTT con QoS1 ha dimostrato un RTT più elevato grazie agli ACK ai livelli applicativo e di trasporto. Per diversi livelli di QoS, le latenze nella rete senza sovraccarico per MQTT sono state di millisecondi, mentre per CoAP sono state di centinaia di microsecondi. Tuttavia, è importante ricordare che nel funzionamento in reti meno affidabili, MQTT, che opera su TCP, mostrerà risultati completamente diversi.
Il tempo di risposta dei protocolli AMQP e MQTT aumentando il payload ha mostrato che con carichi leggeri il livello di latenza è quasi identico. Ma nella trasmissione di grandi volumi di dati, MQTT dimostra un tempo di risposta inferiore. In un altro CoAP è stato confrontato con HTTP in uno scenario di comunicazione machine-to-machine con dispositivi distribuiti su veicoli e dotati di sensori di gas, sensori meteorologici, posizione (GPS) e interfaccia mobile (GPRS). Il tempo necessario per trasmettere un messaggio CoAP attraverso la rete mobile è stato quasi tre volte inferiore rispetto al tempo necessario per utilizzare i messaggi HTTP.
Sono stati condotti studi in cui non sono stati confrontati due, ma tre protocolli. Ad esempio, le prestazioni dei protocolli IoT MQTT, DDS e CoAP in uno scenario di applicazione medica utilizzando un emulatore di rete. DDS ha superato MQTT in termini di latenza di telemetria sperimentata in varie condizioni di rete scadenti. CoAP basato su UDP ha funzionato bene per le applicazioni che richiedevano una risposta rapida, tuttavia, poiché è basato su UDP, si sono verificate perdite di pacchetti significative e imprevedibili.
Larghezza di banda
MQTT e CoAP in termini di efficienza nell'uso della larghezza di banda sono stati valutati calcolando il totale dei dati trasmessi per singolo messaggio. CoAP ha mostrato una minore larghezza di banda rispetto a MQTT nella trasmissione di piccoli messaggi. Tuttavia, confrontando l'efficienza dei protocolli in termini di rapporto tra il numero di byte informativi utili e il totale dei byte trasferiti, CoAP è risultato più efficiente.
Durante sull'uso della larghezza di banda di MQTT, DDS (con TCP come protocollo di trasporto) e CoAP è emerso che CoAP mostrava generalmente un consumo di larghezza di banda relativamente più basso, che non aumentava con l'aumento delle perdite di pacchetti di rete o il ritardo nella rete, a differenza di MQTT e DDS, dove in scenari menzionati si è notato un aumento nell'uso della larghezza di banda. In un altro scenario è stato coinvolto un gran numero di dispositivi che trasmettevano dati simultaneamente, un caso tipico negli ambienti IoT. I risultati hanno mostrato che per carichi più elevati è preferibile utilizzare CoAP.
Con carichi leggeri, CoAP ha utilizzato la minore larghezza di banda, seguito da MQTT e REST HTTP. Tuttavia, quando le dimensioni dei payload sono aumentate, i migliori risultati sono stati ottenuti da REST HTTP.
Consumo energetico
La questione del consumo energetico è sempre di grande importanza, e nel sistema IoT - in particolare. il consumo di energia tra MQTT e HTTP, HTTP "consuma" molto di più. CoAP, invece, è più rispetto a MQTT, permettendo una gestione più semplice dell'alimentazione. In questo senso, in scenari semplici, MQTT è più adatto per lo scambio di informazioni nelle reti di Internet delle cose, soprattutto se non ci sono restrizioni di potenza.
Un esperimento, durante il quale sono state confrontate le capacità di AMQP e MQTT su un banco di prova di una rete wireless mobile o instabile, ha mostrato che AMQP offre maggiori possibilità in termini di sicurezza, mentre MQTT è più energeticamente efficiente.
Sicurezza
La sicurezza è un'altra questione di primaria importanza sollevata nello studio dell'Internet delle cose e del cloud/fog computing. Il meccanismo di sicurezza si basa solitamente su TLS in HTTP, MQTT, AMQP e XMPP, oppure DTLS in CoAP, oltre a supportare entrambi i formati con DDS.
TLS e DTLS iniziano con il processo di stabilire una connessione tra il lato client e il lato server per scambiare set di cifratura e chiavi supportati. Entrambi i lati concordano i set per garantire che le comunicazioni future avvengano su un canale sicuro. La differenza tra di loro risiede in piccole modifiche che consentono a DTLS, basato su UDP, di funzionare su connessioni inaffidabili.
Durante su diverse implementazioni di TLS e DTLS ha rivelato che TLS ha gestito meglio la situazione. Gli attacchi su DTLS sono stati più riusciti a causa della sua tolleranza agli errori.
Tuttavia, la maggiore problematica di questi protocolli risiede nel fatto che non erano originariamente progettati per l'utilizzo nell'IoT e non prevedevano di operare nel fog o nel cloud. Attraverso uno scambio concordato (handshaking), aggiungono traffico extra con ogni connessione stabilita, esaurendo così le risorse computazionali. In media c'è un aumento del 6,5% per TLS e dell'11% per DTLS nel carico di overhead rispetto a una connessione senza livello di sicurezza. Negli ambienti ricchi di risorse, che di solito si trovano A livello, questo non sarà un problema, ma in relazione tra IoT e livello di nebbia questo diventa un'importante limitazione.
Cosa scegliere? Non esiste una risposta univoca. MQTT e HTTP sembrano essere i protocolli più promettenti, poiché sono considerati soluzioni relativamente più mature e più stabili per l'IoT rispetto ad altri protocolli.
Soluzioni basate su un unico protocollo di comunicazione
La pratica della soluzione a protocollo unico ha molti svantaggi. Ad esempio, un protocollo che soddisfa un ambiente limitato potrebbe non funzionare in un dominio con requisiti di sicurezza rigorosi. Tenendo questo a mente, dobbiamo scartare quasi tutte le possibili soluzioni basate su un unico protocollo nell'ecosistema Fog-to-Cloud dell'IoT, tranne MQTT e REST HTTP.
REST HTTP come soluzione a protocollo unico
C'è un buon esempio di interazione tra richieste e risposte REST HTTP nel campo IoT-to-Fog: . Gli animali sono dotati di sensori indossabili (IoT-cliente, C) e gestiti tramite il cloud dalla smart farming system (Fog-server, S).
Nell'intestazione del metodo POST viene specificata la risorsa da modificare (\/farm\/animals), oltre alla versione HTTP e al tipo di contenuto, che in questo caso è un oggetto JSON che rappresenta la fattoria zootecnica di cui deve occuparsi il sistema (Dulcinea\/mucca). La risposta del server indica che la richiesta è stata elaborata con successo, restituendo il codice di stato HTTPS 201 (risorsa creata). Il metodo GET deve specificare solo la risorsa richiesta nell'URI (ad esempio, \/farm\/animals\/1), che restituisce la rappresentazione JSON dell'animale con quell'identificativo dal server.
Il metodo PUT viene utilizzato quando è necessario aggiornare una specifica registrazione della risorsa. In questo caso, nell'argomento della risorsa viene indicato l'URI per il parametro da modificare e il valore corrente (ad esempio, che la mucca in questo momento sta pascolando, \/farm\/animals\/1? stato=camminando). Infine, il metodo DELETE viene utilizzato in modo simile al metodo GET, ma elimina semplicemente la risorsa come risultato dell'operazione.
MQTT come soluzione a protocollo unico
Prendiamo la stessa smart farm, ma invece di utilizzare REST HTTP, utilizziamo il protocollo MQTT. Un server locale con la libreria Mosquitto installata funge da broker. In questo esempio, un computer semplice (indicato come server della fattoria) Raspberry Pi funge da client MQTT, implementato attraverso l'installazione della libreria MQTT Paho, completamente compatibile con il broker Mosquitto.
Questo client corrisponde al livello di astrazione IoT rappresentante un dispositivo con capacità di rilevamento e calcolo. Il mediatore, dall'altra parte, corrisponde a un livello di astrazione più elevato, rappresentante un nodo computazionale di nebbia, caratterizzato da una maggiore potenza in termini di elaborazione e archiviazione dei dati.
Nello scenario proposto della "smart farm", il Raspberry Pi si collega a un accelerometro, al GPS e ai sensori di temperatura e pubblica i dati di questi sensori in un nodo di nebbia. Come saprete, MQTT considera i temi in modo gerarchico. Un publisher MQTT può pubblicare messaggi in un certo insieme di temi. Nel nostro caso, ce ne sono tre. Per il sensore che misura la temperatura nella stalla degli animali, il client sceglie il tema (animalfarm/shed/temperature). Per i sensori che misurano la posizione GPS e il movimento degli animali tramite l'accelerometro, il client pubblica aggiornamenti (animalfarm/animal/GPS) e (animalfarm/animal/movement).
Queste informazioni saranno inviate al broker, che può temporaneamente immagazzinarle in un database locale nel caso in cui successivamente ci sia un altro sottoscrittore interessato.
Oltre al server locale che funge da broker MQTT nella nebbia e a cui il Raspberry Pi, che funge da client MQTT, invia i dati dai sensori, a livello cloud potrebbe esserci un altro broker MQTT. In questo caso, le informazioni inviate al broker locale potrebbero essere temporaneamente memorizzate in un database locale e/o inviate al cloud. Il broker MQTT di nebbia in questa situazione viene utilizzato per collegare tutti i dati al broker MQTT cloud. Con questa architettura, l'utente dell'app mobile può essere iscritto a entrambi i broker.
In caso di interruzione della connessione con uno dei broker (ad esempio, quello cloud), l'utente finale riceverà informazioni da un altro broker (fog). Questa è una caratteristica distintiva dei sistemi combinati di fog e cloud computing. Di default, l'app mobile può essere configurata per connettersi inizialmente a un broker MQTT fog, e in caso di fallimento, per connettersi a un broker MQTT nel cloud. Questa soluzione è solo una delle molte presenti nei sistemi IoT-F2C.
Soluzioni multiprotocollo
Le soluzioni con un solo protocollo sono popolari grazie alla loro implementazione più semplice. Ma è evidente che nei sistemi IoT-F2C ha senso combinare diversi protocolli. La logica sta nel fatto che a diversi livelli possono operare protocolli differenti. Prendiamo, ad esempio, tre astrazioni: i livelli IoT, fog e cloud computing. I dispositivi a livello IoT sono generalmente considerati limitati. Per questa panoramica, consideriamo i livelli IoT come i più limitati, i cloud come i meno limitati e il calcolo fog come "a metà strada". Allora risulta che tra IoT e le astrazioni fog le attuali soluzioni protokolari includono MQTT, CoAP e XMPP. Tra fog e cloud, d'altra parte, AMQP è uno dei protocolli principali utilizzati insieme a REST HTTP, che grazie alla sua flessibilità è utilizzato anche tra IoT e i livelli fog.
Il problema principale qui è la compatibilità funzionale dei protocolli e la semplicità di traduzione dei messaggi da un protocollo all'altro. Ideale sarebbe che, in futuro, l'architettura del sistema di Internet delle cose con risorse cloud e fog fosse indipendente dal protocollo di comunicazione utilizzato e garantisse una buona interazione tra i diversi protocolli.
Poiché al momento non è così, ha senso combinare protocolli che non hanno differenze significative. A tal fine, una potenziale soluzione si basa sulla combinazione di due protocolli che seguono lo stesso stile architettonico, REST HTTP e CoAP. Un'altra soluzione proposta si basa sulla combinazione di due protocolli che offrono interazione secondo il modello "pubblica-iscriviti", MQTT e AMQP. L'uso di concetti simili (sia MQTT che AMQP utilizzano broker, CoAP e HTTP utilizzano REST) semplifica l'implementazione di queste combinazioni e richiede minori sforzi di integrazione.
Nell'immagine (a) sono mostrati due modelli basati su richieste-risposte, HTTP e CoAP, e il loro possibile posizionamento nella soluzione IoT-F2C. Poiché HTTP è uno dei protocolli più noti e adottati nelle reti moderne, è poco probabile che venga completamente sostituito da altri protocolli di messaggistica. Tra i nodi che rappresentano dispositivi potenti, situati tra il cloud e la nebbia, REST HTTP è una soluzione ragionevole.
D'altra parte, per i dispositivi con risorse computazionali limitate che si connettono tra i livelli di nebbia e IoT, è più efficace utilizzare CoAP. Uno dei grandi vantaggi di CoAP è infatti la sua compatibilità con HTTP, poiché entrambi i protocolli si basano sui principi REST.
Nell'immagine (b) sono mostrati due modelli di interazione 'pubblicazione-iscrizione' in uno scenario, inclusi MQTT e AMQP. Anche se ipoteticamente entrambi i protocolli possono essere utilizzati per comunicare tra nodi a ciascun livello di astrazione, la loro posizione dovrebbe essere determinata in base alle prestazioni. MQTT è stato sviluppato come protocollo semplificato per dispositivi con risorse computazionali limitate, quindi può essere utilizzato per la comunicazione tra IoT e nebbia. AMQP è più adatto per dispositivi più potenti, che lo collocherebbero idealmente tra i nodi di nebbia e cloud. Invece di MQTT, nel IoT si può utilizzare il protocollo XMPP, poiché è considerato leggero. Tuttavia, non è così ampiamente utilizzato in scenari simili.
Conclusioni
È poco probabile che uno dei protocolli considerati sia sufficiente per coprire tutta la comunicazione nel sistema, partendo dai dispositivi con risorse computazionali limitate fino ai server cloud. La ricerca ha mostrato che le due opzioni più promettenti, che gli sviluppatori tendono a utilizzare, sono MQTT e RESTful HTTP. Questi due protocolli non sono solo i più maturi e stabili, ma includono anche una vasta gamma di implementazioni ben documentate e risorse online di successo.
Grazie alla sua stabilità e semplice configurazione, MQTT è un protocollo che nel tempo ha dimostrato prestazioni superiori nell'uso a livello IoT con dispositivi limitati. In parti del sistema dove la connettività limitata e il consumo della batteria non sono un problema, come in alcune aree di edge computing e nella maggior parte del cloud computing, RESTful HTTP è una scelta semplice. Anche CoAP merita attenzione, poiché si sta sviluppando rapidamente come standard di messaggistica IoT e probabilmente raggiungerà a breve un livello di stabilità e maturità simile a MQTT e HTTP. Tuttavia, lo standard è attualmente in fase di sviluppo, il che porta a problemi di compatibilità a breve termine.
Cosa altro utile si può leggere nel blog
→
→
→
→
→
Iscriviti al nostro -canale, per non perdere il prossimo articolo! Scriviamo non più di due volte a settimana e solo su argomenti rilevanti.
Fonte: habr.com
