IoT, niebla y nubes: ¿hablar de tecnología?

El desarrollo de tecnologías en el campo del software y el hardware, la aparición de nuevos protocolos de comunicación han llevado a la expansión de Internet de las cosas (IoT). La cantidad de dispositivos crece día a día y generan una gran cantidad de datos. Por lo tanto, surge la necesidad de una arquitectura de sistema conveniente capaz de procesar, almacenar y transmitir estos datos.

Ahora usan servicios en la nube para estos fines. Sin embargo, el paradigma de niebla cada vez mayor (Fog) puede complementar las soluciones en la nube al escalar y optimizar la infraestructura de IoT.

Las nubes pueden cerrar la mayoría de las solicitudes de IoT. Por ejemplo, para proporcionar servicios de monitoreo, procesamiento rápido de cualquier cantidad de datos generados por los dispositivos, así como su visualización. La computación brumosa es más efectiva para resolver problemas en tiempo real. Proporcionan una respuesta rápida a las solicitudes y el mínimo retraso en el procesamiento de datos. Es decir, Fog complementa exactamente las "nubes", expande sus capacidades.

Sin embargo, la pregunta principal es diferente: ¿cómo debería interactuar todo esto en el contexto de IoT? ¿Qué protocolos de comunicación serán más efectivos cuando trabaje en un sistema unificado IoT-Fog-Cloud?

A pesar del aparente dominio de HTTP, IoT, Fog y Cloud, utilizamos una gran cantidad de otras soluciones. Esto se debe a que IoT debe combinar la funcionalidad de una variedad de sensores de dispositivo con la seguridad, la interoperabilidad y otros requisitos del usuario.

Aquí hay una sola idea de la arquitectura de referencia y el estándar de comunicación simplemente no existe. Por lo tanto, la creación de un nuevo protocolo o el refinamiento de uno existente para tareas específicas de IoT es una de las tareas más importantes que enfrenta la comunidad de TI.

¿Qué protocolos se utilizan ahora y qué pueden ofrecer? Vamos a hacerlo bien. Pero primero, analicemos los principios de un ecosistema en el que las nubes, la niebla y el Internet de las cosas interactúan.

Arquitectura de niebla a nube de IoT (F2C)

Debe haber notado cuánto esfuerzo se ha puesto en explorar los beneficios y beneficios de administrar IoT, nubes y niebla de manera racional y coordinada. De lo contrario, ya hay tres iniciativas de estandarización: OpenFog Consortium , Edge Computing Consortium y mF2C H2020 EU project .

Si antes solo se consideraban 2 niveles, nubes y dispositivos finales, entonces la arquitectura propuesta introduce un nuevo nivel: la computación de niebla. En este caso, el nivel de niebla se puede dividir en varios subniveles, según los detalles de los recursos o un conjunto de políticas que determinan el uso de diferentes dispositivos en estos subniveles.

¿Cómo podría ser esta abstracción? Aquí hay un ecosistema típico de IoT-Fog-Cloud. Los dispositivos IoT envían datos a servidores y dispositivos informáticos más potentes para resolver tareas que requieren baja latencia. En el mismo sistema, las nubes son responsables de resolver los problemas que requieren una gran cantidad de recursos informáticos o espacio de almacenamiento de datos.



Los teléfonos inteligentes, los relojes inteligentes y otros dispositivos también pueden ser parte de IoT. Pero tales dispositivos, como regla, usan protocolos de comunicación patentados de grandes desarrolladores. Los datos IoT generados se pasan al nivel de niebla a través del protocolo REST HTTP, que proporciona flexibilidad e interoperabilidad al crear servicios RESTful. Esto es importante a la luz de la necesidad de compatibilidad con la infraestructura informática existente que se ejecuta en computadoras locales, servidores o un clúster de servidores. Los recursos locales, llamados "nodos de la niebla", filtran los datos recibidos y los procesan localmente o los envían a la nube para realizar más cálculos.

Las nubes admiten varios protocolos de comunicación, entre los que se encuentran AMQP y REST HTTP con mayor frecuencia. Dado que HTTP es bien conocido y está encarcelado por Internet, puede surgir la pregunta: "¿Pero debería usarlo para trabajar con IoT y niebla?". Sin embargo, este protocolo tiene problemas de rendimiento. Más sobre esto más tarde.

En general, hay 2 modelos de protocolos de comunicación adecuados para el sistema que necesitamos. Esta es una solicitud-respuesta y publicación-suscripción. El primer modelo es más conocido, especialmente en la arquitectura servidor-cliente. El cliente solicita información del servidor, y recibe la solicitud, la procesa y devuelve un mensaje de respuesta. Los protocolos REST HTTP y CoAP funcionan en este modelo.

El segundo modelo surgió debido a la necesidad de proporcionar una comunicación asincrónica, distribuida y débil entre las fuentes que generan datos y los destinatarios de estos datos.



El modelo involucra a tres participantes: el editor (fuente de datos), el corredor (despachador) y el suscriptor (receptor). Aquí, el cliente que actúa como suscriptor no debe solicitar información del servidor. En lugar de enviar solicitudes, se suscribe a ciertos eventos en el sistema a través de un agente responsable de filtrar todos los mensajes entrantes y enrutarlos entre editores y suscriptores. Y el editor, cuando ocurre un evento relacionado con un tema determinado, lo publica al corredor, quien envía los datos del suscriptor sobre el tema solicitado.

En esencia, esta arquitectura está impulsada por eventos. Y este modelo de interacción es interesante para aplicaciones en IoT, nube, niebla debido a su capacidad de proporcionar escalabilidad y simplificar la interconexión entre diferentes dispositivos, para soportar la comunicación dinámica de muchos a muchos y la comunicación asincrónica. Entre los protocolos de mensajería estandarizados más conocidos que utilizan el modelo de publicación-suscripción están MQTT, AMQP y DDS.

Obviamente, el modelo de publicación-suscripción tiene muchas ventajas:

• Los editores y suscriptores no necesitan saber sobre la existencia del otro;
• Un suscriptor puede recibir información de muchas publicaciones diferentes, y un editor puede enviar datos a muchos suscriptores diferentes (el principio "muchos a muchos");
• No se requiere que el editor y el suscriptor estén activos simultáneamente para el intercambio de datos, porque el intermediario (que funciona como un sistema de cola) podrá almacenar un mensaje para los clientes que actualmente no están conectados a la red.

Sin embargo, el modelo de solicitud-respuesta también tiene sus propias fortalezas. En los casos en que las capacidades del lado del servidor para procesar solicitudes de varios clientes no sean un problema, tiene sentido utilizar soluciones confiables ya probadas.

También hay protocolos que admiten ambos modelos. Por ejemplo, XMPP y HTTP 2.0 que admiten la opción de inserción del servidor. El IETF también ha lanzado CoAP. En un intento por resolver el problema de la mensajería, se crearon varias otras soluciones, como el protocolo WebSockets o el uso del protocolo HTTP a través de QUIC (Quick UDP Internet Connections).

En el caso de WebSockets, aunque se utiliza para la transferencia de datos en tiempo real desde el servidor al cliente web y proporciona conexiones constantes con comunicación bidireccional simultánea, no está destinado a dispositivos con recursos informáticos limitados. QUIC también merece atención, ya que el nuevo protocolo de transporte ofrece muchas características nuevas. Pero dado que QUIC aún no está estandarizado, es prematuro predecir su posible aplicación e impacto en las soluciones de IoT. Así que dejamos WebSockets y QUIC en la memoria con la vista puesta en el futuro, pero aún no estudiaremos con más detalle.

Quién en el mundo es más dulce: comparamos protocolos

Ahora hablemos de las fortalezas y debilidades de los protocolos. Mirando hacia el futuro, inmediatamente hacemos una reserva de que no hay un líder claro. Cada protocolo tiene algunas ventajas / desventajas.

Tiempo de respuesta

Una de las características más importantes de los protocolos de comunicación, especialmente con respecto a Internet de las cosas, es el tiempo de respuesta. Pero entre los protocolos existentes no hay sobresalientes que demuestren un nivel mínimo de retraso cuando se trabaja en diferentes condiciones. Pero hay un montón de investigaciones y comparaciones de capacidades de protocolo.

Por ejemplo, los resultados de comparar la efectividad de HTTP y MQTT cuando se trabaja con IoT mostraron que el tiempo de respuesta para las solicitudes de MQTT es menor que el de HTTP. Y al estudiar el tiempo de recepción y transmisión (RTT) de MQTT y CoAP, resultó que el RTT CoAP promedio es un 20% menor que el de MQTT.

Otro experimento con RTT para los protocolos MQTT y CoAP se llevó a cabo en dos escenarios: una red local y una red IoT. Resultó que el RTT promedio es 2-3 veces mayor en la red IoT. MQTT con QoS0 mostró un resultado más bajo en comparación con CoAP, y MQTT con QoS1 mostró un RTT más alto debido a ACK en los niveles de aplicación y transporte. Para diferentes niveles de QoS, los retrasos de la red sin congestión para MQTT fueron de milisegundos, y para CoAP, cientos de microsegundos. Sin embargo, vale la pena recordar que cuando se trabaja en redes menos confiables, MQTT que se ejecuta sobre TCP mostrará un resultado diferente.

La comparación del tiempo de respuesta para los protocolos AMQP y MQTT al aumentar la carga útil mostró que con una carga pequeña el nivel de retraso es casi el mismo. Pero cuando se transmiten grandes cantidades de datos, MQTT demuestra menos tiempo de respuesta. En otro estudio, se comparó CoAP con HTTP en un escenario de comunicación de máquina a máquina con dispositivos desplegados sobre vehículos equipados con sensores de gas, sensores meteorológicos, ubicación (GPS) y una interfaz de red móvil (GPRS). El tiempo que tardó en enviar un mensaje CoAP a través de una red móvil fue casi tres veces más corto que el tiempo que tardó en utilizar los mensajes HTTP.

Se realizaron estudios que compararon no dos, sino tres protocolos. Por ejemplo, comparando el rendimiento de los protocolos IoT MQTT, DDS y CoAP en un caso de uso médico utilizando un emulador de red. DDS superó a MQTT en términos de latencia de telemetría experimentada en varias condiciones de red deficientes. CoAP basado en UDP funcionó bien para aplicaciones que necesitaban una respuesta rápida, pero debido a que estaba basado en UDP, hubo una pérdida de paquetes impredecible significativa.

Rendimiento

La comparación de MQTT y CoAP en términos de utilización de ancho de banda se realizó como un cálculo de la cantidad total de datos transmitidos por mensaje. CoAP mostró menos ancho de banda que MQTT al enviar mensajes pequeños. Pero al comparar la efectividad de los protocolos en términos de la relación entre el número de bytes de información útil y el número total de bytes transmitidos, CoAP fue más efectivo.

Al analizar el uso de MQTT, DDS (con TCP como protocolo de transporte) y el ancho de banda de CoAP, resultó que CoAP tendía a mostrar un consumo de ancho de banda relativamente menor, que no aumentó con un aumento en la pérdida de paquetes de red o un mayor retraso de la red, a diferencia de MQTT y DDS, donde en los escenarios mencionados hubo un aumento en el uso de la capacidad del canal. En otro escenario, una gran cantidad de dispositivos transmitían datos simultáneamente, lo cual es un caso típico en entornos IoT. Los resultados mostraron que para una carga mayor es mejor usar CoAP.

Con una carga ligera, CoAP utilizó el menor ancho de banda, seguido de MQTT y HTTP REST. Sin embargo, cuando aumentó el tamaño de la carga útil, REST HTTP tuvo los mejores resultados.

El consumo de energía

El tema del consumo de energía siempre es de gran importancia, y especialmente en el sistema IoT. Si comparamos el consumo de energía de MQTT y HTTP, entonces HTTP "come" mucho más. Y CoAP es más eficiente energéticamente que MQTT, lo que le permite administrar la energía. Además, en escenarios simples, MQTT es más adecuado para intercambiar información en Internet de cosas, especialmente si no hay restricciones de poder.

Otro experimento, que comparó las capacidades de AMQP y MQTT en un banco de pruebas para una red inalámbrica móvil o inestable, mostró que AMQP ofrece más opciones de seguridad, mientras que MQTT es más eficiente energéticamente.

Seguridad

La seguridad es otro tema crítico que surge cuando se estudia el tema de Internet de las cosas y la computación en la nube / niebla. El mecanismo de seguridad generalmente se basa en TLS en HTTP, MQTT, AMQP y XMPP, en o DTLS en CoAP, y también es compatible con ambas versiones de DDS.

TLS y DTLS comienzan con el proceso de establecer comunicación entre el cliente y el servidor para intercambiar claves y conjuntos de cifrado compatibles. Ambas partes negocian kits para garantizar que se realice una comunicación adicional en un canal seguro. La diferencia entre los dos está en pequeñas modificaciones que permiten que DTLS basado en UDP funcione a través de una conexión poco confiable.

En los ataques de prueba en varias implementaciones diferentes de TLS y DTLS, resultó que TLS hizo un mejor trabajo. Los ataques a DTLS fueron más exitosos debido a su tolerancia a los errores.

Sin embargo, el mayor problema con estos protocolos es que no fueron diseñados originalmente para su uso en IoT y no implicaban trabajo en la niebla o la nube. A través de un intercambio constante (apretón de manos) agregan tráfico adicional con cada conexión, lo que agota los recursos informáticos. En promedio, hay un aumento de 6.5% para TLS y 11% para DTLS en la carga de trabajo en comparación con la comunicación sin un nivel de seguridad. En entornos ricos en recursos que suelen estar basados ​​en la nube , esto no será un problema, pero se convierte en una limitación importante entre el IoT y el nivel de niebla.

Que elegir No hay una respuesta definitiva. MQTT y HTTP parecen ser los protocolos más prometedores, ya que se consideran soluciones relativamente más maduras y más estables para IoT en comparación con otros protocolos.

Soluciones de protocolo de comunicaciones unificadas

La práctica de una solución de protocolo único tiene muchos inconvenientes. Por ejemplo, un protocolo que satisface un entorno limitado puede no funcionar en un dominio que tenga estrictos requisitos de seguridad. Con esto en mente, nos queda descartar casi todas las soluciones posibles basadas en un protocolo en el ecosistema Fog-to-Cloud en IoT, excepto MQTT y REST HTTP.

REST HTTP como una solución de protocolo único

Existe un buen ejemplo de interacción HTTP de solicitud e respuesta REST de IoT a niebla: granja inteligente . Los animales están equipados con sensores portátiles (cliente IoT, C) y controlados a través de la computación en la nube mediante un sistema de agricultura inteligente (servidor Fog, S).

El título del método POST indica el recurso a cambiar (/ farm / animals), así como la versión HTTP y el tipo de contenido, que en este caso es un objeto JSON que representa la granja de ganado que el sistema debe administrar (Dulcinea / cow). Una respuesta del servidor indica que la solicitud se realizó correctamente enviando un código de estado HTTPS 201 (recurso creado). El método GET debe indicar solo el recurso solicitado en el URI (por ejemplo, / farm / animals / 1), que devuelve la representación JSON del animal con este identificador desde el servidor.

El método PUT se usa cuando necesita actualizar un registro de recursos específico. En este caso, el URI se indica en el recurso para cambiar el parámetro y el valor actual (por ejemplo, indicando que la vaca está caminando, / farm / animals / 1? State = walking). Finalmente, el método DELETE se usa igualmente para el método GET, pero simplemente elimina el recurso como resultado de la operación.

MQTT como una solución de protocolo único



Tome la misma granja inteligente, pero en lugar de REST HTTP usamos el protocolo MQTT. El servidor local con la biblioteca Mosquitto instalada actúa como intermediario. En este ejemplo, una computadora simple (conocida como servidor de granja) Raspberry Pi sirve como cliente MQTT, implementado a través de la instalación de la biblioteca MQTT Paho, que es totalmente compatible con el agente Mosquitto.

Este cliente corresponde a la capa de abstracción de IoT que representa un dispositivo con capacidades de detección y computación. El intermediario, por otro lado, corresponde a un mayor nivel de abstracción, que representa el nodo informático de la niebla, que se caracteriza por un gran poder en términos de procesamiento y almacenamiento de datos.

En el escenario propuesto de Smart Farm, la Raspberry Pi se conecta a los sensores de acelerómetro, GPS y temperatura y publica datos de estos sensores en el nodo de niebla. Como probablemente sepa, MQTT trata los temas como una jerarquía. Un editor de MQTT puede publicar en un conjunto específico de temas. En nuestro caso hay tres de ellos. Para un sensor que mide la temperatura en un establo de animales, el cliente selecciona un tema (granja de animales / cobertizo / temperatura). Para los sensores que miden la ubicación del GPS y el movimiento de los animales a través del acelerómetro, el cliente publicará actualizaciones (animalfarm / animal / GPS) y (animalfarm / animal / movement).

Esta información se transmitirá al agente, que puede almacenarla temporalmente en una base de datos local en caso de que otro suscriptor interesado aparezca más tarde.

Además del servidor local que actúa como el agente MQTT en la niebla y al que Raspberry Pi, que actúa como clientes MQTT, envía datos desde los sensores, puede haber otro agente MQTT a nivel de la nube. En este caso, la información transmitida al agente local puede almacenarse temporalmente en la base de datos local y / o enviarse a la nube. El brumoso bróker MQTT en esta situación se utiliza para vincular todos los datos con el bróker MQTT en la nube. Con esta arquitectura, un usuario de aplicación móvil puede suscribirse a ambos corredores.

En el caso de una falla de conexión con uno de los intermediarios (por ejemplo, nube), el usuario final recibirá información de otro (brumoso). Esta es una característica de los sistemas informáticos combinados de niebla y nube. De manera predeterminada, la aplicación móvil se puede configurar para conectarse al brumoso agente MQTT por primera vez y, en caso de falla, para conectarse al agente MQTT en la nube. Esta solución es solo una de muchas en los sistemas IoT-F2C.

Soluciones multiprotocolo

Las soluciones de protocolo único son populares debido a su implementación más fácil. Pero es obvio que en los sistemas IoT-F2C tiene sentido combinar diferentes protocolos. El punto es que diferentes protocolos pueden funcionar en diferentes niveles. Tomemos, por ejemplo, tres abstracciones: IoT, niebla y niveles de computación en la nube. Los dispositivos IoT generalmente se consideran limitados. Para esta revisión, veamos los niveles de IoT como los más limitados, la nube menos limitada y el cálculo de niebla como "en algún lugar en el medio". Luego resulta que entre IoT y abstracciones de niebla, las decisiones de protocolo actuales incluyen MQTT, CoAP y XMPP. Entre la niebla y la nube, por otro lado, AMQP es uno de los principales protocolos utilizados junto con HTTP REST, que debido a su flexibilidad también se usa entre IoT y capas de niebla.

El principal problema aquí es la interoperabilidad de los protocolos y la simplicidad de traducir mensajes de un protocolo a otro. Idealmente, en el futuro, la arquitectura del sistema IoT con recursos de nube y niebla será independiente del protocolo de comunicación utilizado y proporcionará una buena interoperabilidad entre los diferentes protocolos.



Como esto no es así en este momento, tiene sentido combinar protocolos que no tengan diferencias significativas. Para este fin, una solución potencial se basa en una combinación de dos protocolos que se adhieren al mismo estilo arquitectónico, REST HTTP y CoAP. Otra solución propuesta se basa en una combinación de dos protocolos que ofrecen interacción de publicación-suscripción, MQTT y AMQP. El uso de conceptos cercanos (tanto MQTT como AMQP usan intermediarios, CoAP y HTTP usan REST), simplifica la implementación de estas combinaciones y requiere menos esfuerzo de integración.



La Figura (a) muestra dos modelos basados ​​en solicitud-respuesta, HTTP y CoAP, y su posible ubicación en la solución IoT-F2C.Dado que HTTP es uno de los protocolos más conocidos y adaptados en las redes modernas, es poco probable que sea reemplazado por otros protocolos de mensajería. Entre los nodos que representan dispositivos potentes que se encuentran entre la nube y la niebla, HTTP REST es una solución inteligente.

Por otro lado, para dispositivos con recursos informáticos limitados que se comunican entre niveles de niebla e IoT, es más eficiente usar CoAP. Una de las grandes ventajas de CoAP es su compatibilidad con HTTP, ya que ambos protocolos se basan en los principios REST.

La Figura (b) muestra dos modelos de interacción publicación-suscripción en un escenario, incluidos MQTT y AMQP. Aunque hipotéticamente ambos protocolos pueden usarse para la comunicación entre nodos en cada nivel de abstracción, su posición debe determinarse en función del rendimiento. MQTT se desarrolló como un protocolo simplificado para dispositivos con recursos informáticos limitados, por lo que puede usarse para la comunicación entre IoT y fog. AMQP es más adecuado para dispositivos más potentes que lo posicionarían idealmente entre los nodos de niebla y nube. En lugar de MQTT, IoT puede usar el protocolo XMPP, ya que se considera ligero. Pero no es tan ampliamente utilizado en tales escenarios.

Conclusiones

Es poco probable que uno de los protocolos considerados sea suficiente para cubrir toda la comunicación en el sistema, comenzando desde dispositivos con recursos informáticos limitados y terminando con servidores en la nube. El estudio mostró que las dos opciones más prometedoras que los desarrolladores usan con más frecuencia son MQTT y RESTful HTTP. Estos dos protocolos no solo son los más maduros y estables, sino que también incluyen muchas implementaciones y recursos en línea bien documentados y exitosos.

Debido a su estabilidad y configuración simple, MQTT es un protocolo que con el tiempo ha demostrado su excelente rendimiento cuando se usa en el nivel de IoT con dispositivos limitados. En partes del sistema donde la comunicación limitada y el consumo de batería no son un problema, por ejemplo, en algunas áreas de niebla y la mayoría de la computación en la nube, RESTful HTTP es una opción fácil. CoAP también debe tenerse en cuenta, ya que también se está desarrollando rápidamente como un estándar de mensajería de IoT, y es probable que en un futuro cercano alcance un nivel de estabilidad y madurez similar a MQTT y HTTP. Pero el estándar se está desarrollando ahora, lo que está asociado con problemas de compatibilidad a corto plazo.

¿Qué más es útil para leer en el blog de Cloud4Y?

→ La computadora te hará sabrosa
→ AI ayuda a estudiar animales en África
→ El verano casi ha terminado. Casi no se filtraron datos
→ 4 formas de ahorrar en copias de seguridad en la nube
→ En un único recurso de información federal que contiene información de población

¡Suscríbete a nuestro canal de Telegram para no perderte otro artículo! No escribimos más de dos veces por semana y solo por negocios.