Resumo Executivo

11 de maio de 2026

Análise Comparativa entre MQTT e HTTP na Internet das Coisas

Matheus Campos Henrique; Daniele Aparecida Cicillini Pimenta

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

A evolução tecnológica observada nas últimas décadas impulsionou a utilização de dispositivos no contexto da Internet das Coisas, abrangendo desde a automação de residências até o rastreamento de grandes cargas logísticas. A Internet das Coisas define-se como um conjunto de tecnologias combinadas com o propósito de conectar diversos dispositivos, permitindo a troca de dados e informações entre eles, o que possibilita o monitoramento e o controle remoto de objetos do mundo físico (Tsiatsis et al., 2018). No desenvolvimento de projetos voltados a esse ecossistema, a escolha do protocolo de comunicação assume um papel crítico, pois é responsável pela transmissão de dados entre dispositivos e aplicações, impactando diretamente a eficiência, a segurança e a escalabilidade do sistema. Entre as opções mais difundidas, destacam-se o Message Queuing Telemetry Transport e o Hypertext Transfer Protocol.

O protocolo Message Queuing Telemetry Transport foi desenvolvido originalmente em 1999 por Andy Stanford-Clark e Arlen Nipper para monitorar dados de petróleo e gás de forma remota, sendo posteriormente padronizado como código aberto em 2013 pela Organization for the Advancement of Structured Information Standards (MQTT.org, 2024). Ele opera sob um modelo de publicação e assinatura, no qual uma aplicação publica informações em um tópico gerenciado por um intermediário central, denominado broker, enquanto outras aplicações se inscrevem nesses tópicos para receber os dados. Esse modelo assíncrono é fundamental para reduzir o consumo de energia e melhorar a escalabilidade, permitindo que os dispositivos não precisem estar conectados simultaneamente para a troca de informações (Hillar, 2017). Adicionalmente, o protocolo oferece três níveis de Qualidade de Serviço. O nível zero garante o envio único sem confirmação; o nível um assegura a entrega pelo menos uma vez, podendo gerar duplicidade; e o nível dois garante que a mensagem seja entregue exatamente uma vez por meio de um processo de quatro etapas conhecido como handshake (Tandale et al., 2017).

Em contrapartida, o Hypertext Transfer Protocol consolidou-se como o padrão para o desenvolvimento web desde sua publicação por Tim Berners-Lee no início da década de 1990 (W3C, 1991). Embora amplamente empregado em projetos de Internet das Coisas devido à sua compatibilidade com interfaces de programação de aplicações do tipo Representational State Transfer, o protocolo apresenta uma sobrecarga de dados significativa. Cada requisição carrega informações adicionais em seus cabeçalhos, o que demanda um consumo energético mais elevado e maior largura de banda (Totty et al., 2002). Considerando a ampla utilização de ambos os protocolos, persistem dúvidas sobre a eficiência e a aplicabilidade de cada um em cenários específicos de sistemas embarcados, onde os recursos de processamento e energia são limitados. Diante dessa problemática, torna-se essencial realizar uma comparação técnica rigorosa para identificar as vantagens e limitações operacionais de cada solução em aplicações reais.

A metodologia adotada para a análise comparativa baseou-se em uma pesquisa experimental realizada em um ambiente controlado de Internet das Coisas, focada na medição de latência, consumo de energia, uso de largura de banda e escalabilidade (Sanjaya et al., 2024). O hardware central utilizado foi o microcontrolador ESP32, escolhido por sua conectividade Wi-Fi integrada, robustez e ampla adoção na indústria (Espressif Systems, 2025). Para o desenvolvimento do firmware, utilizou-se o ecossistema PlatformIO integrado ao Visual Studio Code, empregando a linguagem C++ e o framework Arduino. A estratégia experimental consistiu em transformar o próprio microcontrolador no nó central da rede, atuando como broker local para o protocolo de publicação e assinatura e como servidor para o protocolo de transferência de hipertexto. Essa abordagem visou eliminar gargalos externos à rede, como a latência de servidores remotos, permitindo uma avaliação direta do desempenho do hardware sob diferentes cargas de trabalho.

Para a implementação do cenário com Message Queuing Telemetry Transport, utilizou-se a biblioteca TinyMqtt para configurar o broker embarcado no ESP32. No lado do cliente, um script em Python foi desenvolvido utilizando a biblioteca paho-mqtt para gerenciar a comunicação e o envio de mensagens (Eclipse Foundation, 2024). Já para o cenário com Hypertext Transfer Protocol, o código embarcado utilizou a biblioteca ESPAsyncWebServer para implementar um servidor capaz de processar requisições do tipo POST (Me-No-Dev, 2024). O envio das informações foi realizado por um script Python utilizando a biblioteca requests (Python Software Foundation, 2024). Em ambos os casos, as mensagens foram padronizadas no formato JavaScript Object Notation, contendo campos específicos para identificação do remetente, identificador da mensagem e um valor numérico. O fluxo de dados consistia no envio de um objeto pelo cliente e na resposta imediata do microcontrolador com uma confirmação de recebimento.

O detalhamento dos testes envolveu quatro cenários distintos. No primeiro, utilizou-se um pacote de dados de tamanho fixo com variação na frequência de envio, adotando intervalos de 1000 ms, 200 ms, 100 ms e 50 ms, mantendo cada teste por 10 segundos. A latência foi calculada pela diferença entre o instante de envio pelo emissor e o instante de recebimento da resposta vinda do microcontrolador. Para monitorar o tráfego de rede e o overhead por mensagem, utilizou-se a ferramenta tcpdump no servidor (The Tcpdump Group, 2025). O segundo cenário manteve um intervalo fixo de uma mensagem por segundo, mas aumentou progressivamente o tamanho do pacote de dados, passando por 128 bytes, 256 bytes, 1024 bytes e 2048 bytes. O terceiro teste focou na escalabilidade, aumentando a quantidade de requisições por segundo de 10 até 100, com incrementos de 10 unidades a cada 10 segundos, visando identificar perdas de mensagens e falhas críticas no sistema.

A medição do consumo de energia foi realizada de forma minuciosa utilizando um multímetro para registrar a corrente consumida pelo microcontrolador durante a operação. O dispositivo foi alimentado por um regulador de 5V constante, permitindo que a potência instantânea fosse calculada pela multiplicação da tensão pela corrente registrada. Durante 30 segundos, enviou-se uma mensagem por segundo, registrando o comportamento da corrente para identificar picos de consumo associados à transmissão de rádio. Embora a utilização do multímetro apresente limitações na captura de picos de curtíssima duração, a metodologia permitiu obter uma média confiável da potência dissipada em cada protocolo. A análise dos dados coletados buscou correlacionar o volume de bytes trafegados com o esforço computacional exigido do hardware, fornecendo uma base quantitativa para a discussão dos resultados.

Os resultados obtidos no teste com carga de dados fixa e variação de intervalo revelaram uma superioridade consistente do Message Queuing Telemetry Transport. Com um intervalo de envio de 1000 ms, a latência média registrada foi de 68.1 ms com um desvio padrão de 32.7 ms, enquanto o Hypertext Transfer Protocol apresentou 85.5 ms de latência e desvio de 29.2 ms. À medida que a frequência de envio aumentou para 50 ms, a latência do primeiro protocolo caiu drasticamente para 11.8 ms, enquanto o segundo atingiu 18.9 ms. Essa redução na latência com o aumento da taxa de envio justifica-se pela manutenção da conexão ativa, eliminando a necessidade de novos processos de handshake para cada mensagem. Em termos de volume de dados, o protocolo de publicação e assinatura trafegou apenas 3058 bytes no intervalo de 1000 ms, comparado aos 9891 bytes exigidos pelo protocolo de transferência de hipertexto. Essa diferença de quase 223% no volume de dados evidencia o alto overhead gerado pelos cabeçalhos das requisições web tradicionais.

No cenário de carga de dados variável com intervalo fixo, observou-se que a latência do Message Queuing Telemetry Transport aumentou conforme o tamanho do pacote crescia, partindo de 75.7 ms para 128 bytes até alcançar 117.6 ms para 2048 bytes. Curiosamente, o Hypertext Transfer Protocol demonstrou maior estabilidade nesse quesito, mantendo-se na faixa de 82.3 ms a 83.3 ms para os mesmos tamanhos de carga. Isso sugere que, para mensagens volumosas, as otimizações internas da pilha de rede para transferências de hipertexto começam a compensar o peso inicial de seus cabeçalhos. No entanto, a quantidade de bytes trafegados permaneceu significativamente maior no protocolo web: para uma carga de 128 bytes, foram transmitidos 12380 bytes, enquanto o protocolo de telemetria exigiu apenas 4580 bytes. À medida que o tamanho da carga aumentou para 2048 bytes, a diferença proporcional diminuiu, com 33988 bytes para o primeiro e 25440 bytes para o segundo, confirmando que o impacto do overhead é mais crítico em mensagens pequenas e frequentes.

A análise de escalabilidade trouxe à tona limitações operacionais severas do microcontrolador quando atuando como servidor web. Durante o teste, ambos os protocolos deveriam processar um total de 2800 mensagens. O Message Queuing Telemetry Transport completou a tarefa com sucesso absoluto, sem qualquer perda de dados. Por outro lado, o Hypertext Transfer Protocol apresentou falhas críticas a partir de 40 requisições por segundo, resultando em apenas 1874 mensagens entregues. O aumento da carga de processamento no microcontrolador disparou o mecanismo de proteção conhecido como watchdog timer, forçando o reinício do dispositivo por não conseguir responder dentro do tempo limite exigido pela vigilância interna do hardware. Esse comportamento demonstra que a complexidade de processar múltiplas requisições simultâneas torna o protocolo de transferência de hipertexto inadequado para cenários de alta densidade de tráfego em dispositivos embarcados de baixo custo.

Quanto ao consumo energético, as medições confirmaram que a eficiência na transmissão de dados reflete diretamente na economia de bateria. Em estado de repouso, com o Wi-Fi ativo mas sem transmissão, o microcontrolador consumiu uma corrente estável de aproximadamente 65 mA. Durante a operação com o protocolo de publicação e assinatura, observaram-se picos de corrente entre 80 mA e 95 mA, resultando em uma potência média de 346.36 mW. No cenário com o protocolo de transferência de hipertexto, a base de corrente foi cerca de 10 mA superior mesmo sem o envio de mensagens, e os picos durante a transmissão atingiram entre 83.1 mA e 116.2 mA, gerando uma potência média de 404.19 mW. A utilização do protocolo web resultou em um consumo médio 57.82 mW superior, o que representa um aumento significativo para dispositivos que dependem de fontes de energia limitadas, como baterias de lítio ou células solares.

A discussão dos resultados permite confirmar o comportamento reportado na literatura técnica, onde se verifica um maior overhead em mensagens pequenas no protocolo de transferência de hipertexto quando comparado ao de telemetria, resultando em maior latência e volume de dados (Yokotani et al., 2016). Embora estudos anteriores tenham reportado valores de latência mais elevados em cenários com servidores remotos, a execução local neste experimento evidenciou que, mesmo sem os atrasos da internet pública, a estrutura do protocolo influencia o desempenho (Tandale et al., 2017). O estudo de Kumar et al. (2020) também corrobora os achados sobre consumo energético, demonstrando graficamente que a simplicidade do modelo de publicação e assinatura favorece a autonomia dos dispositivos. A falha do servidor web embarcado sob carga de 40 requisições por segundo destaca a importância de dimensionar corretamente a arquitetura do sistema, sugerindo que o uso de brokers externos pode ser uma solução para aliviar o processamento do nó final.

Apesar das vantagens claras, o protocolo de transferência de hipertexto não deve ser totalmente descartado, pois sua maturidade e compatibilidade nativa com navegadores e serviços de nuvem facilitam a integração direta com painéis de controle e interfaces de usuário front-end. No entanto, para a comunicação entre máquinas e sensores onde a eficiência é o requisito primordial, o Message Queuing Telemetry Transport estabelece-se como a escolha técnica mais robusta. Os dados coletados fornecem subsídios para que engenheiros de software possam decidir entre a facilidade de integração do padrão web e a performance superior do padrão de telemetria. Limitações metodológicas, como a precisão do multímetro e a carga de processamento de um broker local, devem ser consideradas, mas não invalidam a tendência de superioridade observada nos testes de campo.

Conclui-se que o objetivo foi atingido, demonstrando experimentalmente que o protocolo Message Queuing Telemetry Transport apresenta maior eficiência que o Hypertext Transfer Protocol em aplicações de Internet das Coisas baseadas no microcontrolador ESP32. Os resultados evidenciaram menor latência média, redução drástica no volume de bytes trafegados e um consumo energético significativamente inferior, além de uma capacidade superior de escalabilidade sem comprometer a estabilidade do hardware. Embora o protocolo web ofereça vantagens em termos de compatibilidade e integração com ecossistemas existentes, sua sobrecarga de processamento e dados o torna menos adequado para dispositivos embarcados com restrições de recursos. Os dados técnicos obtidos servem como guia para a seleção de protocolos em projetos que demandem alta frequência de mensagens e autonomia energética, sugerindo que futuras investigações explorem o desempenho desses protocolos em redes de longa distância e com o uso de criptografia.

Referências Bibliográficas:

Eclipse Foundation. 2024. paho-mqtt 2.1.0. Disponível em: <https://pypi.org/project/paho-mqtt/2.1.0/>. Acesso em: 19 ago. 2025.

Espressif Systems. 2025. ESP32-DevKitC V4 Getting Started Guide. Disponível em: <https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32/esp32-devkitc/index.html>. Acesso em: 22 mar. 2025.

Hillar, G.C. 2017. MQTT Essentials – A Lightweight IoT Protocol. Packt Publishing. Birmingham, Inglaterra.

Kumar, N.V.R.; Kumar P.M.; 2020. Survey on State of Art IoT Protocols and Applications. In: 2020 International Conference on Computational Intelligence for Smart Power System and Sustainable Energy (CISPSSE). 2020, Keonjhar, India. Anais… p. 1-3.

Me-No-Dev. 2024. ESPAsyncWebServer – versão 3.3. Disponível em: <https://github.com/me-no-dev/ESPAsyncWebServer>. Acesso em: 19 ago. 2025.

MQTT.org. 2024. FAQ. Disponível em: <https://mqtt.org/faq/>. Acesso em: 25 mai. 2025.

Python Software Foundation. 2024. requests 2.32.3. Disponível em: <https://pypi.org/project/requests/2.32.3/>. Acesso em: 19 ago. 2025.

Sanjaya, R.; Pamudji, A.K.; Vania, E. 2024. Comparative analysis and practical implementation of loT communication using HTTP/2 and MQTT. In: 7th International Conference on Green Technology and Sustainable Development (GTSD), 2024, Ho Chi Minh City, Vietnã. Anais… p. 221-226.

Tandale, U.; Momin, B.; Seetharam, D. P. 2017. An empirical study of application layer protocols for IoT. In: International Conference on Energy, Communication, Data Analytics and Soft Computing (ICECDS). 2017, Chennai, India. Anais… p. 1-2.

The Tcpdump Group. 2025. Tcpdump(1) Man Page. Disponível em: <https://www.tcpdump.org/manpages/tcpdump.1.html>. Acesso em: 22 mar. 2025.

Totty, B.; Gourley, D.; Sayer, M.; Aggarwal, A.; Reddy, S. 2002. HTTP: The definitive guide. O’Reilly Media. Sebastopol, CA, EUA.

Tsiatsis, V.; Karnouskos, S.; Holler, J.; Boyle D.; Mulligan, C. 2018. Internet of Things: Technologies and Applications for a New Age of Intelligence. Academic Press. San Diego, CA, EUA.

World Wide Web Consortium [W3C]. 1991. The Original HTTP as defined in 1991. Disponível em: <https://www.w3.org/Protocols/HTTP/AsImplemented.html>. Acesso em: 25 mai. 2025.

Yokotani, T.; Sasaki, Y.; 2016. Comparison with HTTP and MQTT on Required Network Resources for IoT. In: The 2016 International Conference on Control, Electronics, Renewable Energy and Communications (ICCEREC). 2016, Bandung, Indonesia. Anais… p. 1-6.

Resumo executivo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy

Quem editou este artigo

Mais recentes

Você também pode gostar

Quer ficar por dentro das nossas últimas publicações? Inscreva-se em nossa newsletter!

Receba conteúdos e fique sempre atualizado sobre as novidades em gestão, liderança e carreira com a Revista E&S.

Ao preencher o formulário você está ciente de que podemos enviar comunicações e conteúdos da Revista E&S. Confira nossa Política de Privacidade