MQTT son las siglas de “Message Queue Telemetry Transport” y es un protocolo de publicación/suscripción (pub/sub). Se utiliza frecuentemente en comunicaciones máquina-a-máquina (M2M) debido a su eficiencia y bajo consumo.

Diferencias en la arquitectura

• MQTT se enfoca en la transmisión de datos a nivel de byte, mientras que HTTP en la transmisión de documentos.

• Por otra parte HTTP funciona como un modelo cliente-servidor (o petición-respuesta), mientras que MQTT funciona mediante publicaciones y suscripciones a un tema (modelo “pub/sub”), mediante un Broker (agente que gestiona las publicaciones y suscripciones).
• En MQTT se mantiene la conexión y se pueden compartir pings o latidos (“heartbeats”) para mantenerla abierta. HTTP sólo crea una conexión cuando se necesita enviar una petición.
• En este sentido HTTP establece una conexión TCP half-duplex, mientras que en MQTT es full-duplex.

¿Cuál es más sencillo y ligero?

• MQTT tiene una especificación muy liviana. Para los desarrolladores basta con conocer los tipos CONNECT, PUBLISH, SUBSCRIBE, UNSUBSCRIBE y DISCONNECT. Por su parte HTTP es mucho más intrincado, aunque esto lo hace apto para aplicaciones que requieran mayor control de la comunicación.
• La cabecera más pequeña de MQTT sólo tiene 2 Bytes, mientras que la cabecera más pequeña de HTTP es de 26 Bytes.
• En cuanto a la carga (payload), MQTT es capaz de transportar datos crudos en binario, mientras que HTTP requiere una codificación en base 64.
• El aplicaciones industriales, el protocolo MQTT permite propagar configuraciones nuevas de los dispositivos mediante suscripciones. En HTTP las configuraciones nuevas deben solicitarse explícitamente mediante un sondeo periódico (polling): “Dispositivo IoT: Servidor, ¿tienes ya alguna configuración nueva para mí?“

Velocidad: ¿Cuál es más rápido?

• MQTT es más rápido y más eficiente que HTTP:
  • En redes 3G es 93 veces más rápido, usa 8 veces menos tráfico y gasta 170 veces menos energía en los receptores.
  • En otros escenarios como este test de performance MQTT fue al menos 20 veces más rápido, usa 50 veces menos tráfico y energéticamente un 22% más eficiente.

QoS: ¿Cuál es más fiable?

HTTP no implementa por sí mismo calidad de servicio (QoS). En cambio, MQTT puede establecer tres diferentes niveles QoS:

• QoS 0 – at most once: sólo realiza una entrega “best effort”, sin garantías frente a fallos. Opción por defecto.
• QoS 1 – at least once: el mensaje será entregado como mínimo una vez y puede proteger frente a pérdidas de conexión (aunque pueden llegar duplicados). Utiliza ACKs (confirmaciones de entrega).
• QoS 2 – exactly once: garantiza que cada mensaje se reciba por la parte receptora sin duplicados.

Esto es importante para garantizar la entrega de confirmaciones después de hacer una actualización remota de un dispositivo. Por ejemplo Google IoT Cloud garantiza con QoS1 el upgrade de la configuración de los dispositivos suscritos.

Especial en MQTT: “Última Voluntad” y Retención de mensajes

• MQTT ofrece además las funciones última voluntad (Last will & Testament, LWT): en caso de una desconexión repentina de un cliente, todos los demás clientes suscritos a ese topic recibirán una notificación por parte del broker.

• Por otra parte la Retención de mensajes permite que un cliente recién suscrito a un tema conseguirá una actualización de estado inmediata sobre el resto de clientes.

• HTTP carece de las funcionalidaes testamento y retención de mensajes.

¿Cuál es más seguro?

• En MQTT la autenticación se puede realizar mediante identificador de cliente, usuario/contraseña o certificados x509.
• Tanto MQTT como HTTP pueden operar sobre TLS ó SSL, ya que esto forma parte del protocolo TCP/IP.
• El broker MQTT puede controlar quién se suscribe y quién publica en qué topics.
• Al igual que los servidores web, los brokers y bridges MQTT soportan autorización mediante JWT (JSON Web Token).
• En este sentido los dos protocolos son igualmente seguros en combinación con SSL y JWT. Y viceversa: HTTP y MQTT son igual de inseguros si no se toma ninguna medida.
• Sin embargo, MQTT puede tener más problemas para pasar a través de los cortafuegos, ya que sus puertos no suelen estar tan aceptados como los de HTTP.
  • Aunque no es lo ideal, si fuera necesario MQTT se podría implementar sobre WebSockets (puerto 80).

Si os interesa el tema de seguridad en IoT háganoslo saber en los comentarios y publicaremos un tutorial más extenso

Conclusiones

MQTT está mucho más optimizado que HTTP en cuanto a tiempos de respuesta, throughput, consumo de batería y ancho de banda.

HTTP derrocha más energía y capacidad. Pero es un viejo conocido y puede ser más fácil de implementar con respecto a sistemas antiguos que todavía usen HTTP. También es idóneo para enviar bloques grandes de datos de una sentada.

Otra diferencia importante a tener en cuenta es la posibilidad de implementar QoS y las funciones especiales de MQTT: última voluntad y retención de mensajes.

Por tanto MQTT es mejor para casi todas las aplicaciones de Internet de las Cosas (IoT), pero si estás empezando y no sabes cuál elegir, implementa HTTP y cambia a MQTT cuando lo necesites.

En próximos tutoriales describiremos algunos ejemplos de implementación usando NodeMCU y el broker Mosquitto. Asegúrate de suscribirte!

La entrada MQTT vs HTTP: ¿qué protocolo es mejor para IoT? se publicó primero en BorrowBits.

Hace unos meses os contábamos que existe, por así decirlo, un paso intermedio entre 4G y 5G que ya está empezando a comercializarse con el nombre de VoLTE (Voice over LTE). En resumen, este protocolo permite realizar llamadas de voz directamente sobre datos.  El principio de funcionamiento es similar a VoIP tradicional, con la salvedad de que en este caso el servicio se opera a nivel de red y no a nivel de aplicación. Es decir: no necesitaríamos aplicaciones como Skype, Viber o Whatsapp, ya que las llamadas de datos estarían integradas directamente en nuestro teléfono.

Durante algunos años, LTE coexistirá con las tecnologías de conmutación de circuitos de voz, también conocidas como Circuit Switch. No obstante, desde hace unos años los proveedores están reemplazando todos sus sistemas de conmutación de datos (Circuit Switched Data, CSD) por sistemas basados 100% en Ethernet. En esta coyuntura, es de esperar que tarde o temprano todas las llamadas de voz móvil se operen exclusivamente sobre datos.

Mientras tanto, muchos nos preguntamos cuál es exactamente la diferencia entre VoLTE y VoIP:

La diferencia está en la QoS

Tradicionalmente, las aplicaciones de voz como Skype han confiado en Internet para entregar los paquetes. Y esto es un mal asunto: la naturaleza intrínseca de Internet no garantiza la entrega de paquetes, y es por esto que se la conoce como una tecnología Best Effort: las aplicaciones que funcionan sobre Internet se ponen una venda en los ojos y cruzan los dedos.

No ocurre así cuando hablamos de VoLTE, ya que éste exige la presencia de un componente de Calidad de Servicio (Quality of Service, QoS).

¿En qué consiste la QoS?

QoS es un conjunto de tecnologías que garantizan la transmisión de cierta cantidad de información en un tiempo dado. Esto es: throughput. Es especialmente importante cuando hablamos de aplicaciones de tiempo real como voz y video.  Existen algunos problemas que afectan a la calidad del servicio y son los que QoS pretende resolver:

Paquetes sueltos

Los routers pueden sufrir pérdidas de paquetes si llegan cuando los buffers ya están llenos. Dependiendo del estado de congestión de la red, se podrían perder uno o muchos paquetes. Un problema que podría solventarse mediante la solicitud de retransmisión de paquetes sueltos por parte del receptor. Como es fácil suponer, esto provoca la aparición de graves retardos.

Retardos

Puede ocurrir que los paquetes tarden un largo período de tiempo en alcanzar su destino, debido a que pueden permanecer en largas colas o tomen una ruta menos directa para prevenir la congestión de la red. En algunos casos, los retardos excesivos pueden llegar a inutilizar las aplicaciones VoIP.

Jitter

Los paquetes del transmisor pueden llegar a su destino con diferentes retardos. Un retardo de un paquete varía impredeciblemente con su posición en las colas de los encaminadores a lo largo de la ruta entre el transmisor y el destino. Esta variación en retardo se conoce como jitter y puede afectar seriamente a la calidad del flujo de audio y/o vídeo.

Entrega de paquetes fuera de orden

Cuando un conjunto de paquetes relacionados del mismo flujo son encaminados hacia Internet, los paquetes pueden tomar diferentes rutas, resultando en diferentes retardos. Básicamente, esto ocasiona que los paquetes lleguen desordenados. Para solventar este problema requerimos de un protocolo que pueda reordenar los paquetes a un estado isócrono una vez que estos lleguen a su destino.

Errores

Los paquetes y los políticos tienen algo en común: algunos se corrompen durante su trayectoria. En este caso, el receptor tiene que detectarlos y solicitar una retransmisión de los mismos.

¿Cómo se implementa QoS en VoLTE?

VoLTE utiliza una combinación de la arquitectura IMS (IP Multimedia Subsystem) y la alta velocidad de la red de acceso (Radio Access Network) para garantizar la QoS. En ese sentido, la calidad de las llamadas VoLTE no tienen nada que envidiar a las llamadas tradicionales basadas en circuitos E1 o T1, y es por esto que se espera que VoLTE desplace a VoIP, al menos cuando nos referimos a dispositivos móviles.

¿Cómo se implementa QoS en sistemas VoIP?

Sin embargo, si de algo se echa de menos en VoIP es la calidad de los sistemas telefónicos tradicionales. Este componente QoS, al contrario que ocurre en VoLTE, se puede implementar en VoIP como una característica opcional y no como una condición necesaria. Existen múltiples técnicas para implementar QoS a nivel de interfaz en VoIP (a nivel de una red global no es posible, en tanto que usa Internet como hemos mencionado anteriormente):

Este es un modelo que es bastante útil para comprender de qué formas podemos intentar garantizar la QoS y con cuáles conseguirlo. En esta figura están representadas las dos acciones fundamentales asociadas a garantizar la QoS:

• Clasificación: El tráfico que entra al equipo y que se ha de transmitir se tiene que clasificar. Pueden usarse muchos criterios de clasificación: Por equipo destino, por marcas en los paquetes, por aplicación… Es algo que siempre hay que hacer ya que si no el propio concepto de QoS no existe. Básicamente, la clasificación es buscar a qué parámetros de QoS negociados o contratados pertenece un paquete (o tráfico) en particular: Tráfico máximo en ráfaga, tráfico mínimo sostenido, latencia máxima, variación en la latencia…
• Asignación de recursos: Una vez que se tiene el tráfico clasificado, y por tanto se saben qué parámetros de QoS se deben cumplir, hay que asignar los recursos en la interfaz. Hay que permitir que los paquetes se transmitan al medio (el aire o un cable).

La fase de clasificación es común a todos los tipos de interfaz que necesitan garantizar la QoS, pero la principal diferencia viene en la fase de asignación de recursos. Existen 2 mecanismos que son lo bastante amplios como para merecer que les demos un nombre “QoS a nivel 3 (L3QoS o IPQoS)” y “QoS a nivel 2 (L2QoS o MACQoS)”.

Existen múltiples estándares y sistemas VoIP profesionales implementados mediante software o hardware que en gran medida tratan de controlar el tráfico de la red para disminuir las posibilidades que se produzcan caídas en el rendimiento.

Como conclusión…

Incluso si los mecanismos para garantizar la QoS en VoIP fueran iguales a los de VoLTE (algunas arquitecturas VoIP implementan IMS), aún tendríamos la ventaja de que éste último ofrece una red de acceso radio y un backbone diseñado especialmente para transportar datos de forma mucho más eficiente que la red IP tradicional.

La entrada VoLTE vs VoIP: la diferencia está en la QoS se publicó primero en BorrowBits.