El desenvolupament de tecnologies en l'àmbit del programari i maquinari, l'aparició de nous protocols de comunicació han propiciat l'expansió de l'Internet de les coses (IoT). El nombre de dispositius creix dia a dia i estan generant una gran quantitat de dades. Per tant, es necessita una arquitectura de sistema convenient capaç de processar, emmagatzemar i transmetre aquestes dades.
Ara els serveis al núvol s'utilitzen per a aquests propòsits. Tanmateix, el paradigma de computació de boira (fog) cada cop més popular pot complementar les solucions al núvol mitjançant l'escalada i l'optimització de la infraestructura IoT.
Els núvols són capaços de cobrir la majoria de sol·licituds d'IoT. Per exemple, per oferir un seguiment dels serveis, un processament ràpid de qualsevol quantitat de dades generades pels dispositius, així com la seva visualització. La computació de boira és més eficaç quan es resolen problemes en temps real. Ofereixen una resposta ràpida a les sol·licituds i una latència mínima en el processament de dades. És a dir, Fog complementa els "núvols" i amplia les seves capacitats.
Tanmateix, la pregunta principal és diferent: com ha d'interaccionar tot això en el context de l'IoT? Quins protocols de comunicació seran més efectius quan es treballi en un sistema combinat IoT-Boira-núvol?
Malgrat l'aparent domini d'HTTP, hi ha un gran nombre d'altres solucions utilitzades en sistemes IoT, Fog i Cloud. Això es deu al fet que IoT ha de combinar la funcionalitat d'una varietat de sensors de dispositius amb la seguretat, la compatibilitat i altres requisits dels usuaris.
Però simplement no hi ha una idea única sobre l'arquitectura de referència i l'estàndard de comunicació. Per tant, crear un nou protocol o modificar-ne un existent per a tasques específiques d'IoT és una de les tasques més importants a què s'enfronta la comunitat informàtica.
Quins protocols s'utilitzen actualment i què poden oferir? Anem a esbrinar-ho. Però primer, parlem dels principis de l'ecosistema en què interactuen els núvols, la boira i l'Internet de les coses.
Arquitectura IoT de boira a núvol (F2C).
Probablement us heu adonat del gran esforç que s'està fent per explorar els avantatges i beneficis associats a la gestió intel·ligent i coordinada de l'IoT, el núvol i la boira. Si no, aquí hi ha tres iniciatives d'estandardització: , и .
Si abans només es consideraven 2 nivells, núvols i dispositius finals, l'arquitectura proposada introdueix un nou nivell: la informàtica de boira. En aquest cas, el nivell de boira es pot dividir en diversos subnivells, segons les especificitats dels recursos o un conjunt de polítiques que determinen l'ús de diferents dispositius en aquests subnivells.
Com podria ser aquesta abstracció? Aquí hi ha un ecosistema típic d'IoT-Boira-núvol. Els dispositius IoT envien dades a servidors i dispositius informàtics més ràpids per resoldre problemes que requereixen una baixa latència. En el mateix sistema, els núvols s'encarreguen de resoldre problemes que requereixen una gran quantitat de recursos informàtics o espai d'emmagatzematge de dades.
Els telèfons intel·ligents, els rellotges intel·ligents i altres aparells també poden formar part de l'IoT. Però aquests dispositius, per regla general, utilitzen protocols de comunicació propietaris de grans desenvolupadors. Les dades d'IoT generades es transfereixen a la capa de boira mitjançant el protocol REST HTTP, que proporciona flexibilitat i interoperabilitat a l'hora de crear serveis RESTful. Això és important tenint en compte la necessitat de garantir la compatibilitat amb la infraestructura informàtica existent que s'executa en ordinadors locals, servidors o un clúster de servidors. Els recursos locals, anomenats "nodes de boira", filtren les dades rebudes i les processen localment o les envien al núvol per a més càlculs.
Els núvols admeten diferents protocols de comunicació, els més comuns són AMQP i REST HTTP. Com que HTTP és molt conegut i adaptat per a Internet, pot sorgir la pregunta: "no l'hauríem d'utilitzar per treballar amb IoT i boira?" Tanmateix, aquest protocol té problemes de rendiment. Més sobre això més endavant.
En general, hi ha 2 models de protocols de comunicació adequats al sistema que necessitem. Aquests són sol·licitud-resposta i publicació-subscripció. El primer model és més conegut, especialment en l'arquitectura servidor-client. El client demana informació al servidor, i el servidor rep la sol·licitud, la processa i retorna un missatge de resposta. Els protocols REST HTTP i CoAP funcionen amb aquest model.
El segon model va sorgir de la necessitat de proporcionar un acoblament asíncron, distribuït i fluix entre les fonts generadores de dades i els destinataris d'aquestes dades.
El model suposa tres participants: un editor (font de dades), un intermediari (despatx) i un subscriptor (receptor). Aquí, el client que actua com a subscriptor no ha de demanar informació al servidor. En lloc d'enviar sol·licituds, es subscriu a determinats esdeveniments del sistema a través d'un corredor, que s'encarrega de filtrar tots els missatges entrants i encaminar-los entre editors i subscriptors. I l'editor, quan es produeix un esdeveniment sobre un tema determinat, el publica al corredor, que envia dades sobre el tema sol·licitat al subscriptor.
Essencialment, aquesta arquitectura es basa en esdeveniments. I aquest model d'interacció és interessant per a aplicacions en IoT, núvol, boira per la seva capacitat per proporcionar escalabilitat i simplificar la interconnexió entre diferents dispositius, suportar la comunicació dinàmica de molts a molts i la comunicació asíncrona. Alguns dels protocols de missatgeria estandarditzats més coneguts que utilitzen un model de publicació i subscripció inclouen MQTT, AMQP i DDS.
Evidentment, el model de publicació-subscripció té molts avantatges:
- Els editors i els subscriptors no necessiten conèixer l'existència dels altres;
- Un subscriptor pot rebre informació de moltes publicacions diferents, i un editor pot enviar dades a molts subscriptors diferents (principi de molts a molts);
- L'editor i el subscriptor no han d'estar actius al mateix temps per comunicar-se, perquè el corredor (que treballa com a sistema de cua) podrà emmagatzemar el missatge per als clients que actualment no estan connectats a la xarxa.
Tanmateix, el model de petició-resposta també té els seus punts forts. En els casos en què la capacitat del servidor per gestionar múltiples sol·licituds de client no és un problema, té sentit utilitzar solucions provades i fiables.
També hi ha protocols que admeten ambdós models. Per exemple, XMPP i HTTP 2.0, que admeten l'opció "server push". L'IETF també ha publicat un CoAP. En un intent de resoldre el problema de missatgeria, s'han creat diverses altres solucions, com ara el protocol WebSockets o l'ús del protocol HTTP a través de QUIC (Quick UDP Internet Connections).
En el cas de WebSockets, encara que s'utilitza per transferir dades en temps real d'un servidor a un client web i proporciona connexions persistents amb comunicació bidireccional simultània, no està pensat per a dispositius amb recursos informàtics limitats. QUIC també mereix atenció, ja que el nou protocol de transport ofereix moltes oportunitats noves. Però com que QUIC encara no està estandarditzat, és prematur predir la seva possible aplicació i impacte en les solucions IoT. Així doncs, tenim presents WebSockets i QUIC amb vista al futur, però de moment no ho estudiarem amb més detall.
Qui és el més maco del món: comparant protocols
Ara parlem dels punts forts i febles dels protocols. De cara al futur, de seguida fem una reserva que no hi ha cap líder clar. Cada protocol té alguns avantatges/desavantatges.
Temps de resposta
Una de les característiques més importants dels protocols de comunicació, especialment en relació a la Internet de les coses, és el temps de resposta. Però entre els protocols existents, no hi ha cap guanyador clar que demostri el nivell mínim de latència quan es treballa en diferents condicions. Però hi ha un munt d'investigacions i comparacions de capacitats de protocol.
Per exemple, Les comparacions de l'efectivitat d'HTTP i MQTT quan es treballa amb IoT van mostrar que el temps de resposta per a les sol·licituds de MQTT és menor que per a HTTP. I quan El temps d'anada i tornada (RTT) de MQTT i CoAP va revelar que el RTT mitjà de CoAP és un 20% menys que el de MQTT.
Altres amb RTT per als protocols MQTT i CoAP es va dur a terme en dos escenaris: xarxa local i xarxa IoT. Va resultar que el RTT mitjà és 2-3 vegades més gran en una xarxa IoT. MQTT amb QoS0 va mostrar un resultat inferior en comparació amb CoAP, i MQTT amb QoS1 va mostrar un RTT més alt a causa dels ACK a les capes d'aplicació i transport. Per a diferents nivells de QoS, la latència de xarxa sense congestió era de mil·lisegons per a MQTT i centenars de microsegons per a CoAP. Tanmateix, val la pena recordar que quan es treballa en xarxes menys fiables, MQTT que s'executa a sobre de TCP mostrarà un resultat completament diferent.
El temps de resposta dels protocols AMQP i MQTT augmentant la càrrega útil va demostrar que amb una càrrega lleugera el nivell de latència és gairebé el mateix. Però quan es transfereixen grans quantitats de dades, MQTT demostra temps de resposta més curts. en un més CoAP es va comparar amb HTTP en un escenari de comunicació màquina a màquina amb dispositius desplegats a la part superior de vehicles equipats amb sensors de gas, sensors meteorològics, sensors d'ubicació (GPS) i una interfície de xarxa mòbil (GPRS). El temps necessari per transmetre un missatge CoAP a la xarxa mòbil era gairebé tres vegades més curt que el temps necessari per utilitzar missatges HTTP.
S'han realitzat estudis que no van comparar dos, sinó tres protocols. Per exemple, rendiment dels protocols IoT MQTT, DDS i CoAP en un escenari d'aplicació mèdica mitjançant un emulador de xarxa. DDS va superar MQTT en termes de latència de telemetria provada en diverses condicions de xarxa pobres. CoAP basat en UDP va funcionar bé per a aplicacions que requerien temps de resposta ràpids, però, com que es basava en UDP, hi va haver una pèrdua de paquets impredictible important.
Ample de banda
MQTT i CoAP en termes d'eficiència d'ample de banda es va dur a terme com a càlcul de la quantitat total de dades transmeses per missatge. CoAP ha mostrat un rendiment més baix que MQTT quan transmet missatges petits. Però en comparar l'eficiència dels protocols pel que fa a la relació entre el nombre de bytes d'informació útils i el nombre total de bytes transferits, CoAP va resultar més eficaç.
En utilitzant MQTT, DDS (amb TCP com a protocol de transport) i ample de banda CoAP, es va trobar que CoAP generalment mostrava un consum d'amplada de banda comparativament menor, que no augmentava amb l'augment de la pèrdua de paquets de xarxa o l'augment de la latència de la xarxa, a diferència de MQTT i DDS, on hi havia un augment de la utilització de l'ample de banda en els escenaris esmentats. Un altre escenari implicava un gran nombre de dispositius que transmetien dades simultàniament, cosa típica en entorns IoT. Els resultats van mostrar que per a una major utilització és millor utilitzar CoAP.
Amb una càrrega lleugera, CoAP va utilitzar el menor ample de banda, seguit de MQTT i REST HTTP. Tanmateix, quan la mida de les càrregues útils va augmentar, REST HTTP va tenir els millors resultats.
Consum d'energia
El tema del consum d'energia és sempre de gran importància, i sobretot en un sistema IoT. Si Mentre que MQTT i HTTP consumeixen electricitat, HTTP consumeix molt més. I CoAP és més en comparació amb MQTT, permetent la gestió de l'energia. Tanmateix, en escenaris senzills, MQTT és més adequat per intercanviar informació a les xarxes d'Internet de les coses, especialment si no hi ha restriccions d'alimentació.
Un experiment que va comparar les capacitats d'AMQP i MQTT en un banc de proves de xarxa sense fil mòbil o inestable va trobar que AMQP ofereix més capacitats de seguretat mentre que MQTT és més eficient energèticament.
Безопасность
La seguretat és un altre tema crític que es planteja quan s'estudia el tema de l'Internet de les coses i la informàtica de boira/núvol. El mecanisme de seguretat es basa normalment en TLS en HTTP, MQTT, AMQP i XMPP, o DTLS en CoAP, i admet ambdues variants de DDS.
TLS i DTLS comencen amb el procés d'establir una comunicació entre els costats del client i el servidor per intercanviar les claus i les suites de xifratge compatibles. Ambdues parts negocien conjunts per assegurar-se que es produeixi més comunicació en un canal segur. La diferència entre els dos rau en petites modificacions que permeten que DTLS basat en UDP funcioni amb una connexió poc fiable.
En Diverses implementacions diferents de TLS i DTLS van trobar que TLS va fer un millor treball. Els atacs a DTLS van tenir més èxit a causa de la seva tolerància a errors.
Tanmateix, el problema més gran d'aquests protocols és que originalment no estaven dissenyats per utilitzar-los a IoT i no estaven pensats per funcionar a la boira o al núvol. Mitjançant l'enllaç de mans, afegeixen trànsit addicional amb cada establiment de connexió, la qual cosa esgota els recursos informàtics. De mitjana, hi ha un augment del 6,5% per a TLS i un 11% per a DTLS en sobrecàrrega en comparació amb les comunicacions sense capa de seguretat. En entorns rics en recursos, que normalment es troben a nivell, això no serà un problema, però en la connexió entre IoT i el nivell de boira, això es converteix en una limitació important.
Què triar? No hi ha una resposta clara. MQTT i HTTP semblen ser els protocols més prometedors, ja que es consideren solucions IoT comparativament més madures i més estables en comparació amb altres protocols.
Solucions basades en un protocol de comunicació unificat
La pràctica d'una solució d'un sol protocol té molts inconvenients. Per exemple, un protocol que s'adapti a un entorn restringit pot no funcionar en un domini que tingui requisits de seguretat estrictes. Tenint això en compte, hem de descartar gairebé totes les solucions possibles d'un sol protocol a l'ecosistema Fog-to-Cloud a IoT, excepte MQTT i REST HTTP.
REST HTTP com a solució d'un sol protocol
Hi ha un bon exemple de com les sol·licituds i respostes HTTP REST interactuen a l'espai IoT-to-Fog: . Els animals estan equipats amb sensors portàtils (client IoT, C) i controlats mitjançant computació en núvol mitjançant un sistema d'agricultura intel·ligent (servidor Fog, S).
La capçalera del mètode POST especifica el recurs a modificar (/farm/animals), així com la versió HTTP i el tipus de contingut, que en aquest cas és un objecte JSON que representa la granja d'animals que el sistema ha de gestionar (Dulcinea/vaca). . La resposta del servidor indica que la sol·licitud ha tingut èxit enviant el codi d'estat HTTPS 201 (recurs creat). El mètode GET ha d'especificar només el recurs sol·licitat a l'URI (per exemple, /farm/animals/1), que retorna una representació JSON de l'animal amb aquest ID des del servidor.
El mètode PUT s'utilitza quan cal actualitzar algun registre de recurs específic. En aquest cas, el recurs especifica l'URI del paràmetre a canviar i el valor actual (per exemple, indicant que la vaca està caminant actualment, /farm/animals/1? state=walking). Finalment, el mètode DELETE s'utilitza igual que el mètode GET, però simplement elimina el recurs com a resultat de l'operació.
MQTT com a solució de protocol únic
Prenem la mateixa granja intel·ligent, però en comptes de REST HTTP fem servir el protocol MQTT. Un servidor local amb la biblioteca Mosquitto instal·lada actua com a intermediari. En aquest exemple, un ordinador senzill (anomenat servidor de la granja) Raspberry Pi serveix com a client MQTT, implementat mitjançant una instal·lació de la biblioteca Paho MQTT, que és totalment compatible amb el corredor Mosquitto.
Aquest client correspon a una capa d'abstracció IoT que representa un dispositiu amb capacitats de detecció i informàtica. El mediador, en canvi, correspon a un nivell d'abstracció superior, que representa un node de computació de boira caracteritzat per una major capacitat de processament i emmagatzematge.
En l'escenari de granja intel·ligent proposat, el Raspberry Pi es connecta a l'acceleròmetre, el GPS i els sensors de temperatura i publica les dades d'aquests sensors a un node de boira. Com probablement sabeu, MQTT tracta els temes com una jerarquia. Un únic editor de MQTT pot publicar missatges sobre un conjunt específic de temes. En el nostre cas n'hi ha tres. Per a un sensor que mesura la temperatura en un graner d'animals, el client selecciona un tema (granja d'animals / cobert / temperatura). Per als sensors que mesuren la ubicació GPS i el moviment dels animals a través de l'acceleròmetre, el client publicarà actualitzacions a (granja/animal/GPS) i (granja/animal/moviment).
Aquesta informació es passarà al corredor, que la pot emmagatzemar temporalment en una base de dades local en cas que més tard arribi un altre subscriptor interessat.
A més del servidor local, que actua com a corredor MQTT a la boira i al qual Raspberry Pis, actuant com a clients MQTT, envia dades de sensors, pot haver-hi un altre corredor MQTT a nivell de núvol. En aquest cas, la informació transmesa al corredor local es pot emmagatzemar temporalment en una base de dades local i/o enviar-se al núvol. El broker MQTT de boira en aquesta situació s'utilitza per associar totes les dades amb el broker MQTT del núvol. Amb aquesta arquitectura, un usuari d'una aplicació mòbil es pot subscriure als dos corredors.
Si la connexió amb un dels intermediaris (per exemple, el núvol) falla, l'usuari final rebrà informació de l'altre (boira). Aquesta és una característica dels sistemes combinats de boira i núvol. De manera predeterminada, l'aplicació mòbil es pot configurar per connectar-se primer al broker MQTT de boira i, si això falla, per connectar-se al broker MQTT del núvol. Aquesta solució és només una de les moltes en sistemes IoT-F2C.
Solucions multiprotocol
Les solucions de protocol únic són populars a causa de la seva implementació més fàcil. Però és evident que als sistemes IoT-F2C té sentit combinar diferents protocols. La idea és que diferents protocols puguin funcionar a diferents nivells. Prenguem, per exemple, tres abstraccions: les capes d'IoT, la boira i la computació en núvol. Els dispositius a nivell d'IoT es consideren generalment limitats. Per a aquesta visió general, considerem els nivells IoT com els més restringits, el núvol el menys restringit i la informàtica de boira com "en algun lloc del mig". Aleshores, resulta que entre les abstraccions d'IoT i de boira, les solucions de protocol actuals inclouen MQTT, CoAP i XMPP. Entre boira i núvol, en canvi, AMQP és un dels principals protocols utilitzats, juntament amb REST HTTP, que per la seva flexibilitat també s'utilitza entre capes IoT i boira.
El principal problema aquí és la interoperabilitat dels protocols i la facilitat de transferir missatges d'un protocol a un altre. Idealment, en el futur, l'arquitectura d'un sistema d'Internet de les coses amb recursos de núvol i boira serà independent del protocol de comunicació utilitzat i garantirà una bona interoperabilitat entre els diferents protocols.
Com que actualment no és així, té sentit combinar protocols que no presenten diferències significatives. Amb aquesta finalitat, una solució potencial es basa en una combinació de dos protocols que segueixen el mateix estil arquitectònic, REST HTTP i CoAP. Una altra solució proposada es basa en una combinació de dos protocols que ofereixen comunicació publicació-subscripció, MQTT i AMQP. L'ús de conceptes similars (tant MQTT com AMQP utilitzen corredors, CoAP i HTTP utilitzen REST) fa que aquestes combinacions siguin més fàcils d'implementar i requereix menys esforç d'integració.
La figura (a) mostra dos models basats en sol·licituds de resposta, HTTP i CoAP, i la seva possible col·locació en una solució IoT-F2C. Com que HTTP és un dels protocols més coneguts i adoptats a les xarxes modernes, és poc probable que sigui completament substituït per altres protocols de missatgeria. Entre els nodes que representen dispositius potents que es troben entre el núvol i la boira, REST HTTP és una solució intel·ligent.
D'altra banda, per als dispositius amb recursos informàtics limitats que es comuniquen entre les capes Fog i IoT, és més eficient utilitzar CoAP. Un dels grans avantatges de CoAP és en realitat la seva compatibilitat amb HTTP, ja que tots dos protocols es basen en principis REST.
La figura (b) mostra dos models de comunicació de publicació-subscripció en el mateix escenari, inclosos MQTT i AMQP. Tot i que ambdós protocols es podrien utilitzar hipotèticament per a la comunicació entre nodes de cada capa d'abstracció, la seva posició s'hauria de determinar en funció del rendiment. MQTT es va dissenyar com un protocol lleuger per a dispositius amb recursos informàtics limitats, de manera que es pot utilitzar per a la comunicació IoT-Fog. AMQP és més adequat per a dispositius més potents, que idealment el col·locarien entre els nodes de boira i núvol. En lloc de MQTT, el protocol XMPP es pot utilitzar a IoT, ja que es considera lleuger. Però no s'utilitza tant en aquests escenaris.
Troballes
És poc probable que un dels protocols comentats sigui suficient per cobrir totes les comunicacions d'un sistema, des de dispositius amb recursos informàtics limitats fins a servidors en núvol. L'estudi va trobar que les dues opcions més prometedores que més utilitzen els desenvolupadors són MQTT i RESTful HTTP. Aquests dos protocols no només són els més madurs i estables, sinó que també inclouen moltes implementacions i recursos en línia ben documentats i reeixits.
A causa de la seva estabilitat i configuració senzilla, MQTT és un protocol que ha demostrat el seu rendiment superior al llarg del temps quan s'utilitza a nivell d'IoT amb dispositius limitats. A les parts del sistema on la comunicació limitada i el consum de bateria no són un problema, com ara alguns dominis de boira i la majoria de computació en núvol, RESTful HTTP és una opció fàcil. També s'ha de tenir en compte CoAP, ja que també està evolucionant ràpidament com a estàndard de missatgeria IoT i és probable que assoleixi un nivell d'estabilitat i maduresa similar a MQTT i HTTP en un futur proper. Però actualment l'estàndard està evolucionant, cosa que comporta problemes de compatibilitat a curt termini.
Què més pots llegir al blog?
→
→
→
→
→
Subscriu-te al nostre -canal, per no perdre's el següent article! Escrivim no més de dues vegades per setmana i només per negocis.
Font: www.habr.com