Este artigo tem como objetivo um resumo bibliográfico, em forma de website, do protocolo MQTT para a disciplina de Redes de Computadores I ministrada pelo professor Luís Kowalski na Universidade Federal do Rio de Janeiro. Ao longo das seções serão abordados assuntos inerentes à tecnologia em questão, tal como: História, Objetivo, Propósitos, desenvolvimentos e o projeções futuras. Além disso, será também apresentado aplicações MQTT com a exibição prática de um dispositivo que faz uso do protocolo. Por fim, cabe mencionar que as referências bibliográficas neste artigo estarão dispostas na aba “fontes” do website. O protocolo MQTT configura-se, de forma resumida, em um protocolo de rede voltado para o uso de equipamentos IoT(Internet of things - Internet das Coisas em tradução literal)[1], tendo aplicações desde de o ramo petrolífero - em sensores de temperatura e medição de tanques - até à vida rotineira como em casas inteligentes[2]. Por esses fatores, define-se também como uma tecnologia eficiente e de fácil implementação, visto as características intrínsecas ao desenvolvimento dos Inventos IoT[3] - dispensar os “tecnicismos” e prezar pela flexibilidade. Apesar de ser uma tecnologia considerada antiga - não em termos de tempo em si, mas em razão da constante mudança de eras tecnológicas -, o cerne do protocolo de comunicação continua o mesmo. Contudo, diversas inovações surgiram, sendo a mais significante residindo no fato de sua passagem de software privado para uma técnica open-source, reafirmando e propagando, assim, seu status como um dos padrões na transmissão de dados na Internet das Coisas[3].

O protocolo MQTT(Transporte de Telemetria MQ em tradução livre) foi originalmente projetado para a “IoTzação” – no tangível ao uso de sensores – de equipamentos na indústria de petróleo e gás, mais especificamente no âmbito de monitoramento dos dutos de óleo. Desenvolvido por uma junção de funcionários da IBM(inclusive MQ advém da linha de equipamentos IBM Message Queue Series) e EuroTech, o protocolo em questão foi proposto em 1999 utilizando redes TCP/IP, sendo, mais tarde, aprimorado para utilização de outros como MQTT sobre SSL/TSL e MQTT sobre WebSockets[4]. Posteriormente a sua criação, o sistema passou por significativas mudanças seja pela padronização em dispositivos IoT, seja pelo incremento de novas tecnologias. Quanto esta última, convém pontuar algumas como: Em 2013, a versão 3.1 adicionou diversas especificações no uso de dispositivos sensores; Entre 2014 e 2019, com o aumento da IoTização de equipamentos, diversos softwares e bibliotecas foram desenvolvidos para dar suporte à tecnologia em questão, tendo suporte de várias plataformas e linguagens de programação.

A arquitetura MQTT funciona através do padrão “publisher-subscriber”(publicadores-subscritores) no qual, em linhas gerais, o primeiro é responsável pelo envio da mensagem, ao passo que o segundo recebe. Além disso, esses podem ser quaisquer dispositivos IoT, sensores ou, até mesmo, aplicações – são geralmente conhecidos como clientes. Contudo, antes de adentrar nesses conceitos, convém definir alguns parâmetros de suma importância para o entendimento do protocolo:

• MQTT Broker: configura-se como o ator intermediário entre a comunicação dos publicadores e subscritores, isto é, recebendo o conteúdo e entregando-o.
• Filtro e roteamento de mensagens;
• Controle de Sessões;
• Controle de segurança(Autenticação e Autorização);
• Responsável pela Escalabilidade, integração e monitoramento;
• MQTT CLient: Ao contrário do Broker, o Client atua na ponta das redes como sistemas finais, seja como publishers -- enviando os dados --, seja como subscribers -- recebendo e interpretando as mensagens ou ambos.
• Tópicos: utilizado para categorizar a mensagem – muitas entendido de forma hierárquica –, ou seja, servindo para organizar assuntos do MQTT.

Na imagem acima, o Broker seria responsável por assegurar a comunicação entre o dispositivo IoT com o sistema final, sempre gerenciando a relação entre publicadores e subscritores. Ele faz isso verificando o tópico da mensagem advinda do publisher e encaminhando para o subscriber do mesmo assunto.

Continuamente, o MQTT funciona por intermédio de Pacotes de controles(Control Packet), dos quais são essenciais para a comunicação entre os sistemas finais e o MQTT Broker, visto que carregam o formato da mensagem. Existem diversos tipos de pacotes, cada um voltado a um propósito específico, sendo que os principais são:

• CONNECT: Utilizado pelo cliente para estabelecer a conexão, possuindo informações como o Identificador do Cliente, Opções de Conexão e autenticação.
• CONNACK: Define-se como a respostas a um CONNACK advindo de um cliente. Além disso, sempre retorna um indicador de conexão.
• PUBLISH: Usado para enviar a mensagem de um cliente para o servidor(subscriber), possuindo campos como tópico, nível de QoS.
• PUBACK: Tal como o CONNACK, é a confirmação do processamento de um PUBLISH com QoS 1.
• PUBREC: Confirmação do processamento de um PUBLISH com QoS 2.
• SUBSCRIBE: Utilizado pelo cliente para exigir tópicos, sempre especificando o QoS(default 0).
• SUBACK: Confirmação do processamento de um SUBSCRIBE.

Quality of Service

Outro conceito importante para o entendimento do protocolo MQTT seria os diferentes níveis de Qualidade de Serviços(QoS), que são utilizados para a confiabilidade da entrega. Existem três níveis QoS:

• QoS 0: Sendo o mais básico de todos, utiliza a técnica “Fire and forget”, isto é, a transmissão não possui nenhum tipo de verificação, enviada apenas uma vez. Cabe enfatizar que em caso de desconexão ou falha, o pacote será totalmente perdido.

• QoS 1: Possui uma complexidade maior que o anterior, enviando a mensagem e verificando se essa foi realmente entregue. Ele faz isso por intermédio da espera de um “ACK”(PUBACK) por parte do cliente. Todavia, caso não receba essa confirmação, enviará a mensagem, tendo, dessa forma, duplicado o pacote.

• QoS 2: Sendo o maior nível de Qualidade de Serviços no MQTT, este envia a mensagem uma única vez, porém garante que a mesma será recebida. Ademais, os publishers e broker asseguram a confiabilidade da entrega através do chamado “four-step handshake” que nada mais é do que um par de request-response.

Persistencia em MQTT

Como já visto, o protocolo MQTT se fundamenta nos princípios da arquitetura TCP do qual possui, como principal serviço, a confiabilidade de transmissão. Tendo esse paradigma em questão, o MQTT possui suporte em persistência, garantindo que a mensagem não será perdida em casos de problemas na rede. Tal feito é possível pelo fato do protocolo em tela armazenar as mensagens no servidor até chegarem ao subscriber. Para essa configuração o MQTT possui três tipos de mensagem: Non-Persistent, Queued Persistent e Persistent with acknowledgment. A primeira, estabelece-se como o padrão do protocolo onde todas as mensagens são perdidas em caso de problemas na rede. Já a segunda, a mensagem ficará armazenada no servidor até sua entrega, ou seja, fica contida numa fila até seu “chamamento”. Por fim, a Persistent with acknowledgment possui as mesmas características da segunda, com exceção do fato que aguarda uma confirmação de entrega por parte do subscriber – lembrando bastante a questão do Quality of Service(QoS). Contudo, é justo enfatizar que tal tecnologia deve ser usada conforme a exigência do caso, haja visto que a demanda por processamento e armazenamento crescerão a medida que houverem mais mensagens em persistência.

Estrutura do Pacote

Para o entendimento do protocolo MQTT, é necessário olhar para a estrutura do pacote. Este é composto um cabeçalho fixo(header) de 2 bytes, do qual o primeiro é responsável por caracterizar atributos da mensagem ao lado de flags, ao passo que o segundo carrega a mensagem de fato.

Como é possível ver acima o byte 1 reserva 2 bits para o nível QoS (visto anteriormente), bem como os bits 4-7 para a o tipo da mensagem(descrito na seção Definição). O bit 3 é usado como como uma flag para garantir uma maior confiabilidade de que a mensagem não foi duplicada – daí sua sigla Duplicate Delivery –, caso haja problemas com os ACK(acknowledgment), contudo, só se aplicará à mensagens cujo valor de QoS é diferente de 0 – caso contrário, “fire and forget” desse nível não faria sentido. Desse modo, quando o MQTT Client envia uma mensagem para o MQTT Broker, o DUP será definido para 0, todavia, se o Client não receber o ACK em um dado período de tempo, assumirá que o pacote não foi enviado propriamente para o destinatário final, retransmitindo, assim o mesmo pacote, mas com DUP configurado em 1 (indicando que o pacote tinha sido enviado). Já o campo “RETAIN”(bit 0), é utilizado para o controle de retenção no broker e do comportamento dos subscribers quando conectados a um tópico. Além disso, com esse campo, os clientes podem acessar informações mesmo que eles não estejam conectados no instante da publicação(publish) do pacote. Dessa maneira, quando for “1”, o broker armazenará a mensagem e irá descartar a que estava anteriormente guardada. Por fim, o byte 2 é reservado exclusivamente para o “remaining length”, no qual é, em linhas gerais, utilizado para determinar o tamanho do variable header(cabeçalho variável) – representado pelos primeiros 7 bits – e o payload, otimizando, portanto, o tamanho da mensagem. Tanto o variable header quanto o payload possuem informações adicionais que estão em função dos pacotes de controles mencionados anteriormente, por exemplo, se o cliente enviar uma mensagem para um servidor(PUBLISH), o variable header terá atributos como o identificador da mensagem, enquanto o payload conterá os dados do tópico enviado(published).