{"id":38375,"date":"2019-10-31T22:23:21","date_gmt":"2019-10-31T19:23:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii\/"},"modified":"2019-10-31T22:23:21","modified_gmt":"2019-10-31T19:23:21","slug":"iot-tuman-i-oblaka-pogovorim-pro-tehnologii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii","title":{"rendered":"IoT, nebbia e nuvole: parliamo di tecnologia?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"IoT, nebbia e nuvole: parliamo di tecnologia?\" src=\"\/wp-content\/uploads\/2019\/09\/89eae3426589d2ed8041fd6dd26498cb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>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\u00e0 di un'architettura di sistema conveniente in grado di elaborare, memorizzare e trasmettere questi dati.<\/p>\n<p>Attualmente, per questi scopi si utilizzano servizi cloud. Tuttavia, la crescente popolarit\u00e0 della nuova paradigma del calcolo fog (Fog) \u00e8 in grado di completare le soluzioni cloud, scalando e ottimizzando l'infrastruttura IoT. <\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>\"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\u00e9 la loro visualizzazione. Il calcolo fog, invece, \u00e8 pi\u00f9 efficace nella risoluzione di compiti in tempo reale. Garantisce una risposta rapida alle richieste e una latenza minima nell'elaborazione dei dati. Cio\u00e8, Fog completa proprio \"le nuvole\", ampliandone le capacit\u00e0.<\/p>\n<p>Tuttavia, la domanda principale \u00e8 un'altra: come dovrebbero interagire tutte queste componenti nel contesto dell'IoT? Quali protocolli di comunicazione saranno pi\u00f9 efficaci nel funzionamento del sistema integrato IoT-Fog-Cloud?<\/p>\n<p>Nonostante il presunto dominio di HTTP, in sistemi IoT, Fog e Cloud vengono utilizzate numerose altre soluzioni. Questo \u00e8 spiegato dal fatto che IoT deve combinare le capacit\u00e0 funzionali dei vari sensori dei dispositivi con la sicurezza, la compatibilit\u00e0 e altri requisiti posti dagli utenti.<\/p>\n<p>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\u00f9 importanti che l'IT community deve affrontare.<\/p>\n<p>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.<\/p>\n<h3>Architettura IoT Fog-to-Cloud (F2C)<\/h3>\n<p>\nAvrete 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: <noindex><a rel=\"nofollow\" href=\"https:\/\/www.openfogconsortium.org\/\">OpenFog Consortium<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"http:\/\/en.ecconsortium.org\/Uploads\/file\/20180328\/1522232376480704.pdf\">Edge Computing Consortium<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"http:\/\/www.mf2c-project.eu\/\">mF2C H2020 EU project<\/a><\/noindex>. <\/p>\n<p>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\u00f2 essere suddiviso in diversi sottolivelli, a seconda della specificit\u00e0 delle risorse o dell'insieme di politiche che definiscono l'uso di diversi dispositivi in questi sottolivelli.<\/p>\n<p>Come pu\u00f2 apparire questa astrazione? Ecco un tipico ecosistema IoT-Fog-Cloud. I dispositivi IoT inviano dati a server e dispositivi di calcolo pi\u00f9 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.<\/p>\n<p><img decoding=\"async\" alt=\"IoT, nebbia e nuvole: parliamo di tecnologia?\" src=\"\/wp-content\/uploads\/2019\/09\/c78ea915ac4743a3def5651778e77873.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSmartphone, 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\u00e0 e interoperabilit\u00e0 nella creazione di servizi RESTful. Questo \u00e8 importante alla luce della necessit\u00e0 di garantire la retrocompatibilit\u00e0 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.<\/p>\n<p>Le nuvole supportano diversi protocolli di comunicazione, tra cui AMQP e REST HTTP, i pi\u00f9 comuni. Poich\u00e9 HTTP \u00e8 ampiamente noto e progettato per il web, pu\u00f2 sorgere la domanda: \"perch\u00e9 non usarlo per lavorare con IoT e nebbia?\". Tuttavia, questo protocollo ha problemi di prestazioni, di cui parleremo dopo.<\/p>\n<p>In generale, esistono 2 modelli di protocolli di comunicazione adatti al nostro sistema. Questo \u00e8 il modello richiesta-risposta e quello pubblicazione-sottoscrizione. Il primo modello \u00e8 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 \u00e8 utilizzato dai protocolli REST HTTP e CoAP.<\/p>\n<p>Il secondo modello \u00e8 emerso dalla necessit\u00e0 di garantire una connessione asincrona, distribuita e debole tra le fonti che generano dati e i destinatari di tali dati.<\/p>\n<p><img decoding=\"async\" alt=\"IoT, nebbia e nuvole: parliamo di tecnologia?\" src=\"\/wp-content\/uploads\/2019\/09\/acf3b411fb9a0b7a61cf0188e4c29292.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <br \/>\nIl 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.<\/p>\n<p>In sostanza, questa architettura si basa sugli eventi. E un tale modello di interazione \u00e8 interessante per le applicazioni in IoT, cloud e fog computing, grazie alla sua capacit\u00e0 di garantire scalabilit\u00e0 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\u00f9 conosciuti che utilizzano il modello \"pubblicazione-sottoscrizione\", possiamo citare MQTT, AMQP e DDS.<\/p>\n<p>\u00c8 evidente che il modello \"pubblicazione-sottoscrizione\" presenta numerosi vantaggi:<\/p>\n<ul>\n<li>Gli editori e gli abbonati non devono conoscere l'esistenza l'uno dell'altro;<\/li>\n<li>Un abbonato pu\u00f2 ricevere informazioni da molteplici pubblicazioni diverse e un editore pu\u00f2 inviare dati a molti abbonati diversi (principio \"molti a molti\");<\/li>\n<li>Editore e abbonato non devono essere attivi contemporaneamente per scambiare dati, poich\u00e9 il broker (che funge da sistema di code) pu\u00f2 memorizzare il messaggio per i clienti che non sono attualmente connessi alla rete.<\/li>\n<\/ul>\n<p>\nTuttavia, anche il modello \"richiesta-risposta\" ha i suoi punti di forza. Nei casi in cui le capacit\u00e0 lato server per gestire le richieste di pi\u00f9 clienti non siano un problema, ha senso utilizzare soluzioni consolidate e affidabili.<\/p>\n<p>Ci sono anche protocolli che supportano entrambi i modelli. Ad esempio, XMPP e HTTP 2.0, che supportano l'opzione \u00abserver push\u00bb. 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).<\/p>\n<p>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 \u00e8 progettato per dispositivi con risorse computazionali limitate. Anche QUIC merita attenzione, poich\u00e9 il nuovo protocollo di trasporto offre molte nuove opportunit\u00e0. Ma dato che QUIC non \u00e8 ancora standardizzato, \u00e8 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.<\/p>\n<h3>Chi \u00e8 il pi\u00f9 gentile del mondo: confrontiamo i protocolli<\/h3>\n<p>\nOra parliamo dei punti di forza e di debolezza dei protocolli. Anticipiamo subito che non c'\u00e8 un chiaro leader. Ci sono vantaggi\/svantaggi per ogni protocollo.<\/p>\n<p><b>Tempo di risposta<\/b><\/p>\n<p>Una delle caratteristiche pi\u00f9 importanti dei protocolli di comunicazione, soprattutto in relazione all'Internet delle cose, \u00e8 il tempo di risposta. Tuttavia, tra i protocolli esistenti non c'\u00e8 un vincitore assoluto che dimostri il livello minimo di latenza in diverse condizioni. Ci sono per\u00f2 molti studi e confronti delle capacit\u00e0 dei protocolli.<\/p>\n<p>Ad esempio, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.researchgate.net\/publication\/323943358_Performance_Analysis_of_Internet_of_Things_Protocols_Based_FogCloud_over_High_Traffic\">i risultati <\/a><\/noindex>Confronti sull'efficienza di HTTP e MQTT nel lavoro con l'IoT hanno mostrato che il tempo di risposta per le richieste di MQTT \u00e8 inferiore rispetto a quello di HTTP. E durante <noindex><a rel=\"nofollow\" href=\"https:\/\/www.researchgate.net\/publication\/303188719_Comparison_of_two_lightweight_protocols_for_smartphone-based_sensing\">l'analisi <\/a><\/noindex>del tempo di round trip (RTT) di MQTT e CoAP \u00e8 emerso che l'RTT medio di CoAP \u00e8 inferiore del 20% rispetto a quello di MQTT.<\/p>\n<p>Altro <noindex><a rel=\"nofollow\" href=\"https:\/\/ieeexplore.ieee.org\/document\/7740559\">un esperimento <\/a><\/noindex>L'RTT dei protocolli MQTT e CoAP \u00e8 stato testato in due scenari: rete locale e rete IoT. Si \u00e8 scoperto che l'RTT medio \u00e8 da 2 a 3 volte pi\u00f9 alto nella rete IoT. MQTT con QoS0 ha mostrato risultati pi\u00f9 bassi rispetto a CoAP, mentre MQTT con QoS1 ha dimostrato un RTT pi\u00f9 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, \u00e8 importante ricordare che nel funzionamento in reti meno affidabili, MQTT, che opera su TCP, mostrer\u00e0 risultati completamente diversi.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.diva-portal.org\/smash\/get\/diva2:1092136\/FULLTEXT01.pdf\">Confronto <\/a><\/noindex>Il tempo di risposta dei protocolli AMQP e MQTT aumentando il payload ha mostrato che con carichi leggeri il livello di latenza \u00e8 quasi identico. Ma nella trasmissione di grandi volumi di dati, MQTT dimostra un tempo di risposta inferiore. In un altro <noindex><a rel=\"nofollow\" href=\"http:\/\/www.tfzr.rs\/esociety\/issues\/eSocietyVol3No1.pdf#page=26\">studio <\/a><\/noindex>CoAP \u00e8 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 \u00e8 stato quasi tre volte inferiore rispetto al tempo necessario per utilizzare i messaggi HTTP.<\/p>\n<p>Sono stati condotti studi in cui non sono stati confrontati due, ma tre protocolli. Ad esempio, <noindex><a rel=\"nofollow\" href=\"https:\/\/ieeexplore.ieee.org\/document\/7496622\">un confronto <\/a><\/noindex>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\u00e9 \u00e8 basato su UDP, si sono verificate perdite di pacchetti significative e imprevedibili.<\/p>\n<p><b>Larghezza di banda<\/b><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.researchgate.net\/publication\/267636202_Performance_evaluation_of_MQTT_and_CoAP_via_a_common_middleware\">Confronto <\/a><\/noindex>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 \u00e8 risultato pi\u00f9 efficiente.<\/p>\n<p>Durante <noindex><a rel=\"nofollow\" href=\"https:\/\/ieeexplore.ieee.org\/document\/7496622\">analisi <\/a><\/noindex>sull'uso della larghezza di banda di MQTT, DDS (con TCP come protocollo di trasporto) e CoAP \u00e8 emerso che CoAP mostrava generalmente un consumo di larghezza di banda relativamente pi\u00f9 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 \u00e8 notato un aumento nell'uso della larghezza di banda. In un altro scenario \u00e8 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\u00f9 elevati \u00e8 preferibile utilizzare CoAP.<\/p>\n<p>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.<\/p>\n<p><b>Consumo energetico<\/b><\/p>\n<p>La questione del consumo energetico \u00e8 sempre di grande importanza, e nel sistema IoT - in particolare. <noindex><a rel=\"nofollow\" href=\"https:\/\/ieeexplore.ieee.org\/document\/7899537\">se confrontiamo <\/a><\/noindex>il consumo di energia tra MQTT e HTTP, HTTP \"consuma\" molto di pi\u00f9. CoAP, invece, \u00e8 pi\u00f9 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.mdpi.com\/1424-8220\/16\/12\/2044\/htm\">energeticamente efficiente <\/a><\/noindex>rispetto a MQTT, permettendo una gestione pi\u00f9 semplice dell'alimentazione. In questo senso, in scenari semplici, MQTT \u00e8 pi\u00f9 adatto per lo scambio di informazioni nelle reti di Internet delle cose, soprattutto se non ci sono restrizioni di potenza.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/cgweb1.northumbria.ac.uk\/SubjectAreaResources\/KF7046\/papers\/review\/iot\/lpb15.pdf\">Altro <\/a><\/noindex>Un esperimento, durante il quale sono state confrontate le capacit\u00e0 di AMQP e MQTT su un banco di prova di una rete wireless mobile o instabile, ha mostrato che AMQP offre maggiori possibilit\u00e0 in termini di sicurezza, mentre MQTT \u00e8 pi\u00f9 energeticamente efficiente.<\/p>\n<p><b>Sicurezza<\/b><\/p>\n<p>La sicurezza \u00e8 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.<\/p>\n<p>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.<\/p>\n<p>Durante <noindex><a rel=\"nofollow\" href=\"http:\/\/www.isg.rhul.ac.uk\/tls\/lucky13.html\">attacchi di prova<\/a><\/noindex> su diverse implementazioni di TLS e DTLS ha rivelato che TLS ha gestito meglio la situazione. Gli attacchi su DTLS sono stati pi\u00f9 riusciti a causa della sua tolleranza agli errori.<\/p>\n<p>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\u00ec le risorse computazionali. In media c'\u00e8 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 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cloud4y.ru\/cloud-hosting\/cloud-server\/?utm_source=habr&amp;utm_medium=referral&amp;utm_campaign=article\">nel cloud <\/a><\/noindex>A livello, questo non sar\u00e0 un problema, ma in relazione tra IoT e livello di nebbia questo diventa un'importante limitazione.<\/p>\n<p>Cosa scegliere? Non esiste una risposta univoca. MQTT e HTTP sembrano essere i protocolli pi\u00f9 promettenti, poich\u00e9 sono considerati soluzioni relativamente pi\u00f9 mature e pi\u00f9 stabili per l'IoT rispetto ad altri protocolli.<\/p>\n<h3>Soluzioni basate su un unico protocollo di comunicazione<\/h3>\n<p>\nLa 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.<\/p>\n<p><b>REST HTTP come soluzione a protocollo unico<\/b><\/p>\n<p>C'\u00e8 un buon esempio di interazione tra richieste e risposte REST HTTP nel campo IoT-to-Fog: <noindex><a rel=\"nofollow\" href=\"https:\/\/dl.acm.org\/citation.cfm?doid=3152130.3152140\">farm intelligente<\/a><\/noindex>. Gli animali sono dotati di sensori indossabili (IoT-cliente, C) e gestiti tramite il cloud dalla smart farming system (Fog-server, S).<\/p>\n<p>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 \u00e8 un oggetto JSON che rappresenta la fattoria zootecnica di cui deve occuparsi il sistema (Dulcinea\\\/mucca). La risposta del server indica che la richiesta \u00e8 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. <\/p>\n<p>Il metodo PUT viene utilizzato quando \u00e8 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. <\/p>\n<p><b>MQTT come soluzione a protocollo unico<\/b><\/p>\n<p><img decoding=\"async\" alt=\"IoT, nebbia e nuvole: parliamo di tecnologia?\" src=\"\/wp-content\/uploads\/2019\/09\/529857b556ea5a186ac1519e2804d1b8.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrendiamo 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.<\/p>\n<p>Questo client corrisponde al livello di astrazione IoT rappresentante un dispositivo con capacit\u00e0 di rilevamento e calcolo. Il mediatore, dall'altra parte, corrisponde a un livello di astrazione pi\u00f9 elevato, rappresentante un nodo computazionale di nebbia, caratterizzato da una maggiore potenza in termini di elaborazione e archiviazione dei dati.<\/p>\n<p>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\u00f2 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).<\/p>\n<p>Queste informazioni saranno inviate al broker, che pu\u00f2 temporaneamente immagazzinarle in un database locale nel caso in cui successivamente ci sia un altro sottoscrittore interessato.<\/p>\n<p>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\u00f2 essere iscritto a entrambi i broker.<\/p>\n<p>In caso di interruzione della connessione con uno dei broker (ad esempio, quello cloud), l'utente finale ricever\u00e0 informazioni da un altro broker (fog). Questa \u00e8 una caratteristica distintiva dei sistemi combinati di fog e cloud computing. Di default, l'app mobile pu\u00f2 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 \u00e8 solo una delle molte presenti nei sistemi IoT-F2C. <\/p>\n<h3>Soluzioni multiprotocollo<\/h3>\n<p>\nLe soluzioni con un solo protocollo sono popolari grazie alla loro implementazione pi\u00f9 semplice. Ma \u00e8 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\u00f9 limitati, i cloud come i meno limitati e il calcolo fog come \"a met\u00e0 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 \u00e8 uno dei protocolli principali utilizzati insieme a REST HTTP, che grazie alla sua flessibilit\u00e0 \u00e8 utilizzato anche tra IoT e i livelli fog. <\/p>\n<p>Il problema principale qui \u00e8 la compatibilit\u00e0 funzionale dei protocolli e la semplicit\u00e0 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.<\/p>\n<p><img decoding=\"async\" alt=\"IoT, nebbia e nuvole: parliamo di tecnologia?\" src=\"\/wp-content\/uploads\/2019\/09\/cddc564cad572966002ae22eff8cb99d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <br \/>\nPoich\u00e9 al momento non \u00e8 cos\u00ec, 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.<\/p>\n<p><img decoding=\"async\" alt=\"IoT, nebbia e nuvole: parliamo di tecnologia?\" src=\"\/wp-content\/uploads\/2019\/09\/395bc75880a154aeab7b61d043476802.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNell'immagine (a) sono mostrati due modelli basati su richieste-risposte, HTTP e CoAP, e il loro possibile posizionamento nella soluzione IoT-F2C. Poich\u00e9 HTTP \u00e8 uno dei protocolli pi\u00f9 noti e adottati nelle reti moderne, \u00e8 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 \u00e8 una soluzione ragionevole.<\/p>\n<p>D'altra parte, per i dispositivi con risorse computazionali limitate che si connettono tra i livelli di nebbia e IoT, \u00e8 pi\u00f9 efficace utilizzare CoAP. Uno dei grandi vantaggi di CoAP \u00e8 infatti la sua compatibilit\u00e0 con HTTP, poich\u00e9 entrambi i protocolli si basano sui principi REST.<\/p>\n<p>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 \u00e8 stato sviluppato come protocollo semplificato per dispositivi con risorse computazionali limitate, quindi pu\u00f2 essere utilizzato per la comunicazione tra IoT e nebbia. AMQP \u00e8 pi\u00f9 adatto per dispositivi pi\u00f9 potenti, che lo collocherebbero idealmente tra i nodi di nebbia e cloud. Invece di MQTT, nel IoT si pu\u00f2 utilizzare il protocollo XMPP, poich\u00e9 \u00e8 considerato leggero. Tuttavia, non \u00e8 cos\u00ec ampiamente utilizzato in scenari simili.<\/p>\n<h3>Conclusioni<\/h3>\n<p>\n\u00c8 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\u00f9 promettenti, che gli sviluppatori tendono a utilizzare, sono MQTT e RESTful HTTP. Questi due protocolli non sono solo i pi\u00f9 maturi e stabili, ma includono anche una vasta gamma di implementazioni ben documentate e risorse online di successo.<\/p>\n<p>Grazie alla sua stabilit\u00e0 e semplice configurazione, MQTT \u00e8 un protocollo che nel tempo ha dimostrato prestazioni superiori nell'uso a livello IoT con dispositivi limitati. In parti del sistema dove la connettivit\u00e0 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 \u00e8 una scelta semplice. Anche CoAP merita attenzione, poich\u00e9 si sta sviluppando rapidamente come standard di messaggistica IoT e probabilmente raggiunger\u00e0 a breve un livello di stabilit\u00e0 e maturit\u00e0 simile a MQTT e HTTP. Tuttavia, lo standard \u00e8 attualmente in fase di sviluppo, il che porta a problemi di compatibilit\u00e0 a breve termine.<\/p>\n<p><b>Cosa altro utile si pu\u00f2 leggere nel blog <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cloud4y.ru\/?utm_source=habr&amp;utm_medium=referral&amp;utm_campaign=article\">Cloud4Y<\/a><\/noindex><\/b><\/p>\n<p>\u2192 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cloud4y\/blog\/466755\/\">Il computer ti far\u00e0 deliziare<\/a><\/noindex><br \/>\n\u2192 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/464155\/\">L'AI aiuta a studiare gli animali dell'Africa <\/a><\/noindex><br \/>\n\u2192 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cloud4y\/blog\/465251\/\">L'estate \u00e8 quasi finita. Quasi non ci sono dati non trapelati<\/a><\/noindex><br \/>\n\u2192 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/461713\/\">4 modi per risparmiare sui backup nel cloud<\/a><\/noindex><br \/>\n\u2192 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cloud4y\/blog\/467769\/\">Sull'unico sistema informativo federale che contiene dati sulla popolazione<\/a><\/noindex><\/p>\n<p>Iscriviti al nostro <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/cloud4y\">Telegram<\/a><\/noindex>-canale, per non perdere il prossimo articolo! Scriviamo non pi\u00f9 di due volte a settimana e solo su argomenti rilevanti.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cloud4y\/blog\/467711\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0420\u0430\u0437\u0432\u0438\u0442\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u043e\u0431\u043b\u0430\u0441\u0442\u0438 \u0441\u043e\u0444\u0442\u0430 \u0438 \u0436\u0435\u043b\u0435\u0437\u0430, \u043f\u043e\u044f\u0432\u043b\u0435\u043d\u0438\u0435 \u043d\u043e\u0432\u044b\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0441\u0432\u044f\u0437\u0438 \u043f\u0440\u0438\u0432\u0435\u043b\u0438 \u043a \u0440\u0430\u0441\u0448\u0438\u0440\u0435\u043d\u0438\u044e \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442\u0430 \u0432\u0435\u0449\u0435\u0439 (IoT). \u041a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432 \u0440\u0430\u0441\u0442\u0451\u0442 \u0434\u0435\u043d\u044c \u043e\u0442\u043e \u0434\u043d\u044f, \u0438 \u043e\u043d\u0438 \u0433\u0435\u043d\u0435\u0440\u0438\u0440\u0443\u044e\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u044b\u0439 \u043e\u0431\u044a\u0451\u043c \u0434\u0430\u043d\u043d\u044b\u0445. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u043f\u043e\u0442\u0440\u0435\u0431\u043d\u043e\u0441\u0442\u044c \u0432 \u0443\u0434\u043e\u0431\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0441\u043f\u043e\u0441\u043e\u0431\u043d\u043e\u0439 \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c, \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u0438 \u043f\u0435\u0440\u0435\u0434\u0430\u0432\u0430\u0442\u044c \u044d\u0442\u0438 \u0434\u0430\u043d\u043d\u044b\u0435. \u0421\u0435\u0439\u0447\u0430\u0441 \u0434\u043b\u044f \u044d\u0442\u0438\u0445 \u0446\u0435\u043b\u0435\u0439 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442 \u043e\u0431\u043b\u0430\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b. \u041e\u0434\u043d\u0430\u043a\u043e \u0441\u0442\u0430\u043d\u043e\u0432\u044f\u0449\u0430\u044f\u0441\u044f \u0432\u0441\u0451 \u0431\u043e\u043b\u0435\u0435 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28806,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-38375","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0420\u0430\u0437\u0432\u0438\u0442\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u043e\u0431\u043b\u0430\u0441\u0442\u0438 \u0441\u043e\u0444\u0442\u0430 \u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/news\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47IoT, \u0442\u0443\u043c\u0430\u043d \u0438 \u043e\u0431\u043b\u0430\u043a\u0430: \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043f\u0440\u043e \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438? | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0420\u0430\u0437\u0432\u0438\u0442\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u043e\u0431\u043b\u0430\u0441\u0442\u0438 \u0441\u043e\u0444\u0442\u0430 \u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/news\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:23:21+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:23:21+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47IoT, edge e cloud: parliamo di tecnologie? | ProHoster","description":"Sviluppo delle tecnologie nel settore software e.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/news\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47IoT, \u0442\u0443\u043c\u0430\u043d \u0438 \u043e\u0431\u043b\u0430\u043a\u0430: \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043f\u0440\u043e \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438? | ProHoster","og:description":"\u0420\u0430\u0437\u0432\u0438\u0442\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u043e\u0431\u043b\u0430\u0441\u0442\u0438 \u0441\u043e\u0444\u0442\u0430 \u0438.","og:url":"https:\/\/prohoster.info\/it\/blog\/news\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:23:21+00:00","article:modified_time":"2019-10-31T19:23:21+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38375","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 21:45:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:10:24","updated":"2026-01-23 21:45:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38375","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=38375"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38375\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/28806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=38375"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=38375"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=38375"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}