MQTT

Arquitetura do MQTT

O MQTT é executado sobre o TCP/IP usando uma topologia PUSH/SUBSCRIBE. Na arquitetura MQTT, há dois tipos de sistemas: clientes e corretores. Um intermediário é o servidor com o qual os clientes se comunicam. O intermediário recebe as comunicações dos clientes e as envia a outros clientes. Os clientes não se comunicam diretamente uns com os outros, mas se conectam ao intermediário. Cada cliente pode ser um editor, um assinante ou ambos.

O MQTT é um protocolo orientado por eventos. Não há transmissão de dados periódica ou contínua. Isso mantém a transmissão em um nível mínimo. Um cliente só publica quando há informações a serem enviadas, e um intermediário só envia informações aos assinantes quando chegam novos dados.

Arquitetura da mensagem

Outra maneira pela qual o MQTT minimiza suas transmissões é com uma construção de mensagens pequenas e bem definidas. Cada mensagem tem um cabeçalho fixo de apenas 2 bytes. Um cabeçalho opcional pode ser usado, mas aumenta o tamanho da mensagem. A carga útil da mensagem é limitada a apenas 256 MB. Três níveis diferentes de Qualidade de Serviço (QoS) permitem que os projetistas de rede escolham entre minimizar a transmissão de dados e maximizar a confiabilidade.

• QoS 0 - Oferece a quantidade mínima de transmissão de dados. Com esse nível, cada mensagem é entregue a um assinante uma vez, sem confirmação. Não há como saber se os assinantes receberam a mensagem. Esse método às vezes é chamado de "dispare e esqueça" ou "entrega no máximo uma vez" Como esse nível pressupõe que a entrega foi concluída, as mensagens não são armazenadas para entrega a clientes desconectados que se reconectam posteriormente.
• QoS 1 - O broker tenta entregar a mensagem e aguarda uma resposta de confirmação do assinante. Se uma confirmação não for recebida em um período de tempo especificado, a mensagem será enviada novamente. Usando esse método, o assinante pode receber a mensagem mais de uma vez se o intermediário não receber a confirmação do assinante a tempo. Isso às vezes é chamado de "entrega pelo menos uma vez".
• QoS 2 - O cliente e o intermediário usam um handshake de quatro etapas para garantir que a mensagem seja recebida e que seja recebida apenas uma vez. Isso às vezes é chamado de "entrega exatamente uma vez".
  
  

Para situações em que as comunicações são confiáveis, mas limitadas, a QoS 0 pode ser a melhor opção. Para situações em que as comunicações não são confiáveis, mas em que as conexões não são tão limitadas em termos de recursos, a QoS 2 seria a melhor opção. A QoS 1 oferece uma espécie de solução do melhor dos dois mundos, mas exige que o aplicativo que recebe os dados saiba como lidar com duplicatas.

Tanto na QoS 1 quanto na QoS 2, as mensagens são salvas ou enfileiradas para clientes que estão off-line e que têm uma sessão persistente estabelecida. Essas mensagens são reenviadas (de acordo com o nível de QoS apropriado) quando o cliente volta a ficar on-line.

Tópicos

As mensagens no MQTT são publicadas como tópicos. Os tópicos são estruturas em uma hierarquia usando o caractere de barra (/) como delimitador. Essa estrutura se assemelha à de uma árvore de diretórios em um sistema de arquivos de computador. Uma estrutura como sensors/OilandGas/Pressure/ permite que um assinante especifique que só devem ser enviados dados de clientes que publicam no tópico Pressure ou, para uma visão mais ampla, talvez todos os dados de clientes que publicam em qualquer tópico sensors/OilandGas. Os tópicos não são criados explicitamente no MQTT. Se um corretor receber dados publicados em um tópico que não existe no momento, o tópico é simplesmente criado e os clientes podem se inscrever no novo tópico.

Mensagens retidas

Para manter a área de cobertura pequena, as mensagens recebidas não são armazenadas no broker, a menos que estejam marcadas com o sinalizador retido. Isso é chamado de mensagem retida. Os usuários que desejarem armazenar as mensagens recebidas precisarão armazená-las em outro lugar fora do protocolo MQTT. Há uma exceção.

Como um protocolo orientado por eventos, é possível, até mesmo provável, que um assinante receba muito poucas mensagens de um determinado tópico, mesmo durante um longo período de tempo. Na estrutura de tópicos mencionada anteriormente, talvez as mensagens para o tópico Pressão sejam enviadas somente quando um sensor detectar que a pressão excedeu um determinado valor. Supondo que o sensor que está monitorando não falhe com frequência, pode levar meses ou até anos para que um cliente publique uma mensagem nesse tópico.

Para garantir que um novo assinante receba as mensagens de um tópico, os corretores podem manter a última mensagem enviada a cada tópico. Isso é chamado de mensagem retida. Sempre que um novo cliente se inscreve em um tópico ou quando um cliente existente volta a ficar on-line, a mensagem retida é enviada aos assinantes, garantindo assim que a assinatura esteja ativa e que tenha as informações mais recentes.

Última vontade e testamento

Quando as comunicações não são confiáveis, é possível que um editor se desconecte da rede sem aviso. Um editor pode registrar uma mensagem a ser enviada aos assinantes caso ele se desconecte inesperadamente, o que é chamado de testamento. Essa mensagem é armazenada em cache no broker e enviada aos assinantes caso o editor se desconecte indevidamente. Normalmente, essa mensagem inclui informações que permitem que o editor desconectado seja identificado para que as ações apropriadas possam ser tomadas.

Mensagens MQTT

Para manter o protocolo pequeno, há apenas quatro ações possíveis em qualquer comunicação: publicar, assinar, cancelar a assinatura ou pingar.

• Publicar - Envia um bloco de dados que contém a mensagem a ser enviada. Esses dados são específicos de cada implementação, mas podem ser algo tão simples quanto uma indicação de ligado/desligado ou um valor de um determinado sensor, como temperatura, pressão etc. Caso o tópico que está sendo publicado não exista, o tópico é criado no agente.
• Assinar - Transforma um cliente em assinante de um tópico. Os tópicos podem ser assinados especificamente ou por meio de curingas que permitem assinaturas em um ramo inteiro de tópicos ou em parte de qualquer ramo de tópicos. Para se inscrever, o cliente envia um pacote SUBSCRIBE e recebe um pacote SUBACK em troca. Se houver uma mensagem retida para o tópico, o novo assinante também receberá essa mensagem.
• PING - Um cliente pode pingar o corretor. Um pacote PINGREQ é enviado pelo assinante e um pacote PINGRESP é enviado como resposta. Os pings podem ser usados para garantir que a conexão ainda esteja funcionando e que a sessão TCP não tenha sido fechada inesperadamente por outro equipamento de rede, como um roteador ou gateway.
• DESCONEXÃO - Um assinante ou editor pode enviar uma mensagem de DESCONEXÃO para o agente. Essa mensagem informa ao agente que ele não precisará mais enviar ou enfileirar mensagens para um assinante e que não receberá mais dados de um editor. Esse tipo de desligamento permite que o cliente se reconecte usando a mesma identidade de cliente anterior. Quando um cliente se desconecta sem enviar uma mensagem de desconexão, sua última vontade e testamento são enviados aos assinantes

Segurança

O objetivo original do protocolo MQTT era fazer a menor e mais eficiente transmissão de dados possível por meio de linhas de comunicação caras e não confiáveis. Dessa forma, a segurança não foi uma preocupação principal durante o projeto e a implementação do MQTT.

Entretanto, há algumas opções de segurança disponíveis ao custo de mais transmissão de dados e de um espaço maior.

• Segurança da rede - Se a própria rede puder ser protegida, a transmissão de dados MQTT inseguros será irrelevante. Nesse caso, os problemas de segurança teriam que ocorrer de dentro da própria rede, talvez por meio de um agente mal-intencionado ou outra forma de penetração na rede.
• Nome de usuário e senha - o MQTT permite nomes de usuário e senhas para que um cliente estabeleça uma conexão com um broker. Infelizmente, para manter a sobrecarga leve, os nomes de usuário e as senhas são transmitidos em texto claro. Em 1999, isso era mais do que suficiente porque interceptar uma comunicação via satélite para o que era essencialmente uma leitura de sensor sem importância teria sido proibitivamente difícil. No entanto, hoje em dia, a interceptação de muitos tipos de comunicações de rede sem fio é trivial, o que torna essa autenticação praticamente inútil.
  Muitos casos de uso exigem um nome de usuário e uma senha não como proteção contra agentes de má-fé, mas como uma forma de evitar conexões não intencionais.
• SSL/TLS - Executada sobre o TCP/IP, a solução óbvia para proteger as transmissões entre clientes e corretores é a implementação do SSL/TLS. Infelizmente, isso adiciona uma sobrecarga substancial às comunicações que, de outra forma, seriam leves.