O MQTT Usa TCP ou UDP? Camada de Transporte Explicada

O MQTT usa TCP ou UDP? O MQTT roda sobre TCP: diretamente, encapsulado em TLS ou transportado dentro de uma conexão WebSocket, que por sua vez roda sobre TCP. Este artigo explica por que o MQTT depende das garantias do TCP, onde se encaixam variantes baseadas em UDP como o MQTT-SN e o experimental MQTT sobre QUIC, e exatamente quais portas abrir no firewall para um broker na nuvem.

O MQTT usa TCP ou UDP? A resposta curta

As especificações MQTT 3.1.1 e 5.0 exigem um transporte subjacente que entregue um fluxo de bytes ordenado, sem perdas e bidirecional. O TCP/IP oferece exatamente isso, então é o transporte padrão. TLS sobre TCP e WebSocket sobre TCP também se qualificam, porque preservam essas propriedades. O UDP puro não, então o MQTT padrão nunca roda diretamente sobre UDP.

Transporte	Protocolo subjacente	Porta típica	MQTT padrão?
MQTT sobre TCP	TCP	1883	Sim
MQTT sobre TLS	TLS sobre TCP	8883	Sim
MQTT sobre WebSocket	Upgrade HTTP sobre TCP	8083 (`ws`)	Sim
MQTT sobre WebSocket seguro	TLS sobre TCP	8084 (`wss`)	Sim
MQTT-SN	UDP ou outras redes de datagramas	Depende do gateway	Protocolo separado
MQTT sobre QUIC	QUIC sobre UDP	Depende do broker	Não faz parte do padrão OASIS

Onde o MQTT fica na pilha de rede

O MQTT é um protocolo da camada de aplicação. Visualize a pilha de cima para baixo:

Aplicação: o código do seu sensor, painel ou serviço de backend.
MQTT: pacotes CONNECT, PUBLISH, SUBSCRIBE e de confirmação.
Enquadramento WebSocket opcional: usado por navegadores e alguns ambientes com proxy.
TLS opcional: criptografia e autenticação do broker.
TCP: entrega confiável e ordenada, com retransmissão e controle de fluxo.
IP e camada de enlace: Wi-Fi, Ethernet, rede celular.

Como o MQTT fica acima do TCP, ele pode continuar simples. Não precisa de números de sequência próprios para ordenação nem de temporizadores de retransmissão próprios para segmentos perdidos; o TCP cuida disso salto a salto entre cliente e broker.

Por que o MQTT escolheu o TCP

Ordem e integridade

Os pacotes MQTT têm um cabeçalho de tamanho variável e podem ser divididos em vários segmentos TCP. O parser espera que os bytes cheguem completos e em ordem. Com UDP, os pacotes podem chegar fora de ordem, duplicados ou simplesmente não chegar, e o protocolo teria de reinventar a remontagem.

Estado da conexão

O MQTT é orientado a conexão. A troca CONNECT/CONNACK autentica o cliente, e o broker associa a conexão aberta a uma sessão. Keep alive, Last Will e takeover de sessão dependem de uma noção clara de "esta conexão está aberta" ou "esta conexão caiu", que o TCP fornece.

A QoS se apoia em um link confiável

As QoS 1 e 2 acrescentam garantias diante de falhas de conexão e entre cliente e broker, não confiabilidade no nível de pacote. Elas pressupõem que o link é confiável enquanto está ativo e tratam apenas do que acontece quando ele cai. O guia de níveis de QoS do MQTT mostra esses fluxos.

Firewalls e NAT

Conexões TCP iniciadas de saída por um dispositivo são bem compreendidas por roteadores e firewalls. O broker pode enviar mensagens de volta pela mesma conexão, então os dispositivos nunca precisam de uma porta de entrada aberta.

Os custos do TCP

O TCP não é gratuito, e é justo conhecer os prós e contras:

Estabelecimento da conexão: o TCP precisa de um handshake de três vias, e o TLS acrescenta o seu por cima. Dispositivos que acordam, conectam, publicam e dormem pagam isso toda vez.
Bloqueio head-of-line: um segmento perdido atrasa tudo o que vem depois dele na mesma conexão até ser retransmitido.
Memória: uma pilha TCP/IP e uma biblioteca TLS ocupam RAM e flash que os menores microcontroladores não têm.
Timeouts de inatividade: dispositivos NAT descartam mapeamentos TCP ociosos, então o keep alive do MQTT precisa ser menor que esses timeouts.

Para a maioria dos dispositivos Wi-Fi, Ethernet e celulares, esses custos são pequenos em comparação com os benefícios, sobretudo quando as conexões ficam abertas por horas. O guia de latência MQTT mostra como medir o efeito na sua própria rede.

Onde o UDP se encaixa: MQTT-SN

Para dispositivos sem TCP, como nós Zigbee ou sensores em redes de rádio simples, existe o MQTT-SN (MQTT for Sensor Networks). Ele mantém o modelo publish/subscribe, mas usa pacotes compactos, topic IDs numéricos e suporte a clientes em modo sleep, e roda sobre UDP ou outros transportes de datagramas. Os clientes MQTT-SN falam com um gateway, que converte o tráfego deles em MQTT normal sobre TCP para o broker. Leia MQTT-SN explicado para configuração do gateway e topic IDs.

O ponto importante: o MQTT-SN é um protocolo de rede diferente. Um broker padrão só o aceita por meio de um gateway.

E o MQTT sobre QUIC?

O QUIC é um transporte moderno construído sobre UDP que oferece fluxos confiáveis e criptografados, com estabelecimento de conexão mais rápido e menos bloqueio head-of-line do que TCP mais TLS. Alguns fornecedores de brokers já experimentaram transportar MQTT sobre QUIC, o que pode ajudar clientes móveis que trocam de rede com frequência. Até hoje, ele não faz parte do padrão MQTT da OASIS, o suporte das bibliotecas cliente é limitado e não é algo em torno do qual planejar uma frota, a menos que seu broker e suas bibliotecas o suportem explicitamente. Observe que, mesmo aqui, o MQTT fica sobre um fluxo confiável e ordenado; o QUIC apenas fornece esse fluxo sobre UDP.

Quais portas abrir para o seu broker

Como todo transporte MQTT padrão é TCP, as regras de firewall são todas de TCP de saída. Para o servidor MQTT público broker.connectmq.com e os brokers privados do ConnectMQ:

TCP 8883 para dispositivos, gateways e serviços que usam MQTT sobre TLS. É a primeira a solicitar.
TCP 8084 para navegadores e aplicações web que usam WebSocket seguro no caminho /mqtt.
TCP 1883 apenas para testes ou redes isoladas; ela não é criptografada.
TCP 8083 apenas para experimentos locais com WebSocket.
Nenhuma porta UDP é necessária para o MQTT padrão.

Detalhes e solução de problemas em portas MQTT explicadas.

Verifique você mesmo

Você pode confirmar que o MQTT usa TCP com as ferramentas que já tem. Primeiro, verifique a acessibilidade TCP:

nc -vz broker.connectmq.com 8883

Depois, abra uma sessão MQTT sobre TLS no servidor MQTT público (gratuito), pensado para testes, com saída de depuração, que imprime cada pacote MQTT enviado pela conexão TCP:

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i tcp-check-62ab -t "connectmq/demo/62ab/#" -v -d

Enquanto ele roda, liste a conexão em outro terminal:

# Linux
ss -tnp | grep 8883
# macOS
netstat -an -p tcp | grep 8883

Você verá uma conexão TCP ESTABLISHED com a porta 8883 e, a cada intervalo de keep alive, PINGREQ e PINGRESP na saída de depuração. Se capturar o tráfego no Wireshark, os pacotes aparecem como TCP, depois TLS, com o MQTT dentro.

No código, a escolha do transporte é apenas um esquema de URL. No MQTT.js, mqtts://broker.connectmq.com:8883 usa TLS sobre TCP e wss://broker.connectmq.com:8084/mqtt usa WebSocket seguro sobre TCP; o restante do código é idêntico.

const mqtt = require("mqtt");

// Mesma semântica de sessão MQTT, dois transportes baseados em TCP
const url = process.env.USE_WSS
  ? "wss://broker.connectmq.com:8084/mqtt"
  : "mqtts://broker.connectmq.com:8883";

const client = mqtt.connect(url, { clientId: "tcp-js-62ab", protocolVersion: 5 });

client.on("connect", () => {
  console.log("Connected via", url);
  client.publish("connectmq/demo/62ab/transport", url, { qos: 1 }, () => client.end());
});

Considerações para produção

Quando você vai além do servidor MQTT público, a escolha de transporte continua a mesma, mas a segurança fica mais rigorosa: TLS em todo lugar, credenciais únicas por dispositivo e keep alive ajustado à sua rede. Um broker MQTT gerenciado como o ConnectMQ expõe exatamente esses endpoints TCP, com um certificado Let's Encrypt já configurado, então seus dispositivos só precisam de acesso de saída à 8883 (e à 8084 para clientes web). Para um passo a passo completo do protocolo, veja o tutorial de MQTT.

Comece a usar o ConnectMQ

Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, libere a saída TCP 8883 na sua rede e conecte-se com as credenciais geradas. O cliente no navegador do ConnectMQ permite confirmar a conectividade antes de implantar qualquer dispositivo.

Perguntas frequentes