Lo sviluppo delle tecnologie nel campo del software e dell'hardware, l'emergere di nuovi protocolli di comunicazione hanno portato all'espansione dell'Internet delle cose (IoT). Il numero di dispositivi cresce di giorno in giorno e generano un'enorme quantità di dati. Pertanto, è necessaria un'architettura di sistema conveniente in grado di elaborare, archiviare e trasmettere questi dati.
Ora i servizi cloud vengono utilizzati per questi scopi. Tuttavia, il sempre più popolare paradigma del fog computing (Fog) può integrare le soluzioni cloud scalando e ottimizzando l’infrastruttura IoT.
I cloud sono in grado di coprire la maggior parte delle richieste IoT. Ad esempio, per fornire il monitoraggio dei servizi, l'elaborazione rapida di qualsiasi quantità di dati generati dai dispositivi, nonché la loro visualizzazione. Il fog computing è più efficace quando si risolvono problemi in tempo reale. Forniscono una risposta rapida alle richieste e una latenza minima nell'elaborazione dei dati. Cioè, Fog integra le "nuvole" ed espande le sue capacità.
La domanda principale però è un’altra: come dovrebbe interagire tutto questo nel contesto dell’IoT? Quali protocolli di comunicazione saranno più efficaci lavorando in un sistema combinato IoT-Fog-Cloud?
Nonostante l’apparente predominanza dell’HTTP, esistono numerose altre soluzioni utilizzate nei sistemi IoT, Fog e Cloud. Questo perché l’IoT deve combinare la funzionalità di una varietà di sensori dei dispositivi con la sicurezza, la compatibilità e altri requisiti degli utenti.
Ma semplicemente non esiste un’idea univoca sull’architettura di riferimento e sullo standard di comunicazione. Pertanto, la creazione di un nuovo protocollo o la modifica di uno esistente per attività IoT specifiche è uno dei compiti più importanti che la comunità IT deve affrontare.
Quali protocolli sono attualmente in uso e cosa possono offrire? Scopriamolo. Ma prima discutiamo dei principi dell'ecosistema in cui interagiscono nuvole, nebbia e Internet delle cose.
Architettura IoT Fog-to-Cloud (F2C).
Probabilmente avrai notato quanti sforzi vengono profusi nell'esplorazione dei vantaggi e dei benefici associati alla gestione intelligente e coordinata di IoT, cloud e fog. In caso contrario, ecco tre iniziative di standardizzazione: , и .
Se in precedenza venivano considerati solo 2 livelli, cloud e dispositivi finali, l'architettura proposta introduce un nuovo livello: il fog computing. In questo caso, il livello di nebbia può essere suddiviso in diversi sottolivelli, a seconda delle specificità delle risorse o di un insieme di politiche che determinano l'uso di diversi dispositivi in questi sottolivelli.
Come potrebbe essere questa astrazione? Ecco un tipico ecosistema IoT-Fog-Cloud. I dispositivi IoT inviano dati a server e dispositivi informatici più veloci per risolvere problemi che richiedono una bassa latenza. Nello stesso sistema, i cloud sono responsabili della risoluzione di problemi che richiedono una grande quantità di risorse di calcolo o spazio di archiviazione dei dati.
Anche smartphone, orologi intelligenti e altri gadget possono far parte dell’IoT. Ma tali dispositivi, di regola, utilizzano protocolli di comunicazione proprietari di grandi sviluppatori. I dati IoT generati vengono trasferiti al livello Fog tramite il protocollo REST HTTP, che fornisce flessibilità e interoperabilità durante la creazione di servizi RESTful. Ciò è importante alla luce della necessità di garantire la compatibilità con le versioni precedenti dell'infrastruttura informatica esistente in esecuzione 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 inviano al cloud per ulteriori calcoli.
I cloud supportano diversi protocolli di comunicazione, i più comuni sono AMQP e REST HTTP. Dato che HTTP è ben noto e realizzato su misura per Internet, potrebbe sorgere la domanda: “non dovremmo usarlo per lavorare con l’IoT e la nebbia?” Tuttavia, questo protocollo presenta problemi di prestazioni. Ne parleremo più avanti.
In generale esistono 2 modelli di protocolli di comunicazione adatti al sistema di cui abbiamo bisogno. Si tratta di richiesta-risposta e pubblicazione-sottoscrizione. Il primo modello è quello più conosciuto, soprattutto nell'architettura server-client. Il client richiede informazioni dal server e il server riceve la richiesta, la elabora e restituisce un messaggio di risposta. Su questo modello operano i protocolli REST HTTP e CoAP.
Il secondo modello è nato dalla necessità di fornire un accoppiamento libero, asincrono, distribuito tra le fonti che generano dati e i destinatari di questi dati.
Il modello presuppone tre partecipanti: un editore (fonte dati), un broker (dispatcher) e un abbonato (destinatario). In questo caso il client che funge da abbonato non deve richiedere informazioni al server. Invece di inviare richieste, si iscrive a determinati eventi nel sistema tramite un broker, che è responsabile di filtrare tutti i messaggi in arrivo e di instradarli tra editori e abbonati. E l'editore, quando si verifica un evento riguardante un determinato argomento, lo pubblica al broker, che invia i dati sull'argomento richiesto all'abbonato.
Essenzialmente, questa architettura è basata sugli eventi. E questo modello di interazione è interessante per le applicazioni in IoT, cloud, fog per la sua capacità di fornire scalabilità e semplificare l'interconnessione tra diversi dispositivi, supportare la comunicazione dinamica molti-a-molti e la comunicazione asincrona. Alcuni dei protocolli di messaggistica standardizzati più noti che utilizzano un modello di pubblicazione-sottoscrizione includono MQTT, AMQP e DDS.
Ovviamente, il modello di pubblicazione-sottoscrizione presenta molti vantaggi:
- Editori e abbonati non hanno bisogno di conoscere l'esistenza l'uno dell'altro;
- Un abbonato può ricevere informazioni da molte pubblicazioni diverse e un editore può inviare dati a molti abbonati diversi (principio molti-a-molti);
- L'editore e l'abbonato non devono essere attivi contemporaneamente per comunicare, perché il broker (funzionando come un sistema di coda) sarà in grado di archiviare il messaggio per i client che non sono attualmente connessi alla rete.
Tuttavia, anche il modello richiesta-risposta ha i suoi punti di forza. Nei casi in cui la capacità del lato server di gestire più richieste client non è un problema, è opportuno utilizzare soluzioni comprovate e affidabili.
Esistono anche protocolli che supportano entrambi i modelli. Ad esempio XMPP e HTTP 2.0, che supportano l'opzione “server push”. L'IETF ha anche rilasciato un CoAP. Nel tentativo di risolvere il problema della messaggistica sono state create diverse altre soluzioni, come il protocollo WebSockets o l'utilizzo del protocollo HTTP su QUIC (Quick UDP Internet Connections).
Nel caso dei WebSocket, sebbene siano utilizzati per trasferire dati in tempo reale da un server a un client Web e forniscano connessioni persistenti con comunicazione bidirezionale simultanea, non sono destinati a dispositivi con risorse di elaborazione limitate. Anche QUIC merita attenzione, poiché il nuovo protocollo di trasporto offre molte nuove opportunità. Ma poiché QUIC non è ancora standardizzato, è prematuro prevederne la possibile applicazione e l’impatto sulle soluzioni IoT. Teniamo quindi a mente WebSocket e QUIC con uno sguardo al futuro, ma per ora non lo studieremo più in dettaglio.
Chi è il più carino del mondo: protocolli a confronto
Ora parliamo dei punti di forza e di debolezza dei protocolli. Guardando al futuro, facciamo subito una riserva sul fatto che non esiste un leader chiaro. Ciascun protocollo presenta alcuni vantaggi/svantaggi.
Tempo di risposta
Una delle caratteristiche più importanti dei protocolli di comunicazione, soprattutto in relazione all’Internet delle cose, è il tempo di risposta. Ma tra i protocolli esistenti non esiste un chiaro vincitore che dimostri il livello minimo di latenza quando si lavora in condizioni diverse. Ma c’è tutta una serie di ricerche e confronti sulle capacità del protocollo.
Per esempio, i confronti dell'efficacia di HTTP e MQTT quando si lavora con l'IoT hanno mostrato che il tempo di risposta per le richieste per MQTT è inferiore rispetto a quello per HTTP. E quando Il tempo di andata e ritorno (RTT) di MQTT e CoAP ha rivelato che l’RTT medio di CoAP è inferiore del 20% rispetto a quello di MQTT.
Altro con RTT per i protocolli MQTT e CoAP è stato effettuato in due scenari: rete locale e rete IoT. Si è scoperto che l’RTT medio è 2-3 volte superiore in una rete IoT. MQTT con QoS0 ha mostrato un risultato inferiore rispetto a CoAP e MQTT con QoS1 ha mostrato un RTT più elevato a causa degli ACK a livello di applicazione e trasporto. Per diversi livelli di QoS, la latenza di rete senza congestione è stata di millisecondi per MQTT e di centinaia di microsecondi per CoAP. Tuttavia, vale la pena ricordare che quando si lavora su reti meno affidabili, l'esecuzione di MQTT su TCP mostrerà un risultato completamente diverso.
il tempo di risposta per i protocolli AMQP e MQTT aumentando il carico utile ha mostrato che con un carico leggero il livello di latenza è quasi lo stesso. Ma quando si trasferiscono grandi quantità di dati, MQTT dimostra tempi di risposta più brevi. in un altro CoAP è stato confrontato con HTTP in uno scenario di comunicazione da macchina a macchina con dispositivi distribuiti su veicoli dotati di sensori di gas, sensori meteorologici, sensori di posizione (GPS) e un'interfaccia di rete mobile (GPRS). Il tempo necessario per trasmettere un messaggio CoAP sulla rete mobile era quasi tre volte inferiore al tempo necessario per utilizzare i messaggi HTTP.
Sono stati condotti studi che hanno confrontato non due, ma tre protocolli. Per esempio, prestazioni dei protocolli IoT MQTT, DDS e CoAP in uno scenario applicativo medico utilizzando un emulatore di rete. DDS ha sovraperformato MQTT in termini di latenza della telemetria testata in una serie di condizioni di rete sfavorevoli. Il CoAP basato su UDP funzionava bene per le applicazioni che richiedevano tempi di risposta rapidi, tuttavia, poiché era basato su UDP, si verificava una significativa perdita di pacchetti imprevedibile.
capacità
MQTT e CoAP in termini di efficienza della larghezza di banda sono stati effettuati come calcolo della quantità totale di dati trasmessi per messaggio. CoAP ha mostrato un throughput inferiore rispetto a MQTT durante la trasmissione di messaggi di piccole dimensioni. Ma confrontando l'efficienza dei protocolli in termini di rapporto tra il numero di byte di informazioni utili e il numero totale di byte trasferiti, CoAP si è rivelato più efficace.
A utilizzando MQTT, DDS (con TCP come protocollo di trasporto) e larghezza di banda CoAP, si è riscontrato che CoAP generalmente mostrava un consumo di larghezza di banda relativamente inferiore, che non aumentava con l'aumento della perdita di pacchetti di rete o con l'aumento della latenza di rete, a differenza di MQTT e DDS, dove c'era un aumento dell’utilizzo della larghezza di banda negli scenari menzionati. Un altro scenario prevedeva la trasmissione simultanea di dati da parte di un gran numero di dispositivi, tipico degli ambienti IoT. I risultati hanno mostrato che per un utilizzo più elevato è meglio utilizzare CoAP.
In condizioni di carico leggero, CoAP ha utilizzato la larghezza di banda minima, seguito da MQTT e REST HTTP. Tuttavia, quando la dimensione dei payload aumentava, REST HTTP ha ottenuto i risultati migliori.
Consumo di energia
Il tema del consumo energetico è sempre di grande importanza, soprattutto in un sistema IoT. Se Mentre MQTT e HTTP consumano elettricità, HTTP ne consuma molta di più. E CoAP è molto di più rispetto a MQTT, consentendo la gestione dell'energia. Tuttavia, in scenari semplici, MQTT è più adatto per lo scambio di informazioni nelle reti Internet of Things, soprattutto se non ci sono limitazioni di potenza.
Un esperimento che ha confrontato le capacità di AMQP e MQTT su un banco di prova di rete wireless mobile o instabile ha rilevato che AMQP offre maggiori funzionalità di sicurezza mentre MQTT è più efficiente dal punto di vista energetico.
sicurezza
La sicurezza è un’altra questione critica sollevata quando si studia il tema dell’Internet delle cose e del fog/cloud computing. Il meccanismo di sicurezza è in genere basato su TLS in HTTP, MQTT, AMQP e XMPP o DTLS in CoAP e supporta entrambe le varianti DDS.
TLS e DTLS iniziano con il processo di creazione della comunicazione tra i lati client e server per lo scambio di suite di crittografia e chiavi supportate. Entrambe le parti negoziano i set per garantire che ulteriori comunicazioni avvengano su un canale sicuro. La differenza tra i due risiede in piccole modifiche che consentono al DTLS basato su UDP di funzionare su una connessione inaffidabile.
A Diverse implementazioni diverse di TLS e DTLS hanno riscontrato che TLS ha svolto un lavoro migliore. Gli attacchi a DTLS hanno avuto più successo grazie alla sua tolleranza agli errori.
Tuttavia, il problema più grande con questi protocolli è che non sono stati originariamente progettati per l’uso nell’IoT e non erano destinati a funzionare nella nebbia o nel cloud. Attraverso l'handshaking, aggiungono ulteriore traffico a ogni connessione stabilita, consumando risorse di calcolo. In media, si registra un aumento del 6,5% per TLS e dell'11% per DTLS in termini di sovraccarico rispetto alle comunicazioni senza livello di sicurezza. In ambienti ricchi di risorse, che in genere si trovano su livello, questo non sarà un problema, ma nella connessione tra IoT e livello di nebbia, questo diventa una limitazione importante.
Cosa scegliere? Non esiste una risposta chiara. MQTT e HTTP sembrano essere i protocolli più promettenti in quanto sono considerati soluzioni IoT comparativamente più mature e più stabili rispetto ad altri protocolli.
Soluzioni basate su un protocollo di comunicazione unificato
La pratica di una soluzione a protocollo singolo presenta numerosi svantaggi. Ad esempio, un protocollo adatto a un ambiente limitato potrebbe non funzionare in un dominio che prevede requisiti di sicurezza rigorosi. Con questo in mente, non ci resta che scartare quasi tutte le possibili soluzioni a protocollo singolo nell’ecosistema Fog-to-Cloud in IoT, ad eccezione di MQTT e REST HTTP.
REST HTTP come soluzione a protocollo singolo
Esiste un buon esempio di come le richieste e le risposte HTTP REST interagiscono nello spazio IoT-to-Fog: . Gli animali sono dotati di sensori indossabili (client IoT, C) e controllati tramite cloud computing da un sistema di agricoltura intelligente (server Fog, S).
L'intestazione del metodo POST specifica la risorsa da modificare (/farm/animals) nonché la versione HTTP e il tipo di contenuto, che in questo caso è un oggetto JSON che rappresenta la fattoria degli animali che il sistema deve gestire (Dulcinea/cow) . La risposta dal server indica che la richiesta è andata a buon fine inviando 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 una rappresentazione JSON dell'animale con quell'ID dal server.
Il metodo PUT viene utilizzato quando è necessario aggiornare alcuni record di risorse specifici. In questo caso, la risorsa specifica l'URI per il parametro da modificare e il valore corrente (ad esempio, indicando che la mucca sta attualmente camminando, /farm/animals/1? state=walking). Infine, il metodo DELETE viene utilizzato allo stesso modo del metodo GET, ma elimina semplicemente la risorsa come risultato dell'operazione.
MQTT come soluzione a protocollo singolo
Prendiamo 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 (denominato server della farm) Raspberry Pi funge da client MQTT, implementato attraverso l'installazione della libreria Paho MQTT, che è 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 corrisponde invece ad un livello di astrazione più elevato, rappresentando un nodo di fog computing caratterizzato da maggiore capacità di elaborazione e immagazzinamento.
Nello scenario proposto per la fattoria intelligente, il Raspberry Pi si connette all’accelerometro, al GPS e ai sensori di temperatura e pubblica i dati di questi sensori su un nodo di nebbia. Come probabilmente saprai, MQTT tratta gli argomenti come una gerarchia. Un singolo editore MQTT può pubblicare messaggi su un insieme specifico di argomenti. Nel nostro caso ce ne sono tre. Per un sensore che misura la temperatura in una stalla per animali, il cliente seleziona un tema (fattoria/capannone/temperatura). Per i sensori che misurano la posizione GPS e il movimento degli animali attraverso l'accelerometro, il client pubblicherà gli aggiornamenti a (animalfarm/animal/GPS) e (animalfarm/animal/movement).
Queste informazioni verranno passate al broker, che potrà memorizzarle temporaneamente in un database locale nel caso in cui arrivi successivamente un altro abbonato interessato.
Oltre al server locale, che funge da broker MQTT nella nebbia e al quale Raspberry Pi, in qualità di client MQTT, invia i dati dei sensori, potrebbe esserci un altro broker MQTT a livello cloud. In questo caso, le informazioni trasmesse al broker locale possono essere temporaneamente archiviate in un database locale e/o inviate al cloud. Il broker MQTT fog in questa situazione viene utilizzato per associare tutti i dati al broker MQTT cloud. Con questa architettura, un utente dell’applicazione mobile può essere iscritto ad entrambi i broker.
Se la connessione a uno dei broker (ad esempio cloud) fallisce, l'utente finale riceverà informazioni dall'altro (fog). Questa è una caratteristica dei sistemi combinati di nebbia e cloud computing. Per impostazione predefinita, l'app mobile può essere configurata per connettersi prima al broker MQTT fog e, se fallisce, per connettersi al broker MQTT cloud. Questa soluzione è solo una delle tante nei sistemi IoT-F2C.
Soluzioni multiprotocollo
Le soluzioni a protocollo singolo sono popolari grazie alla loro più semplice implementazione. Ma è chiaro che nei sistemi IoT-F2C ha senso combinare protocolli diversi. L’idea è che protocolli diversi possano operare a livelli diversi. Prendiamo, ad esempio, tre astrazioni: gli strati dell’IoT, della nebbia e del cloud computing. I dispositivi a livello IoT sono generalmente considerati limitati. Per questa panoramica, consideriamo i livelli IoT come quelli più vincolati, il cloud come quello meno vincolato e il fog computing come "una via di mezzo". Risulta quindi che tra IoT e astrazioni fog, le attuali soluzioni di protocollo includono MQTT, CoAP e XMPP. Tra fog e cloud, invece, AMQP è uno dei principali protocolli utilizzati, insieme a REST HTTP, che per la sua flessibilità viene utilizzato anche tra IoT e fog layer.
Il problema principale qui è l'interoperabilità dei protocolli e la facilità di trasferire i messaggi da un protocollo all'altro. Idealmente, in futuro, l’architettura di un sistema Internet of Things con risorse cloud e fog sarà indipendente dal protocollo di comunicazione utilizzato e garantirà una buona interoperabilità tra diversi protocolli.
Poiché attualmente questo non è il caso, è logico combinare protocolli che non presentino differenze significative. A tal fine, una potenziale soluzione si basa su una combinazione di due protocolli che seguono lo stesso stile architetturale, REST HTTP e CoAP. Un'altra soluzione proposta si basa su una combinazione di due protocolli che offrono comunicazione di pubblicazione-sottoscrizione, MQTT e AMQP. L’utilizzo di concetti simili (sia MQTT che AMQP utilizzano broker, CoAP e HTTP utilizzano REST) rende queste combinazioni più facili da implementare e richiede meno sforzi di integrazione.
La figura (a) mostra due modelli basati su richiesta-risposta, HTTP e CoAP, e il loro possibile posizionamento in una soluzione IoT-F2C. Poiché HTTP è uno dei protocolli più conosciuti e adottati sulle reti moderne, difficilmente verrà completamente sostituito da altri protocolli di messaggistica. Tra i nodi che rappresentano dispositivi potenti che si trovano tra il cloud e la nebbia, REST HTTP è una soluzione intelligente.
D'altro canto, per i dispositivi con risorse di elaborazione limitate che comunicano tra i livelli Fog e IoT, è più efficiente utilizzare CoAP. Uno dei grandi vantaggi di CoAP è proprio la sua compatibilità con HTTP, poiché entrambi i protocolli si basano sui principi REST.
La figura (b) mostra due modelli di comunicazione di pubblicazione-sottoscrizione nello stesso scenario, inclusi MQTT e AMQP. Sebbene entrambi i protocolli possano ipoteticamente essere utilizzati per la comunicazione tra i nodi su ciascun livello di astrazione, la loro posizione dovrebbe essere determinata in base alle prestazioni. MQTT è stato progettato come un protocollo leggero per dispositivi con risorse di elaborazione limitate, quindi può essere utilizzato per la comunicazione IoT-Fog. AMQP è più adatto a dispositivi più potenti, che lo posizionerebbero idealmente tra i nodi nebbia e nuvole. Invece di MQTT, nell’IoT può essere utilizzato il protocollo XMPP poiché è considerato leggero. Ma non è così ampiamente utilizzato in tali scenari.
risultati
È improbabile che uno dei protocolli discussi sia sufficiente a coprire tutte le comunicazioni in un sistema, dai dispositivi con risorse informatiche limitate ai server cloud. Dallo studio è emerso che le due opzioni più promettenti utilizzate dagli sviluppatori sono MQTT e RESTful HTTP. Questi due protocolli non sono solo i più maturi e stabili, ma includono anche molte implementazioni e risorse online ben documentate e di successo.
Grazie alla sua stabilità e alla semplicità di configurazione, MQTT è un protocollo che ha dimostrato nel tempo prestazioni superiori se utilizzato a livello IoT con dispositivi limitati. Nelle parti del sistema in cui la comunicazione limitata e il consumo della batteria non sono un problema, come alcuni domini fog e la maggior parte del cloud computing, RESTful HTTP è una scelta facile. Anche CoAP dovrebbe essere preso in considerazione poiché anch’esso si sta evolvendo rapidamente come standard di messaggistica IoT ed è probabile che raggiungerà un livello di stabilità e maturità simile a MQTT e HTTP nel prossimo futuro. Ma lo standard è attualmente in evoluzione, il che comporta problemi di compatibilità a breve termine.
Cos'altro puoi leggere sul blog?
→
→
→
→
→
Iscriviti al nostro -channel per non perdere il prossimo articolo! Scriviamo non più di due volte a settimana e solo per affari.
Fonte: habr.com