Lo sviluppo delle tecnologie nel software e nell'hardware e l'emergere di nuovi protocolli di comunicazione hanno portato a un'espansione dell'Internet delle cose (IoT). Il numero di dispositivi cresce ogni giorno, generando enormi volumi di dati. Pertanto, c'è bisogno di un'architettura di sistema conveniente in grado di elaborare, memorizzare e trasmettere questi dati.
Attualmente, per questi scopi, si utilizzano servizi cloud. Tuttavia, il paradigma in espansione del fog computing può integrare le soluzioni cloud, scalando e ottimizzando l'infrastruttura IoT.
Le ‘nuvole’ possono soddisfare la maggior parte delle richieste IoT. Ad esempio, possono garantire il monitoraggio dei servizi, l'elaborazione rapida di qualsiasi volume di dati generato dai dispositivi e anche la loro visualizzazione. Il fog computing, invece, è più efficace nella gestione di compiti real-time. Assicura una risposta rapida alle richieste e una latenza minima nell'elaborazione dei dati. In altre parole, il fog computing integra le ‘nuvole’, ampliando le loro capacità.
Tuttavia, la domanda principale è un'altra: come deve funzionare tutto questo nel contesto dell'IoT? Quali protocolli di comunicazione saranno i più efficaci nel lavorare in un sistema integrato IoT-Fog-Cloud?
Nonostante il dominio apparente dell'HTTP, nei sistemi IoT, Fog e Cloud vengono utilizzate molte altre soluzioni. Questo è dovuto al fatto che l'IoT deve combinare le funzionalità di vari sensori con requisiti di sicurezza, compatibilità e altre esigenze degli utenti.
Tuttavia, non esiste una visione univoca di un'architettura di riferimento e di uno standard di comunicazione. Pertanto, la creazione di un nuovo protocollo o l'adeguamento di uno esistente per compiti specifici dell'IoT è uno dei compiti più importanti per la comunità IT.
Quali protocolli vengono utilizzati attualmente e cosa possono offrire? Approfondiamo. Ma prima, discutiamo i principi dell'ecosistema in cui interagiscono i cloud, il fog e l'internet delle cose.
Architettura IoT Fog-to-Cloud (F2C)
Hai sicuramente notato quanto impegno venga dedicato allo studio dei vantaggi e dei benefici associati a una gestione razionale e coordinata dell'IoT, del cloud e del fog. Se non lo hai fatto, ecco tre iniziative di standardizzazione: , e .
Se in passato si consideravano solo 2 livelli, il cloud e i dispositivi finali, l'architettura proposta introduce un nuovo livello: il fog computing. Questo livello di fog può essere suddiviso in diversi sottolivelli, a seconda delle specificità delle risorse o dell'insieme di politiche che definiscono l'uso di vari dispositivi in questi sottolivelli.
Come potrebbe apparire questa astrazione? Ecco un ecosistema tipico IoT-Fog-Cloud. I dispositivi IoT inviano dati a server e dispositivi di calcolo più potenti per affrontare compiti che richiedono un basso livello di latenza. In questo sistema, i cloud sono responsabili della risoluzione di compiti che richiedono una grande quantità di risorse di calcolo o spazio di archiviazione.
Smartphone, smartwatch e altri dispositivi possono far parte dell'IoT. Tuttavia, questi dispositivi tendono a utilizzare protocolli di comunicazione proprietari di grandi sviluppatori. I dati generati dall'Internet delle cose vengono trasmessi al livello di fog computing tramite il protocollo REST HTTP, che garantisce flessibilità e compatibilità funzionale nella creazione di servizi RESTful. Questo è fondamentale per garantire la retrocompatibilità con l'infrastruttura informatica esistente, che opera su computer locali, server o cluster di server. Le risorse locali, chiamate "nodi di fog", filtrano i dati ricevuti e li elaborano localmente oppure li inoltrano al cloud per ulteriori elaborazioni.
I cloud supportano diversi protocolli di comunicazione, tra cui i più comuni sono AMQP e REST HTTP. Poiché HTTP è ben noto e ottimizzato per Internet, potrebbe sorgere la domanda: "non sarebbe meglio utilizzarlo per lavorare con l'IoT e il fog?" Tuttavia, questo protocollo presenta problemi di prestazioni. Di questo parleremo più avanti.
In generale, ci sono 2 modelli di protocolli di comunicazione adatti al nostro sistema. Questi sono il modello richiesta-risposta e il modello pubblicazione-sottoscrizione. Il primo modello è più conosciuto, specialmente nell'architettura client-server. Il client richiede informazioni dal server, il quale riceve la richiesta, la elabora e restituisce un messaggio di risposta. I protocolli REST HTTP e CoAP operano secondo questo modello.
Il secondo modello è emerso dalla necessità di garantire una comunicazione asincrona, distribuita e flessibile tra le fonti che generano dati e i destinatari di tali dati.
Il modello prevede la partecipazione di tre attori: l'editore (fonte di dati), il broker (dispatcher) e l'abbonato (destinatario). Qui, il client, in quanto abbonato, non deve richiedere informazioni dal server. Invece di inviare richieste, si iscrive a determinati eventi nel sistema attraverso il broker, responsabile della filtrazione di tutti i messaggi in entrata e del loro instradamento tra editori e abbonati. L'editore, quando si verifica un evento relativo a un certo argomento, lo pubblica al broker, che invia i dati all'abbonato sull'argomento richiesto.
Fondamentalmente, questa architettura si basa su eventi. Questa modalità di interazione è interessante per le applicazioni IoT, nel cloud e nel fog computing, grazie alla sua capacità di garantire scalabilità e semplificare le connessioni tra diversi dispositivi, sostenendo una comunicazione dinamica "molti a molti" e comunicazioni asincrone. Tra i protocolli di scambio messaggi più noti che utilizzano il modello "pubblicazione-iscrizione" ci sono MQTT, AMQP e DDS.
È evidente che il modello "pubblicazione-iscrizione" presenta numerosi vantaggi:
- Editori e iscritti non devono conoscere l'esistenza l'uno dell'altro;
- Un sottoscrittore può ricevere informazioni da numerose pubblicazioni diverse, mentre un editore può inviare dati a molti sottoscrittori diversi (principio "molti a molti");
- L’editore e il sottoscrittore non devono essere attivi contemporaneamente per scambiare dati, poiché il broker (che funziona come un sistema di code) può memorizzare il messaggio per i clienti che attualmente non sono connessi alla rete.
Tuttavia, anche il modello "request-response" ha i suoi punti di forza. Negli scenari in cui le capacità del server per gestire le richieste di più clienti non rappresentano un problema, ha senso utilizzare soluzioni affidabili già collaudate.
Esistono anche protocolli che supportano entrambi i modelli. Ad esempio, XMPP e HTTP 2.0 supportano l'opzione "server push". L'IETF ha anche rilasciato CoAP. Nel tentativo di risolvere il problema della messaggistica, sono state create diverse altre soluzioni, come il protocollo WebSockets o l'uso del protocollo HTTP tramite QUIC (Quick UDP Internet Connections).
Nel caso dei WebSockets, sebbene siano utilizzati per la trasmissione di dati in tempo reale dal server al client web e forniscano connessioni continue con comunicazione bidirezionale simultanea, non sono adatti per dispositivi con risorse computazionali limitate. Anche QUIC merita attenzione, poiché il nuovo protocollo di trasporto offre molte nuove opportunità. Tuttavia, poiché QUIC non è ancora standardizzato, è prematuro prevedere il suo possibile utilizzo e impatto nelle soluzioni IoT. Pertanto, lasciamo i WebSockets e QUIC nella nostra memoria per il futuro, ma per ora non approfondiremo ulteriormente.
Chi è il più amabile nel mondo: confrontiamo i protocolli
Ora parliamo dei punti di forza e di debolezza dei protocolli. Anticipando, diciamo subito che non esiste un chiaro leader. Ogni protocollo ha dei propri vantaggi/svantaggi.
Tempo di risposta
Una delle caratteristiche più importanti dei protocolli di comunicazione, specialmente per quanto riguarda l'internet delle cose, è il tempo di risposta. Tuttavia, tra i protocolli esistenti non c'è un vincitore assoluto che dimostri il livello di latenza più basso in diverse condizioni. Ci sono invece numerosi studi e confronti sulle capacità dei protocolli.
Ad esempio, del confronto tra l'efficacia di HTTP e MQTT nel contesto dell'IoT hanno mostrato che il tempo di risposta per le richieste è inferiore con MQTT rispetto a HTTP. Inoltre, del tempo di andata e ritorno (RTT) di MQTT e CoAP, è emerso che il RTT medio di CoAP è inferiore del 20% rispetto a quello di MQTT.
Un altro sull'RTT dei protocolli MQTT e CoAP è stato condotto in due scenari: rete locale e rete IoT. Si è scoperto che l'RTT medio è 2-3 volte più alto nella rete IoT. MQTT con QoS0 ha mostrato risultati inferiori rispetto a CoAP, mentre MQTT con QoS1 ha dimostrato un RTT superiore a causa degli acknowledgment (ACK) nei livelli applicativo e di trasporto. Per diversi livelli di QoS, le latenze nella rete non congestionata per MQTT sono state misurate in millisecondi, mentre per CoAP in centinaia di microsecondi. Tuttavia, è importante ricordare che in reti meno affidabili, MQTT, che opera sopra TCP, darà risultati completamente diversi.
del tempo di risposta dei protocolli AMQP e MQTT aumentando il carico utile ha mostrato che con carichi leggeri il livello di latenza è quasi identico. Tuttavia, nella trasmissione di grandi volumi di dati, MQTT dimostra un tempo di risposta inferiore. Inoltre, in un'altra CoAP è stato confrontato con HTTP in uno scenario di comunicazione macchina a macchina con dispositivi distribuiti su veicoli e dotati di sensori di gas, sensori meteorologici, localizzazione (GPS) e interfaccia di rete mobile (GPRS). Il tempo necessario per la trasmissione di un messaggio CoAP attraverso la rete mobile è stato quasi tre volte più breve rispetto al tempo necessario per utilizzare messaggi HTTP.
Sono state condotte ricerche in cui sono stati confrontati non due, ma tre protocolli. Ad esempio, le prestazioni dei protocolli IoT MQTT, DDS e CoAP in uno scenario medico utilizzando un emulatore di rete. DDS ha superato MQTT in termini di latenza della telemetria testata in diverse condizioni di rete difficili. CoAP, basato su UDP, ha funzionato bene per le applicazioni che richiedevano una risposta rapida, tuttavia, a causa della sua natura basata su UDP, ha subito una notevole perdita di pacchetti imprevedibile.
Larghezza di banda
La valutazione di MQTT e CoAP in termini di utilizzo della larghezza di banda è stata effettuata calcolando la quantità totale di dati trasmessi per singolo messaggio. CoAP ha mostrato una minore larghezza di banda rispetto a MQTT nella trasmissione di messaggi di piccole dimensioni. Tuttavia, quando si confronta l'efficienza dei protocolli in termini di rapporto tra i byte di informazioni utili e il numero totale di byte trasmessi, CoAP si è rivelato più efficiente.
Durante L'uso della larghezza di banda con MQTT, DDS (con TCP come protocollo di trasporto) e CoAP ha rivelato che CoAP tendeva a mostrare un consumo di banda relativamente più basso, che non aumentava con l'aumentare della perdita di pacchetti di rete o della latenza di rete, a differenza di MQTT e DDS, dove si osservava un aumento dell'uso della larghezza di banda in tali scenari. In un altro scenario, è stata coinvolta un'ampia quantità di dispositivi che trasmettevano dati simultaneamente, il che è un caso tipico negli ambienti IoT. I risultati hanno mostrato che per carichi più elevati, CoAP è la scelta migliore.
Con un carico ridotto, CoAP ha utilizzato la minor larghezza di banda, seguito da MQTT e REST HTTP. Tuttavia, quando la dimensione delle payload è aumentata, i migliori risultati sono stati ottenuti con REST HTTP.
Consumo energetico
La questione del consumo energetico è sempre di grande importanza, e nel sistema IoT è particolarmente rilevante. Se il consumo energetico di MQTT e HTTP, HTTP 'consuma' molte più risorse. CoAP è invece più rispetto a MQTT, consente di gestire l'alimentazione. In scenari semplici, MQTT è più adatto per lo scambio di informazioni nelle reti IoT, soprattutto quando non ci sono restrizioni di potenza.
un esperimento che ha confrontato le capacità di AMQP e MQTT su un banco di prova in una rete mobile o wireless instabile ha mostrato che AMQP offre maggiore sicurezza, mentre MQTT è più efficiente in termini energetici.
Sicurezza
La sicurezza è un'altra questione cruciale sollevata nello studio dell'IoT e del calcolo fog/cloud. Il meccanismo di sicurezza si basa solitamente su TLS in HTTP, MQTT, AMQP e XMPP, o DTLS in CoAP, supportando entrambi i protocolli DDS.
TLS e DTLS iniziano con un processo di stabilimento della connessione tra il client e il server per lo scambio dei set di crittografia e delle chiavi supportate. Entrambe le parti concordano sui set per garantire che le comunicazioni successive avvengano in un canale sicuro. La differenza tra di loro si basa su piccole modifiche che consentono a DTLS, basato su UDP, di funzionare su una connessione inaffidabile.
Durante Diverse implementazioni di TLS e DTLS hanno dimostrato che TLS affronta meglio la situazione. Gli attacchi su DTLS sono stati più efficaci a causa della sua tolleranza agli errori.
Tuttavia, il principale problema di questi protocolli è che non sono stati originariamente progettati per l'uso in IoT e non prevedevano operazioni in ambienti di fog computing o cloud. Attraverso un processo di handshake, aggiungono traffico extra con ogni nuova connessione, esaurendo le risorse di calcolo. Si osserva un aumento medio del 6,5% per TLS e dell'11% per DTLS nel sovraccarico rispetto alla comunicazione senza livello di sicurezza. In ambienti ricchi di risorse, tipicamente situati a a livello, non sarà un problema, ma in relazione tra IoT e il livello di nebbia questo diventa un'importante limitazione.
Cosa scegliere? Non c'è una risposta definitiva. MQTT e HTTP sembrano essere i protocolli più promettenti, poiché sono considerati soluzioni relativamente mature e stabili per IoT rispetto ad altri protocolli.
Soluzioni basate su un protocollo di comunicazione unico
L'uso di una soluzione a protocollo unico presenta molti svantaggi. Ad esempio, un protocollo che funziona in un ambiente limitato potrebbe non funzionare in un dominio con requisiti di sicurezza rigorosi. Tenendo ciò a mente, dobbiamo escludere quasi tutte le possibili soluzioni basate su un solo protocollo nell'ecosistema Fog-to-Cloud nell'IoT, tranne MQTT e REST HTTP.
REST HTTP come soluzione a protocollo unico
Ecco un buon esempio di interazione tra richieste e risposte REST HTTP nel campo IoT-to-Fog: . Gli animali sono dotati di sensori indossabili (IoT-client, C) e gestiti tramite il calcolo cloud da un sistema agricolo intelligente (Fog-server, S).
Nell'intestazione del metodo POST viene indicato il recurso da modificare (/farm/animals), insieme alla versione HTTP e al tipo di contenuto, che in questo caso è un oggetto JSON che rappresenta la fattoria animale che il sistema deve gestire (Dulcinea/mucca). La risposta del server indica che la richiesta è stata elaborata con successo, inviando il codice di stato HTTPS 201 (resource created). Il metodo GET deve indicare solo il recurso richiesto nell'URI (ad esempio, /farm/animals/1), che restituisce la rappresentazione JSON dell'animale con quell'identificativo dal server.
Il metodo PUT è utilizzato quando è necessario aggiornare un record specifico di una risorsa. In questo caso, la risorsa specifica l'URI per il parametro da modificare e il valore attuale (ad esempio, indicando che la mucca al momento sta pascolando, /farm/animals/1?state=walking). Infine, il metodo DELETE è utilizzato in modo simile al metodo GET, ma semplicemente elimina la risorsa in seguito all'operazione.
MQTT come soluzione a protocollo unico
Consideriamo la stessa smart farm, ma invece di REST HTTP, utilizziamo il protocollo MQTT. Un server locale con la libreria Mosquitto installata funge da broker. In questo esempio, un semplice computer (designato come server della fattoria) Raspberry Pi funge da client MQTT, implementato tramite l'installazione della libreria MQTT Paho, completamente compatibile con il broker Mosquitto.
Questo client corrisponde a un livello di astrazione IoT che rappresenta un dispositivo con capacità di rilevamento e calcolo. Il mediatore, d'altra parte, corrisponde a un livello di astrazione più elevato, rappresentando un nodo di calcolo di edge computing, caratterizzato da elevate capacità di elaborazione e archiviazione dei dati.
Nello scenario proposto della "smart farm", Raspberry Pi si collega a un accelerometro, GPS e sensori di temperatura e pubblica i dati provenienti da questi sensori in un nodo fog. Come saprete, MQTT considera i temi come una gerarchia. Un editore MQTT può pubblicare messaggi in un determinato insieme di temi. Nel nostro caso, ce ne sono tre. Per il sensore che misura la temperatura nel capanno per gli animali, il client sceglie il tema (animalfarm/shed/temperature). Per i sensori che misurano la posizione GPS e il movimento degli animali tramite accelerometro, il client pubblicherà aggiornamenti (animalfarm/animal/GPS) e (animalfarm/animal/movement).
Queste informazioni saranno inviate a un broker, che può temporaneamente conservarle in un database locale nel caso in cui successivamente ci sia un altro abbonato interessato.
Oltre a un server locale che funge da broker MQTT nel fog computing, al livello del cloud può esserci un altro broker MQTT. In questo caso, le informazioni inviate al broker locale possono essere temporaneamente archiviate in un database locale e/o inviate al cloud. In questa situazione, il broker MQTT nel fog computing viene utilizzato per collegare tutti i dati al broker MQTT nel cloud. Con questa architettura, l'utente dell'app mobile può iscriversi a entrambi i broker.
In caso di perdita di connessione con uno dei broker (ad esempio, quello nel cloud), l'utente finale riceverà informazioni dall'altro broker (quello nel fog computing). Questa è una caratteristica tipica dei sistemi combinati di fog e cloud computing. Di default, l'app mobile può essere configurata per connettersi prima al broker MQTT nel fog computing e, in caso di failure, per collegarsi al broker MQTT nel cloud. Questa soluzione è solo una delle molte disponibili nei sistemi IoT-F2C.
Soluzioni multi-protocollo
Le soluzioni con un protocollo sono popolari per la loro implementazione più semplice. Tuttavia, è evidente che nei sistemi IoT-F2C ha senso combinare diversi protocolli. L'idea è che a livelli diversi possano funzionare protocolli diversi. Prendiamo ad esempio tre astrazioni: i livelli IoT, di edge computing e di cloud computing. I dispositivi a livello IoT sono generalmente considerati limitati. Per questa panoramica, consideriamo i livelli IoT come i più limitati, il cloud come il meno limitato e l'edge computing come "nel mezzo". Dunque, tra IoT e le astrazioni di edge, le attuali soluzioni di protocollo includono MQTT, CoAP e XMPP. Dall'altro lato, tra edge e cloud, AMQP è uno dei protocolli principali utilizzati, insieme a REST HTTP, che grazie alla sua flessibilità è utilizzato anche tra IoT e i livelli di edge.
Il problema principale riguarda la compatibilità funzionale dei protocolli e la semplicità nel trasferire messaggi da un protocollo all'altro. Idealmente, in futuro l'architettura del sistema Internet delle Cose con risorse cloud e fog computing sarà indipendente dal protocollo di comunicazione utilizzato e garantirà una buona interazione tra diversi protocolli.
Poiché attualmente non è così, ha senso unire protocolli che non presentano 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 è basata sulla combinazione di due protocolli che offrono interazione secondo il modello 'pubblicazione-sottoscrizione', MQTT e AMQP. L'utilizzo di concetti simili (sia MQTT che AMQP utilizzano broker, CoAP e HTTP utilizzano REST) semplifica l'implementazione di queste combinazioni e richiede minori sforzi per l'integrazione.
Nella figura (a) sono mostrate due modelli basati su richieste-risposte, HTTP e CoAP, e il loro possibile posizionamento nella soluzione IoT-F2C. Poiché l'HTTP è uno dei protocolli più conosciuti e adattati nelle reti moderne, è improbabile che venga completamente sostituito da altri protocolli di messaggistica. Tra i nodi che rappresentano dispositivi potenti, che si trovano tra il cloud e il fog, REST HTTP costituisce una soluzione sensata.
D'altra parte, per i dispositivi con risorse computazionali limitate, che si connettono tra i livelli di fog 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 mostrate due modelli di interazione "pubblicazione-sottoscrizione" in uno stesso scenario, inclusi MQTT e AMQP. Sebbene entrambi i protocolli possano teoricamente essere utilizzati per la comunicazione tra nodi a ogni livello di astrazione, la loro posizione dovrebbe essere determinata in base alle prestazioni. MQTT è stato sviluppato come protocollo semplificato per dispositivi con risorse di calcolo limitate, pertanto può essere utilizzato per la comunicazione tra IoT e fog computing. AMQP è più adatto per dispositivi più potenti, che lo collocherebbero idealmente tra i nodi del fog e del cloud. Invece di MQTT, nel contesto IoT può essere utilizzato il protocollo XMPP, poiché è considerato leggero. Tuttavia, non è così ampiamente utilizzato in scenari simili.
Conclusioni
È poco probabile che uno dei protocolli considerati sia sufficiente a coprire tutte le comunicazioni nel sistema, partendo da dispositivi con risorse computazionali limitate fino ad arrivare ai server cloud. La ricerca ha mostrato che le due opzioni più promettenti, frequentemente adottate dagli sviluppatori, sono MQTT e RESTful HTTP. Questi due protocolli non solo sono i più maturi e stabili, ma offrono anche una vasta gamma di implementazioni ben documentate e risorse online di successo.
Grazie alla sua stabilità e alla facile configurazione, MQTT è un protocollo che ha dimostrato nel tempo le sue superiori prestazioni nell'uso a livello IoT con dispositivi a basso consumo. In parti del sistema dove la connettività limitata e il consumo di batteria non sono un problema, come in alcune aree di edge computing e nella maggior parte delle applicazioni di cloud computing, RESTful HTTP è una scelta semplice. Anche CoAP merita attenzione, poiché sta rapidamente emergendo come standard per la messaggistica IoT, ed è molto probabile che nel prossimo futuro raggiunga un livello di stabilità e maturità simile a quello di MQTT e HTTP. Tuttavia, lo standard è ancora in fase di sviluppo, il che comporta problemi di compatibilità a breve termine.
Cosa altro è utile leggere nel blog
→
→
→
→
→
Iscriviti alla nostra newsletter -canale per non perdere il prossimo articolo! Scriviamo al massimo due volte a settimana e solo quando necessario.
Fonte: habr.com
