Consumo de Banda MQTT: Calculando o Overhead por Mensagem

O consumo de banda MQTT é fácil de estimar quando você sabe de onde vem cada byte: o próprio pacote MQTT, os cabeçalhos TCP/IP que o transportam, a criptografia TLS em volta dele e o tráfego de fundo de conexões e keep alives. Este guia calcula cada camada para uma mensagem de telemetria realista em QoS 0, 1 e 2 e depois transforma os números em uma estimativa mensal de dados que você pode usar ao escolher um plano de dados móveis para os seus dispositivos, seja em sensores de uma fazenda no Mato Grosso ou em medidores de uma rede de saneamento.

Por Que o MQTT É Leve, e Para Onde os Bytes Ainda Vão

O fixed header do MQTT pode ter apenas dois bytes, não há cabeçalhos de texto como no HTTP e uma única conexão de longa duração substitui um handshake por requisição. Isso torna o overhead do protocolo por mensagem minúsculo. Mas, em um link tarifado, você paga por bytes IP, não por bytes MQTT, e com payloads pequenos as camadas inferiores dominam. Um modelo mental útil tem quatro camadas:

Há ainda dois custos de fundo que não são por mensagem: o estabelecimento da conexão (TCP, handshake TLS, CONNECT) e os pings de keep alive enquanto a conexão está ociosa. Ambos são tratados abaixo. Para o layout em nível de byte da camada MQTT, veja o guia sobre a estrutura de pacotes MQTT.

Overhead MQTT por Mensagem e por QoS

Vamos a um exemplo típico: MQTT 3.1.1, topic plant1/line2/pump3/telemetry (28 caracteres) e um payload JSON de 48 bytes como {"t":1760601600,"flow":12.4,"p":3.1,"temp":41.7}.

O pacote PUBLISH em QoS 0 fica assim:

• Fixed header: 2 bytes (tipo e flags, um byte de remaining length)
• Topic: prefixo de tamanho de 2 bytes + 28 bytes = 30 bytes
• Payload: 48 bytes
• Total: 80 bytes

Em QoS 1 e 2, o PUBLISH ganha um packet identifier de 2 bytes, e são adicionados pacotes de confirmação de 4 bytes cada:

Com MQTT 5, some um byte para o tamanho de properties vazio no PUBLISH; confirmações de sucesso sem properties continuam com 4 bytes. Na camada MQTT, portanto, a escolha do QoS altera o custo apenas modestamente. A diferença real aparece na camada de transporte, porque cada pacote extra normalmente significa um segmento TCP extra. O guia de níveis de QoS MQTT explica quando as garantias extras de entrega compensam.

O Nome do Topic Costuma Ser o Maior Custo MQTT

No exemplo acima, o topic representa 30 dos 32 bytes de overhead em QoS 0. Topics profundos no estilo ISA-95 passam facilmente de 50 caracteres. Há dois remédios: manter os topics do lado do dispositivo concisos ou usar topic aliases do MQTT 5, que substituem o topic por um número de 2 bytes depois do primeiro publish. O guia de topic alias MQTT mostra a economia em detalhes.

Somando TCP/IP e TLS

Cada pacote MQTT enviado sozinho viaja em um segmento TCP com pelo menos 40 bytes de cabeçalhos IPv4 e TCP. O receptor confirma os dados com ACKs TCP, que também são segmentos de 40 bytes, a menos que possam pegar carona em dados que fluem no sentido oposto. O comportamento de delayed ACK varia conforme o sistema operacional e a pilha de rede, então trate os custos de ACK como aproximados.

O TLS envolve cada escrita em um registro. Com TLS 1.3 e uma cifra AES-GCM, cada registro adiciona 5 bytes de cabeçalho, 1 byte de tipo de conteúdo interno e uma tag de autenticação de 16 bytes: 22 bytes. O TLS 1.2 com AES-GCM adiciona 29 bytes, por causa de um nonce explícito de 8 bytes.

Juntando tudo para uma mensagem de telemetria, com IPv4 sem opções TCP, TLS 1.3 e contando um ACK TCP puro por segmento de dados:

Para um payload de 48 bytes, o custo na rede é de aproximadamente quatro a oito vezes os dados. Essa proporção diminui à medida que os payloads crescem: um payload de 1 KB tem praticamente o mesmo overhead absoluto, que passa a ser uma fração pequena. É por isso que agrupar leituras, por exemplo uma mensagem com dez amostras em vez de dez mensagens, é a otimização de banda mais eficaz de todas.

O TLS não é opcional em implantações reais e, como a tabela mostra, seu custo por mensagem é modesto. O custo maior dele está no handshake.

Custos de Estabelecimento de Conexão

Cada nova conexão paga por:

1. Handshake TCP: três segmentos, aproximadamente 120 a 180 bytes.
2. Handshake TLS: normalmente alguns kilobytes, a maior parte da cadeia de certificados do servidor. A retomada de sessão do TLS 1.3, quando a sua biblioteca a suporta, reduz isso substancialmente.
3. CONNECT e CONNACK: um CONNECT com client ID de 20 caracteres, usuário e senha tem cerca de 80 bytes; o CONNACK tem 4 bytes no MQTT 3.1.1.
4. SUBSCRIBE e SUBACK para cada assinatura, se você não usa sessão persistente.

Assim, uma única reconexão pode custar tanto quanto dezenas de mensagens de telemetria. Dispositivos que conectam, publicam uma vez e desconectam a cada minuto desperdiçam a maior parte dos dados em handshakes. A menos que o dispositivo durma por longos períodos, mantenha a conexão aberta e use uma sessão persistente para não precisar assinar de novo após cada reconexão. O guia de sessão persistente explica como.

Custos do Keep Alive

Quando um cliente não tem nada para enviar durante o intervalo de keep alive, ele envia PINGREQ (2 bytes) e o broker responde com PINGRESP (2 bytes). Com TLS 1.3 e TCP/IP, uma troca de ping custa cerca de 64 + 64 bytes, mais um ACK: aproximadamente 170 bytes.

Os pings só são enviados quando a conexão está ociosa, então um dispositivo que publica a cada 30 segundos com keep alive de 60 segundos não envia nenhum ping. Intervalos mais longos economizam dados, mas arriscam timeouts de NAT em redes celulares, que derrubam conexões ociosas e forçam uma reconexão cara. Ajuste o valor com as orientações do artigo sobre o intervalo de keep alive MQTT.

Estimando os Dados Mensais de um Dispositivo Celular

Esta calculadora em Python junta as peças. Ajuste as entradas para o seu dispositivo:

def mqtt_monthly_bytes(
    payload=48, topic_len=28, qos=1, msgs_per_day=1440,
    tls=True, reconnects_per_day=2, handshake_bytes=5000,
    keepalive_s=120, idle_seconds_per_day=0,
):
    ip_tcp = 40
    tls_rec = 22 if tls else 0
    publish = 2 + 2 + topic_len + payload + (2 if qos else 0)

    def seg(mqtt_bytes):
        return mqtt_bytes + tls_rec + ip_tcp

    if qos == 0:
        per_msg = seg(publish) + ip_tcp
    elif qos == 1:
        per_msg = seg(publish) + seg(4) + ip_tcp
    else:
        per_msg = seg(publish) + 3 * seg(4) + 2 * ip_tcp

    pings = idle_seconds_per_day / keepalive_s if keepalive_s else 0
    ping_bytes = pings * (2 * seg(2) + ip_tcp)
    connect_bytes = reconnects_per_day * (handshake_bytes if tls else 300)

    per_day = msgs_per_day * per_msg + ping_bytes + connect_bytes
    return per_day * 30

for qos in (0, 1, 2):
    mb = mqtt_monthly_bytes(qos=qos) / 1_000_000
    print(f"QoS {qos}: {mb:.1f} MB per month")

Com uma mensagem por minuto em QoS 1 sobre TLS, o resultado fica em torno de 11 MB por mês por dispositivo, com apenas uma pequena parte vindo das duas reconexões assumidas. Altere msgs_per_day para 144 (a cada dez minutos), com keep alive de 300 segundos e o tempo ocioso incluído, e o total cai bastante. Essas são estimativas calculadas, não medições; valide-as verificando o consumo real em um SIM de teste ou capturando o tráfego por um dia com tcpdump e somando os bytes.

Checklist para Reduzir o Consumo de Banda

1. Agrupe amostras em menos mensagens, porém maiores, quando a latência permitir.
2. Use payloads compactos: chaves JSON curtas, CBOR ou Protobuf. Veja formato de payload MQTT.
3. Encurte os topics dos dispositivos ou use topic aliases com MQTT 5.
4. Escolha o QoS por topic: QoS 0 para telemetria frequente em que uma perda ocasional é aceitável, QoS 1 para eventos e comandos.
5. Mantenha as conexões abertas e use sessões persistentes em vez de reconectar a cada mensagem.
6. Ajuste o keep alive para o maior valor que o timeout de NAT da sua rede permitir.
7. Publique na mudança em vez de a uma taxa fixa quando os valores estiverem estáveis.
8. Evite assinaturas desnecessárias: uma assinatura com wildcard em um dispositivo recebe todas as mensagens correspondentes, o que consome dados de downlink.

Rode Dispositivos Eficientes na ConnectMQ

A ConnectMQ suporta MQTT 3.1.1 e 5.0, incluindo topic aliases e session expiry, sobre TLS na porta 8883 com certificado Let's Encrypt, então as otimizações acima funcionam sem configuração especial. Faça o protótipo no servidor MQTT público (gratuito), que serve para testes e não para dados de produção, e depois meça o tráfego real em um broker privado. O tutorial de MQTT cobre os fundamentos se você é novo no protocolo.

Comece com a ConnectMQ

Um broker MQTT gerenciado permite que você se concentre na eficiência dos dispositivos em vez da operação de servidores. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e use o explorador de topics ao vivo para ver exatamente o que os seus dispositivos enviam. Para uma comparação mais ampla, leia nosso guia sobre como escolher um broker MQTT na nuvem.

Perguntas frequentes

Quanto overhead o MQTT adiciona por mensagem?

Na camada MQTT, um PUBLISH adiciona 4 bytes mais o nome do topic em QoS 0, e 6 bytes mais o topic em QoS 1 e 2, antes das confirmações. TCP/IP e TLS somam aproximadamente 60 bytes ou mais por pacote.

O TLS deixa o MQTT muito mais caro?

Por mensagem, o TLS 1.3 adiciona cerca de 22 bytes por registro, o que é modesto. O custo maior é o handshake de alguns kilobytes a cada nova conexão, então mantenha as conexões abertas em vez de reconectar com frequência.

Quantos dados o keep alive do MQTT consome?

Uma troca de ping custa poucos bytes na camada MQTT, mas cerca de 170 bytes com TCP, IP e TLS. Com intervalo de 60 segundos em uma conexão ociosa, isso dá aproximadamente 240 KB por dia.

O QoS 0 é sempre o mais barato?

Sim, em bytes, porque não envia pacotes de confirmação. Mas, se mensagens perdidas obrigarem sua aplicação a reenviar dados ou fazer polling, o QoS 1 pode acabar saindo mais barato no total.