El desarrollo de tecnologías en software y hardware, junto con la aparición de nuevos protocolos de comunicación, ha llevado a la expansión del Internet de las Cosas (IoT). La cantidad de dispositivos crece día a día, generando un enorme volumen de datos. Por lo tanto, surge la necesidad de una arquitectura de sistema que pueda procesar, almacenar y transmitir estos datos de manera eficiente.
En la actualidad, se utilizan servicios en la nube para estos fines. Sin embargo, la cada vez más popular paradigma de la computación en la niebla (Fog) puede complementar las soluciones en la nube, escalando y optimizando la infraestructura de IoT.
Las 'nubes' pueden satisfacer la mayoría de las demandas de IoT. Por ejemplo, pueden proporcionar monitoreo de servicios, procesamiento rápido de cualquier volumen de datos generados por los dispositivos, así como su visualización. Por otro lado, la computación en la niebla es más efectiva para resolver problemas en tiempo real. Proporciona una respuesta rápida a las solicitudes y una mínima latencia en el procesamiento de datos. Es decir, Fog complementa a las 'nubes', ampliando sus capacidades.
Sin embargo, la pregunta principal es: ¿cómo debe interactuar todo esto en el contexto de IoT? ¿Cuáles protocolos de comunicación serán los más efectivos en un sistema integrado IoT-Fog-Cloud?
A pesar del aparente dominio de HTTP, se utilizan muchas otras soluciones en los sistemas IoT, Fog y Cloud. Esto se debe a que IoT debe combinar las funcionalidades de diversos sensores de dispositivos con la seguridad, compatibilidad y otros requisitos que exigen los usuarios.
Sin embargo, no hay un consenso sobre una arquitectura de referencia y un estándar de comunicación. Por lo tanto, la creación de un nuevo protocolo o la modificación 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 actualmente y qué pueden ofrecer? Vamos a profundizar. Pero primero, discutamos los principios de la ecosistema en el que interactúan las nubes, la niebla y el Internet de las cosas.
Arquitectura IoT Fog-to-Cloud (F2C)
Seguramente has notado los significativos esfuerzos que se realizan para estudiar las ventajas y beneficios asociados con la gestión racional y coordinada de IoT, las nubes y la niebla. Si no, aquí tienes tres iniciativas de estandarización: , y .
Si antes solo se consideraban dos niveles, la nube y los dispositivos finales, la arquitectura propuesta introduce un nuevo nivel: la computación en la niebla. Este nivel de niebla puede dividirse en varios subniveles, dependiendo de la especificidad de los recursos o del conjunto de políticas que determinan el uso de diferentes dispositivos en estos subniveles.
¿Cómo podría lucir esta abstracción? Aquí hay un ecosistema típico de IoT-Niebla-Nube. Los dispositivos IoT envían datos a servidores y dispositivos de cómputo más potentes para resolver tareas que requieren un bajo nivel de latencia. En este sistema, las nubes son responsables de resolver tareas que requieren una gran cantidad de recursos computacionales o espacio de almacenamiento de datos.
Los smartphones, los relojes inteligentes y otros dispositivos también pueden ser parte del IoT. Sin embargo, tales dispositivos generalmente utilizan protocolos de comunicación propietarios de grandes desarrolladores. Los datos generados por Internet de las cosas se transfieren al nivel de niebla a través del protocolo REST HTTP, que garantiza flexibilidad y compatibilidad funcional al crear servicios RESTful. Esto es importante en vista de la necesidad de asegurar la compatibilidad con la infraestructura de computación existente que opera en computadoras locales, servidores o conjuntos de servidores. Los recursos locales, conocidos como 'nodos de niebla', filtran los datos recibidos y los procesan localmente o los envían a la nube para su procesamiento adicional.
Las nubes admiten diferentes protocolos de comunicación, entre los que se encuentran AMQP y REST HTTP. Dado que HTTP es bien conocido y está diseñado para internet, podría surgir la pregunta: '¿Por qué no utilizarlo para trabajar con IoT y la niebla?'. Sin embargo, este protocolo tiene problemas de rendimiento. Hablaremos de eso más adelante.
En general, existen 2 modelos de protocolos de comunicación adecuados para nuestro sistema. Estos son la solicitud-respuesta y la publicación-suscripción. El primer modelo es más conocido, especialmente en la arquitectura cliente-servidor. El cliente solicita información del servidor, que recibe la solicitud, la procesa y devuelve un mensaje de respuesta. Los protocolos REST HTTP y CoAP operan bajo este modelo.
El segundo modelo surgió de la necesidad de proporcionar una comunicación asíncrona, distribuida y débil entre las fuentes que generan datos y los receptores de esos datos.
El modelo prevé tres participantes: el publicador (fuente de datos), el corredor (gestor) 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 del corredor, que es responsable de filtrar todos los mensajes entrantes y su enrutamiento entre publicadores y suscriptores. Y el publicador, cuando ocurre un evento relacionado con un tema específico, lo publica al corredor, quien envía los datos al suscriptor sobre el tema solicitado.
Este modelo está esencialmente basado en eventos. Y esta forma de interacción es interesante para aplicaciones en IoT, en la nube y en la niebla debido a su capacidad para asegurar escalabilidad y facilitar la interconexión entre diferentes dispositivos, manteniendo una comunicación dinámica de «muchos a muchos» y comunicación asíncrona. Algunos de los protocolos de mensajería estandarizados más conocidos que utilizan el modelo de «publicación-suscripción» son MQTT, AMQP y DDS.
Es evidente que el modelo de «publicación-suscripción» tiene muchas ventajas:
- Los publicadores y suscriptores no necesitan conocer la existencia del otro;
- Un suscriptor puede recibir información de muchas publicaciones diferentes, y un publicador puede enviar datos a muchos suscriptores diferentes (principio de «muchos a muchos»);
- El publicador y el suscriptor no tienen que estar activos al mismo tiempo para intercambiar datos, porque el corredor (que actúa como sistema de colas) puede almacenar el mensaje para los clientes que en ese momento no están conectados a la red.
Sin embargo, el modelo de «solicitud-respuesta» también tiene sus puntos fuertes. En aquellos casos donde la capacidad del lado del servidor para procesar solicitudes de múltiples clientes no es un problema, vale la pena utilizar soluciones ya probadas y fiables.
También existen protocolos que admiten ambos modelos. Por ejemplo, XMPP y HTTP 2.0, que admiten la opción de "server push". IETF también ha lanzado CoAP. En un intento por resolver el problema del intercambio de mensajes, se han creado varias otras soluciones, como el protocolo WebSockets o el uso de HTTP a través de QUIC (Quick UDP Internet Connections).
En el caso de WebSockets, aunque se utiliza para la transmisión de datos en tiempo real desde el servidor al cliente web y proporciona conexiones permanentes con retroalimentación bidireccional simultánea, no está diseñado para dispositivos con recursos computacionales limitados. QUIC también merece atención, ya que este nuevo protocolo de transporte ofrece muchas nuevas posibilidades. Sin embargo, dado que QUIC aún no está estandarizado, es prematuro predecir su posible aplicación e impacto en las soluciones de IoT. Así que dejaremos WebSockets y QUIC en la memoria con la vista puesta en el futuro, pero no profundizaremos en ellos por ahora.
¿Quién es el más querido del mundo? Comparando protocolos
Ahora hablemos de las fortalezas y debilidades de los protocolos. A modo de anticipación, aclaremos que no hay un líder claro. Cada protocolo tiene sus propias ventajas y desventajas.
Tiempo de respuesta
Una de las características más importantes de los protocolos de comunicación, especialmente en lo que respecta a Internet de las Cosas, es el tiempo de respuesta. Sin embargo, entre los protocolos existentes no hay un ganador absoluto que demuestre el nivel mínimo de latencia en diferentes condiciones. Sin embargo, hay una gran cantidad de investigaciones y comparaciones sobre las capacidades de los protocolos.
Por ejemplo, Las comparaciones de la eficiencia de HTTP y MQTT al trabajar con IoT mostraron que el tiempo de respuesta para las solicitudes de MQTT es menor que el de HTTP. Y al el tiempo de envío y recepción (RTT) de MQTT y CoAP, se descubrió que el RTT promedio de CoAP es un 20% menor que el de MQTT.
Otro El RTT de 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 de 2 a 3 veces más alto en la red IoT. MQTT con QoS0 mostró un resultado inferior en comparación con CoAP, mientras que MQTT con QoS1 demostró un RTT más alto debido a los ACK en los niveles de aplicación y transporte. Para diferentes niveles de QoS, las latencias en una red sin congestión para MQTT fueron de milisegundos, mientras que para CoAP fueron de cientos de microsegundos. Sin embargo, es importante recordar que al trabajar en redes menos confiables, MQTT, que opera sobre TCP, mostrará resultados completamente diferentes.
del tiempo de respuesta de los protocolos AMQP y MQTT al aumentar la carga útil mostró que bajo poca carga el nivel de latencia es casi el mismo. Sin embargo, al transferir grandes volúmenes de datos, MQTT muestra un tiempo de respuesta menor. En otro se comparó CoAP con HTTP en un escenario de comunicación máquina a máquina con dispositivos desplegados sobre vehículos y equipados con sensores de gas, sensores meteorológicos, ubicación (GPS) y una interfaz de red móvil (GPRS). El tiempo necesario para transmitir un mensaje CoAP a través de la red móvil fue casi tres veces más corto que el necesario para utilizar mensajes HTTP.
Se realizaron estudios en los que se compararon no dos, sino tres protocolos. Por ejemplo, el rendimiento de los protocolos IoT MQTT, DDS y CoAP en un escenario de aplicación médica utilizando un emulador de red. DDS superó a MQTT en términos de latencia de telemetría probada en diversas condiciones de red adversas. CoAP basado en UDP funcionó bien para aplicaciones que requieren una respuesta rápida, sin embargo, debido a su naturaleza basada en UDP, se produjo una significativa pérdida de paquetes impredecible.
Ancho de banda
MQTT y CoAP en términos de eficiencia en el uso del ancho de banda se llevó a cabo como un conteo de la cantidad total de datos transmitidos por mensaje. CoAP mostró menor capacidad de ancho de banda que MQTT al enviar mensajes pequeños. Pero al comparar la eficiencia de los protocolos en función de la relación entre la cantidad de bytes de información útil y el total de bytes transmitidos, CoAP resultó ser más eficaz.
Al del uso del ancho de banda de MQTT, DDS (con TCP como protocolo de transporte) y CoAP reveló que CoAP generalmente mostró un consumo de ancho de banda comparativamente más bajo, el cual no aumentó con el incremento de pérdidas de paquetes en la red o con el aumento de la latencia de la red, a diferencia de MQTT y DDS, donde en los escenarios mencionados se observó un aumento en el uso del ancho de banda. En otro escenario se involucró un gran número de dispositivos transmitiendo datos simultáneamente, lo cual es un caso típico en entornos IoT. Los resultados mostraron que para cargas más altas, es mejor utilizar CoAP.
Con una carga baja, CoAP utilizó el menor ancho de banda, seguido de MQTT y REST HTTP. Sin embargo, cuando el tamaño de las cargas útiles aumentó, los mejores resultados fueron para REST HTTP.
Consumo de energía
La cuestión del consumo de energía siempre es importante, y en un sistema IoT, especialmente. el consumo de electricidad de MQTT y HTTP, HTTP 'consume' mucho más. CoAP es más en comparación con MQTT, permitiendo un mejor manejo de la energía. En escenarios simples, MQTT es más adecuado para el intercambio de información en redes de internet de las cosas, especialmente si no hay restricciones de potencia.
un experimento en el que se compararon las capacidades de AMQP y MQTT en un banco de pruebas de una red móvil o inalámbrica inestable, mostró que AMQP ofrece más capacidades en términos de seguridad, mientras que MQTT es más energéticamente eficiente.
Seguridad
La seguridad es otra cuestión crucial planteada al estudiar el tema del internet de las cosas y la computación en la niebla/nube. El mecanismo de seguridad generalmente se basa en TLS en HTTP, MQTT, AMQP y XMPP, o DTLS en CoAP, además de soportar ambos DDS.
TLS y DTLS comienzan con un proceso de establecimiento de conexión entre el cliente y el servidor para intercambiar conjuntos de cifrado y claves compatibles. Ambas partes acuerdan los conjuntos para garantizar que la comunicación posterior ocurra en un canal seguro. La diferencia entre ellos radica en pequeñas modificaciones que permiten a DTLS, basado en UDP, operar sobre una conexión no fiable.
Al a varias implementaciones diferentes de TLS y DTLS revelaron que TLS manejó mejor la tarea. Los ataques a DTLS tuvieron más éxito debido a su tolerancia a los errores.
Sin embargo, el mayor problema de estos protocolos es que no fueron diseñados originalmente para su uso en IoT y no contemplaban operar en la niebla o en la nube. A través del intercambio acordado (handshaking) añaden tráfico adicional con cada establecimiento de conexión, lo que agota los recursos computacionales. Se observa un aumento promedio del 6.5% para TLS y del 11% para DTLS en la carga útil administrativa en comparación con la comunicación sin nivel de seguridad. En entornos con recursos abundantes, que generalmente se encuentran en En este nivel, no será un problema, pero en la relación entre IoT y el nivel de niebla, esto se convierte en una limitación importante.
¿Qué elegir? No hay una respuesta clara. MQTT y HTTP parecen ser los protocolos más prometedores, ya que se consideran soluciones relativamente más maduras y estables para IoT en comparación con otros protocolos.
Soluciones basadas en un único protocolo de comunicación
La práctica de soluciones de un solo protocolo tiene muchas desventajas. Por ejemplo, un protocolo que satisface un entorno limitado puede no funcionar en un dominio que tiene estrictos requisitos de seguridad. Teniendo esto en cuenta, nos queda descartar casi todas las posibles soluciones basadas en un solo protocolo en el ecosistema Fog-to-Cloud en IoT, excepto MQTT y REST HTTP.
REST HTTP como solución de un solo protocolo
Hay un buen ejemplo de la interacción de solicitudes y respuestas de REST HTTP en el ámbito de IoT-to-Fog: . Los animales están equipados con sensores portátiles (cliente IoT, C) y son gestionados a través de la computación en la nube por un sistema de granja inteligente (servidor Fog, S).
En el encabezado del método POST se especifica el recurso a modificar (/farm/animals), así como la versión de HTTP y el tipo de contenido, que en este caso es un objeto JSON que representa la granja ganadera que debe gestionar el sistema (Dulcinea/vaca). La respuesta del servidor indica que la solicitud fue exitosa, enviando un código de estado HTTPS 201 (recurso creado). El método GET solo debe indicar el recurso solicitado en el URI (por ejemplo, /farm/animals/1), que devuelve la representación JSON del animal con ese identificador desde el servidor.
El método PUT se utiliza cuando es necesario actualizar algún registro específico del recurso. En este caso, el recurso especifica el URI para el parámetro a modificar y el valor actual (por ejemplo, indicando que la vaca está en pastoreo, /farm/animals/1?estado=paseando). Finalmente, el método DELETE se utiliza en igualdad de condiciones que el método GET, pero simplemente elimina el recurso como resultado de la operación.
MQTT como solución de un solo protocolo
Tomemos la misma granja inteligente, pero en lugar de REST HTTP, usaremos el protocolo MQTT. Un servidor local con la biblioteca Mosquitto instalada actúa como corredor. En este ejemplo, una computadora simple (designada como servidor de la granja) Raspberry Pi sirve como cliente MQTT, implementado a través de la instalación de la biblioteca MQTT Paho, completamente compatible con el corredor Mosquitto.
Este cliente corresponde al nivel de abstracción de IoT que representa un dispositivo con capacidades de detección y cálculo. El intermediario, por otro lado, corresponde a un nivel de abstracción más alto, representando un nodo de computación de niebla, caracterizado por una mayor capacidad en términos de procesamiento y almacenamiento de datos.
En el escenario propuesto de la "granja inteligente", Raspberry Pi se conecta a un acelerómetro, GPS y sensores de temperatura y publica datos de estos sensores en un nodo de niebla. Como probablemente sepas, MQTT considera los temas como una jerarquía. Un publicador MQTT puede publicar mensajes en un conjunto específico de temas. En nuestro caso, hay tres. Para el sensor que mide la temperatura en el establo de animales, el cliente elige el tema (animalfarm/shed/temperature). Para los sensores que miden la ubicación 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 será enviada al corredor, que puede almacenarla temporalmente en una base de datos local por si más tarde aparece otro suscriptor interesado.
Además del servidor local que actúa como corredor MQTT en la niebla y al que Raspberry Pi, actuando como clientes MQTT, envían datos de los sensores, puede haber otro corredor MQTT en la nube. En este caso, la información enviada al corredor local puede almacenarse temporalmente en una base de datos local y/o enviarse a la nube. El corredor MQTT de niebla en esta situación se utiliza para vincular todos los datos con el corredor MQTT en la nube. Con esta arquitectura, el usuario de la aplicación móvil puede estar suscrito a ambos corredores.
En caso de una falla de conexión con uno de los corredores (por ejemplo, en la nube), el usuario final recibirá información de otro (en la niebla). Esta es una característica distintiva de los sistemas combinados de niebla y computación en la nube. Por defecto, la aplicación móvil puede configurarse para la primera conexión a un corredor MQTT de niebla y, en caso de falla, conectarse a un corredor MQTT en la nube. Esta solución es solo una de muchas en los sistemas IoT-F2C.
Soluciones multiprotocolo
Las soluciones con un solo protocolo son populares debido a su implementación más sencilla. Pero es evidente que en los sistemas IoT-F2C tiene sentido combinar diferentes protocolos. La idea es que diferentes protocolos pueden operar en diferentes niveles. Tomemos, por ejemplo, tres abstracciones: los niveles IoT, de niebla y de computación en la nube. Los dispositivos en el nivel IoT se consideran generalmente limitados. Para este análisis, consideremos los niveles IoT como los más limitados, los de nube como los menos limitados y la computación de niebla como 'en algún lugar intermedio'. Así, entre IoT y las abstracciones de niebla, las soluciones 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 REST HTTP, que debido a su flexibilidad también se utiliza entre IoT y las capas de niebla.
El principal problema aquí es la compatibilidad funcional de los protocolos y la facilidad de traducción de mensajes de un protocolo a otro. Idealmente, en el futuro, la arquitectura del sistema de Internet de las cosas con recursos en la nube y en la niebla será independiente del protocolo de comunicación utilizado y proporcionará una buena interacción entre diferentes protocolos.
Dado que esto no es así en este momento, tiene sentido combinar protocolos que no tengan diferencias significativas. Con este objetivo, una posible solución se basa en la combinación de dos protocolos que siguen el mismo estilo arquitectónico, REST HTTP y CoAP. Otra solución propuesta se basa en la combinación de dos protocolos que ofrecen interacción bajo el modelo de 'publicación-suscripción', MQTT y AMQP. El uso de conceptos cercanos (tanto MQTT como AMQP utilizan corredores, CoAP y HTTP utilizan REST), simplifica la implementación de estas combinaciones y requiere menos esfuerzo para la integración.
En la figura (a) se muestran dos modelos basados en solicitudes-respuestas, 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 completamente por otros protocolos de mensajería. Entre los nodos que representan dispositivos potentes, que se sitúan entre la nube y la niebla, REST HTTP es una solución razonable.
Por otro lado, para los dispositivos con recursos computacionales limitados que se conectan entre los niveles de niebla e IoT, es más eficiente utilizar CoAP. Una de las grandes ventajas de CoAP es de hecho su compatibilidad con HTTP, ya que ambos protocolos se basan en principios REST.
En la figura (b) se muestran dos modelos de interacción de ‘publicación-suscripción’ en un escenario, incluidos MQTT y AMQP. Aunque hipotéticamente ambos protocolos pueden ser utilizados para la comunicación entre nodos en cada nivel de abstracción, su ubicación debe definirse en función del rendimiento. MQTT fue diseñado como un protocolo simplificado para dispositivos con recursos computacionales limitados, por lo que puede usarse para la comunicación entre IoT y la niebla. AMQP es más adecuado para dispositivos más potentes, que lo situarían idealmente entre los nodos de niebla y nube. En lugar de MQTT, en IoT se puede utilizar el protocolo XMPP, ya que se considera ligero. Pero no es tan ampliamente utilizado en escenarios similares.
Conclusiones
Es poco probable que uno de los protocolos analizados sea suficiente para cubrir toda la comunicación en el sistema, desde dispositivos con recursos computacionales limitados hasta servidores en la nube. La investigación ha demostrado que las dos opciones más prometedoras que utilizan con mayor frecuencia los desarrolladores son MQTT y RESTful HTTP. Estos dos protocolos son no solo los más maduros y estables, sino que también incluyen numerosas implementaciones bien documentadas y exitosas, así como recursos en línea.
Gracias a su estabilidad y fácil configuración, MQTT es un protocolo que con el tiempo ha demostrado su excelente rendimiento en aplicaciones de IoT con dispositivos limitados. En partes del sistema donde la conectividad y el consumo de batería no son problemas, como en algunas áreas de niebla y en la mayoría de la computación en la nube, RESTful HTTP es una elección sencilla. CoAP también debe ser considerado, ya que rápidamente se está convirtiendo en un estándar de mensajería IoT, y es bastante probable que en un futuro cercano alcance un nivel de estabilidad y madurez comparable a MQTT y HTTP. Sin embargo, el estándar se está desarrollando actualmente, lo que conlleva problemas de compatibilidad a corto plazo.
¿Qué más útil se puede leer en el blog?
→
→
→
→
→
Suscríbete a nuestro -canal para no perderte el próximo artículo. Escribimos no más de dos veces a la semana y solo lo necesario.
Fuente: habr.com
