¿Quién inventó MQTT? La historia, de los oleoductos al IoT

¿Quién inventó MQTT? Andy Stanford-Clark, de IBM, y Arlen Nipper, de Arcom Control Systems, lo diseñaron en 1999 para monitorizar oleoductos a través de costosos enlaces por satélite. Este artículo sigue a MQTT desde ese nicho industrial hasta convertirse en un estándar abierto de OASIS e ISO y en el protocolo por defecto del IoT, y explica cómo los objetivos de diseño originales siguen marcando la forma en que lo usas hoy.

El problema en 1999: oleoductos, satélites y ancho de banda

A finales de los años noventa, los operadores de petróleo y gas necesitaban recoger telemetría de equipos remotos de los oleoductos: presiones, caudales, posiciones de válvulas, estados de bombas. Muchos emplazamientos no tenían red terrestre, así que los datos viajaban por enlaces de satélite lentos, intermitentes y facturados por byte. Los enfoques existentes sondeaban cada dispositivo según un calendario, desperdiciando ancho de banda en valores que no habían cambiado y sufriendo cada vez que se caía el enlace.

Dos ingenieros abordaron el problema desde lados distintos:

• Andy Stanford-Clark, de IBM, que trabajaba en middleware de mensajería y tenía un gran interés por la computación ubicua.
• Arlen Nipper, de Arcom Control Systems (que más tarde pasó a formar parte de Eurotech), que aportaba una amplia experiencia de campo en SCADA y hardware embebido.

Juntos diseñaron un protocolo que enviara datos solo cuando cambiaban, sobreviviera a enlaces poco fiables y funcionara en hardware modesto.

Los objetivos de diseño originales

Los objetivos que se marcaron parecen una lista de comprobación del IoT moderno:

1. Sencillo de implementar en dispositivos pequeños con memoria y CPU limitadas.
2. Sobrecarga mínima, para que cada byte por satélite transportara datos útiles.
3. Publish/subscribe, para que los dispositivos remotos no necesitaran saber quién consumía sus datos.
4. Niveles de calidad de servicio para que el emisor pudiera equilibrar fiabilidad y ancho de banda en cada mensaje.
5. Tolerancia a la conectividad intermitente, incluida una forma de avisar a todos cuando un dispositivo se caía inesperadamente.
6. Agnóstico respecto a los datos, capaz de transportar cualquier formato de payload sin que al protocolo le importara.

Cada objetivo se corresponde directamente con funciones que sigues usando: la cabecera fija de dos bytes como mínimo, el modelo publish/subscribe centrado en el broker, QoS 0/1/2, el keep-alive y el Last Will, y los payloads opacos.

¿Qué significa MQTT?

El "MQ" venía de la familia de productos de mensajería MQSeries de IBM, y el protocolo se llamaba originalmente MQ Telemetry Transport. Ese nombre causó años de confusión, porque MQTT no es una cola de mensajes en el sentido de MQSeries. Cuando MQTT se estandarizó, el nombre pasó a ser simplemente "MQTT", que oficialmente ya no se trata como un acrónimo.

Cronología de MQTT: quién inventó MQTT y qué vino después

Los documentos de la especificación están disponibles en el comité de OASIS y resumidos en mqtt.org.

De propietario a abierto: por qué 2010 fue el punto de inflexión

Durante su primera década, MQTT fue sobre todo una tecnología de IBM. Publicar la especificación 3.1 libre de royalties en 2010 lo cambió todo. Los desarrolladores pudieron escribir clientes y brokers sin preocuparse por licencias, y lo hicieron:

• Eclipse Paho ofreció bibliotecas cliente en muchos lenguajes, lo que dio a los desarrolladores un punto de partida común.
• Mosquitto, un broker open source ligero, hizo trivial ejecutar MQTT en un portátil o en una Raspberry Pi.
• Aficionados y startups lo adoptaron para domótica y productos conectados, a menudo descubriéndolo a través de proyectos con Arduino y Linux.

Ese momento coincidió con el auge de los microcontroladores Wi-Fi baratos y de los smartphones. Un protocolo diseñado para enlaces por satélite resultó ideal para sensores alimentados por batería y aplicaciones móviles en redes celulares inestables.

Estandarización: OASIS e ISO

Las implementaciones abiertas crearon impulso, pero las empresas querían un estándar neutral respecto a los fabricantes. IBM y otros llevaron MQTT a OASIS, donde un comité técnico refinó la versión 3.1 hasta convertirla en MQTT 3.1.1, aclarando zonas ambiguas y manteniendo la compatibilidad en la práctica. Se convirtió en estándar OASIS en 2014 e ISO/IEC lo adoptó como 20922 en 2016.

Después, el comité abordó las lecciones aprendidas en grandes despliegues. MQTT 5.0, aprobado en 2019, mantuvo el modelo central pero añadió lo que los operadores echaban en falta: reason codes para diagnosticar fallos, expiración de sesión y de mensajes, suscripciones compartidas para balancear la carga, topic aliases, user properties y metadatos de request/response. Nuestro resumen de las funciones de MQTT 5 explica cada novedad.

Ideas erróneas habituales sobre el origen de MQTT

Algunos mitos aparecen una y otra vez en foros y entrevistas:

• "MQTT se creó para el internet de las cosas." El término IoT apenas existía en 1999. MQTT se creó para la telemetría industrial y solo más tarde se convirtió en el protocolo por defecto del IoT.
• "MQTT es una cola de mensajes." El MQ del nombre original hace referencia a una familia de productos, no a una semántica de colas. Cada suscriptor coincidente recibe su propia copia de un mensaje.
• "MQTT siempre fue abierto." Fue propietario durante una década aproximadamente, antes de su publicación libre de royalties en 2010.
• "MQTT 5 sustituyó a 3.1.1." Ambas versiones siguen muy usadas y la mayoría de brokers admiten las dos en paralelo.

Por qué el diseño original sigue importando

Muchas de las buenas prácticas actuales son los requisitos de 1999 con ropa nueva:

1. Mantén las conexiones de larga duración. MQTT presupone un enlace persistente y amortiza los costes de establecimiento entre muchos mensajes.
2. Publica cuando algo cambia, no con un temporizador, cuando el ancho de banda o la batería son valiosos.
3. Usa el Last Will para la presencia, exactamente el requisito de "avisar a todos cuando un dispositivo se cae".
4. Elige el QoS según el tipo de mensaje, equilibrando fiabilidad y coste como pretendían sus diseñadores.
5. El formato del payload lo eliges tú, ya sea JSON, Protobuf o Sparkplug B.

Entender esta historia también explica los límites de MQTT. No se diseñó como un log duradero ni como una plataforma de procesamiento de streams, y por eso los sistemas de producción combinan un broker con bases de datos, historians o procesadores de streams conectados como clientes.

De los brokers autoalojados al broker MQTT gestionado

Los primeros usuarios ejecutaban sus propios brokers en sus propios servidores. Sigue siendo posible, pero significa que los parches, la renovación de certificados, la monitorización y el escalado son cosa tuya. Una proporción creciente de equipos elige ahora un broker MQTT gestionado y dedica su tiempo a los dispositivos y las aplicaciones.

ConnectMQ es uno de esos brokers MQTT en la nube. Admite tanto MQTT 3.1.1 como 5.0, ofrece TLS en el 8883 y WebSocket seguro en el 8084, e incluye funciones industriales que habrían complacido a los orígenes del protocolo en la monitorización de oleoductos: detección de topics ISA-95 y Unified Namespace y decodificación de Sparkplug B. Si quieres experimentar el protocolo que diseñaron sus inventores sin ninguna configuración, conéctate al servidor MQTT público gratuito, pensado para pruebas y no para datos de producción:

mosquitto_sub -h broker.connectmq.com -p 1883 -i history-sub-e41f \
  -t "connectmq/demo/e41f/pipeline/#" -v

mosquitto_pub -h broker.connectmq.com -p 1883 -i history-pub-e41f \
  -t "connectmq/demo/e41f/pipeline/station7/pressure" -m "42.7" -q 1

Una estación remota publica un valor, el broker lo envía a todos los suscriptores interesados y nadie sondea. Esa es la idea de 1999 en dos comandos. Para profundizar, continúa con el tutorial de MQTT o descubre dónde se usa hoy el protocolo en casos de uso de MQTT por sector.

Empieza con ConnectMQ

Experimenta MQTT tal como lo concibieron sus inventores, sin gestionar un servidor. Regístrate en app.connectmq.com, crea un broker Serverless gratuito sin tarjeta de crédito y usa el cliente integrado en el navegador de ConnectMQ para publicar tu primer mensaje en minutos.

Preguntas frecuentes

¿Quién inventó MQTT?

Andy Stanford-Clark, de IBM, y Arlen Nipper, de Arcom Control Systems (más tarde Eurotech), inventaron MQTT en 1999.

¿Por qué se creó MQTT?

Para monitorizar equipos de oleoductos a través de enlaces por satélite caros y poco fiables, lo que exigía un protocolo ligero que enviara solo los cambios y tolerara las conexiones caídas.

¿Qué significa MQTT?

Originalmente significaba MQ Telemetry Transport, por los productos MQSeries de IBM. Hoy el estándar lo llama simplemente MQTT.

¿MQTT es un estándar abierto?

Sí. MQTT 3.1.1 y 5.0 son estándares OASIS, y MQTT 3.1.1 es además ISO/IEC 20922.