Quem inventou o MQTT? Andy Stanford-Clark, da IBM, e Arlen Nipper, da Arcom Control Systems, o projetaram em 1999 para monitorar oleodutos por meio de caros links de satélite. Este artigo acompanha o MQTT desde esse nicho industrial até se tornar um padrão aberto da OASIS e da ISO e o protocolo padrão da IoT, e explica como os objetivos de design originais ainda moldam a forma como você o usa hoje.
O problema em 1999: oleodutos, satélites e largura de banda
No fim dos anos 1990, as operadoras de petróleo e gás precisavam coletar telemetria de equipamentos remotos de oleodutos: pressões, vazões, posições de válvulas, estados de bombas. Muitas instalações não tinham rede terrestre, então os dados trafegavam por links de satélite lentos, intermitentes e cobrados por byte. As abordagens existentes consultavam cada dispositivo em intervalos fixos (polling), desperdiçando banda com valores que não haviam mudado e enfrentando dificuldades sempre que o link caía.
Dois engenheiros abordaram o problema por lados diferentes:
- Andy Stanford-Clark, da IBM, que trabalhava com middleware de mensageria e tinha grande interesse em computação pervasiva.
- Arlen Nipper, da Arcom Control Systems (mais tarde parte da Eurotech), que trouxe do campo uma profunda experiência em SCADA e hardware embarcado.
Juntos, eles projetaram um protocolo que enviaria dados apenas quando mudassem, sobreviveria a links instáveis e rodaria em hardware modesto.
Os objetivos de design originais
Os objetivos que definiram parecem um checklist moderno de IoT:
- Simples de implementar em dispositivos pequenos, com memória e CPU limitadas.
- Overhead mínimo, para que cada byte enviado via satélite carregasse dados úteis.
- Publish/subscribe, para que os dispositivos remotos não precisassem saber quem consumia seus dados.
- Níveis de qualidade de serviço, para que o remetente pudesse equilibrar confiabilidade e banda em cada mensagem.
- Tolerância a conectividade intermitente, incluindo uma forma de avisar a todos quando um dispositivo saísse do ar inesperadamente.
- Agnóstico quanto aos dados, transportando qualquer formato de payload sem que o protocolo se importasse.
Cada objetivo corresponde diretamente a recursos que você ainda usa: o cabeçalho fixo mínimo de dois bytes, o modelo publish/subscribe centrado no broker, QoS 0/1/2, keep alive e Last Will, e payloads opacos.
O que significa MQTT?
O "MQ" veio da família de produtos de mensageria MQSeries da IBM, e o protocolo se chamava originalmente MQ Telemetry Transport. Esse nome causou anos de confusão, porque o MQTT não é uma fila de mensagens no sentido do MQSeries. Quando o MQTT foi padronizado, o nome passou a ser simplesmente "MQTT", que oficialmente deixou de ser tratado como sigla.
Linha do tempo do MQTT: quem inventou o MQTT e o que veio depois
| Ano | Marco |
|---|---|
| 1999 | Andy Stanford-Clark e Arlen Nipper criam a primeira versão para telemetria de oleodutos |
| Anos 2000 | A IBM usa o MQTT internamente e em seus produtos de mensageria; a adoção cresce nos setores industrial e de energia |
| Fim dos anos 2000 | O MQTT-S (mais tarde MQTT-SN) é especificado para redes de sensores sem TCP |
| 2010 | A IBM publica o MQTT 3.1 livre de royalties, permitindo que qualquer pessoa o implemente |
| Início dos anos 2010 | Surgem clientes e brokers open source, incluindo Eclipse Paho e Mosquitto |
| 2013 | A OASIS forma um Comitê Técnico de MQTT para padronizar o protocolo |
| 2014 | O MQTT 3.1.1 se torna um padrão OASIS |
| 2016 | O MQTT 3.1.1 é publicado como o padrão internacional ISO/IEC 20922 |
| De 2016 em diante | O Sparkplug, criado pela Cirrus Link (cofundada por Arlen Nipper), acrescenta convenções industriais sobre o MQTT e depois passa para a Eclipse Foundation |
| 2019 | O MQTT 5.0 se torna um padrão OASIS, acrescentando reason codes, session expiry, shared subscriptions e mais |
Os documentos de especificação estão disponíveis no comitê da OASIS e resumidos em mqtt.org.
Do proprietário ao aberto: por que 2010 foi a virada
Na sua primeira década, o MQTT foi principalmente uma tecnologia da IBM. Tornar a especificação 3.1 livre de royalties em 2010 mudou isso. Os desenvolvedores passaram a poder escrever clientes e brokers sem preocupações com licenciamento, e foi o que fizeram:
- O Eclipse Paho forneceu bibliotecas cliente em várias linguagens, dando aos desenvolvedores um ponto de partida comum.
- O Mosquitto, um broker open source leve, tornou trivial rodar MQTT em um notebook ou em um Raspberry Pi.
- Hobbistas e startups o adotaram para automação residencial e produtos conectados, muitas vezes descobrindo-o por meio de projetos com Arduino e Linux.
Esse momento coincidiu com a ascensão dos microcontroladores Wi-Fi baratos e dos smartphones. Um protocolo projetado para links de satélite se revelou ideal para sensores alimentados por bateria e aplicativos móveis em redes celulares instáveis.
Padronização: OASIS e ISO
As implementações abertas criaram impulso, mas as empresas queriam um padrão neutro em relação a fornecedores. A IBM e outros levaram o MQTT à OASIS, onde um comitê técnico refinou a versão 3.1 até o MQTT 3.1.1, esclarecendo pontos ambíguos e mantendo a compatibilidade na prática. Ele se tornou um padrão OASIS em 2014 e foi adotado pela ISO/IEC como 20922 em 2016.
O comitê então se dedicou às lições aprendidas em grandes implantações. O MQTT 5.0, aprovado em 2019, manteve o modelo central, mas acrescentou o que os operadores sentiam falta: reason codes para diagnosticar falhas, expiração de sessão e de mensagem, shared subscriptions para balanceamento de carga, topic aliases, user properties e metadados de requisição/resposta. Nossa visão geral dos recursos do MQTT 5 explica cada acréscimo.
Equívocos comuns sobre as origens do MQTT
Alguns mitos aparecem repetidamente em fóruns e entrevistas:
- "O MQTT foi criado para a internet das coisas." O termo IoT mal existia em 1999. O MQTT foi criado para telemetria industrial e só depois se tornou o protocolo padrão da IoT.
- "O MQTT é uma fila de mensagens." O MQ do nome original se refere a uma família de produtos, não à semântica de fila. Cada assinante correspondente recebe sua própria cópia de uma mensagem.
- "O MQTT sempre foi aberto." Ele foi proprietário por cerca de uma década, até a liberação sem royalties em 2010.
- "O MQTT 5 substituiu o 3.1.1." Os dois continuam amplamente usados, e a maioria dos brokers suporta ambos lado a lado.
Por que o design original ainda importa
Muitas das boas práticas de hoje são os requisitos de 1999 com roupa nova:
- Mantenha as conexões de longa duração. O MQTT pressupõe um link persistente e dilui os custos de estabelecimento entre muitas mensagens.
- Publique na mudança, não por temporizador, quando banda ou bateria são preciosas.
- Use o Last Will para presença, exatamente o requisito de "avisar a todos quando um dispositivo cair".
- Escolha a QoS por tipo de mensagem, equilibrando confiabilidade e custo como os criadores pretendiam.
- Mantenha o formato do payload à sua escolha, seja JSON, Protobuf ou Sparkplug B.
Entender essa história também explica os limites do MQTT. Ele não foi projetado como um log durável nem como uma plataforma de processamento de streams, e é por isso que os sistemas de produção combinam um broker com bancos de dados, historiadores ou processadores de streams conectados como clientes.
De brokers auto-hospedados ao broker MQTT gerenciado
Os primeiros a adotar o protocolo rodavam seus próprios brokers em seus próprios servidores. Isso ainda é possível, mas significa que patches, renovação de certificados, monitoramento e escalabilidade ficam por sua conta. Uma parcela crescente das equipes hoje escolhe um broker MQTT gerenciado e dedica seu tempo aos dispositivos e às aplicações.
O ConnectMQ é um desses brokers MQTT na nuvem. Ele suporta MQTT 3.1.1 e 5.0, oferece TLS na 8883 e WebSocket seguro na 8084, e inclui recursos industriais que teriam agradado às origens do protocolo no monitoramento de oleodutos: detecção de tópicos ISA-95 e Unified Namespace e decodificação de Sparkplug B. Se quiser experimentar o protocolo que os inventores projetaram sem nenhuma configuração, conecte-se ao servidor MQTT público, pensado para testes e protótipos:
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
Uma estação remota publica um valor, o broker o envia a todos os assinantes interessados e ninguém faz polling. Essa é a ideia de 1999 em dois comandos. Para se aprofundar, continue com o tutorial de MQTT ou veja onde o protocolo é usado hoje em casos de uso do MQTT por setor.
Comece a usar o ConnectMQ
Experimente o MQTT como seus inventores pretendiam, sem rodar um servidor. Cadastre-se em app.connectmq.com, crie um broker Serverless gratuito sem cartão de crédito e use o cliente no navegador do ConnectMQ para publicar sua primeira mensagem em minutos.
Perguntas frequentes
Quem inventou o MQTT?
Andy Stanford-Clark, da IBM, e Arlen Nipper, da Arcom Control Systems (mais tarde Eurotech), inventaram o MQTT em 1999.
Por que o MQTT foi criado?
Para monitorar equipamentos de oleodutos por links de satélite instáveis e caros, o que exigia um protocolo leve que enviasse apenas mudanças e tolerasse quedas de conexão.
O que significa MQTT?
Originalmente significava MQ Telemetry Transport, em referência aos produtos MQSeries da IBM. Hoje o padrão o chama simplesmente de MQTT.
O MQTT é um padrão aberto?
Sim. O MQTT 3.1.1 e o 5.0 são padrões OASIS, e o MQTT 3.1.1 também é a norma ISO/IEC 20922.



