# SMPP ou HTTP: qual conexão encaixa

O SMPP mantém uma sessão persistente com uma janela de taxa por bind; o HTTP autentica cada requisição e recebe eventos em um callback. Os dois transportam as mesmas mensagens e informam os mesmos estados de entrega. Escolha pela forma do tráfego e pelas falhas que a sua equipe sabe operar.

- O SMPP mantém uma sessão aberta e carrega uma janela de requisições em voo por bind.

- O HTTP inicia uma requisição autenticada por envio e usa um callback para os recibos.

- Os dois modelos devolvem os mesmos estados de entrega; o transporte muda como eles chegam.

- As falhas diferem: janela de bind cheia no SMPP, callback lento no HTTP.

## A decisão em um parágrafo

Comece com HTTP se o volume é baixo, o tráfego vai em rajadas e a equipe já opera endpoints web. Passe para SMPP quando o tráfego é um fluxo constante, quando a autenticação e o estabelecimento de conexão por requisição têm um custo visível, ou quando os recibos precisam chegar pela mesma sessão transceiver dos envios. Muitas plataformas usam os dois: SMPP para o fluxo de envio e HTTP para os callbacks de entrada.
O protocolo não é o produto. A rota, o registro do remetente e os testes em celulares decidem se a mensagem chega. SMPP e HTTP são duas formas de alcançar a mesma central de mensagens, e qualquer uma pode ser bem ou mal operada.
A pergunta certa não é qual protocolo é mais novo. É qual falha a sua equipe consegue ver e corrigir na velocidade que o tráfego produz. Um bind silencioso às duas da manhã e um callback falhando às duas da manhã são problemas operacionais. Escolha o que as suas ferramentas sabem diagnosticar.

### O mesmo trabalho, dois formatos

|  | SMPP | HTTP |
| --- | --- | --- |
| Sessão | Bind autenticado mantido aberto | Chave enviada em cada requisição |
| Janela | Janela fixa de requisições em voo por bind | Concorrência definida pelo cliente e pelo pool |
| Recibo de entrega | PDU deliver_sm em um bind transceiver (ou um receiver separado) | Callback para o seu endpoint |
| Mensagem recebida | deliver_sm em um bind receiver ou transceiver | Callback para o seu endpoint |
| Retentativa | O cliente gerencia a janela e o backoff | O cliente repete a requisição; o provedor repete o callback |

A tabela descreve o transporte, não a implementação de um provedor. Confirme os detalhes no onboarding.

## A taxa segue o formato

Um bind SMPP é provisionado com uma taxa e uma janela. Com a sessão aberta, um envio custa uma PDU e uma resposta, sem novo handshake. Isso torna o SMPP eficiente para um fluxo sustentado e previsível para planejar capacidade: conte os binds, leia a alocação e mantenha as requisições em voo abaixo da janela.
O HTTP paga autenticação e estabelecimento de conexão em cada requisição, embora a reutilização de conexões reduza o custo. A capacidade vem da concorrência, não de uma janela de bind, então o cliente pode disparar uma rajada e depois bater em um limite de taxa ou em uma fila. Essa flexibilidade combina com campanhas e aplicações de baixo volume; também torna o pico mais difícil de raciocinar se o cliente não limita a concorrência. Um limite de taxa e uma janela são controles diferentes: um limita requisições por segundo, o outro requisições em voo. O custo por requisição aparece em volume alto, não com alguns milhares de mensagens por dia.

Mude a taxa e a janela; o planejador roda no navegador.

[Open the tool](/pt/tools/tps-planner/?src=learn-smpp-vs-http&scenario=campaign-50tps&tps=50&windowMin=60)

## Recibos e entrada decidem a integração

O SMPP entrega recibos e mensagens recebidas por um bind receiver ou transceiver. O cliente precisa manter a sessão viva para recebê-los, parear cada recibo com o message ID guardado e responder com deliver_sm_resp. Não há um endpoint de callback para proteger, mas há uma sessão para monitorar: um bind aberto e silencioso é um modo de falha.
O HTTP entrega recibos e mensagens recebidas em uma URL. O receptor verifica a assinatura, responde rápido e processa o evento de forma assíncrona. Um callback lento é a falha comum: o provedor expira o tempo, repete, e o mesmo evento é processado duas vezes. Chaves de idempotência e uma confirmação rápida fazem parte da integração, não são uma otimização.
Seja qual for o caminho do recibo, guarde o payload original. A interpretação do provedor pode mudar, e um caso de suporte muitas vezes depende do estado ou do código de erro original. Guarde-o com o message ID, a rota e a hora.

### Modos de falha para projetar

| Falha | Como aparece | O que fazer |
| --- | --- | --- |
| Janela de bind cheia | Timeouts e retentativas sobem juntos; a fila cresce | Pare de repetir, deixe a janela esvaziar, adicione um bind |
| Sessão silenciosa | O bind está aberto mas nenhuma resposta chega | Envie enquire_link, expire a sessão, reconecte com backoff |
| Recibo mal pareado | Os estados vão para a mensagem errada | Pareie por message ID, não por ordem de chegada |
| Callback lento | O provedor repete; aparecem duplicados | Responda rápido, processe depois, use uma chave de idempotência |
| Falta de idempotência | Uma retentativa de rede cria duas mensagens | Carregue uma referência do cliente e deduplique por ela |
| Desvio de codificação | Uma mensagem longa chega em pedaços ou com caracteres errados | Defina GSM-7 ou UCS-2 de propósito e teste a contagem de segmentos |

As correções são operacionais. Nenhum transporte as elimina.

## Escolher e integrar

Escolha SMPP quando o fluxo de envio é sustentado, o provedor aloca uma janela que você consegue dimensionar e a equipe sabe operar uma sessão: gestão de binds, keep-alive, reconexão e logs no nível de PDU. Escolha HTTP quando o volume é moderado, a equipe já opera endpoints web seguros e um callback encaixa na arquitetura. Escolha os dois quando o envio e a entrada têm donos diferentes.
Seja qual for a escolha, peça a mesma evidência: uma rota de teste, a alocação de taxa, o formato do recibo, a lista de códigos de erro e a política de retentativa. A [explicação de SMPP](/pt/resources/learn/what-is-smpp/) cobre a sessão, e o [guia de conexão](/pt/resources/guides/smpp-http-connection/) cobre o caminho até produção.
Escreva a escolha com números: taxa de pico, janela por bind, timeout do callback e orçamento de retentativas. Uma decisão sem esses números é uma preferência. Revise quando o pico ou a equipe mudar.

### Check what you learned

**Uma campanha roda a 40 mensagens por segundo de forma constante e os recibos precisam chegar pela mesma sessão transceiver. Qual transporte encaixa?**

SMPP com um bind transceiver, binds suficientes e uma janela dimensionada para a taxa. O HTTP pode levar o volume, mas os recibos chegam a um callback, não pela sessão SMPP.

**O endpoint de callback leva oito segundos para responder. O que dá errado?**

O provedor expira o tempo e repete, então o mesmo evento é entregue de novo. Responda rápido e processe depois da resposta.

**Por que um bind silencioso é mais difícil que um bind caído?**

Um bind caído falha de forma visível. Um bind silencioso parece aberto, então o cliente continua enviando até um timeout expor. O keep-alive encontra antes.

## FAQ

**Podemos usar os dois?**

Sim. Muitas plataformas enviam por SMPP e recebem callbacks por HTTP durante a migração.

**Qual é mais rápido de integrar?**

HTTP, normalmente em uma tarde; SMPP compensa quando o volume justifica uma sessão persistente.

**Qual é mais confiável?**

Nenhum é confiável sozinho. A confiabilidade vem da rota, da política de retentativa e das operações em volta.

**O HTTP aguenta volume alto?**

Sim, com concorrência, pool de conexões e callbacks assíncronos. O SMPP costuma ser mais eficiente para um fluxo sustentado, porque a sessão e o canal de recibos já estão abertos.

**Precisamos de IP fixo?**

Muitas vezes sim para SMPP, porque o provedor libera o IP do cliente. Integrações HTTP costumam usar TLS e uma chave. Confirme o requisito antes de construir.

## Sources

- [smpp.org: sessões SMPP, operações PDU e recibos de entrega](https://smpp.org/) — Accessed: 2026-10-19
- [IETF RFC 9110: semântica do HTTP](https://datatracker.ietf.org/doc/html/rfc9110) — Accessed: 2026-10-19
- [3GPP TS 23.040: realização técnica do serviço de mensagens curtas](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19

Updated: 2026-10-19