MQTT vs CoAP: Pub/Sub sobre TCP vs Requisição/Resposta sobre UDP

MQTT vs CoAP é uma escolha entre dois protocolos criados para o mesmo tipo de hardware, pequenos dispositivos alimentados por bateria em redes com perdas, que ainda assim funcionam de maneiras opostas. O MQTT é publish/subscribe sobre TCP por meio de um broker; o CoAP é requisição/resposta RESTful sobre UDP, diretamente entre os endpoints. Este guia compara transporte, headers, segurança, multicast e fluxo de dados para que você decida qual se encaixa nos seus dispositivos e no seu backend.

A Versão Curta

Se seus dispositivos conseguem manter uma conexão TCP e seus dados precisam chegar a vários consumidores na nuvem, o MQTT com um broker costuma ser o caminho mais simples. Se seus dispositivos ficam em uma rede IPv6 restrita, como 6LoWPAN ou Thread, dormem a maior parte do tempo e são endereçados como pequenos servidores web, o CoAP é a escolha natural. Muitas implantações de grande porte usam CoAP na rede local restrita e MQTT de um gateway até a nuvem.

Como o CoAP Funciona

O CoAP (Constrained Application Protocol, RFC 7252) leva o modelo REST para microcontroladores. Cada dispositivo expõe recursos como /sensors/temp, e os clients usam GET, POST, PUT e DELETE neles, como no HTTP, mas em um formato binário compacto sobre UDP. As respostas trazem códigos inspirados nos status codes do HTTP, por exemplo 2.05 Content ou 4.04 Not Found.

Como o UDP não garante entrega, o CoAP adiciona sua própria confiabilidade leve: uma mensagem pode ser Confirmable (CON), que o receptor precisa confirmar, ou Non-confirmable (NON), do tipo "dispare e esqueça". As retransmissões usam backoff exponencial.

O CoAP também tem a opção Observe (RFC 7641). Um client registra interesse em um recurso e o servidor envia uma notificação sempre que ele muda. É o mais próximo que o CoAP tem do subscribe do MQTT, mas é ponto a ponto entre um client e um único servidor.

Como o MQTT Funciona

Clients MQTT abrem uma conexão TCP (opcionalmente com TLS) com um broker e então publicam mensagens em topics e assinam filtros de topic. Os dispositivos nunca falam diretamente entre si; o broker cuida do fan-out, dos últimos valores conhecidos retidos, das sessões persistentes para assinantes offline e das mensagens de Last Will para desconexões abruptas. Se o conceito de broker é novo para você, comece por o que é um broker MQTT e, para uma introdução passo a passo, veja o tutorial de MQTT.

MQTT vs CoAP em Resumo

Transporte: TCP vs UDP

O transporte é a raiz da maioria das diferenças. O TCP dá ao MQTT fluxos de bytes ordenados e confiáveis, mas custa um handshake de três vias para conectar e mantém estado nas duas pontas. Em um link de rádio com perdas, retransmissões TCP e bloqueio head-of-line podem aumentar a latência. Para saber mais sobre a questão do transporte, veja o MQTT usa TCP ou UDP.

O UDP permite que o CoAP envie uma leitura em um único datagrama, sem estabelecer conexão, o que combina com dispositivos que acordam por instantes, transmitem e voltam a dormir. O preço é que a aplicação, no caso o CoAP, precisa cuidar sozinha de confiabilidade, deduplicação e controle de congestionamento, e que dispositivos atrás de NAT ficam difíceis de alcançar porque os mapeamentos UDP expiram rapidamente.

Tamanho do Header e Overhead

Os dois protocolos são compactos. Um PUBLISH do MQTT pode ser muito pequeno, mas a string do topic viaja em toda mensagem, a menos que você use topic aliases do MQTT 5. O CoAP usa um header de 4 bytes, um token curto e opções codificadas como deltas, então o caminho da URI também é compacto. Na prática, o overhead por mensagem fica na mesma faixa pequena para ambos; a diferença maior está no overhead de conexão (TCP e TLS no MQTT versus nenhum ou DTLS no CoAP).

Segurança: TLS vs DTLS

O MQTT usa TLS sobre TCP, a mesma pilha bem conhecida que protege o HTTPS, com suporte maduro em SDKs de dispositivos, gateways e brokers em nuvem. Um broker MQTT gerenciado normalmente cuida dos certificados para você; o ConnectMQ, por exemplo, serve um certificado Let's Encrypt na porta 8883 para TLS e na 8084 para WebSocket seguro.

O CoAP usa DTLS, a versão para datagramas do TLS. Funciona, mas o estado de sessão, a retransmissão do handshake em links com perdas e o rebinding de NAT adicionam complexidade, e as ferramentas são menos difundidas. O OSCORE (RFC 8613) oferece segurança de objeto fim a fim que sobrevive a proxies, o que é atraente em redes restritas com múltiplos saltos, mas adiciona seu próprio gerenciamento de chaves.

Para qualquer um dos protocolos, a regra prática é a mesma: criptografe todo salto que sai do dispositivo e nunca dependa apenas do isolamento de rede. O guia de boas práticas de segurança MQTT aborda credenciais, TLS e design de topics em implantações MQTT.

Observe vs Subscribe

O Observe do CoAP e o subscribe do MQTT entregam atualizações sem polling, mas a topologia é diferente. Com o Observe, cada client interessado se registra no próprio dispositivo. Dez dashboards significam dez observadores em um microcontrolador que pode ter apenas kilobytes de RAM. Com o MQTT, o dispositivo publica uma vez no broker e o broker atende qualquer número de assinantes. É por isso que o MQTT escala melhor quando os dados têm muitos consumidores, enquanto o CoAP funciona bem quando um controlador conversa com muitos dispositivos pequenos.

Multicast e Descoberta Local

Esta é a vantagem clara do CoAP. Um client pode enviar uma única requisição para um grupo IP multicast, por exemplo para apagar todas as luzes de um andar, e todos os membros respondem. Combinado com a descoberta de recursos em /.well-known/core, isso torna o CoAP adequado para redes locais de automação predial e residencial, em que os dispositivos se encontram sem um servidor central. O MQTT não tem multicast; toda mensagem passa pelo broker.

Um Padrão Híbrido Comum

Redes em malha restritas e a nuvem têm necessidades diferentes, por isso muitos sistemas colocam um gateway entre elas:

1. Sensores em uma malha Thread ou 6LoWPAN expõem recursos CoAP.
2. Um gateway de borda observa esses recursos ou recebe POSTs CoAP.
3. O gateway publica cada atualização via MQTT com TLS em um broker MQTT na nuvem, por exemplo em site1/floor2/room14/temperature.
4. Dashboards, historiadores e serviços de alerta assinam o broker.

Aqui está o lado de nuvem desse gateway em Python. O tratamento do CoAP depende da sua biblioteca, então ele é representado por uma função que recebe uma leitura; a parte MQTT está completa.

import json
import ssl
import time
import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.will_set("site1/gateway1/status", "offline", qos=1, retain=True)

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.publish("site1/gateway1/status", "online", qos=1, retain=True)

client.on_connect = on_connect
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_start()

def forward_coap_reading(resource_path, value):
    """Chame isto a partir do seu callback de observe do CoAP."""
    topic = "site1/" + resource_path.strip("/").replace("sensors/", "")
    payload = json.dumps({"value": value, "ts": int(time.time())})
    client.publish(topic, payload, qos=1, retain=True)

# Exemplo: uma leitura observada em coap://[fd00::12]/sensors/floor2/room14/temperature
forward_coap_reading("/sensors/floor2/room14/temperature", 21.6)
time.sleep(2)

Para experimentar sem uma conta, troque a conexão por client.connect("broker.connectmq.com", 1883) com qualquer client ID único e um prefixo de topic como connectmq/demo/<random-id>/, mas lembre-se de que o servidor MQTT público (gratuito) pode ser lido por todos e serve apenas para testes.

Quando Escolher Cada Um

Escolha MQTT quando:

• Os dispositivos estão em Wi-Fi, Ethernet ou rede celular e conseguem manter uma conexão TCP de saída.
• Os dados precisam chegar a vários consumidores na nuvem.
• Você quer estado retido, status online via Last Will e buffer para assinantes offline.
• Você prefere bibliotecas client maduras e amplamente disponíveis e hospedagem gerenciada.

Escolha CoAP quando:

• Os dispositivos rodam em malhas IPv6 restritas, com RAM e energia muito limitadas.
• Você precisa de comandos multicast ou descoberta local sem servidor central.
• A interação é naturalmente de requisição/resposta, como ler ou alterar uma configuração do dispositivo.

Se o seu projeto está mais próximo do lado do MQTT, mas os dispositivos são extremamente restritos ou não usam TCP, veja também o MQTT-SN, que leva a semântica do MQTT para UDP e outros transportes de datagramas.

Comece com o ConnectMQ

Quer seus dispositivos falem MQTT nativamente ou por meio de um gateway CoAP, o lado da nuvem precisa de um broker confiável. O ConnectMQ é um broker MQTT gerenciado com MQTT 3.1.1 e 5.0, TLS na 8883 e um explorador de topics ao vivo para conferir cada gateway assim que ele fica online. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e conecte seu primeiro gateway em minutos.

Perguntas frequentes

O CoAP é melhor que o MQTT para dispositivos a bateria?

Pode ser, para dispositivos que acordam raramente e enviam um único datagrama, porque o UDP evita o estabelecimento de conexão. Para dispositivos que reportam com frequência ou precisam receber comandos, a conexão persistente do MQTT costuma ser igualmente eficiente e mais simples de operar.

O CoAP precisa de um broker?

Não. Clients CoAP falam diretamente com os endpoints dos dispositivos. Proxies podem adicionar cache e tradução de protocolo, mas não existe um broker central como no MQTT.

CoAP e MQTT podem trabalhar juntos?

Sim. É comum um gateway observar recursos CoAP em uma malha local e publicar os valores em um broker MQTT na nuvem, combinando eficiência local com fan-out na nuvem.

O MQTT suporta UDP?

O MQTT padrão roda sobre TCP ou WebSocket. O MQTT-SN é um protocolo relacionado, projetado para UDP e outras redes de datagramas, normalmente conectado a um broker MQTT comum por meio de um gateway.