O desenvolvemento das tecnoloxías no ámbito do software e hardware, a aparición de novos protocolos de comunicación propiciaron a expansión da Internet das Cousas (IoT). O número de dispositivos crece día a día e xeran unha enorme cantidade de datos. Polo tanto, cómpre contar cunha arquitectura de sistema cómoda capaz de procesar, almacenar e transmitir estes datos.
Agora os servizos na nube utilízanse para estes fins. Non obstante, o paradigma de computación de néboa (fog) cada vez máis popular pode complementar as solucións na nube escalando e optimizando a infraestrutura de IoT.
As nubes son capaces de cubrir a maioría das solicitudes de IoT. Por exemplo, para proporcionar seguimento dos servizos, procesamento rápido de calquera cantidade de datos xerados polos dispositivos, así como a súa visualización. A computación de néboa é máis eficaz á hora de resolver problemas en tempo real. Ofrecen resposta rápida ás solicitudes e unha latencia mínima no procesamento de datos. É dicir, Fog complementa as "nubes" e amplía as súas capacidades.
Non obstante, a pregunta principal é diferente: como debería interactuar todo isto no contexto do IoT? Que protocolos de comunicación serán máis eficaces cando se traballe nun sistema combinado IoT-Fog-Cloud?
A pesar do aparente dominio de HTTP, hai un gran número de outras solucións utilizadas nos sistemas IoT, Fog e Cloud. Isto débese a que IoT debe combinar a funcionalidade dunha variedade de sensores de dispositivos coa seguridade, compatibilidade e outros requisitos dos usuarios.
Pero simplemente non hai unha idea única sobre a arquitectura de referencia e o estándar de comunicación. Polo tanto, crear un novo protocolo ou modificar un xa existente para tarefas específicas de IoT é unha das tarefas máis importantes ás que se enfronta a comunidade informática.
Que protocolos están en uso actualmente e que poden ofrecer? Imos descubrir. Pero primeiro, imos discutir os principios do ecosistema no que interactúan as nubes, a néboa e a Internet das cousas.
Arquitectura IoT Fog-to-Cloud (F2C).
Probablemente notaches o esforzo que se está a facer para explorar as vantaxes e beneficios asociados á xestión intelixente e coordinada de IoT, nube e néboa. Se non, aquí hai tres iniciativas de normalización: , и .
Se antes só se consideraban 2 niveis, nubes e dispositivos finais, entón a arquitectura proposta introduce un novo nivel: a computación de néboa. Neste caso, o nivel de néboa pódese dividir en varios subniveles, dependendo das especificidades dos recursos ou dun conxunto de políticas que determinen o uso de diferentes dispositivos nestes subniveles.
Como pode ser esta abstracción? Aquí tes un ecosistema típico de IoT-Néboa-Nube. Os dispositivos IoT envían datos a servidores e dispositivos informáticos máis rápidos para resolver problemas que requiren baixa latencia. No mesmo sistema, as nubes encárganse de resolver problemas que requiren unha gran cantidade de recursos informáticos ou espazo de almacenamento de datos.
Os teléfonos intelixentes, reloxos intelixentes e outros aparellos tamén poden formar parte do IoT. Pero estes dispositivos, por regra xeral, usan protocolos de comunicación propietarios de grandes desenvolvedores. Os datos de IoT xerados transfírense á capa de néboa a través do protocolo HTTP REST, que proporciona flexibilidade e interoperabilidade ao crear servizos RESTful. Isto é importante á luz da necesidade de garantir a compatibilidade con versións anteriores coa infraestrutura informática existente que se executa en ordenadores locais, servidores ou un clúster de servidores. Os recursos locais, chamados "nodos de néboa", filtran os datos recibidos e procesalos localmente ou envíano á nube para realizar máis cálculos.
As nubes admiten diferentes protocolos de comunicación, sendo os máis comúns AMQP e REST HTTP. Dado que HTTP é moi coñecido e adaptado para Internet, pode xurdir a pregunta: "Non deberíamos usalo para traballar con IoT e néboa?" Non obstante, este protocolo ten problemas de rendemento. Máis sobre isto despois.
En xeral, existen 2 modelos de protocolos de comunicación axeitados ao sistema que necesitamos. Estes son solicitude-resposta e publicar-subscribir. O primeiro modelo é máis coñecido, especialmente na arquitectura servidor-cliente. O cliente solicita información ao servidor, e o servidor recibe a solicitude, procesa e devolve unha mensaxe de resposta. Os protocolos REST HTTP e CoAP funcionan neste modelo.
O segundo modelo xurdiu da necesidade de proporcionar un acoplamento asíncrono, distribuído e solto entre as fontes xeradoras de datos e os destinatarios destes datos.
O modelo asume tres participantes: un editor (fonte de datos), un corredor (despachador) e un subscritor (receptor). Aquí, o cliente que actúa como subscritor non ten que solicitar información ao servidor. En lugar de enviar solicitudes, subscríbese a determinados eventos do sistema a través dun corredor, que se encarga de filtrar todas as mensaxes entrantes e encamiñalas entre editores e subscritores. E o editor, cando se produce un evento sobre un determinado tema, publícao ao corredor, que envía datos sobre o tema solicitado ao subscritor.
Esencialmente, esta arquitectura está baseada en eventos. E este modelo de interacción é interesante para aplicacións en IoT, nube, néboa pola súa capacidade de proporcionar escalabilidade e simplificar a interconexión entre diferentes dispositivos, admitir comunicación dinámica de moitos a moitos e comunicación asíncrona. Algúns dos protocolos de mensaxería estandarizados máis coñecidos que usan un modelo de publicación e subscrición inclúen MQTT, AMQP e DDS.
Obviamente, o modelo de publicación-subscrición ten moitas vantaxes:
- Os editores e os subscritores non precisan coñecer a existencia uns dos outros;
- Un subscritor pode recibir información de moitas publicacións diferentes, e un editor pode enviar datos a moitos subscritores diferentes (principio de moitos a moitos);
- O editor e o subscritor non teñen que estar activos ao mesmo tempo para comunicarse, porque o intermediario (que traballa como sistema de colas) poderá almacenar a mensaxe para os clientes que non están actualmente conectados á rede.
Non obstante, o modelo de solicitude-resposta tamén ten os seus puntos fortes. Nos casos en que a capacidade do servidor para xestionar varias solicitudes de clientes non é un problema, ten sentido utilizar solucións probadas e fiables.
Tamén hai protocolos que admiten ambos modelos. Por exemplo, XMPP e HTTP 2.0, que admiten a opción "server push". O IETF tamén lanzou un CoAP. No intento de resolver o problema da mensaxería, creáronse outras varias solucións, como o protocolo WebSockets ou o uso do protocolo HTTP sobre QUIC (Quick UDP Internet Connections).
No caso dos WebSockets, aínda que se utiliza para transferir datos en tempo real dun servidor a un cliente web e proporciona conexións persistentes con comunicación bidireccional simultánea, non está pensado para dispositivos con recursos informáticos limitados. QUIC tamén merece atención, xa que o novo protocolo de transporte ofrece moitas novas oportunidades. Pero como QUIC aínda non está estandarizado, é prematuro prever a súa posible aplicación e impacto nas solucións de IoT. Polo tanto, temos en conta WebSockets e QUIC coa vista posta no futuro, pero non o estudaremos con máis detalle polo momento.
Quen é o máis lindo do mundo: comparar protocolos
Agora imos falar dos puntos fortes e débiles dos protocolos. De cara ao futuro, fagamos inmediatamente unha reserva de que non hai un líder claro. Cada protocolo ten algunhas vantaxes/inconvenientes.
Tempo de resposta
Unha das características máis importantes dos protocolos de comunicación, especialmente en relación coa Internet das Cousas, é o tempo de resposta. Pero entre os protocolos existentes, non hai un gañador claro que demostre o nivel mínimo de latencia cando se traballa en diferentes condicións. Pero hai unha chea de investigacións e comparacións de capacidades de protocolo.
Por exemplo, a As comparacións da eficacia de HTTP e MQTT cando se traballa con IoT mostraron que o tempo de resposta para as solicitudes de MQTT é menor que para HTTP. E cando O tempo de ida e volta (RTT) de MQTT e CoAP revelou que o RTT medio de CoAP é un 20% menor que o de MQTT.
Outro con RTT para os protocolos MQTT e CoAP realizouse en dous escenarios: rede local e rede IoT. Resultou que o RTT medio é 2-3 veces maior nunha rede IoT. MQTT con QoS0 mostrou un resultado inferior en comparación co CoAP, e MQTT con QoS1 mostrou un RTT maior debido aos ACK nas capas de aplicación e transporte. Para diferentes niveis de QoS, a latencia da rede sen conxestión foi de milisegundos para MQTT e de centos de microsegundos para CoAP. Non obstante, paga a pena lembrar que cando se traballa en redes menos fiables, MQTT que se executa enriba de TCP mostrará un resultado completamente diferente.
O tempo de resposta dos protocolos AMQP e MQTT ao aumentar a carga útil demostrou que cunha carga leve o nivel de latencia é case o mesmo. Pero ao transferir grandes cantidades de datos, MQTT mostra tempos de resposta máis curtos. nun máis CoAP comparouse co HTTP nun escenario de comunicación de máquina a máquina con dispositivos despregados encima de vehículos equipados con sensores de gas, sensores meteorolóxicos, sensores de localización (GPS) e unha interface de rede móbil (GPRS). O tempo necesario para transmitir unha mensaxe CoAP a través da rede móbil foi case tres veces menor que o tempo necesario para usar as mensaxes HTTP.
Realizáronse estudos que compararon non dous, senón tres protocolos. Por exemplo, desempeño dos protocolos IoT MQTT, DDS e CoAP nun escenario de aplicación médica mediante un emulador de rede. DDS superou a MQTT en canto á latencia de telemetría probada baixo unha variedade de condicións de rede pobres. CoAP baseado en UDP funcionou ben para aplicacións que requirían tempos de resposta rápidos, non obstante, debido a que estaba baseado en UDP, houbo unha importante perda de paquetes imprevisible.
Ancho de banda
MQTT e CoAP en canto á eficiencia do ancho de banda realizáronse como cálculo da cantidade total de datos transmitidos por mensaxe. CoAP mostrou un rendemento menor que MQTT ao transmitir mensaxes pequenas. Pero ao comparar a eficiencia dos protocolos en termos de relación entre o número de bytes de información útil e o número total de bytes transferidos, CoAP resultou máis eficaz.
En utilizando MQTT, DDS (con TCP como protocolo de transporte) e ancho de banda CoAP, comprobouse que CoAP xeralmente mostraba un consumo de ancho de banda comparativamente menor, que non aumentaba co aumento da perda de paquetes de rede ou o aumento da latencia da rede, a diferenza de MQTT e DDS, onde había un aumento da utilización do ancho de banda nos escenarios mencionados. Outro escenario implicou un gran número de dispositivos que transmitían datos de forma simultánea, o que é típico nos contornos IoT. Os resultados mostraron que para unha maior utilización é mellor usar CoAP.
Con carga lixeira, CoAP utilizou o menor ancho de banda, seguido de MQTT e REST HTTP. Non obstante, cando o tamaño das cargas útiles aumentou, REST HTTP tivo os mellores resultados.
Consumo de enerxía
O tema do consumo enerxético é sempre de gran importancia, e especialmente nun sistema IoT. Se Mentres MQTT e HTTP consomen electricidade, HTTP consome moito máis. E CoAP é máis en comparación con MQTT, permitindo a xestión de enerxía. Non obstante, en escenarios sinxelos, MQTT é máis axeitado para intercambiar información en redes de Internet das Cousas, especialmente se non hai restricións de enerxía.
Un experimento que comparou as capacidades de AMQP e MQTT nun banco de probas de rede sen fíos móbil ou inestable descubriu que AMQP ofrece máis capacidades de seguridade mentres que MQTT é máis eficiente enerxéticamente.
Безопасность
A seguridade é outra cuestión crítica que se suscita ao estudar o tema da Internet das cousas e a computación en nube/néboa. O mecanismo de seguranza baséase normalmente en TLS en HTTP, MQTT, AMQP e XMPP, ou DTLS en CoAP, e admite ambas as variantes de DDS.
TLS e DTLS comezan co proceso de establecer a comunicación entre os lados do cliente e do servidor para intercambiar chaves e conxuntos de cifrado compatibles. Ambas as partes negocian conxuntos para garantir que a comunicación se produza nunha canle segura. A diferenza entre ambos reside en pequenas modificacións que permiten que DTLS baseado en UDP funcione nunha conexión pouco fiable.
En Varias implementacións diferentes de TLS e DTLS descubriron que TLS fixo un traballo mellor. Os ataques a DTLS tiveron máis éxito debido á súa tolerancia aos erros.
Non obstante, o maior problema con estes protocolos é que orixinalmente non foron deseñados para o seu uso en IoT e non estaban pensados para funcionar na néboa ou na nube. Mediante a comunicación, engaden tráfico adicional con cada establecemento de conexión, o que drena os recursos informáticos. De media, hai un aumento do 6,5% para TLS e do 11% para DTLS nos gastos xerais en comparación coas comunicacións sen capa de seguridade. En ambientes ricos en recursos, que normalmente se localizan nivel, isto non será un problema, pero na conexión entre IoT e o nivel de néboa, isto convértese nunha limitación importante.
Que escoller? Non hai unha resposta clara. MQTT e HTTP parecen ser os protocolos máis prometedores xa que se consideran solucións IoT comparativamente máis maduras e máis estables en comparación con outros protocolos.
Solucións baseadas nun protocolo de comunicación unificado
A práctica dunha solución dun só protocolo ten moitas desvantaxes. Por exemplo, un protocolo que se adapta a un ambiente restrinxido pode non funcionar nun dominio que teña requisitos de seguridade estritos. Con isto en mente, quedamos por descartar case todas as posibles solucións dun só protocolo no ecosistema Fog-to-Cloud en IoT, excepto MQTT e REST HTTP.
REST HTTP como solución de protocolo único
Hai un bo exemplo de como interactúan as solicitudes e respostas HTTP REST no espazo IoT-to-Fog: . Os animais están equipados con sensores portátiles (cliente IoT, C) e controlados mediante computación en nube mediante un sistema de cultivo intelixente (servidor Fog, S).
A cabeceira do método POST especifica o recurso a modificar (/farm/animals), así como a versión HTTP e o tipo de contido, que neste caso é un obxecto JSON que representa a granxa de animais que o sistema debe xestionar (Dulcinea/vaca). . A resposta do servidor indica que a solicitude foi exitosa enviando o código de estado HTTPS 201 (recurso creado). O método GET debe especificar só o recurso solicitado no URI (por exemplo, /farm/animals/1), que devolve unha representación JSON do animal con ese ID desde o servidor.
O método PUT úsase cando hai que actualizar algún rexistro de recursos específico. Neste caso, o recurso especifica o URI do parámetro que se vai modificar e o valor actual (por exemplo, indicando que a vaca está camiñando actualmente, /farm/animals/1? state=andando). Finalmente, o método DELETE úsase igual que o método GET, pero simplemente elimina o recurso como resultado da operación.
MQTT como solución de protocolo único
Tomemos a mesma granxa intelixente, pero en lugar de REST HTTP usamos o protocolo MQTT. Un servidor local coa biblioteca Mosquitto instalada actúa como intermediario. Neste exemplo, un ordenador sinxelo (denominado servidor da granxa) Raspberry Pi serve como cliente MQTT, implementado mediante unha instalación da biblioteca Paho MQTT, que é totalmente compatible co corredor Mosquitto.
Este cliente corresponde a unha capa de abstracción IoT que representa un dispositivo con capacidades de detección e informática. O mediador, pola súa banda, correspóndese cun maior nivel de abstracción, representando un nodo de computación de néboa caracterizado por unha maior capacidade de procesamento e almacenamento.
No escenario de granxa intelixente proposto, o Raspberry Pi conéctase ao acelerómetro, ao GPS e aos sensores de temperatura e publica os datos destes sensores nun nodo de néboa. Como probablemente saibas, MQTT trata os temas como unha xerarquía. Un único editor de MQTT pode publicar mensaxes sobre un conxunto específico de temas. No noso caso son tres. Para un sensor que mide a temperatura nun hórreo de animais, o cliente selecciona un tema (granja/galpón/temperatura). Para os sensores que miden a localización GPS e o movemento dos animais a través do acelerómetro, o cliente publicará actualizacións de (granja/animal/GPS) e (granja/animal/movemento).
Esta información pasarase ao corredor, quen pode almacenala temporalmente nunha base de datos local no caso de que apareza máis tarde outro subscritor interesado.
Ademais do servidor local, que actúa como intermediario MQTT na néboa e ao que Raspberry Pis, actuando como clientes MQTT, envía datos de sensores, pode haber outro corredor MQTT a nivel de nube. Neste caso, a información transmitida ao corredor local pódese almacenar temporalmente nunha base de datos local e/ou enviarse á nube. O broker MQTT de néboa nesta situación úsase para asociar todos os datos co corredor MQTT na nube. Con esta arquitectura, un usuario de aplicacións móbiles pode subscribirse a ambos os corredores.
Se a conexión cun dos corredores (por exemplo, a nube) falla, o usuario final recibirá información do outro (néboa). Esta é unha característica dos sistemas combinados de néboa e computación en nube. De forma predeterminada, a aplicación móbil pódese configurar para conectarse primeiro ao corredor MQTT de néboa e, se iso falla, para conectarse ao corredor MQTT na nube. Esta solución é só unha das moitas dos sistemas IoT-F2C.
Solucións multiprotocolo
As solucións de protocolo único son populares debido á súa fácil implementación. Pero está claro que nos sistemas IoT-F2C ten sentido combinar diferentes protocolos. A idea é que diferentes protocolos poidan operar a diferentes niveis. Tomemos, por exemplo, tres abstraccións: as capas de IoT, fog e cloud computing. Os dispositivos a nivel de IoT considéranse en xeral limitados. Para esta visión xeral, consideremos os niveis de IoT como os máis restrinxidos, a nube o menos restrinxido e a computación de néboa como "nalgún lugar no medio". Resulta entón que entre as abstraccións de IoT e de néboa, as solucións de protocolo actuais inclúen MQTT, CoAP e XMPP. Entre a néboa e a nube, pola súa banda, AMQP é un dos principais protocolos empregados, xunto co REST HTTP, que pola súa flexibilidade tamén se utiliza entre as capas de IoT e de néboa.
O principal problema aquí é a interoperabilidade dos protocolos e a facilidade de transferencia de mensaxes dun protocolo a outro. O ideal é que no futuro a arquitectura dun sistema de Internet das Cousas con recursos de nube e néboa sexa independente do protocolo de comunicación empregado e garantirá unha boa interoperabilidade entre os distintos protocolos.
Dado que este non é o caso actualmente, ten sentido combinar protocolos que non teñan diferenzas significativas. Para iso, unha solución potencial baséase nunha combinación de dous protocolos que seguen o mesmo estilo arquitectónico, REST HTTP e CoAP. Outra solución proposta baséase nunha combinación de dous protocolos que ofrecen comunicación publicación-subscrición, MQTT e AMQP. Usar conceptos similares (tanto MQTT como AMQP usan corredores, CoAP e HTTP usan REST) fai que estas combinacións sexan máis fáciles de implementar e require menos esforzo de integración.
A figura (a) mostra dous modelos baseados en solicitudes e respostas, HTTP e CoAP, e a súa posible colocación nunha solución IoT-F2C. Dado que HTTP é un dos protocolos máis coñecidos e adoptados nas redes modernas, é improbable que sexa completamente substituído por outros protocolos de mensaxería. Entre os nodos que representan dispositivos poderosos que se sitúan entre a nube e a néboa, REST HTTP é unha solución intelixente.
Por outra banda, para dispositivos con recursos informáticos limitados que se comunican entre as capas Fog e IoT, é máis eficiente usar CoAP. Unha das grandes vantaxes de CoAP é en realidade a súa compatibilidade con HTTP, xa que ambos os protocolos están baseados nos principios REST.
A figura (b) mostra dous modelos de comunicación de publicación-subscrición no mesmo escenario, incluíndo MQTT e AMQP. Aínda que hipotéticamente ambos protocolos poderían usarse para a comunicación entre nodos de cada capa de abstracción, a súa posición debería determinarse en función do rendemento. MQTT foi deseñado como un protocolo lixeiro para dispositivos con recursos informáticos limitados, polo que se pode usar para a comunicación IoT-Fog. AMQP é máis axeitado para dispositivos máis potentes, que o situarían idealmente entre os nós de néboa e de nube. En lugar de MQTT, o protocolo XMPP pódese usar en IoT xa que se considera lixeiro. Pero non é tan amplamente utilizado en tales escenarios.
Descubrimentos
É pouco probable que un dos protocolos comentados sexa suficiente para cubrir todas as comunicacións dun sistema, desde dispositivos con recursos informáticos limitados ata servidores na nube. O estudo descubriu que as dúas opcións máis prometedoras que máis usan os desenvolvedores son MQTT e RESTful HTTP. Estes dous protocolos non só son os máis maduros e estables, senón que tamén inclúen moitas implementacións e recursos en liña ben documentados e exitosos.
Debido á súa estabilidade e configuración sinxela, MQTT é un protocolo que demostrou o seu rendemento superior ao longo do tempo cando se usa a nivel de IoT con dispositivos limitados. Nas partes do sistema onde a comunicación limitada e o consumo de batería non son un problema, como algúns dominios de néboa e a maioría da computación en nube, RESTful HTTP é unha opción sinxela. Tamén se debe ter en conta CoAP, xa que tamén está a evolucionar rapidamente como estándar de mensaxería IoT e é probable que alcance un nivel de estabilidade e madurez similar ao MQTT e HTTP nun futuro próximo. Pero o estándar está a evolucionar actualmente, o que vén con problemas de compatibilidade a curto prazo.
Que máis podes ler no blog?
→
→
→
→
→
Subscríbete ao noso -canle, para non perder o seguinte artigo! Escribimos non máis de dúas veces por semana e só por negocios.
Fonte: www.habr.com