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 del Internet de las cosas (IoT). El número de dispositivos crece día a día y generan una enorme cantidad de datos. Por lo tanto, existe la necesidad de una arquitectura de sistema conveniente capaz de procesar, almacenar y transmitir estos datos.
Ahora se utilizan servicios en la nube para estos fines. Sin embargo, el cada vez más popular paradigma de computación en la niebla (Fog) puede complementar las soluciones en la nube escalando y optimizando la infraestructura de IoT.
Las nubes son capaces de cubrir la mayoría de las solicitudes de IoT. Por ejemplo, para proporcionar seguimiento de servicios, procesamiento rápido de cualquier cantidad de datos generados por los dispositivos, así como su visualización. La computación en la niebla es más efectiva cuando se resuelven problemas en tiempo real. Proporcionan una respuesta rápida a las solicitudes y una latencia mínima en el procesamiento de datos. Es decir, Fog complementa las “nubes” y amplía sus capacidades.
Sin embargo, la pregunta principal es otra: ¿cómo debería interactuar todo esto en el contexto de IoT? ¿Qué protocolos de comunicación serán más efectivos cuando se trabaje en un sistema combinado IoT-Fog-Cloud?
A pesar del aparente predominio de HTTP, existe una gran cantidad de otras soluciones utilizadas en los sistemas IoT, Fog y Cloud. Esto se debe a que IoT debe combinar la funcionalidad de una variedad de sensores de dispositivos con la seguridad, la compatibilidad y otros requisitos de los usuarios.
Pero simplemente no existe una idea única sobre la arquitectura de referencia y el estándar de comunicación. Por lo tanto, crear un nuevo protocolo o modificar 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 resolverlo. Pero primero, analicemos los principios del ecosistema en el que interactúan las nubes, la niebla y el Internet de las cosas.
Arquitectura de IoT de niebla a nube (F2C)
Probablemente haya notado cuánto esfuerzo se está poniendo en explorar las ventajas y beneficios asociados con la gestión inteligente y coordinada de IoT, la nube y la niebla. Si no es así, aquí hay tres iniciativas de estandarización: , и .
Si antes solo se consideraban dos niveles, las nubes y los dispositivos finales, entonces la arquitectura propuesta introduce un nuevo nivel: la computación en la niebla. En este caso, el nivel de niebla se puede dividir en varios subniveles, dependiendo de las características específicas de los recursos o de un conjunto de políticas que determinan el uso de diferentes dispositivos en estos subniveles.
¿Cómo sería esta abstracción? Este es un ecosistema típico de IoT-Fog-Cloud. Los dispositivos IoT envían datos a servidores y dispositivos informáticos más rápidos para resolver problemas que requieren baja latencia. En un mismo sistema, las nubes se encargan de solucionar 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 formar parte del IoT. Pero estos dispositivos suelen utilizar protocolos de comunicación propietarios de grandes desarrolladores. Los datos de IoT generados se transfieren a la capa de niebla a través del protocolo HTTP REST, que proporciona flexibilidad e interoperabilidad al crear servicios RESTful. Esto es importante a la luz de la necesidad de garantizar la compatibilidad con versiones anteriores de la infraestructura informática existente que se ejecuta en computadoras locales, servidores o un clúster de servidores. Los recursos locales, llamados "nodos de 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 diferentes protocolos de comunicación, siendo los más comunes AMQP y REST HTTP. Dado que HTTP es bien conocido y está diseñado para Internet, puede surgir la pregunta: "¿no deberíamos usarlo para trabajar con IoT y niebla?" Sin embargo, este protocolo tiene problemas de rendimiento. Más sobre esto más adelante.
En general existen 2 modelos de protocolos de comunicación adecuados al sistema que necesitamos. Estos son 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 al servidor y el servidor recibe la solicitud, la procesa y devuelve un mensaje de respuesta. Los protocolos REST HTTP y CoAP operan en este modelo.
El segundo modelo surgió de la necesidad de proporcionar un acoplamiento flexible, distribuido y asincrónico entre las fuentes que generan datos y los destinatarios de estos datos.
El modelo supone tres participantes: un editor (fuente de datos), un intermediario (despachador) y un suscriptor (receptor). Aquí, el cliente que actúa como suscriptor no tiene que solicitar información al servidor. En lugar de enviar solicitudes, se suscribe a ciertos eventos del sistema a través de un intermediario, que se encarga 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, que envía datos sobre el tema solicitado al suscriptor.
Esencialmente, esta arquitectura se basa en eventos. Y este modelo de interacción es interesante para aplicaciones en IoT, nube y niebla debido a su capacidad para proporcionar escalabilidad y simplificar la interconexión entre diferentes dispositivos, admitir comunicación dinámica de muchos a muchos y comunicación asincrónica. Algunos de los protocolos de mensajería estandarizados más conocidos que utilizan un modelo de publicación-suscripción incluyen MQTT, AMQP y DDS.
Evidentemente, el modelo publicación-suscripción tiene muchas ventajas:
- Los editores y suscriptores no necesitan conocer la existencia de los demás;
- Un suscriptor puede recibir información de muchas publicaciones diferentes y un editor puede enviar datos a muchos suscriptores diferentes (principio de muchos a muchos);
- El editor y el suscriptor no tienen que estar activos al mismo tiempo para comunicarse, porque el intermediario (que funciona como un sistema de cola) podrá almacenar el mensaje para los clientes que no están actualmente conectados a la red.
Sin embargo, el modelo de solicitud-respuesta también tiene sus puntos fuertes. En los casos en los que la capacidad del lado del servidor para manejar múltiples solicitudes de clientes no es un problema, tiene sentido utilizar soluciones confiables y probadas.
También existen protocolos que admiten ambos modelos. Por ejemplo, XMPP y HTTP 2.0, que admiten la opción "server push". El IETF también ha publicado un CoAP. En un intento de solucionar el problema de la mensajería, se han creado otras soluciones, como el protocolo WebSockets o el uso del protocolo HTTP sobre QUIC (Quick UDP Internet Connections).
En el caso de WebSockets, aunque se utiliza para transferir datos en tiempo real desde un servidor a un cliente web y proporciona conexiones persistentes con comunicación bidireccional simultánea, no está pensado para dispositivos con recursos informáticos limitados. QUIC también merece atención, ya que el nuevo protocolo de transporte ofrece muchas oportunidades nuevas. Pero como QUIC aún no está estandarizado, es prematuro predecir su posible aplicación e impacto en las soluciones de IoT. Por eso tenemos en mente WebSockets y QUIC con la vista puesta en el futuro, pero no los estudiaremos con más detalle por ahora.
Quién es el más lindo del mundo: comparando protocolos
Ahora hablemos de las fortalezas y debilidades de los protocolos. De cara al futuro, hagamos inmediatamente la 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 en relación con el Internet de las cosas, es el tiempo de respuesta. Pero entre los protocolos existentes, no hay un ganador claro que demuestre el nivel mínimo de latencia cuando se trabaja en diferentes condiciones. Pero hay una gran cantidad de investigaciones y comparaciones de capacidades de protocolo.
Por ejemplo, Las comparaciones de 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 cuando El tiempo de ida y vuelta (RTT) de MQTT y CoAP reveló que el RTT promedio de CoAP es un 20% menor que el de MQTT.
Otro con RTT para los protocolos MQTT y CoAP se realizó en dos escenarios: red local y red IoT. Resultó que el RTT promedio es 2-3 veces mayor en una 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 los ACK en las capas de aplicación y transporte. Para diferentes niveles de QoS, la latencia de la red sin congestión fue de milisegundos para MQTT y de cientos de microsegundos para CoAP. Sin embargo, vale la pena recordar que cuando se trabaja en redes menos confiables, MQTT ejecutándose sobre TCP mostrará un resultado completamente diferente.
El tiempo de respuesta para los protocolos AMQP y MQTT al aumentar la carga útil mostró que con una carga ligera el nivel de latencia es casi el mismo. Pero al transferir grandes cantidades de datos, MQTT demuestra tiempos de respuesta más cortos. en uno mas CoAP se comparó con HTTP en un escenario de comunicación de máquina a máquina con dispositivos desplegados en la parte superior de vehículos equipados con sensores de gas, sensores meteorológicos, sensores de 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 era casi tres veces más corto que el tiempo necesario para utilizar mensajes HTTP.
Se han realizado estudios que compararon no dos, sino tres protocolos. Por ejemplo, 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 una variedad de condiciones de red deficientes. CoAP basado en UDP funcionó bien para aplicaciones que requerían tiempos de respuesta rápidos; sin embargo, debido a que estaba basado en UDP, hubo una pérdida significativa de paquetes impredecible.
Ancho de banda
MQTT y CoAP en términos de eficiencia del ancho de banda se llevaron a cabo como un cálculo de la cantidad total de datos transmitidos por mensaje. CoAP ha mostrado un rendimiento más bajo que MQTT al transmitir mensajes pequeños. Pero al comparar la eficiencia 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 transferidos, CoAP resultó ser más efectivo.
en Al utilizar MQTT, DDS (con TCP como protocolo de transporte) y ancho de banda CoAP, se encontró que CoAP generalmente mostraba un consumo de ancho de banda comparativamente menor, que no aumentó con una mayor pérdida de paquetes de red o una mayor latencia de red, a diferencia de MQTT y DDS, donde sí hubo un aumento en la utilización del ancho de banda en los escenarios mencionados. Otro escenario involucraba una gran cantidad de dispositivos que transmitían datos simultáneamente, lo cual es típico en entornos de IoT. Los resultados mostraron que para una mayor utilización es mejor utilizar CoAP.
Bajo carga ligera, CoAP utilizó el menor ancho de banda, seguido de MQTT y REST HTTP. Sin embargo, cuando aumentó el tamaño de las cargas útiles, REST HTTP obtuvo los mejores resultados.
Consumo de energía
La cuestión del consumo de energía siempre es de gran importancia, y especialmente en un sistema IoT. Si Mientras que MQTT y HTTP consumen electricidad, HTTP consume mucho más. Y CoAP es más en comparación con MQTT, lo que permite la gestión de energía. Sin embargo, en escenarios simples, MQTT es más adecuado para intercambiar información en redes de Internet de las cosas, especialmente si no hay restricciones de energía.
Un experimento que comparó las capacidades de AMQP y MQTT en un banco de pruebas de red inalámbrica móvil o inestable encontró que AMQP ofrece más capacidades de seguridad mientras que MQTT es más eficiente energéticamente.
seguridad
La seguridad es otra cuestión crítica que se plantea al estudiar el tema de Internet de las cosas y la computación en la nube/niebla. El mecanismo de seguridad normalmente se basa en TLS en HTTP, MQTT, AMQP y XMPP, o DTLS en CoAP, y admite ambas variantes 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 conjuntos para garantizar que la comunicación adicional se produzca en un canal seguro. La diferencia entre los dos radica en pequeñas modificaciones que permiten que DTLS basado en UDP funcione a través de una conexión no confiable.
en Varias implementaciones diferentes de TLS y DTLS descubrieron que TLS hizo un mejor trabajo. Los ataques a DTLS tuvieron más éxito debido a su tolerancia a errores.
Sin embargo, el mayor problema con estos protocolos es que no fueron diseñados originalmente para su uso en IoT y no estaban destinados a funcionar en la niebla o la nube. Mediante el protocolo de enlace, agregan tráfico adicional con cada establecimiento de conexión, lo que agota los recursos informáticos. En promedio, hay un aumento del 6,5 % para TLS y del 11 % para DTLS en los gastos generales en comparación con las comunicaciones sin una capa de seguridad. En entornos ricos en recursos, que normalmente se encuentran en A nivel de nivel, esto no será un problema, pero en la conexión entre IoT y 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 de IoT comparativamente más maduras y estables en comparación con otros protocolos.
Soluciones basadas en un protocolo de comunicación unificado
La práctica de una solución de protocolo único tiene muchas desventajas. Por ejemplo, un protocolo que se adapte a un entorno restringido puede no funcionar en un dominio que tenga requisitos de seguridad estrictos. Teniendo esto en cuenta, debemos descartar casi todas las posibles soluciones de protocolo único en el ecosistema Fog-to-Cloud en IoT, excepto MQTT y REST HTTP.
REST HTTP como solución de protocolo único
Hay un buen ejemplo de cómo interactúan las solicitudes y respuestas HTTP REST en el espacio IoT-to-Fog: . Los animales están equipados con sensores portátiles (cliente IoT, C) y controlados mediante computación en la nube mediante un sistema agrícola inteligente (servidor Fog, S).
El encabezado del método POST especifica el recurso a modificar (/granja/animales), así como la versión HTTP y el tipo de contenido, que en este caso es un objeto JSON que representa la granja de animales que va a administrar el sistema (Dulcinea/vaca). . La respuesta del servidor indica que la solicitud fue exitosa enviando el código de estado HTTPS 201 (recurso creado). El método GET debe especificar solo el recurso solicitado en el URI (por ejemplo, /granja/animales/1), que devuelve una representación JSON del animal con esa ID del servidor.
El método PUT se utiliza cuando es necesario actualizar algún registro de recurso específico. En este caso, el recurso especifica el URI del parámetro que se va a cambiar y el valor actual (por ejemplo, indica que la vaca está caminando actualmente, /farm/animals/1? state=walking). Finalmente, el método DELETE se usa igual que el método GET, pero simplemente elimina el recurso como resultado de la operación.
MQTT como solución de protocolo único
Tomemos la misma granja inteligente, pero en lugar de REST HTTP usamos el protocolo MQTT. Un servidor local con la biblioteca Mosquitto instalada actúa como intermediario. En este ejemplo, una computadora simple (denominada servidor de granja) Raspberry Pi sirve como cliente MQTT, implementado mediante una instalación de la biblioteca Paho MQTT, que es totalmente compatible con el corredor Mosquitto.
Este cliente corresponde a una capa de abstracción de IoT que representa un dispositivo con capacidades de detección y computación. El mediador, por otro lado, corresponde a un mayor nivel de abstracción, representando un nodo de computación en la niebla caracterizado por una mayor capacidad de procesamiento y almacenamiento.
En el escenario de granja inteligente propuesto, la Raspberry Pi se conecta al acelerómetro, al GPS y a los sensores de temperatura y publica los datos de estos sensores en un nodo de niebla. Como probablemente sepa, MQTT trata los temas como una jerarquía. Un único editor MQTT puede publicar mensajes sobre un conjunto específico de temas. En nuestro caso son tres. 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 GPS y el movimiento de los animales a través del acelerómetro, el cliente publicará actualizaciones en (animalfarm/animal/GPS) y (animalfarm/animal/movimiento).
Esta información se pasará al corredor, quien puede almacenarla temporalmente en una base de datos local en caso de que aparezca otro suscriptor interesado más adelante.
Además del servidor local, que actúa como intermediario MQTT en la niebla y al que Raspberry Pis, actuando como clientes MQTT, envía datos de sensores, puede haber otro intermediario MQTT a nivel de nube. En este caso, la información transmitida 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 asociar todos los datos con el corredor MQTT de nube. Con esta arquitectura, un usuario de una aplicación móvil puede suscribirse a ambos corredores.
Si falla la conexión con uno de los brokers (por ejemplo, la nube), el usuario final recibirá información del otro (niebla). Este es un rasgo característico de los sistemas combinados de computación en la nube y en la niebla. De forma predeterminada, la aplicación móvil se puede configurar para conectarse primero al corredor MQTT de niebla y, si eso falla, para conectarse al corredor MQTT de 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 sencilla. Pero está claro que en los sistemas IoT-F2C tiene sentido combinar diferentes protocolos. La idea es que diferentes protocolos puedan operar en diferentes niveles. Tomemos, por ejemplo, tres abstracciones: las capas de IoT, la niebla y la computación en la nube. Los dispositivos a nivel de IoT generalmente se consideran limitados. Para esta descripción general, consideremos los niveles de IoT como los más restringidos, la nube como los menos restringidos y la computación en la niebla como "en algún punto intermedio". Resulta entonces que entre IoT y abstracciones de niebla, las soluciones de protocolo actuales incluyen MQTT, CoAP y XMPP. Entre niebla y nube, por otro lado, AMQP es uno de los principales protocolos utilizados, junto con REST HTTP, que por su flexibilidad también se utiliza entre IoT y capas de niebla.
El principal problema aquí es la interoperabilidad de los protocolos y la facilidad de transferir mensajes de un protocolo a otro. Idealmente, en el futuro, la arquitectura de un sistema de Internet de las cosas con recursos de nube y niebla será independiente del protocolo de comunicación utilizado y garantizará una buena interoperabilidad entre diferentes protocolos.
Dado que este no es el caso actualmente, tiene sentido combinar protocolos que no tengan diferencias significativas. Para ello, una posible solución se basa en una combinación de dos protocolos que siguen el mismo estilo arquitectónico, REST HTTP y CoAP. Otra solución propuesta se basa en una combinación de dos protocolos que ofrecen comunicación de publicación-suscripción, MQTT y AMQP. El uso de conceptos similares (tanto MQTT como AMQP usan intermediarios, CoAP y HTTP usan REST) hace que estas combinaciones sean más fáciles de implementar y requieren menos esfuerzo de integración.
La Figura (a) muestra dos modelos basados en solicitud-respuesta, HTTP y CoAP, y su posible ubicación en una solución IoT-F2C. Dado que HTTP es uno de los protocolos más conocidos y adoptados en las redes modernas, es poco probable que sea completamente reemplazado por otros protocolos de mensajería. Entre los nodos que representan dispositivos potentes que se encuentran entre la nube y la niebla, REST HTTP es una solución inteligente.
Por otro lado, para dispositivos con recursos informáticos limitados que se comunican entre las capas Fog e IoT, es más eficiente utilizar CoAP. Una de las grandes ventajas de CoAP es en realidad su compatibilidad con HTTP, ya que ambos protocolos se basan en principios REST.
La Figura (b) muestra dos modelos de comunicación de publicación-suscripción en el mismo escenario, incluidos MQTT y AMQP. Aunque hipotéticamente ambos protocolos podrían usarse para la comunicación entre nodos en cada capa de abstracción, su posición debe determinarse en función del rendimiento. MQTT fue diseñado como un protocolo liviano para dispositivos con recursos informáticos limitados, por lo que puede usarse para la comunicación IoT-Fog. AMQP es más adecuado para dispositivos más potentes, lo que idealmente lo ubicaría entre los nodos de niebla y nube. En lugar de MQTT, el protocolo XMPP se puede utilizar en IoT, ya que se considera liviano. Pero no se utiliza tan ampliamente en tales escenarios.
Hallazgos
Es poco probable que uno de los protocolos discutidos sea suficiente para cubrir todas las comunicaciones de un sistema, desde dispositivos con recursos informáticos limitados hasta servidores en la nube. El estudio encontró que las dos opciones más prometedoras que los desarrolladores utilizan 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 exitosos y bien documentados.
Debido a su estabilidad y configuración simple, MQTT es un protocolo que ha demostrado su rendimiento superior a lo largo del tiempo cuando se usa a 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, como algunos dominios de niebla y la mayoría de la computación en la nube, RESTful HTTP es una opción fácil. También se debe tener en cuenta CoAP, ya que también está evolucionando rápidamente como estándar de mensajería de IoT y es probable que alcance un nivel de estabilidad y madurez similar a MQTT y HTTP en un futuro próximo. Pero el estándar está evolucionando actualmente, lo que conlleva problemas de compatibilidad a corto plazo.
¿Qué más puedes leer en el blog?
→
→
→
→
→
Suscríbase a nuestro -canal, para no perderse el próximo artículo! Escribimos no más de dos veces por semana y solo por negocios.
Fuente: habr.com