MQTT

MQTT
Logotipo do MQTT
Estado	Publicado
Ano de início	1999; há 27 anos (1999)
Versão mais recente	5.0 7 de março de 2019; há 7 anos (2019-03-07)
Organização	OASIS IEC / ISO
Comitê	Comitê Técnico do OASIS Message Queuing Telemetry Transport
Editores	Andrew Banks (IBM), Ed Briggs (Microsoft), Ken Borgendale (IBM), Rahul Gupta (IBM)
Padrões relacionados	MQTT-SN
Website	mqtt.org

MQTT é um protocolo de comunicação de rede máquina a máquina (M2M), leve e de publicação–subscrição, para serviços de filas de mensagens. Ele foi projetado para conexões com locais remotos que possuem dispositivos com restrições de recursos ou largura de banda de rede limitada, como na Internet das Coisas (IoT). Ele deve ser executado sobre um protocolo de transporte que forneça conexões bidirecionais ordenadas e sem perdas — tipicamente, TCP/IP. É um padrão aberto da OASIS e uma recomendação da ISO (ISO/IEC 20922).

Histórico

Andy Stanford-Clark (IBM) e Arlen Nipper (então trabalhando na Arcom Control Systems) criaram a primeira versão do protocolo em 1999. Ele foi usado para monitorar oleodutos dentro do sistema de controle industrial SCADA. O objetivo era ter um protocolo que fosse eficiente em largura de banda, leve e consumisse pouca bateria, porque os dispositivos estavam conectados via link de satélite, o que era extremamente caro naquela época.

Historicamente, o "MQ" em "MQTT" veio da linha de produtos IBM MQ (então "MQSeries"), onde significa "Message Queue" (Fila de Mensagens). No entanto, o protocolo fornece mensagens de publicação e subscrição (sem filas, apesar do nome). Na especificação aberta pela IBM, como versão 3.1, o protocolo era chamado de "MQ Telemetry Transport". Versões subsequentes lançadas pela OASIS referem-se estritamente ao protocolo apenas como "MQTT", embora o comitê técnico em si seja chamado de "Comitê Técnico de Message Queuing Telemetry Transport da OASIS". Desde 2013, "MQTT" não é uma sigla para nada.

Em 2013, a IBM submeteu o MQTT v3.1 ao órgão de especificação da OASIS com um estatuto que garantiu que apenas pequenas alterações na especificação pudessem ser aceitas. Após assumir a manutenção do padrão da IBM, a OASIS lançou a versão 3.1.1 em 29 de outubro de 2014. Uma atualização mais substancial para o MQTT versão 5, adicionando vários novos recursos, foi lançada em 7 de março de 2019.

Visão geral

O protocolo MQTT define dois tipos de entidades de rede: um broker de mensagens e vários clientes. Um broker MQTT é um servidor que recebe mensagens de clientes publicadores e, em seguida, as roteia para os clientes de destino apropriados. Um cliente MQTT é qualquer dispositivo (desde um microcontrolador até um servidor completo) que executa uma biblioteca MQTT e se conecta a um broker MQTT através de uma rede.

As informações são organizadas em uma hierarquia de tópicos. Quando um publicador tem um novo item de dados para distribuir, ele envia uma mensagem de controle com os dados para o broker conectado. O broker então distribui a informação para quaisquer clientes que tenham se inscrito nesse tópico. O publicador não precisa ter nenhum dado sobre o número ou a localização dos assinantes; e os assinantes, por sua vez, não precisam ser configurados com nenhum dado sobre os publicadores.

Se um broker receber uma mensagem sobre um tópico para o qual não há assinantes no momento, o broker descarta a mensagem, a menos que o publicador da mensagem tenha designado a mensagem como uma mensagem retida (retained message). Uma mensagem retida é uma mensagem MQTT normal com o sinalizador de retenção definido como verdadeiro. O broker armazena a última mensagem retida e a respectiva qualidade de serviço (QoS) para o tópico selecionado. Cada cliente que se inscreve em um padrão de tópico que corresponde ao tópico da mensagem retida recebe a mensagem retida imediatamente após se inscrever. O broker armazena apenas uma mensagem retida por tópico. Isso permite que novos assinantes de um tópico recebam o valor mais atual, em vez de esperar pela próxima atualização de um publicador.

Quando um cliente publicador se conecta ao broker pela primeira vez, ele pode configurar uma mensagem padrão a ser enviada aos assinantes caso o broker detecte que o cliente publicador foi desconectado inesperadamente do broker.

Os clientes interagem apenas com um broker, mas um sistema pode conter vários servidores broker que trocam dados com base nos tópicos de seus assinantes atuais.

Uma mensagem de controle MQTT mínima pode ter apenas dois bytes de dados. Uma mensagem de controle pode carregar quase 256 megabytes de dados, se necessário. Existem 14 tipos de mensagens definidos usados para conectar e desconectar um cliente de um broker, publicar dados, confirmar o recebimento de dados e supervisionar a conexão entre cliente e servidor.

O MQTT baseia-se no protocolo TCP para a transmissão de dados. Uma variante, o MQTT-SN, é usada sobre outros transportes, como UDP ou Bluetooth.

O MQTT envia credenciais de conexão em formato de texto simples e não inclui nenhuma medida de segurança ou autenticação. Isso pode ser fornecido usando o TLS para criptografar e proteger as informações transferidas contra interceptação, modificação ou falsificação.

A porta MQTT padrão não criptografada é 1883. A porta criptografada é 8883.

Broker MQTT

O broker MQTT é um software executado em um computador (localmente ou na nuvem), podendo ser construído pelo próprio usuário ou hospedado por terceiros. Ele está disponível em implementações de código aberto e proprietárias.

O broker atua como uma agência de correios. Os clientes MQTT não usam um endereço de conexão direto do destinatário pretendido, mas usam a linha de assunto chamada "Tópico" (Topic). Qualquer pessoa que se inscreva recebe uma cópia de todas as mensagens para esse tópico. Vários clientes podem se inscrever em um tópico de um único broker (capacidade de um para muitos), e um único cliente pode registrar inscrições em tópicos com vários brokers (muitos para um).

Cada cliente pode produzir e receber dados tanto publicando quanto se inscrevendo, ou seja, os dispositivos podem publicar dados de sensores e ainda ser capazes de receber informações de configuração ou comandos de controle (o MQTT é um protocolo de comunicação bidirecional). Isso ajuda tanto no compartilhamento de dados quanto no gerenciamento e controle de dispositivos. Um cliente não pode transmitir os mesmos dados para uma faixa de tópicos e deve publicar várias mensagens para o broker, cada uma com um único tópico fornecido.

Com a arquitetura de broker MQTT, os dispositivos clientes e a aplicação do servidor tornam-se desacoplados. Dessa forma, os clientes permanecem inconscientes das informações uns dos outros. O MQTT, se configurado para isso, pode usar criptografia TLS com conexões protegidas por certificado, nome de usuário e senha. Opcionalmente, a conexão pode exigir certificação, na forma de um arquivo de certificado que um cliente fornece e que deve corresponder à cópia do servidor.

Em caso de falha, o software broker e os clientes podem alternar automaticamente para um broker de backup redundante/automático. Brokers de backup também podem ser configurados para compartilhar a carga de clientes entre vários servidores no local, na nuvem ou em uma combinação de ambos.

O broker pode dar suporte tanto ao MQTT padrão quanto ao MQTT para especificações compatíveis, como o Sparkplug. Isso pode ser feito com o mesmo servidor, ao mesmo tempo e com os mesmos níveis de segurança.

O broker monitora todas as informações da sessão à medida que o dispositivo entra e sai do ar, em uma função chamada "sessões persistentes" (persistent sessions). Nesse estado, um broker armazenará as informações de conexão para cada cliente, os tópicos aos quais cada cliente se inscreveu e quaisquer mensagens para um tópico com QoS 1 ou 2.

As principais vantagens de um broker MQTT são:

1. Eliminação de conexões de clientes vulneráveis e inseguras (quando configuradas adequadamente).
2. Capacidade de escalar facilmente de um único dispositivo para milhares.
3. Gerenciamento e rastreamento de estados de conexão de clientes, incluindo credenciais de segurança e certificados (quando configurados adequadamente).
4. Redução da carga em redes celulares ou de satélite sem comprometer a segurança (quando configuradas adequadamente).

Tipos de mensagem

Connect

Aguarda o estabelecimento de uma conexão com o servidor e cria um link entre os nós.

Versão 5.0

Em 2019, a OASIS lançou o padrão oficial MQTT 5.0. A versão 5.0 inclui os seguintes novos recursos principais:

• Códigos de motivo (Reason codes): As confirmações agora suportam códigos de retorno, que fornecem um motivo para uma falha.
• Assinaturas compartilhadas (Shared subscriptions): Permitem que a carga seja balanceada entre os clientes, reduzindo assim o risco de problemas de sobrecarga.
• Expiração de mensagens (Message expiry): As mensagens podem incluir uma data de validade e são excluídas se não forem entregues dentro desse período de tempo.
• Apelido de tópico (Topic alias): O nome de um tópico pode ser substituído por um único número.

Qualidade de serviço

Cada conexão com o broker pode especificar uma medida de QoS. Elas são classificadas em ordem crescente de sobrecarga (overhead):

• No máximo uma vez (At most once / QoS 0) – a mensagem é enviada apenas uma vez e o cliente e o broker não tomam nenhuma medida adicional para confirmar a entrega (fire and forget).
• No mínimo uma vez (At least once / QoS 1) – a mensagem é reenviada pelo remetente várias vezes até que a confirmação seja recebida (entrega confirmada).
• Exatamente uma vez (Exactly once / QoS 2) – o remetente e o receptor realizam um aperto de mão (handshake) de dois níveis para garantir que apenas uma cópia da mensagem seja recebida (entrega garantida).

Este campo não afeta o tratamento das transmissões de dados TCP subjacentes; ele é usado apenas entre remetentes e receptores MQTT.

Segurança

O protocolo MQTT versão 3.1.1 exige que o servidor (broker) use um tempo limite (timeout) que seja uma vez e meia o valor de keepalive especificado pelo cliente. Isso (e funcionalidades semelhantes de keepalive em outros protocolos, como o HTTP) permite um ataque de negação de serviço (Slow DoS attack) publicado em 2020 chamado SlowITe, no qual o atacante tenta abrir e manter o máximo possível de conexões, privando usuários legítimos de suas conexões. Novas variações do ataque e novos métodos de detecção/mitigação são tópicos de pesquisa atual.

Agrupamento (clustering)

A especificação MQTT define a comunicação entre um cliente e um único broker, e não especifica a comunicação entre brokers. Implantações que precisam de mais capacidade ou disponibilidade do que um único broker fornece dependem de mecanismos específicos de implementação. As duas abordagens comuns são a ponte (bridging), na qual um broker se conecta a outro broker como cliente e encaminha mensagens para tópicos selecionados, e o agrupamento (clustering), no qual um grupo de nós de broker compartilha o estado de inscrição e de sessão e aparece para os clientes como um único broker lógico.

O Eclipse Mosquitto implementa pontes através da configuração do broker. Brokers agrupados (clustered) como EMQX e HiveMQ executam como sistemas de múltiplos nós cujos nós compartilham sessões de clientes, inscrições de tópicos e informações de roteamento. Um estudo de 2020 que comparou implantações distribuídas de três brokers MQTT em um cluster de edge-gateway encontrou diferenças substanciais entre as implementações em termos de vazão (throughput), latência e perda de mensagens durante a falha de um nó.

Limitações

Ver também

• Advanced Message Queuing Protocol (AMQP)
• Apache ActiveMQ
• Comparação de implementações de MQTT
• Constrained Application Protocol (CoAP)
• RabbitMQ
• Solace PubSub+
• Streaming Text Oriented Messaging Protocol (STOMP)

Referências

Ligações externas

• Sítio oficial